Best practice to pass control around the main vi

[EdoardoA]

I'd like to go deeper in this conversation:

---

@altenbach  ha scritto: 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.).

For the reason mentioned by you (that I have also read in several posts in the forum) I am trying to avoid both of them whenever it is possible. However, if I need to update a control in the front panel, what can be a good alternative to a local variable?

I found this post which gives a lot of good alternatives. but which one would be still ideal? The set control values by index 

approach works well, but is it better compared to the easy and clean format of the local variable? especially because my controls are not so heavy, just clusters of numbers or similar..

---

@altenbach  ha scritto: 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).

On this point, I agree that the best solution would be placing the control directly inside the event structure. In this case, how can I initialize the big cluster with all the control values? Using local variables or property nodes once in the very beginning (replacing the controls as shown in the VI I shared previously?)?

---

@altenbach  ha scritto: 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.

This is related to the previous comment. By initialize, I refer to the act of retrieving all the control values from an .ini file indeed, and then building a big cluster of control values to send in a while loop and run it with shift register and an event structure that can update values depending on the user interaction with the program. At this point my question is how to build this cluster if I want to keep all the controls in the event structure?

Best,

E

[Yamaeda]

---

@EdoardoA wrote:

This is related to the previous comment. By initialize, I refer to the act of retrieving all the control values from an .ini file indeed, and then building a big cluster of control values to send in a while loop and run it with shift register and an event structure that can update values depending on the user interaction with the program. At this point my question is how to build this cluster if I want to keep all the controls in the event structure?

Best,

E

---

1 type def. (or better one type def for each cluster and have one 'super cluster' that uses the others) 🙂

[EdoardoA]

Thank you for the reply but I don't fully understand what you mean even if that is probably what I am looking for:

If I make my control as type def. (some are already) don't I have still the same problem? since the number of control terminals are the same, and if I use the to initialize the big cluster I can't use them again for the event structure... 

Can you please share an example or modify my previously shared one?

Thank you for helping.

E

[altenbach]

---

@EdoardoA wrote:

 However, if I need to update a control in the front panel, what can be a good alternative to a local variable?

---

The primary use of a control is as a data source operated by the user. In the rare cases it needs to be modified programmatically (e.g. during initialization) a local variable is probably the best option. Nothing wrong with that!

If your controls are nicely corralled in a few clusters, the code can be very simple.

I assume only a small subset of controls needs to be initialized from an ini file and that happens only once. There is no reason to worry about performance. You never need to worry about indicators, latch action booleans, and any control that has a permanent reasonable default.

[LVNinja]

I'm not sure if it helps you but I played with your cluster and save it's content into a binary csv file using a function converting Anything into a string, using the Cluster reference. One example is to use something similar to read the content of your cluster and update your shift register on the "Init" stage of the state machine. Then, if you want it updated, save it at the instance the cluster is changed.  

Create a simple txt file to use it together, the forum rules don't let me attach the file. 

[EdoardoA]

Dear LVNinja,

This is something that I am already doing in a slightly different way: I just save and reload all the values in the front panel after saving them in a .txt file and then I initialize the shift register with the control terminals. However, this prevents me from using them inside the event structure ...would it be a quick solution to use the local variables to initialize the shift register and leave the control terminals inside the event structure? Because I am using the new val option to update the shift register, but this means that I would need to create many events, one for each control and it might become tricky to retrieve the value from the variant value that I get when merging different control type in the same event... 

[Yamaeda]

---

@EdoardoA wrote:

Dear LVNinja,

This is something that I am already doing in a slightly different way: I just save and reload all the values in the front panel after saving them in a .txt file and then I initialize the shift register with the control terminals. However, this prevents me from using them inside the event structure ...would it be a quick solution to use the local variables to initialize the shift register and leave the control terminals inside the event structure? Because I am using the new val option to update the shift register, but this means that I would need to create many events, one for each control and it might become tricky to retrieve the value from the variant value that I get when merging different control type in the same event... 

---

Yes, you will probably need a bunch of events. You can however place them at Cluster level if you've organized your controls as such.

It's probably best to not mix data types in an event even if can be done and handled.

[JÞB]

---

@Yamaeda wrote:

---

@EdoardoA wrote:

Dear LVNinja,

This is something that I am already doing in a slightly different way: I just save and reload all the values in the front panel after saving them in a .txt file and then I initialize the shift register with the control terminals. However, this prevents me from using them inside the event structure ...would it be a quick solution to use the local variables to initialize the shift register and leave the control terminals inside the event structure? Because I am using the new val option to update the shift register, but this means that I would need to create many events, one for each control and it might become tricky to retrieve the value from the variant value that I get when merging different control type in the same event... 

---

Yes, you will probably need a bunch of events. You can however place them at Cluster level if you've organized your controls as such.

It's probably best to not mix data types in an event even if can be done and handled.

---

SUPER LabVIEW Ninja tip: You could use datalogging for those control values.  A lot easier than txt files.  A little known LabVIEW feature.   Like Kudos.  Check the LabVIEW Help file for details - I haven't seen it used in over a decade.

[Yamaeda]

SUPER LabVIEW Ninja tip: You could use datalogging for those control values.  A lot easier than txt files.  A little known LabVIEW feature.   Like Kudos.  Check the LabVIEW Help file for details - I haven't seen it used in over a decade.

---

Cool! Can you programmatically retrieve them as easily?

[EdoardoA]

I usually load and save control in this way! (Here a "skeleton" version)

Best,

E