From Friday, January 17th 11 PM CDT (January 18th 5 AM UTC) through Saturday, January 18th 11:30 AM CDT (January 18th 5:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
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.
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.
"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
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.
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
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
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.
