LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Improving Action Engine

Solved!
Go to solution

I am new to the use of action engines in my code and am hoping to learn and improve my use of action engines. The first one I have created is to control a set of relays which will open and close air-operated valves using the NI 9474. I was hoping that I could get some general feedback on DOs and DONTs with this action engine and that it will help me with future creation of AEs for my code. What should I be doind differently from an efficiency standpoint, etc?

 

Thanks.

 

I have attached the VI.

 

Valves_AE.png

0 Kudos
Message 1 of 11
(4,365 Views)

Just from the picture, I would say your biggest issue is that you should have the Init case create the DAQmx Task, initialize the digital outputs, and then store the task reference in a shift register.  Then you only need the list of channels at the initialization and you are not constantly creating and destroying a reference to the same IO.

 

And you should also have all of your outputs on the outside of the case structure.  There is a thread floating around called "Clear As Mud" that goes throught specifics of why.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 11
(4,362 Views)

Would you then create a case to destroy the reference that you call upon ending the execution of your main vi?

0 Kudos
Message 3 of 11
(4,346 Views)

Yes, If you are going to have an AE handle this functionality then you should have it handle the functionality for all possible use cases. Especially as it seems from your picture that you at no stage pass a reference to any of this out of the AE.

0 Kudos
Message 4 of 11
(4,329 Views)

This might be a tad off topic...

 

Considering the size of this AE would you consider moving over to a class?  You'd be able to keep this functionality and really reduce your visual complexity.  Not an option for everyone, but might be something worth looking into.

0 Kudos
Message 5 of 11
(4,326 Views)

@rkmadse wrote:

Would you then create a case to destroy the reference that you call upon ending the execution of your main vi?


Yes, but also consider making two Action Engines, one to handle the Hardware (Valves), with three Actions:  Init (which takes Channels In, configures the Channels, and starts DAQmx), Set Valves (which takes an Array of Booleans and does the DAQmx Write), and Close (which stops and clears the Task).  Note that the Task constant created by Init should be carried on a Shift Register in this Action Engine for use in Set Valves and Close, and should be set to a Null Task when Close exits.  This will "error out" if you try to Set Valve before Init, or after Close (which is, I presume, "desired behavior").

 

The other Action Engine only manipulates the Valves.  I'm a little confused why you have both an Enum (to control a single valve at a time) and an Array of (Valve) Booleans -- I'd think about which (single) method you want to use and stick with it.  Let's consider an Action Engine that handles the "Valve as Enum", i.e. you specify a single Valve as your input.  Here is a possible Action Engine for you (all having Valve # (your Enum) as the Input, and the Array of Valves as the Output):

  • Init --first call, initializes Valve Array to All Off.
  • All Off -- ignores Valve #, clears all Valves.
  • All On
  • Valve On --turns Valve # on, leaving remaining Valves unchanged.
  • Valve Off -- turns Valve # off, leaving remaining Valves unchanged.

You might notice that Init is the same as All Off -- the reason to put it there is to remind you when you Init the Hardware, you should follow up by Init-ing the Valves.

 

Now put these two together in some top-level code.  A typical sequence might be Init (H), Init (V), Set Valves.  What do you do if you want, say, to turn both Valves 3 and 5 on at the same time?  You call Valve On (3), Valve On (5), Set Valves.  Note that you are separating the enumeration of which valve(s) to turn on or off from the actual operation of the DAQ Hardware.

 

Another thing to note is that the Hardware Action Engine returns Valves Out, the actual State of the Valves.  if you wire this in your Top-Level program to an 8-element Array of Boolean Indicators (which often look like Green LEDs), you will have a visual indicator of which Valves are On (and Off).

 

Bob Schor

Message 6 of 11
(4,319 Views)

So Bob, I have taken your advise and set it up with two separate AE's. Is this what you were talking about basically?

 

Initializing in the Main Producer

AE_Being_Used.png

 

Event Case if a User manually changes Valve State

Valve_Being_Used.png

 

Event Case if User Wants to set All Valves

All_Valves_being_used.png

 

Don't critique the use of everything else, the main VI is still in the works.

 

Download All
0 Kudos
Message 7 of 11
(4,303 Views)

Largely.  I would get rid of the U8 quantities and stick with an 8-element Array of Boolean (initialized using Initialize Array in the Init action of Valve Control.  Valve Control should have no Valve Hardware VIs inside it.  Note that if you are dealing with arrays, and if Valve to Control is basically an index into the array, setting Valve On corresponds to setting that index element to True, i.e. it becomes a Replace Array Subset (element).

 

The missing "Third Element" is the routine that puts it all together.  When the Top Level routine starts, it calls Init for the Valve Control, calls Init for the Hardware, and calls Set Valve (to turn all the valves off).  The Valve Array should be carried in a Shift Register in both Action Engines.  However, the Hardware AE should ignore Valves In unless it was Set Valves (in contrast, Valves Out should always be wired).  

 

Bob Schor

Message 8 of 11
(4,289 Views)
Solution
Accepted by rkmadse

Bob,

I am not seeing the point of making 2 AEs, especially since you should not be calling the hardware's "set" case from the main VI.  And you are duplicating effort by having both hold the DIO state (and the Valve AE could have "old" data if the HW AE was called).  So what is wrong with just having all of the functionality in a single AE?  It makes the API A LOT simpler.  So the states I see are:

  • Initialize: setup the hardware task and clear all of the valves
  • Set Valve: turn on a single designated valve
  • Clear Valve: turn off a single designated valve
  • Set All: turn on all valves
  • Clear All: turn off all valves
  • Close: turn off all valves and stop/clear the task

GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 9 of 11
(4,258 Views)

Yep, that works for me, too.

 

BS

0 Kudos
Message 10 of 11
(4,190 Views)