LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Crash course in Event Structures


DFGray wrote:

 

I must partially disagree with my esteemed colleague on this one. 


I must thank you for regarding me so highly.  I consider that quite an honor coming from someone such as yourself.

 

I think Ben did an excellent job discussing some of the thoughts I had in mind as to the problems that could occur by having an event structure in a piece of code that is not always guaranteed to execute.  That it would be collecting events even while the case is not in the line of execution.  By the time the case would execute again, the events that have queued up might be stale, that the event might no longer have any meaning in the current state of the program.  Even if you go about just discarding the event at that point, it would be hard to distinguish between the old, stale, meaningless events, and any newer, valid events that may need to be processed.

 

Also, let's say you have queued a handful of events such as different button presses over a period of time and the case becomes active again, it is very possible that handling that event or other happenings in the code cause the state of the state machine to change again and only one event gets handled.  The other queued up events would remain in the queue for a while longer.

 

Not that having an event structure inside a case structure can't work, but it would add a level of complication that I think most users of LabVIEW couldn't event anticipate.  I'm sure you would know about it and be able to work around it.  But hearing that someone as experienced as Ben ran into problems, causes me to shy away from doing something like that.

 

I think I would tend to do what you had suggested where the event structure is separate.  Depending on the event and the current state of the overall state machine of the program, it would execute what needed to be done within the event case if peeking at the state showed it was valid (such as enabling/disabling controls, anthing that could be done in no more than a few seconds), discard the event if peeking at the state showed it should be an invalid action, or queue up the event into one or more queues as necessary to be sent off to whatever parallel consumer loops need to know about the event to be able to handle the event  asynchronously.  And if it is a critical event (such as shut down any data processing, flush the queue, and stop the consumer loop to shutdown everything), I would even place it at the front of the queue so the consumer loop handles it next in case there is still a long queue still to be processed in that loop.

0 Kudos
Message 11 of 34
(1,389 Views)

I actually found that the synchronous task handler with embedded event structure gives me more predictable behavior than putting an asynchronous task handler in another loop.  I tried (and shipped) both when the event structure first appeared in LabVIEW 6.1, but the asynchronous pattern caused me a lot more grief than the synchronous, so I do not use the asynchronous pattern much any more.

 

I am not a fan of multiple event structures in the same VI.  I understand that if you use dynamically registered events or different events in each one that it can work.  However, it adds a layer of complexity I have never needed.  For the different operating states example Ben suggested, I prefer to put case statements with cases for each state in either the event or the handling code.  I realize this can run to a lot of case statements (I have had code with near 100 events registered).  However, it also does not need dynamic event allocation or event flushing mechanisms.

 

Most of this boils down to programming preferences, as well.  All of the patterns we have discussed are valid, working, methods.  It really depends on what you are comfortable with.  We all have our preferred patterns. Smiley Tongue

Message 12 of 34
(1,368 Views)

Wow - page 13, i found this on!  Anyway, i have aother question now.  🙂

 

I have some controls being updated by local variables at the moment.  I also have some event structure events which execute when the values of some of these controls change.  How can i get these events to only execute when the control values are changed manually and not when they're changed by the local variables?



Never say "Oops." Always say "Ah, interesting!"

0 Kudos
Message 13 of 34
(1,333 Views)

Prorperty >>> Value will not trigger an event

 

Property >>> Value (signalling) will trigger an event.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 14 of 34
(1,329 Views)

So's that mean I should be using a 'value' property node instead of a local variable?

 

Sorry if it seems simple - my brains not working too well today! Smiley Sad



Never say "Oops." Always say "Ah, interesting!"

0 Kudos
Message 15 of 34
(1,327 Views)

James Mamakos wrote:

Wow - page 13, i found this on!  Anyway, i have aother question now.  🙂

 

I have some controls being updated by local variables at the moment.  I also have some event structure events which execute when the values of some of these controls change.  How can i get these events to only execute when the control values are changed manually and not when they're changed by the local variables?


I'm known as the "anti-Local" guy of the forum...  😉

 

Since you are using Event Structures, within a While Loop (note that I have not seen your code, just reading this thread), and using (can use?) shift registers, then you do not need Local Variables.  Using an Event Structure will only execute when the event setting (usually value change upon releasing a button) is detected (occurs).  

 

I have not seen what the code is supposed to do when the operator triggers an event (ie: push/release a button).  One solution is to use Event Structures with either a Queue (data) or Token which typically causes a State Machine within another loop to proceed with whatever actions need to occur as per the event.

 

Hope I didn't confuse you too much 😉

My brain is still trying to adapt to lack of sleep and a little bit of jet-lag..  without the use of cafeine... 😮

 

R

Message 16 of 34
(1,322 Views)

I've got my shift registers all wired up too, don't worry. 😉

 

The controls i'm talking about are numeric controls which can be changed either manually or programatically.  I want their value (on the FP) to update every time they're changed, but for the event structure to only execute when the user types a new value or uses the little arrows to the side of the control to increase or decrease the value.  I do not want it to execute if the value has been updated programatically because of something happening elsewhere in the code (for example being updated by a local variable, or property node).

Message Edited by James Mamakos on 05-13-2009 06:26 PM


Never say "Oops." Always say "Ah, interesting!"

0 Kudos
Message 17 of 34
(1,319 Views)

James Mamakos wrote:

So's that mean I should be using a 'value' property node instead of a local variable?


Don't make assumptions about things that are not written down! 😄 (Ben did not mention local variables!).

  1. Change via local variable: does not trigger a value change event
  2. Change via value property node: does not trigger a value change event
  3. Change via a signaling value property node: will trigger a value change event (unconditionally, even if the old and new values are the same!)

If you don't want to trigger an event, you have a choice between 1&2 and 1 (local variable) is strongly preferred in most cases.

Message 18 of 34
(1,303 Views)

btw: I like the title of this thread.

 

Is a crash course in programming similar to the blowout sale at the tire center? 😄

Message 19 of 34
(1,286 Views)
RAY , I lost your email , what is it again ? could you please send me a reply to any of my emails !! Thank you
LV 8.2
0 Kudos
Message 20 of 34
(1,248 Views)