LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Possible bug using sequence structure and nested event structure?

Using LabVIEW 2019 (64bit) on Win 10.

 

Working with a colleague and we found this behavior when nesting an event structure inside a sequence structure and I just wanted a sanity check. 

 

We are aware of this page:

http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/caveatsrecmndtnsevnts/

 

Example code attached. We have a first panel in the sequence structure waiting for user input ('1st button'). That works fine. Then the second button for the event works fine if pressed after the first one is done.

 

However if the user presses the 'Event' button before the '1st button', it paralyses the VI. 

 

Can someone explain why this is happening? 

 

Obviously we can redesign our code to avoid this problem but it piqued my interest and I wanted to understand what's happening here.

caleyjag_0-1574895625659.png   

caleyjag_1-1574895660733.png

 

 

P.S. I appreciate some people loathe and despise sequence structures but I love them so there!

 

0 Kudos
Message 1 of 7
(2,390 Views)

Don't have 2019 here but make sure you uncheck Lock Panel.

 

Snap5.png

 

My guess it is checked.

 

mcduff

0 Kudos
Message 2 of 7
(2,378 Views)

You really need to rethink your architecture. Try a state machine instead of a sequence train. Create an event structure in the toplevel or producer loop and add events for both buttons.

 

Even if you disable panel locking as suggested above the code will probably not work in a reasonable way because if you press the event button first, nothing will happen until you stop the first loop at which point the event will immediately fire the queued up even from earlier.

 

(I also don't understand the need for your local variable. Why not use latch action instead? Overuse of sequences are a hallmark of beginner code. In your case you could just wire from the while loop to the edge of the event structure to fully define execution order.)  

0 Kudos
Message 3 of 7
(2,370 Views)

Good observation. That is true, I did not know about the lock panel radio button.

 

With that said, it seems the event structure here is looking activity on the 'Event Button' as soon as the VI starts running and not when the second panel in the sequence structure is started.

 

So this code still wouldn't work as intended?

0 Kudos
Message 4 of 7
(2,365 Views)

Ok. I guess I want to understand why the event structure is queuing anything up at all before it is called. 

 

I'd naively expect it only to register events that happen only after the event structure has been called, not since the VI started running.

 

0 Kudos
Message 5 of 7
(2,359 Views)

@caleyjag wrote:

 

So this code still wouldn't work as intended?


Sir Altenbach gave you good advice, I suggest you follow it. The code you have now is unreliable and unmaintainable. It may or may not work in some cases.

 

mcduff

0 Kudos
Message 6 of 7
(2,355 Views)

@caleyjag wrote:

Ok. I guess I want to understand why the event structure is queuing anything up at all before it is called. 

 

I'd naively expect it only to register events that happen only after the event structure has been called, not since the VI started running.

 


The event structure is always listening, it may not execute until that sequence frame, but beforehand it was listening, recording events, and then waiting to execute. It is building up a queue of events.

 

mcduff

0 Kudos
Message 7 of 7
(2,354 Views)