LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

triggering events from a list or ENUM Constant (Type Def)

Solved!
Go to solution

I have a list of commands that the user builds on the front panel, enum constant, that is fed into a For Loop.  Each command in the list executes specific tasks, I have a task where the code needs to wait until a trigger event occurs.  This requires the For Loop to pause until the trigger occurs. 

 

I'm thinking this should be possible with an Event structure but I am unsure how to set up the events from the command list?

 

Typically what I've done in the past with events is to use user inputs like button pushes as events.

0 Kudos
Message 1 of 6
(1,851 Views)
Solution
Accepted by topic author coolhandLV7

@coolhandLV7 wrote:

I have a task where the code needs to wait until a trigger event occurs.


What is this trigger event?  It might sound more complex, but you might want to look into using a State Machine.  You can have a state that just increments when action you are performing.  But then you have states looking for specific events, performing specific actions, etc.  This reason I'm saying this is you might need to make sure you can abort while waiting for the trigger or any other action.  If you set up your states appropriately and allow for repeating states instead of being stuck in them, a proper state machine can handle this.


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 6
(1,831 Views)

Yes, i think you're right.  I use State Machines a lot, the reason for the Event structure is that they are very clean and simple to setup.  I agree with you though that the SM is probably the answer.  Was hoping there was an event method to save me from going through all of the logic required for a SM.

0 Kudos
Message 3 of 6
(1,814 Views)

The logic will be the same whether you use an event structure or a state machine, right?  i mean, instead of "going through all the logic" to create the state machine, you would be "going through all the logic" of setting up an event-based application instead, which will turn out to be basically the same thing.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 6
(1,798 Views)

My experience is that events are just cleaner, you drop the event structure put the code you want in it, assign the event trigger and move on.  The state machine will have the same code (logic), but will have decision aspects to help it navigate correctly with shift registers and potentially polling of multiple inputs both user and system.  It's the same functionally but the logic is more involved.

 

For example, motion control...in manual mode I run all event structures...go here: do this type of stuff, in any order.  If an E-stop is tripped do that process...etc.  Auto mode in my case needs an external trigger from a robot, so i need to wait on that, state-machine will do it.  However if an E-stop is hit, or the user makes a process change the code will need to take all of those situations into account, thus much more logic for different situations.

 

Would be neat if you could tie an event to an IO point or any output.  If the process threw a specific error or an output reached a certain/specific value to trigger an event, that would be useful...  I'm no expert with LabVIEW, simply learning, so maybe there is a way I'm just not familiar with it.

 

 

0 Kudos
Message 5 of 6
(1,787 Views)

@coolhandLV7 wrote:

My experience is that events are just cleaner, you drop the event structure put the code you want in it, assign the event trigger and move on.  The state machine will have the same code (logic), but will have decision aspects to help it navigate correctly with shift registers and potentially polling of multiple inputs both user and system.  It's the same functionally but the logic is more involved.

 

For example, motion control...in manual mode I run all event structures...go here: do this type of stuff, in any order.  If an E-stop is tripped do that process...etc.  Auto mode in my case needs an external trigger from a robot, so i need to wait on that, state-machine will do it.  However if an E-stop is hit, or the user makes a process change the code will need to take all of those situations into account, thus much more logic for different situations.

 

Would be neat if you could tie an event to an IO point or any output.  If the process threw a specific error or an output reached a certain/specific value to trigger an event, that would be useful...  I'm no expert with LabVIEW, simply learning, so maybe there is a way I'm just not familiar with it.

 

 


I would be careful with putting code in an event structure. Remember, everything inside that event must execute before the next event can execute. The event structure is an awesome tool, but it does have its limitations. I generally prefer to use a queued state machine architecture. In my event I send the messages to the state machine. This frees up the event structure to do what it was designed to do - handle the user interface. With that being said there are times where a User Defined event is useful. It wouldn't take much code to create a user event to handle each of the events that you want to capture.

0 Kudos
Message 6 of 6
(1,778 Views)