LabVIEW
SubVIs and code efficiency
Solved!
Hi GPC,
it seems you're new to Labview:
Some rules:
- Best way to move data is to use wires. LabView uses dataflow...
- Style guide: block diagram should not exceed the screen size...
- globals create datacopies, property nodes create datacopies and require a thread-switch...
- when putting subvi connector terminals outside any structure LabView is able to minimze mem usage...
Gerd already covered most points.
Typically, you pass data to subVIs via the connector pane.
GPC wrote:I would like to know what is better (when thinking about program velocity), to make a huge VI or a lot of subvis distributed in many levels.
With todays computers, you should not worry about performance, but focus on a modular program design that is easy to debug. You should not make one gigantic flat diagram, because you'll spend days debugging it for a possible saving of a few nanoseconds in execution time. Correctly programmed, you will never even get near 100% CPU usage in normal operations, except for short bursts.
Many of my older (quite fancy!) programs were first developed on a 100MHz Pentium with 64 MB od RAM and they run just fine back then. Today, the computers are orders of magnitude more powerful.
If your think that performance is insufficient, look for better algorithms but don't sacrifice modular program design. Compared to everything else, the subVI calling overhead is negligible. Don't worry about it.
If you have very specific performance problems, please post your VIs and we have a look.
GPC wrote:I have to read and write on 20 indicators lots of times. Sometimes this updates are triggered by the user, sometimes are triggered by the slave loop and some of them are done on each loop interaction of the main while loop of my application.
As my program is really modular and the updates are done on different parts of the software. I thought it would be a good idea to created a cluster with all the references from my indicators and I wire it on all the vis so I would have access to the controls and indicators of my main front panel all the time.
NO!!!!
Don't use controls/indicators as a primary means of data storage. Accessing them via references and value property nodes is extremely inefficient because each read or write forces synchronous execution. This method is several orders of magnitude slower than better alternatives.
You probably want to keep all your data for example in an action engine subVI where you can read and write an nearly any speed and order because it does not involve the UI. The main program can asynchronously read from it and update the relevant indicators at a leisurely pace, e.g. 10x/second. That's all you need for a smooth display to the observer.
