topic Re: Crash course in Event Structures in LabVIEW

Crash course in Event Structures

J.Mamakos — Thu, 30 Apr 2009 12:49:38 GMT

I have several VIs which just sit in While Loops during their 'idle' state. This allows data to be preserved in the shift registers, but means that I have several controls and indicators that are being read and written to in every iteration with a couple of VIs being called up each time too. I've had someone suggest I use Event Structures to only do something when a FP object has a state/data change. I've considered this myself too, but have had no prior experience with them (nor have any of my collegues) and the LabVIEW 6.1 help section on them is not particularly enlightening.

I was wondering if anyone would be willing to give me a crash course in how, when and why to use Event Structures, and perhaps include a bit of example code so i can see them in operation. If you haven't got lv6.1 then pictures will be fine (as long as you don't use something i can't). I'm happy to copy things out if necessary

I hope someone (anyone) will be able to give me a hand here since I have rather limited time available to learn their use. It may turn out that they're not the best way of executing my code, but I still need to be able to use them if possible!

Thank you in advance.

James

Message Edited by James Mamakos on 04-30-2009 07:49 AM

Re: Crash course in Event Structures

Ben — Thu, 30 Apr 2009 13:20:31 GMT

From what I saw in the other thread, yes you are right an event structure can help you.

The tag "LabVIEW_Event" has some good threads to review.

This one goes into the working of the events structure and its subtlties.

Ben

BTW: No I am not following you around. You are just asking good question and seem to want to learn LV.

Re: Crash course in Event Structures

J.Mamakos — Thu, 30 Apr 2009 18:28:20 GMT

Thank you - there's a lot to read there, but I'm working my way through it! I'll get back to you once i run out of reading material!

I'm only 19 (just), and I'm on a working gap-year before going to uni in october. I've been given a project to achieve using LabVIEW - most of out computers run on lv6.1 with a couple on lv8.5 - I think we even have an ancient machine running lv5... it can't handle anything more than that! I've been working on it for about 4 months now, and my only prior programming knowledge came from a tiny bit of QBasic during my electronics A level. I have to admit, I'm enjoying myself probably way too much with LabVIEW and I keep finding out how to do something else and then going off on a tangent - not too good for productivity, but i do stumble upon some useful tricks! Pretty much everything I've learnt so far has been through experimentation -by far the best way to learn!

P.S. I don't mind you following me - just so long as you keep answering my questions!

Re: Crash course in Event Structures

DFGray — Fri, 01 May 2009 12:55:00 GMT

Here is a quick tutorial on basic design you may find useful. It includes an event structure and a mechanism for data storage. The data storage mechanism is a bit dated. I would recommend action engines or single-element queues for current development (and you can use those in LabVIEW 6.1), but the basics are similar. Unfortunately, the code is LabVIEW 7.0. If you can't get time on the newer versions of LabVIEW, let me know and I will install 7.0 and save to 6.1 for you.

Re: Crash course in Event Structures

J.Mamakos — Fri, 01 May 2009 13:19:10 GMT

I'm afraid we run LabVIEW 8.5, 6.1, and 5.0. I am not allowed on the computers with tthe more advanced version, so i am stuck with 6.1. Would you (or anyone else) be able to convert this down one more level please?

Thank you for the additional help.

Re: Crash course in Event Structures

DFGray — Mon, 04 May 2009 14:20:05 GMT

Here it is in 6.1. I do not have 6.1 installed, so was unable to check it. All the VIs should be there, but linking may be a bit flaky. Relink and save on first load and you should be OK. Let me know if you run into problems.

Re: Crash course in Event Structures

J.Mamakos — Tue, 05 May 2009 17:10:33 GMT

Thank you for all this material. I've a question about part of one of the VIs. In the first image, you can see the event structure when the "exit" boolean has been pressed. Why is there an empty false case here if the "exit" control must be true for the VI to even get as far as the case statement?

On a more general note, I've been reading about and playing with event structures, and I'm beginning to get to grips with them. However, what is the advantage of having an event structure with several events over having a case structure with several cases (and an empty default case if no control has changed)? The second image shows one such case statement (case for no action is displayed). The third shows a case statement that executes on one of many controls (false case is blank), and also shows another version of that shown in the second image (case statement for this is inside the sub VI).

Whereas only one event structure is recommended (and advised) per VI, you can have several case statements working in parallel. How can one customise an event structure to match the apparent speed of multiple parallel case statements?

And about queues... Can you have more than one queue per VI, and what else (other than event structures) can use them? What is their advantage over multiple separate controls? Do they limit parallelism and/or speed?

As an aside, what (if any) is the operational difference between wiring a false constant to the 'continue if true' terminal of a while loop and wiring a true constant to the 'stop if true'?

I apologise for all these questions (some of which must seem rather obvious). I have and am scanning help sections and forum entries etc, but I'm not quite finding answers to everything. All replies are greatly appreciated.

Re: Crash course in Event Structures

RavensFan — Wed, 06 May 2009 03:27:09 GMT

James Mamakos wrote:
Thank you for all this material. I've a question about part of one of the VIs. In the first image, you can see the event structure when the "exit" boolean has been pressed. Why is there an empty false case here if the "exit" control must be true for the VI to even get as far as the case statement?

I don't see any valid explanation for having the Exit Case structure inside the Exit Button event. If you were dealing with a button that had perhaps a switch action, where you had the possible of a value change to True, or a value change to False, then a case structure inside the event would make sense. One other thing tha doesn't make sense in that image is that if it is an Exit event, what causes the while loop to stop?

That image shows what I would consider a bad practice, having an event structure inside a case structure. The event structure would be there capturing and queuing up events even if that case of the outer case structure never runs. That may be unlikely to happen, but as a general rule, putting event structures inside case structures may lead to unpredictable behavior of the code.

On a more general note, I've been reading about and playing with event structures, and I'm beginning to get to grips with them. However, what is the advantage of having an event structure with several events over having a case structure with several cases (and an empty default case if no control has changed)? The second image shows one such case statement (case for no action is displayed). The third shows a case statement that executes on one of many controls (false case is blank), and also shows another version of that shown in the second image (case statement for this is inside the sub VI).

An event structure could have one or more event cases. An event case could be fired for one or more different events (such as value change on multiple controls, or mouse events, or panel close events ...) An event structure could have a timeout event. Case structures are similar, you could have a default case that executes if nothing matches. Multiple cases, or even combinational cases where a case could run in the event such as an integer is 1, 2, 4, 8..10 So you can usually come up with code that has parallels between an event structure and a case structure. There isn't any particular advantage of one setup vs. another beyond the advantages of using an event structure to eliminate polling of controls or wire values.

Whereas only one event structure is recommended (and advised) per VI, you can have several case statements working in parallel. How can one customise an event structure to match the apparent speed of multiple parallel case statements?

You can have multiple event structures, but there usually isn't a reason to. If you do, it is best to minimize the number, try to have any particular event only occur in one (though this isn't absolutely necessary). Having multiple event structures, or common events between structures adds extra complication to code that could lead to unpredictable behavior of your VI if you aren't careful. Event structures are usually intended to just handle user interface requirements and thus only one is usually necessary. If you need to do something where it is best to have parallel loops, then you want your event structure to handle the event quickly, then pass off any processing to one or more parallel loops by way of notifiers or queues.

And about queues... Can you have more than one queue per VI, and what else (other than event structures) can use them? Yes. Anything can use queues. What is their advantage over multiple separate controls? I'm not clear on what you are asking. Do they limit parallelism and/or speed? No. They generally help with parallelism or increasing speed.

As an aside, what (if any) is the operational difference between wiring a false constant to the 'continue if true' terminal of a while loop and wiring a true constant to the 'stop if true'? Nothing. It is just a matter of boolean logic. Whether it is more logical to stop if something is true (such as an error or a value is out of range), or continue if something is true (such as a value is in range.) If you ever find the need to put a Not! function on the boolean wire going into the terminal, then it is probably more logical to swap the state of the termina rather than adding the extra boolean logic.

I apologize for all these questions (some of which must seem rather obvious). I have and am scanning help sections and forum entries etc, but I'm not quite finding answers to everything. All replies are greatly appreciated.

Re: Crash course in Event Structures

DFGray — Wed, 06 May 2009 12:35:56 GMT

Why is there an empty false case here if the "exit" control must be true for the VI to even get as far as the case statement?

The exit control does not need to be TRUE to get to the case statement, it merely needs to change value. The empty case is to avoid problems which could occur if the button were pressed before running. While in the development environment, you can set any state for the button. The latching action is only enforced at run-time. This is a fairly low use case. The extra case structure is also a fail-safe in the event the mechanical action of the button changes in the future.

That image shows what I would consider a bad practice, having an event structure inside a case structure.

I must partially disagree with my esteemed colleague on this one. The event structure is part of a synchronous, event-driven task handler. I consider this a core design pattern and use it in most of my GUI driven applications. All events will be executed in the order they are received. They can also be easily modified and discarded, something not always easy using a bare event structure. Most time is spent at the event structure waiting on an event. You can achieve an asynchronous task handler by placing the queue driven task handler in a separate loop from the event loop. You can have both in the same application by using two or more queues. This is fairly common, since you often want some events to be synchronous and some asynchronous.

Re: Crash course in Event Structures

Ben — Wed, 06 May 2009 12:56:48 GMT

DFGray wrote:
...

That image shows what I would consider a bad practice, having an event structure inside a case structure.

I must partially disagree with my esteemed colleague on this one. The event structure is part of a synchronous, event-driven task handler. I consider this a core design pattern and use it in most of my GUI driven applications. All events will be executed in the order they are received. They can also be easily modified and discarded, something not always easy using a bare event structure. Most time is spent at the event structure waiting on an event. You can achieve an asynchronous task handler by placing the queue driven task handler in a separate loop from the event loop. You can have both in the same application by using two or more queues. This is fairly common, since you often want some events to be synchronous and some asynchronous.

My coffee is still trying to displace the effects of head-cold medicine but you have me wondering...

Say I have an app that runs in two modes ... Set-up and Run and I decide to code all of the Set-up stuff in one event structure and all of the Run stuff in another.

Let's also assume that I have made sure none of the events are set to NOT "Lock FP".

I could put the two event structures in two different cases of a case structure and everything would run fine UNLESS there is a common event for both event structures. THe event structre for the mode we are opperating in would get fired but the ones for the non-executing events structure would just pile up.... YES?

If so we have a memory leak (using the term loosly here).

Rather than use two static event strutures I have been using dynamic events so that only events that are servicable in the current state of the app are active at any time.

Confession Time:

Back in the early days of LV 7.0 I coded up an app using the State Diagram Editor where I had multiple events structures used for the differents states. I had to bend over backwards to flush queued up events that occured earlier (compared time now to to time of event) or to disable/enable controls to prevent events that I was not ready for yet in the code. I did not like the app in the end and have avoided that since.

Clarification:

I am not saying that multiple events structures is bad. What I am saying is that if an event is registered it should be allowed to execute.

Still waking up,

Ben

Re: Crash course in Event Structures

RavensFan — Thu, 07 May 2009 00:56:06 GMT

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.

Re: Crash course in Event Structures

DFGray — Thu, 07 May 2009 13:59:34 GMT

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.

Re: Crash course in Event Structures

J.Mamakos — Wed, 13 May 2009 16:19:47 GMT

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?

Re: Crash course in Event Structures

Ben — Wed, 13 May 2009 17:00:12 GMT

Prorperty >>> Value will not trigger an event

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

Ben

Re: Crash course in Event Structures

J.Mamakos — Wed, 13 May 2009 17:07:07 GMT

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!

Re: Crash course in Event Structures

Ray.R — Wed, 13 May 2009 17:19:50 GMT

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... 😮

Re: Crash course in Event Structures

J.Mamakos — Wed, 13 May 2009 17:26:05 GMT

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

Re: Crash course in Event Structures

altenbach — Wed, 13 May 2009 18:23:16 GMT

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!).

Change via local variable: does not trigger a value change event
Change via value property node: does not trigger a value change event
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.

Re: Crash course in Event Structures

altenbach — Wed, 13 May 2009 18:58:37 GMT

btw: I like the title of this thread.

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

Re: Crash course in Event Structures

kmous — Thu, 14 May 2009 13:16:36 GMT

RAY , I lost your email , what is it again ? could you please send me a reply to any of my emails !! Thank you