Subsequent event structures activating on previous events.

[Riggy]

I have a stacked sequence with, for arguments sake, at least 10 frames. In a handful of these frames I have placed event structures. I have one particular event structure case that exists in all the event structures throughout the vi.  The problem I have is this: The event that triggers this particular case also seems to trigger the subsequent event cases automatically. That's not very clear,  so maybe this will help:

1. In the first sequence frame there is an event structure that can be triggered by a Mouse-Up action.
2. Once the user performs a Mouse-Up event the case is triggered, running the code within the event structure. The event structure is within a while loop, and triggering the case also allows the while loop to finish.
3. The code then advances to the next frame of the sequence. All good so far.
4. In this sequence frame is a 'virtually identical' event structure, also within a while loop.
5. One of the cases of this event structure is the same the first event structure. Now, although the user has yet to perform another Mouse-Up action, the case runs anyway within the event structure! This runs the code within the event case, exits the while loop and the code moves onto the next sequence frame, where there is another event structure.
6. Again this happens, with the event structure performing the case associated with the same Mouse-Up event, even though the event has not recurred. There are about five of these event structures within the stacked sequence, and all run through automatically without stopping.

I am using a stacked sequence because between these event structures are many stacked sequence frames with code in, and each event structure is strategically positioned to ask the user to make changes, to continue or to cancel, at relevant stages of the code.

My question is : why is the event not 'forgotten' once registered with the first event structure? I want the all subsequent event structures to require a re-issue of the event, not to peform automatically based on past events.

Can anyone help me with this?

Thanks in advance,
Riggy.

[Christian Mergl]

Hey Thomas,

When using Event Sturctures with cases waiting on the same event to occure, LabVIEW activates this case in all structures as this event fires. This is due to the compile process of LabVIEW. The only way to avoid this is to not use the same event in more than one structures within a VI!

BR, Christian

[Riggy]

Hi BR,

Thanks for your reply. I did not realise that the event structures were waiting simultaneously? I had put the event structures in different frames of a stacked sequence and therefore presumed that as each frame was executed, the event structure would be approached afresh. I find it a little confusing to see that, even with several seconds of delay between each event structure, subsequent event structures can still be triggered by expired events that occured many seconds ago.
I see that I have no choice but to re-write my code to work another way.

Many thanks for you advice, I have learned something new today already

Regards,
Riggy.

[tbob]

I would like to suggest that you abandon the sequence structure altogether in favor of a state machine architecture.  There are many examples of state machines.  I believe the Labview community will agree with me on this one.  State Machines have many advantages over sequence structures.  Also, it is best to use just one event structure in a vi.  An example of how to use an event structure in a state machine is to create a state (just one case in a case structure) called events.  Put the event structure in this case.  The event structure can then dictate the next state.  See attached example.

[Ben]

Christian Mergl wrote;

"

The only way to avoid this is to not use the same event in more than one structures within a VI!

"

[Emphesis added]

Actually the same event can be used in more than one event structure by dynamically registering and un-registering the event as needed.

Ton posted a Nugget on dynamic events that can be found here.

Christian also wrote "This is due to the compile process of LabVIEW."

Could you please expand on this point. I do not know what the compiling has to do with this.

Trying to help,

Ben

PS: Tbob suggestion will allow you get away with only a single event provide the rest of the code is set up to adabpt.

Message Edited by Ben on 07-30-2007 12:41 PM

[Christian Mergl]

Hey,

Sure, using the dynamic event terminals is another possibility. But I tried to explain the origin problem and will say it again: "Never use the same event in more than one event structure!"

Configuring two event structures waiting for the same event, within the compile process the event is registered for each structure and is placed in their event queue when it occurs. Then both event structures will fire, but the second one executes after the dataflow reaches it.

Hope this helps!

[Ben]

"Sure, using the dynamic event terminals is another possibility."

Thank you Christian.

My reply was intended for the purposes of correcting the record. More than once I have read posting were users have quoted "NI-postings" as gospel.

Ben

[wdmot]

How do you make use of the "Lock front panel until the event case for this event completes" functionality if you're using a state machine?  When the user presses a button, I don't want them to be able to press it again until I'm done processing it, to avoid getting multiple button presses stacked up.

I have a similar problem to Riggy, and have not been able to find a solution that isn't messy.  I'm using LV 8.5 Full.  After my VI starts, I need to wait for the user to select some settings (e.g. which Com port a device is connected to, initial values, etc.) and then press a button to initialise and continue to the "main loop".  The main loop then processes changes in desired settings.

I've attached an extremely simplified VI that demonstrates the problem in my implementation.  The user should be able to turn the "Set on/off 1, 2, 3" booleans on or off, before pressing the Start button.  The "real" program would then use those values to initialise the devices and proceed to monitor user input and act on it (there would be many other device settings).  At that point the user should be able to change device on/off settings and so on.  The changes in "Set on/off 1" setting should not trigger an event before the Start button is pressed, but should afterward.  Note that there are two event structures but they do not handle ANY of the same events.

The problem in my implementation is that the UI locks up if you click any of the controls other than the "Start" button, unless you click the "Start" button first.  Of course that prevents the user from being able to select initial conditions.  If in the second event structure I disable the front panel from being locked, this doesn't happen.  However, I don't want the user to be able to be triggering more events while I'm processing one.

Is there a way to do this?  Or does anyone have a suggestion for an alternate approach?  I've read that you can't process the same event in different event structures, but I'm not doing that and it's still locking up.  The only way I can think of is to consolidate into one event structure, add a variable (or shift register) that indicates initialisation status, and add a case statement to check that status in every event.  I'd rather not have all those extra case statements.  Is there another way?

Thank you in advance for any help or pointers.

Tom

[altenbach]

---

@wdmot wrote:
I've attached an extremely simplified VI that demonstrates the problem in my implementation. 

---

Try again to attach your VI, it did not make it.

[wdmot]

Ok, I'll try again...   Browse... select file... Submit Post.  Ah, it must not have worked the first time because I previewed the message before actually posting; it must have lost the attachment then.

Message Edited by wdmot on 10-23-2007 01:10 PM