Hey Guys, I am Dwight Reid an electrical engineer and lecturer at the University of Technology (also IEEE member and branch counselor) in Jamaica. Some months ago I had started working on a block diagram editor for python that I dream one day will become a reasonable alternative to Matlab Simulink. I want to put a special emphasis on automatic code generation (ACG) and so far I have done ACG for python Scipy and also for the arduino, these are however just an implementation of some basic functions. 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 think it would definitely get more people using python since it is much easier to program graphically and it would be very useful to scientific computing. I imagine a better, moretailored graphic editor with predefined blocks that you can pull out like simulink or scilab xcos (maybe a stripped down libre office draw), implementing this is beyond my current skill level so it goes slowly. I hope I'm clear enough, let me know what you think. Dwight
Dear Dwight, Have a look at Enthought BlockCanvas ( http://code.enthought.com/projects/block_canvas/ and https://github.com/enthought/blockcanvas) Cheers, Eraldo On Tue, Nov 20, 2012 at 7:01 PM, dwight reid <dreid@dwightreid.com> wrote:
Hey Guys,
I am Dwight Reid an electrical engineer and lecturer at the University of Technology (also IEEE member and branch counselor) in Jamaica. Some months ago I had started working on a block diagram editor for python that I dream one day will become a reasonable alternative to Matlab Simulink. I want to put a special emphasis on automatic code generation (ACG) and so far I have done ACG for python Scipy and also for the arduino, these are however just an implementation of some basic functions.
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 think it would definitely get more people using python since it is much easier to program graphically and it would be very useful to scientific computing. I imagine a better, moretailored graphic editor with predefined blocks that you can pull out like simulink or scilab xcos (maybe a stripped down libre office draw), implementing this is beyond my current skill level so it goes slowly.
I hope I'm clear enough, let me know what you think.
Dwight _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
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!" Kindest regards, Tim
On Tue, Nov 20, 2012 at 11:41 AM, Cera, Tim <tim@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
Charles R Harris wrote:
On Tue, Nov 20, 2012 at 11:41 AM, Cera, Tim <tim@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
On Wed, Nov 21, 2012 at 8:01 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Charles R Harris wrote:
On Tue, Nov 20, 2012 at 11:41 AM, Cera, Tim <tim@cerazone.net> wrote:
As is, the block diagram editing is done in libre office draw and you
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
have 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
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. Cheers, Eraldo On Wed, Nov 21, 2012 at 4:48 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Wed, Nov 21, 2012 at 8:01 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Charles R Harris wrote:
On Tue, Nov 20, 2012 at 11:41 AM, Cera, Tim <tim@cerazone.net> wrote:
As is, the block diagram editing is done in libre office draw and you
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
because of reasons described in the old saying, "To hell with
have partially 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@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
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@gmail.com> wrote:
On Wed, Nov 21, 2012 at 8:01 AM, Neal Becker <ndbecker2@gmail.com> wrote: Charles R Harris wrote:
On Tue, Nov 20, 2012 at 11:41 AM, Cera, Tim <tim@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@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
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. DR ________________________________ From: Matthias BUSSONNIER <bussonniermatthias@gmail.com> To: SciPy Developers List <scipy-dev@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@gmail.com> wrote:
On Wed, Nov 21, 2012 at 8:01 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Charles R Harris wrote:
On Tue, Nov 20, 2012 at 11:41 AM, Cera, Tim <tim@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@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________
SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
2012/11/21 dwight reid <dreid@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@gmail.com> *To:* SciPy Developers List <scipy-dev@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@gmail.com> wrote:
On Wed, Nov 21, 2012 at 8:01 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Charles R Harris wrote:
On Tue, Nov 20, 2012 at 11:41 AM, Cera, Tim <tim@cerazone.net> wrote:
As is, the block diagram editing is done in libre office draw and you
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
have 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@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi, I think a block diagram editor would be a great addition to the Python scientific ecosystem. I've had this in mind for some years now, but never put it seriously on my programming agenda. Now, I would really make the difference between : 1) a block diagram editor ("Simulink/xcos/Modelica-like") which, as Chuck said, is really a tool to describe a dynamical system (either a physical system or a control system). 2) a visual programming environment, like Labview, which has many flaws that Matthias forcefully described ;-) Now, to come back closer to what Dwight presented, I think that using the GUI from an existing Office suite won't lead far enough. I've experienced a bit GUI programming on the closely related matter of a schematic editor (schematics of electrical circuits : see http://www.youtube.com/watch?v=HYv-6w8FCf4&feature=player_detailpage#t=39s). This GUI is done in Python+Qt (PyQt or PySide as a matter of licensing taste) with the key element being a QGraphicsView (http://qt-project.org/doc/qt-4.8/graphicsview.html) which handles the display of the schematic. I've really had a positive feeling with this graphical framework from Qt. (However, I didn't practice with many others to allow for a fair comparison). Also, these years have seen the growing popularity of browser-based editors (like https://www.circuitlab.com/) so that it may be worth studying javascript/HTML5 frameworks (which I unfortunately never did). Best, Pierre
Guys, I agree with Pierre that the GUI from an existing Office suite won't lead far enough, which is where I need the help actually (with the GUI programming). I was hoping to maybe strip down Libre office draw and then tailor it to suit this application but from what I've seen so far it may be easier to build from scratch. Currently I am just parsing the .odf file, which is essentially XML. This proves relatively easy and I was hoping to continue with this file format for the GUI. If anyone knows of a minimal drawing program (open sourced of course) that can produce the .odf file or a similar format I would try to use it, also if there are any suggestions regarding a file format or general approach that would be welcomed. Scilab Xcos looked like they were trying code generation for some micro-controllers but they seem to have stopped, does anyone have any experience using it for code generation? For openModelica I would need to be pointed in the direction of using it for code generation, I haven't looked extensively but so far I can't see how to generate code with it. ________________________________ From: Pierre Haessig <pierre.haessig@crans.org> To: SciPy Developers List <scipy-dev@scipy.org> Sent: Thursday, November 22, 2012 4:17 AM Subject: Re: [SciPy-Dev] Python Scipy Block Diagram Editor with ACG Hi, I think a block diagram editor would be a great addition to the Python scientific ecosystem. I've had this in mind for some years now, but never put it seriously on my programming agenda. Now, I would really make the difference between : 1) a block diagram editor ("Simulink/xcos/Modelica-like") which, as Chuck said, is really a tool to describe a dynamical system (either a physical system or a control system). 2) a visual programming environment, like Labview, which has many flaws that Matthias forcefully described ;-) Now, to come back closer to what Dwight presented, I think that using the GUI from an existing Office suite won't lead far enough. I've experienced a bit GUI programming on the closely related matter of a schematic editor (schematics of electrical circuits : see http://www.youtube.com/watch?v=HYv-6w8FCf4&feature=player_detailpage#t=39s). This GUI is done in Python+Qt (PyQt or PySide as a matter of licensing taste) with the key element being a QGraphicsView (http://qt-project.org/doc/qt-4.8/graphicsview.html) which handles the display of the schematic. I've really had a positive feeling with this graphical framework from Qt. (However, I didn't practice with many others to allow for a fair comparison). Also, these years have seen the growing popularity of browser-based editors (like https://www.circuitlab.com/) so that it may be worth studying javascript/HTML5 frameworks (which I unfortunately never did). Best, Pierre _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
The PySimulator paper might be relevant - they tied into Modelica and have a plugin based GUI [1]. [1] http://elib.dlr.de/77223/1/ecp12076523_PfeifferHellererHartwegOtter.pdf On 23 November 2012 06:09, dwight reid <dreid@dwightreid.com> wrote:
Guys,
I agree with Pierre that the GUI from an existing Office suite won't lead far enough, which is where I need the help actually (with the GUI programming). I was hoping to maybe strip down Libre office draw and then tailor it to suit this application but from what I've seen so far it may be easier to build from scratch. Currently I am just parsing the .odf file, which is essentially XML. This proves relatively easy and I was hoping to continue with this file format for the GUI. If anyone knows of a minimal drawing program (open sourced of course) that can produce the .odf file or a similar format I would try to use it, also if there are any suggestions regarding a file format or general approach that would be welcomed.
Scilab Xcos looked like they were trying code generation for some micro-controllers but they seem to have stopped, does anyone have any experience using it for code generation?
For openModelica I would need to be pointed in the direction of using it for code generation, I haven't looked extensively but so far I can't see how to generate code with it.
------------------------------ *From:* Pierre Haessig <pierre.haessig@crans.org>
*To:* SciPy Developers List <scipy-dev@scipy.org> *Sent:* Thursday, November 22, 2012 4:17 AM
*Subject:* Re: [SciPy-Dev] Python Scipy Block Diagram Editor with ACG
Hi,
I think a block diagram editor would be a great addition to the Python scientific ecosystem. I've had this in mind for some years now, but never put it seriously on my programming agenda.
Now, I would really make the difference between : 1) a block diagram editor ("Simulink/xcos/Modelica-like") which, as Chuck said, is really a tool to describe a dynamical system (either a physical system or a control system). 2) a visual programming environment, like Labview, which has many flaws that Matthias forcefully described ;-)
Now, to come back closer to what Dwight presented, I think that using the GUI from an existing Office suite won't lead far enough. I've experienced a bit GUI programming on the closely related matter of a schematic editor (schematics of electrical circuits : see http://www.youtube.com/watch?v=HYv-6w8FCf4&feature=player_detailpage#t=39s ). This GUI is done in Python+Qt (PyQt or PySide as a matter of licensing taste) with the key element being a QGraphicsView (http://qt-project.org/doc/qt-4.8/graphicsview.html) which handles the display of the schematic. I've really had a positive feeling with this graphical framework from Qt. (However, I didn't practice with many others to allow for a fair comparison). Also, these years have seen the growing popularity of browser-based editors (like https://www.circuitlab.com/) so that it may be worth studying javascript/HTML5 frameworks (which I unfortunately never did).
Best, Pierre
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Le 25/11/2012 04:29, Brian Thorne a écrit :
The PySimulator paper might be relevant - they tied into Modelica and have a plugin based GUI [1].
[1] http://elib.dlr.de/77223/1/ecp12076523_PfeifferHellererHartwegOtter.pdf This new project is pretty exciting ! Thanks for sharing.
However, though it is said to be open source, I didn't find any code on https://code.google.com/p/pysimulator/ which seems to be the project homepage. I only trace fresh development news on http://www.vworker.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBid... which is a development method I'm not familiar with. Best, Pierre
It seems they have put their code on https://code.google.com/p/pysimulator/as a download but haven't put it under source control. Cheers, Brian On 26 November 2012 09:11, Pierre Haessig <pierre.haessig@crans.org> wrote:
Le 25/11/2012 04:29, Brian Thorne a écrit :
The PySimulator paper might be relevant - they tied into Modelica and have a plugin based GUI [1].
[1] http://elib.dlr.de/77223/1/ecp12076523_PfeifferHellererHartwegOtter.pdf
This new project is pretty exciting ! Thanks for sharing.
However, though it is said to be open source, I didn't find any code on https://code.google.com/p/pysimulator/ which seems to be the project homepage. I only trace fresh development news on http://www.vworker.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?lngBid... is a development method I'm not familiar with.
Best, Pierre
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
participants (9)
-
Benny Malengier -
Brian Thorne -
Cera, Tim -
Charles R Harris -
dwight reid -
Eraldo Pomponi -
Matthias BUSSONNIER -
Neal Becker -
Pierre Haessig