LabVIEW
Best practice to pass control around the main vi
Since we are graphical programmers, an actual VI would show your concepts much better that long wordy paragraphs. Some fantastic LabVIEW programmers are even dyslexic to some degree.
@EdoardoA wrote:
Or by doing so I'm using a lot of memory passing the whole data continuously around with a shift register instead of placing local variables here and there when I need to use the value associated to a control?
I am sensing that you seem to have some misconception about shift registers.
They operate "in place" and nothing is ever "passed around", so they are the most efficient way to keep data. (Of course if they contain arrays and their size change, some memory allocations need to be made occasionally, but only as needed).
Local variables and value properties require additional data copies in memory. In addition value property nodes must execute synchronously for significantly more overhead (thread switch, etc.).
@EdoardoA wrote:
. For instance inside the event structure I use the "new value" to update the cluster since I use all the controls outside the main while loop to create the cluster.
If you have all controls outside the toplevel loop to initialize the shift register data, you now need either N event frames or an event frame that needs to figure out what actually changed, so you just shift the complications elsewhere. Reading even 100 scalar controls is trivial, and it might be easier to just have an event for all and bundle them hack if any of them changes. Maybe you could have events for a few logical subsets of the controls. Depending on the front panel design, you could even contain all controls inside a cluster right there. (The container can even be made transparent).
@EdoardoA wrote:I saw the way Ben initialize the main vi in this thread but using references: is it a better way?
It is not clear what you mean by "initialize". If you want the program to start with a set of typical control values, make these the default. This guarantees that all are as expected once you built an executable. During development (only!), you have the problem that controls could have been changed at edit time and are thus not predictable. There is a method to initialize all to default that can do it in one swoop. If you need to programmatically change control values at runtime, local variables are most efficient (But don't forget to update the cluster element too. Or you could write to a signaling property to fire the event that updates the cluster if used sparingly). You don't need to worry about initializing indicators, because the VI can be set to "clear indicators when called". This is useful if certain indicators are not in the dataflow early.
Sometimes, all initial control values are read form an ini file that can change between applications, and there are tools for that.
I would recommend to attach a simple code skeleton (Maybe 10 controls) and shows us exactly what you are doing for a much clearer picture. Save it for LabVIEW 2020 or below. This will give us opportunities for more detailed comments.
Understood. I'll be on the road for most of the weekend. Might have time to look at it tomorrow.
Don't modify the tables via front panel references, you have all the data in your main cluster, just send that (the table, not the full cluster) to your table-vi and then update the indicator via the output.
Also the Steps in Exp1 should hide the From To Steps-label and have it as a table heading (just copy the text outside the list and then hide the labels in the list)
Otherwise it looks like a decent start!
