LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to advance automatically to a different event structure (one case triggers another)

Hi there,

 

I am new to Event structures and I am trying to figure out how to programmatically advance to a different even once one has been triggered.  The case I want triggered is where the data is graphed and updated on the front panel which happens frequently during the use of the program.  The event case I want to trigger it is just at the beginning where the data is read in.  Right now the data is read in when the read file button is depressed and I can't figure out how to get to the case where the data is conditioned and graphed.  I think there must be a solution that doesn't require copying all that code into the read file case?  I am trying to figure out how to use these event structures to their full benefit!

 

Thanks for your wisdom!

 

Jenn.

0 Kudos
Message 1 of 14
(1,384 Views)

You could use a user event:

 

https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/creating_user_events/

 

Then have both the event cases that should use the shared code both call the same user event, which will then trigger the follow-up event.

 

There's alternate solutions as well.  For instance, you could wrap your event handler inside of a state machine, and while most events would point right back at the "Wait for events" state, certain ones would go to other states with this sort of common code in it.

 

Or, if the case you're referring to is a "Value change" event for a control, you can create a property node for the control in question, and write to the "Value (Signaling)" property.

0 Kudos
Message 2 of 14
(1,378 Views)

Create a Boolean indicator for your Event and use the Value(Signaling) Property Node to trigger that event when ever you want to run it.

 

evCapture.PNG

In the picture above the Measure? Val(Sgnl) Property Node make it run the same case over and over again but it could just as easily be Val(Sgnl) for any of the other Event cases.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 3 of 14
(1,341 Views)

I typically do all recalculations &indicator updates in the timeout case. Keep the timeout in a shift register and set it to -1 (infinite) in all events that don't need recalculations (incl. In the timeout event, of course!). Leave it unwired in all events that require updating.

Message 4 of 14
(1,328 Views)

I would suggest looking into the JKI State Machine. This is my opinion here, but event structures should not do too much inside their events; they should just respond to events.

 

The JKI State Machine combines an event structure and state machine. For your case each different event could go to the same series of states, no code duplication needed.

mcduff

 

 

Message 5 of 14
(1,284 Views)

Handling events by generating them (either value signaling and\or user events) is convenient.

 

It can go wrong though. You don't have any control of the ordering of the event stack. You can delete events, but if things get more complex, this might not scale up well.

 

I do use this all the time, but sometimes you simply need more control.

 


@PA_UW wrote:

 The case I want triggered is where the data is graphed and updated on the front panel which happens frequently during the use of the program. 


If you do need more control, the solution is pretty simple.

 

Put "where the data is graphed and updated on the front panel" in a subVI, and call that when needed.

 

For me that subVI would live in a  class. On init, the class would get all references to the FP objects, and I'd put everything that is related to the group of objects in that class. In this case, there would be a graph class.

 

You'd have Graph.lvclass:Update.vi, and simply call it when you want the graph updated.

 

You can mix the methods. Use VIs to make the graph do things, and\or put code in event cases and trigger them.

Message 6 of 14
(1,212 Views)

wiebe@CARYA wrote:

Handling events by generating them (either value signaling and\or user events) is convenient.

 

It can go wrong though. You don't have any control of the ordering of the event stack. You can delete events, but if things get more complex, this might not scale up well.

 


You actually can get this level of control, but it's probably more complicated than most are willing to even contemplate.

I've made recursive event structures to guarantee order of execution and branching within a single event loop. It involves a lot of "register for Events" and swapping out of Event registration refnums, but it works nicely. Not that I'd recommend it as a starting point, but it can help with legacy code and race conditions.

 

edit: It also requires having everything implemented as user events. Which is something I prefer anyway.

0 Kudos
Message 7 of 14
(1,182 Views)

@Intaris wrote:

wiebe@CARYA wrote:

Handling events by generating them (either value signaling and\or user events) is convenient.

 

It can go wrong though. You don't have any control of the ordering of the event stack. You can delete events, but if things get more complex, this might not scale up well.


You actually can get this level of control, but it's probably more complicated than most are willing to even contemplate.

I've made recursive event structures to guarantee order of execution and branching within a single event loop. It involves a lot of "register for Events" and swapping out of Event registration refnums, but it works nicely. Not that I'd recommend it as a starting point, but it can help with legacy code and race conditions.

 

edit: It also requires having everything implemented as user events. Which is something I prefer anyway.


Do you mean dynamic events?

 

If you're just using user events, then, yes, you can make it deterministic.

 

If you're mixing them with user actions it can get complicated. If case A triggers B that triggers C, nothing prevents D from being triggered in between by the user.

 

0 Kudos
Message 8 of 14
(1,174 Views)

@mcduff wrote:

I would suggest looking into the JKI State Machine. This is my opinion here, but event structures should not do too much inside their events; they should just respond to events.


I'll echo mcduff's warning here. When you configure the event there is a little checkbox for "lock front panel until event is handled". If someone else is using your software and the screen locks up on them, they might click the button 10 more times and then tell you your software doesn't work. If you're the only using it, this might not be an issue.

 

Also, when you inevitably make changes, it's going to be easier if the bulk of your code is in a state machine. Right now, maybe state (event) 1 always goes to state (event) 2. But later you might need to add state 1.5. Doing it once will be no problem, but doing this many times will be easier if you're using the (JKI) state machine.

0 Kudos
Message 9 of 14
(1,151 Views)

Thank-you so much for you advice - I will check out the JKI State machine.  Sounds very useful.

0 Kudos
Message 10 of 14
(1,100 Views)