Basic Data flow explanation and documentation

[NIDave]

I'm trying to teach LabVIEW to a few others here at work and am having trouble convincing them to use data flow and not just manipulate the data everywhere with 5,000 property nodes.  It seems the property nodes to write values are out of hand and debugging and upkeep of the code will be a mission.  I need some authoritative source that explains this and the benefits of following the data flow model rather than just doing what you please.  I'd appreciate it if anyone can point me to a link or something that explains the drawbacks because it seems my word is not convincing enough.  Thanks for the help converting everyone to LabVIEW.

-Dave

[Bob_Y.]

NIDave,

The best answer that I can think of is to have everyone read and follow the suggestions in the book A Software Engineering Approach to LabVIEW (by Conway and Watts from Prentice Hall PTR).  It should be available from Amazon and the like.  It is an extremely well written book that covers the basics of software engineering and a very good way to apply it with LabVIEW.  It will reinforce the dataflow paradigm and show why it makes so much sense to use.

Hope that this helps,
Bob Young

[NIDave]

Thanks for the suggestion Bob, I really appreciate it.

The reviews are a little shaky though, has anyone else read this book, and if so whats your opinion?

Thanks,

Dave

[tst]

You could try the memory management white paper and the style guide (chapter 6 of the dev guidelines paper), both of which can be found in the bookshelf. They don't have any explicit orders no to do this (as a matter of fact, the style guide says to use the fewest bends you can), but you can probably find something.

Also, creating a demo application with a race condition (but one that isn't particularly easy to catch, maybe a state machine with a couple of other loops where it will be hard to know where you are exactly) might help to show them why wires are good. If you have any large application where you can show them that this will make a mess, it will also probably be a good demonstration. You could actually try to give them a finished application and challenge them to change it into using property nodes and then to make modifications.

[johnsold]

Dave,

I have read the book, use what it contains regularly, and keep it on my desk. The later printings apparently had some print quality problems with the graphics, but that does not reduce the value of the ideas.

Lynn

[Travis_M. · Accepted solution]

Hello all,

Dataflow-style programming is the heart of LabVIEW!  Asking why you would use dataflow in LabVIEW is like asking you would use OOP in Java.  In addition to the resources cited above, the biggest gains from dataflow programming come from debugging and performance. 

From a debugging standpoint, LabVIEW code is graphical with ‘wires’ connecting nodes of code.  If you break the connectivity of the nodes (via global/local variables and property nodes) you are making the code much more difficult to follow for yourself and other users.  This may not come up when learning LabVIEW with small programs, but when larger programs are involved it gets complicated quick!

From a performance standpoint, each variable and property node operation must take place in the UI thread.  Since a lot can happen in this single thread you are going to RAPIDLY diminish performance.  Check out the attached example for a demonstration.

Hope this very brief synopsis helps!  Feel free to check out all the documentation online or to consult with the books.  Also the LabVIEW Intermediate course addresses this in a little more detail.  I encourage all who are going to be programming in LabVIEW to register for these courses.

Please let us know if you have any questions, and have a great afternoon!

[NIDave]

Travis, that example is great, that will reinforce my point.  Im stuck in a situation where Im trying to teach Labview to two older programmers who don't really understand the benefits of dataflow and don't really want to take it from me.  Also, I have my books from the intermediate course, I may have to bring those into work too for backup. 

Currenty, I'm writing the engine that will sequence and run all our hardware and scripts and they wanted to get involved and help on some of the Sub-VIs which is great but as I found when I recieved the first one its going to make alot more work trying to debug it.   Hopefully this example will help me fully convince them to do it the right way and thereby make my engine more effective and my job a little easier. 

Thanks again!

[Otman]

to add to Travis' good explanation,

it's easy to see the great advantage of just connecting wires from, say vi1 to vi2. anyone who doesn't follow this paradigm, in my opinion, should not be programming in labview.

[Travis_M.]

Glad it helps!  Another reason to avoid property nodes is they force the Front Panel of the VI to remain in memory (even when it's a sub-VI that doesnt need to display), which can end up causing more copies of data to be generated (thus slowing performance).  Also any access of a global/local variable automatically results in a copy of data.  If they are C(++) programmers the result is similar to passing all data by value.  With dataflow the LabVIEW compiler has a better idea of the order of execution so it can determine when/if coppies need to be made.

Everybody learns in different ways so the approach you take to teaching can hopefully benefit from these examples, documentation, and of course your personal expertise!

-Have a great weekend everybody-