Crash course in Event Structures

[J.Mamakos]

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

[Ben]

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.

[J.Mamakos]

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! 

[DFGray]

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.

[J.Mamakos]

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.

[DFGray]

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.

[J.Mamakos]

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.

[RavensFan]

---

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.

---

[DFGray]

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.

[Ben]

---

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