LabVIEW
Front panel design and efficiency
Solved!
I think you are confusing the front panel and the diagram. The main problem is your block diagram, i.e. the "code".
This is programmed like text based code, with local variables acting as variables and sequence frames acting as line breaks. This is the opposite of how LabVIEW is supposed to work. First you break all data dependencies due to overuse of local varaibles, then you need to re-establish correct execution order using sequence structures. Local varables force extra data copies in memory and all these sequences force sequenctial execution where order does not always matter and where thinghs could be done in parallel. You are severly limiting compiler optimizations.
I would recommend that you look into state machines architecture. None of your local varaibles are needed.
Check out this link here.
The main thing is:
"LabVIEW follows a dataflow model for running VIs. A block diagram node executes when it receives all required inputs. When a node executes, it produces output data and passes the data to the next node in the dataflow path. The movement of data through the nodes determines the execution order of the VIs and functions on the block diagram."
The easiest way to string up sub-vis is to use the error cluster controls and indicators to force dependencies - the output of the error cluster indicator on one sub-vi goes into the error cluster control of the next sub-vi, enforcing execution order. For instance, by simply adding them to the MOTOR with BACKLASH FINAL.vi (and hooking them up properly inside the VI), then connecting the error cluster wire into and out of it, you can get rid of that sequence structure frame.
Seems that you're meaning to ask about your "Block-diagram" (which has all your program logic), not the Front Panel (which has all those fields to enter values or to read them). I'm basing that on the fact that both of your concerns are related to a block-diagram, not a front panel. Most default LabVIEW front panel items do not affect the performance of LabVIEW applications but how you design block-diagrams have direct effect on everything.
Using local variables all over the map could very possibly cause "race-conditions" where the outcome would be unexpected and difficult to debug. Best way to "store values" in LabVIEW would be to use wires, they also prevent race-conditions (use clusters to keep number of wires to minimum, that way your design is easy to work with.) State-machines are one of the best/high-performance design structures, with that your entire program could be made into a very efficient program within a small block diagram area. I have converted a small portion of your design into a state-machine based design (you could use what I have attached to learn and expand to include rest of your design). Start on a small scale by converting little items and testing to ensure your functionality remains the same. You can use more than one clusters (I prefer to use clusters within a main "local variable cluster" to keep things clean- so that only one wire runs through states). That is also how you would convert your whole design into State Machines (enum-based are best for performance as well as to prevent user-errors). If you're not familiar with Enums, you can read help. Hopefully this explains what I mean by use "wires" to store values rather than local variables. Not only that it is more efficient (when compiled), but also very readable/maintainable.
You can also use a "while loop" instead of "for loop" in attached VI, and implement the logic to stop the loop when your required feature is done.
-BTC
My bad - I didn't mean anything complicated, I was simply meaning to say that I like to keep one main cluster that contains all variables and then to further organize items, I like to use clusters within that main cluster (take a look at attached image which shows one input and one output cluster within main cluster). To give you a specific example, you have three sections on your Front Panel - "Image parameters, Motor Configuration, and ADC-FIFO Configuration" - if that's how you intend to modularize your design, I would make one cluster for each of those sections and then I would put all three clusters inside the main cluster. This is very helpful in modularized designs to keep things organized and to keep a track of which functionality you are using from which section of the code. This way you can readily tell which parameter is from which part of your code - "easily readable".
I hope that helps, good luck.
(One tip: Always keep your design simple and organized, because it produces best robust results and takes the least amount of time to test/debug.)
-DP
BatchTest Corp.
NI Alliance Partner
Well, the way you have done is not a state-machine design as you have simply used a stacked structure to sequentially perform each functionality within a loop - so that sequence will keep happening until you hit stop button. Plus you are "sort of" using a cluster wire as a local variable, but your design keeps reinitializing the wire in every loop - that's actually not an efficient way of programming things. Instead, you can convert your stacked structure into a case structure, and only execute first frame once at the beginning of your application ("Initialize" state in attached vi.) That will create a much more efficient design. Simply putting a stacked sequence in a while loop doesn't make it a state-machine based design.
Look at how I changed your code into a state-machine design (including enum usage which show each case as a name you can define in enum definition - LabVIEW compiler takes care of replacing them with numerics according to representation you specify). Both vi have same the functionality, but my state machine based design goes through about 38 million iterations in 5 seconds on my computer - whereas your design goes through merely 1 million iterations in the same time period. (However, this much higher performance is also due to the fact that I do not call those popup messages functionality in every loop whereas you do). Run both of the attached vi's on your computer and you'll see what I mean.
In commercial business, performance is everything and we like highly optimized LabVIEW applications (especially since a very large portion of our business is in LabVIEW RT/Embedded, every microsecond counts), but perhaps that is not such an important factor in your field (I'm assuming that you're in Research/Academic) as your top priority is probably to put together a simple implementation and get things running quickly. I made my VI in about 15 minutes, but it will probably take you a bit longer in the beginning until you gain experience. You really should look up examples and take some NI LabVIEW courses for further help.
State-machine based designs can be made very simple yet very powerful.
-DP
BatchTest Corp.
NI Alliance Partner
