LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I programmatically create and use a global variable?

I understand the concept of the action engine, especially the way it is used in the example shown previously.  I would like to find out what others think of this idea...  Instead of creating an array, how about just creating a cluster that is loaded one time at the beginning and only "read" every time after that. 

 

In my instance, I do not need to change any variables in the cluster throughout the code, just use as reference (i.e.. paths, addresses, etc.).  The action engine can have values added dynamically, but in my case, I know all the variables that will be needed throughout the code upfront.  Although, I do have a way of changing the values, but I won't get into that.

 

I think this is much better than passing a cluster from VI to VI and case to case inside my state machine and I think it uses a significantly less amount of memory, right!?  The other advantage of this is you can open the VI and see the values in your cluster at any given time, much like a global page.

 

This is a very simplified example, but you'll get the point.

 

Global.JPG

0 Kudos
Message 21 of 27
(2,687 Views)

Trouble wrote:

I understand the concept of the action engine, especially the way it is used in the example shown previously.  I would like to find out what others think of this idea...  Instead of creating an array, how about just creating a cluster that is loaded one time at the beginning and only "read" every time after that. 

 

In my instance, I do not need to change any variables in the cluster throughout the code, just use as reference (i.e.. paths, addresses, etc.).  The action engine can have values added dynamically, but in my case, I know all the variables that will be needed throughout the code upfront.  Although, I do have a way of changing the values, but I won't get into that.

 

I think this is much better than passing a cluster from VI to VI and case to case inside my state machine and I think it uses a significantly less amount of memory, right!?  The other advantage of this is you can open the VI and see the values in your cluster at any given time, much like a global page.

 

This is a very simplified example, but you'll get the point.

 

Global.JPG


"I think you've got it!" (My Fair Lady)

 

Try taking a look at that Nuget I linked early in this thread. It should give you some more ideas on this topic.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 22 of 27
(2,683 Views)

Trouble said, in regards to his action engine....

 


Trouble wrote:

I think this is much better than passing a cluster from VI to VI and case to case inside my state machine...


Well, depends... If you can pass the cluster from VI to VI by using a wire, then you should use a wire.

As far as going from case to case inside a state machine, I don't see why you'd use an action engine other than wow factor, sense the state machine will accommodate a shift register and wire.

 

 

Richard






0 Kudos
Message 23 of 27
(2,673 Views)

Okay, I agree with the case to case, but in the instance of VI to VI, I have nearly 1000 VIs.  If I put that cluster in each one, which it has to be in there twice (in and out), and that cluster has about 50+ values, (BTW - it is a typedef incase it needs changed) say bye-bye to the memory. 🙂

 

 

0 Kudos
Message 24 of 27
(2,669 Views)

Broken Arrow wrote:

Trouble said, in regards to his action engine....

 


Trouble wrote:

I think this is much better than passing a cluster from VI to VI and case to case inside my state machine...


Well, depends... If you can pass the cluster from VI to VI by using a wire, then you should use a wire.

As far as going from case to case inside a state machine, I don't see why you'd use an action engine other than wow factor, sense the state machine will accommodate a shift register and wire.

 

 


This code with some explaiantion may help illustrate

 

Dynamic_Event.JPG

 

The VI I am showing you is a sub-VI that handles all of the work involved while collectiong data. It is only concerned with a sub-set of all of the controls and indicators on the top level GUI. So I needed a method to let this sub-VI get at all of the FP objects. That was handled by an Action Engine that holds all of my control refs along with some other functionality.

 

 

The VI that looks like it is labeled "GUI Cnt Get Refs" is a wrapper around an action engine that holds about 100-200 control references for controls on the FP of the top level VI. The Action used in that wrapper is "Get Refs" and returns a cluster that lets me choose via an unbundle by name. In the code above you can see that I am registering events for a handful of the objects that will be used while I am in collection mode. So this Action Engine lets me get at the GUI objects by choosing the right name from the cluster.

 

Hold it I'm not done!

 

THe VI just to the right that looks like it is labeled "GUI Cnt Collect" is yet another wrapper around the same Action Engine but it invokes a method "Set Collection Mode" that goes through all of the control refs on the FP of the top level GUI and hides shows, re-lables everything to make the GUI look like it is in Collection mode.

 

So using Action Engines (in wrappers) to store values or references that are not used in every case gives me the following benefits

 

1) I can get any any FP object from anywhere in my app.

2) Keeps my code cleaner such that only the data associated with the sub-VI is stored in a SR.

3) Let me encapsulate the pile of Fp property nodes

4) Clearly enunciate what FP objects I am working with

 

As always, just trying to help,

 

Ben

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 25 of 27
(2,659 Views)

Ben,

In your enumerated list, I see #2 as being a huge advantage, and an inspiration.  Granted, your ap is fairly large (going by the number of FPterms) and, by being so, inspires such inventiveness. I guess my point was more so for a standard, simple state machine. And the poster's cluster was very simple. I'd use a wire for that.

 

 

Richard






Message 26 of 27
(2,614 Views)

Broken Arrow wrote:

Ben,

In your enumerated list, I see #2 as being a huge advantage, and an inspiration.  Granted, your ap is fairly large (going by the number of FPterms) and, by being so, inspires such inventiveness. I guess my point was more so for a standard, simple state machine. And the poster's cluster was very simple. I'd use a wire for that.

 

 


Occam's Razor in action!

 

Yes Sir!

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 27 of 27
(2,610 Views)