Storing Information within VIs

[Norbert_B]

No, the Execution Buffer is never emptied. It is read/written when accessing the terminal of the control/indicator during runtime.

And please try not to compare LV with C. It is like comparing apples with oranges.....

Norbert

[rthorpe]

Norbert,

So, what you're saying essentially is that when I say "on the front panel" I'm wrong because the front panel isn't necessarily loaded. But, the execution buffer is always there and never emptied.

"When a VI is loaded into memory the execution buffer is loaded with the front-panel default values, even if the VI isn't visible. Using the execution buffer LabVIEW retains the values set by the last use of the VI."

Would that be correct?

[Norbert_B]

Yes, but i still would point out: If the values are changed (e.g. by a property node), those changes are not saved in the VI, so the change is "volatile". (hair splitting you know 😉 ).

To be exact, using property nodes load the front panel into memory (transfer buffer and operate buffer), but it will not be shown...

Norbert

[Yamaeda]

"Even if I put A, B & C within a larger cluster I still have to write to all of them whenever a SubVI is called. The larger cluster follows that same rules as the smaller one, it must be written as a block when it's wired into a connector pane."

If you send the existing cluster to Bundle by name it'll keep its values and only update those you select.

So, get Master cluster from a VI, change a value of a cluster or an array (or something) and write back the Master cluster to the AE.

/Y 

[Ben · Accepted solution]

The Shift Register (SR) inside an AE (Action Engine) acts like a static local in C.

The value in it persist from call to call.

The data type of the SR does not have to be the same as the data type on the Icon connector.

Quick example:

I want to stor config info for DAQ and Serial widgets. The config for both are read at start-up. Both DAQ and serial want their config at other times.

Create an AE with a cluster consisting of two other clusters, one for DAQ and one for serial in the SR.

Init - Acepts a path and read the config info and fills out the cluster in the SR, done.

Get DAQ - Method does an unbunlde by name from the SR data and pushes the value to an indicator on the Icon connector.

Get Serial - Similar to DAQ but use the serial config.

So the data will be ut in the SR durring init and read when DAQ and Serail need the data.

The data is encapsulated in the AE and (read that AE Nugget) is protected against potetial race conditions.

Ben

[rthorpe]

Yamaeda,

I see what you mean. My problem is that the higher level VI shouldn't know about most of the stuff in the clusters.  Even if I use a cluster of clusters then the higher level VI has to know about it.

One of my colleagues uses a similiar sort of approach. She copies cluster constants from the lower-level VIs into the upper level VIs for each run with a new configuration.  That solves the problem, but it's messy and difficult to use.

[rthorpe]

Ben,

I think your Action Engine looks like the best approach, though it's going to take me a long time to rewrite everything.

[Ben]

---

@rthorpe wrote:

Ben,

I think your Action Engine looks like the best approach, though it's going to take me a long time to rewrite everything.

---

maybe but if you take the advise that Jim Kring posted in that thread about creating a wrapper for each method your code will much easier to maintain and understand.

If you post images of your AE as you are developing we can offer hints to make it better before you run into any other gotchas.

Take Care,

Ben