04-16-2021 04:37 PM
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.
04-16-2021 04:48 PM
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.
04-16-2021 05:30 PM
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.
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.
04-16-2021 06:27 PM
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.
04-17-2021 07:52 AM
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
04-19-2021 03:24 AM
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.
04-19-2021 08:42 AM - edited 04-19-2021 08:43 AM
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.
04-19-2021 09:31 AM
@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.
04-19-2021 12:34 PM
@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.
04-20-2021 10:51 AM
Thank-you so much for you advice - I will check out the JKI State machine. Sounds very useful.