[SciPy-Dev] Python Scipy Block Diagram Editor with ACG

Thu Nov 22 03:59:27 EST 2012

2012/11/21 dwight reid <dreid at dwightreid.com>

> Guys,
> I think graphical programming is more appreciated by people who are not
> traditional programmers but who have to use programming as a tool to get a
> bigger job done. A common example is control system development, like for
> an aircraft. Simulink got popular because it allows the designer to model
> the dynamics of the system with generic blocks, simulate that system and
> then design and tweak a controller to work with the system. So it allows
> simulating the system the way you would do a circuit in a good spice
> simulator and with code generation you can then implement your final
> controller with the click of a button (somewhat).
>
> Its a powerful tool and obviously engineers love it. The block diagram
> seems to make it easier to understand what the program is doing and we must
> note that most new designs start as block diagrams anyway.
>
> As we know there are good ways and bad ways of doing things, a text based
> code can be just as impossible to debug if it is not documented properly as
> a complicated block diagram.
>

About all this, I'm no expert, but is Modelica not the way to go here?
http://en.wikipedia.org/wiki/Modelica

That does code generation, and uses ode/dae solvers to solve the resulting
equations. There have been open source attempts at a visual part:
http://www.euclides.dia.uned.es/Interactive/
https://www.modelica.org/Different-views-of-Modelica

I am sure they would welcome contribution of extra parts

There are two competing open source implementatins (JModelica,
openmodelica), and they use sundials ode solver or others to solve it.
They have python bridges that allow use of scipy:
https://openmodelica.org/index.php/home/tools/212 and
http://www.jmodelica.org/page/69

It has been mentioned many times on this list already that the current ode
solvers in scipy are _not_ state of the art. Several python wrappers of the
vastly improved sundials solvers are available on the internet (one partly
by me, scikit odes, no release, use trunk).

So, although better ode/dae solvers should be part of scipy in my view, the
block diagram approach is better aligned with the modelica approach I
believe.

Benny

>
> DR
>
>
>   ------------------------------
> *From:* Matthias BUSSONNIER <bussonniermatthias at gmail.com>
> *To:* SciPy Developers List <scipy-dev at scipy.org>
> *Sent:* Wednesday, November 21, 2012 1:43 PM
> *Subject:* Re: [SciPy-Dev] Python Scipy Block Diagram Editor with ACG
>
> Hi list,
>
> Le 21 nov. 2012 à 17:21, Eraldo Pomponi a écrit :
>
> AFAIK the best example of visual programming/interaction is LabView (
> http://www.ni.com/labview/).
> I agree that many scientist don't like it but it is really widely adopted
> not just for control theory and application.
> It was also the subject of a "Patent Litigation" between MatWorks
> (Simulink) and NI (
> http://www.ni.com/pdf/products/us/patent_litigation_faq.pdf)......
> Ni won!
> I think that it shows pretty much cleanly that complex projects can be
> managed completely graphically if  the environment is enough mature for
> that.
> LabView seems to meet that requirement. Of course it is NOT open. This is
> why I do not use it.
>
>
>
> It is not because something is widely adopted that it is well used, and
> does its job.
> In this case it does not prove that Labview allow to managed correctly
> things,
> at best that people achieve to (sort of) work with that.
>
> To be working in a lab that does use labview and to be forced to use it,
> one of the main reason lab view is used it because it comes with drivers
> for instrument,
> and support that goes with it.
>
> The others being:
>   *  it is already use by others nearby scientist.
>   *  scientist think do not know how to program,
>   *  they need a visual interface fast
>   * The lab have already paid for the license you better have to use it.
>
>
> We use labview for are optical tweezer and microscope control, which is a
> pretty big piece of software in labview.
> The code exist for years, when I arrived each files had a v0.1,
> v0.1.1….v0.9-bis, first file was 4 year old.
> The working copy was the v0.8-smth. The way labview is made we have to
> copy and past things all around,
> have global variable, it is not unit tested.
> We all know theses are good programming practice BTW.
>
> For versioning system .vi files are binary blob (800 kb diff to just move
> a wire so that it avoid a text label ??? )
> So no way to know what modification have been made except trusting the
> commit message.
>
> I had to throw away 2 month of data / 2 month of lab view coding because
> one commit was introducing a bug,
> and there was no way to remove just the effect of this commit.
>
> I suppose most of these problem could be fixed in some non trivial way,
> but they are not in labview.
>
> As a Scientist and a Programmer IMHO the project is not managed in any
> way.
> And I don't see how one can really manage a project in labview.
>
> A good managed project should be easily
>   * shared,
>   * explained
>   * reusable by other (other can be me in 3 years),
>
> And right now, no labview project I know of have survived their creator /
> been modified by others.
> Which is really scary in an era of reproducible science.
>
> The others things that concern me is the inability to search for help.
>
> Question/anwser are made of **screenshot**.
> You don't even know what the boxes are and what they do, they don't have
> name.
> You don't know in which submenu to get them.
> Boxes can have several representation.
> Sometime boxes change appearance when you change an option in it !
>
> Inability to search for help is also due to that fact that as things don't
> have name,
> you can't search for it, and everyone is reinventing its naming.
>
> All that and other make me think that labview is not good for complex
> project.
>
> I hope those are issues that can be solved by people that are trying to do
> the same,
> but some of those are IMHO inherent to the graphical paradigm used.
> Rapidly, crossing wires are unavoidable in 2d space for example.
>
> As a bonus, that also highlight another problem.
> Try to guess what this simplified snippet does
> http://imgur.com/PEgeq,n47uH#1
> http://imgur.com/PEgeq,n47uH#0 (condition of the if statement set to true)
>
> It also allow people that does not know labview to understand what it
> looks like.
>
> Solution in  rot13 :
> Vg gel gb perngr svyr jvgu tvira anzr, vs fhpu n svyr rkvfg vg vaperzragf
> gur anzr ...
> Qvq fbzrobql frr gur raq bs gur sbe ybbc ng gur obggbz bs gur fperrafubg ?
>
> TL;DR:
>   I think Labview Sucks, I hope other FlowPrograming will find a way to
> correct It, I wish them Luck.
>
> --
> Matthias
>
>
>
>
> Cheers,
> Eraldo
>
>
>
>
> On Wed, Nov 21, 2012 at 4:48 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>
>
> On Wed, Nov 21, 2012 at 8:01 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
>
> Charles R Harris wrote:
>
> > On Tue, Nov 20, 2012 at 11:41 AM, Cera, Tim <tim at cerazone.net> wrote:
> >
> >>
> >> As is, the block diagram editing is done in libre office draw and you
> have
> >>> to manually type in the functions and commands, I have
> >>> attached an example exported to pdf.
> >>
> >>
> >>
> >> Would anyone be willing to help with this, I have no experience
> developing
> >>> with the open source community.
> >>>
> >>
> >> I won't be able to help, except to give some information.  Found this
> >> http://wiki.python.org/moin/FlowBasedProgramming a long time ago which
> >> might be useful.  Some of the links are broken now, and some of the
> others
> >> are really old, but something there might be helpful.
> >>
> >> In general, flow based programming hasn't caught on.   I think partially
> >> because of reasons described in the old saying, "To hell with
> tradition, we
> >> are going to do it like we always did!"
> >>
> >>
> > Simulink is pretty widely used, especially for modelling and rapid
> > development of control software.  Equipment vendors provide blocks for
> > their devices, gyroscopes and such, that can be used for the models and
> > then Matlab will generate control code to run on the targeted system.
> > Simulink itself is basically a way of setting up a big system of DEs, but
> > what really makes it go are the vendor blocks and code generation.
> >
> > Chuck
>
> So why would vlsi guys use text (e.g., verilog) to design a cpu, instead of
> schematics?
>
> 1. IMO, graphical representations work nicely for low-complexity, but not
> productive for highly complex systems
>
> 2. It is less productive to manipulate a graphical  representation
>
> 3. text can be manipulated by all your favorite tools, more open
> ecosystem, no
> lockin, proprietary formats
>
>
> I'm not saying it's the best way, just that Simulink is widely used and is
> part of a mature ecosystem. FPGA design software, say Xilinx ISE, does have
> a visual front end, generally in tabular form. In that regard it is rather
> like gui design tools where objects can be opened and their attributes set.
> I think the thing that makes all of those tools go is code generation, the
> ability run simulations, and to insert probes that display values in
> graphical form as the simulation progresses. IIRC, Simulink can also be
> used to drive hardware for breadboarding designs.
>
> Chuck
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20121122/d057314b/attachment.html>