LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Front panel locked, but not due to event structure

Solved!
Go to solution

Hi there LV community,

 

I've made a staemachine program that runs an oscilloscope (screenshot of one state included below... the problem state). I ran my program yesterday and it worked great. Then, like a dummy, a dialogue box opened up and I just clicked it in a hurry; now my front panel locks up as soon as I enter the aforementioned state "Oscilloscope Settings."

 

As shown, I've go a repeating while loop which collects successive pulses from my oscilloscope and displays them on the front panel (this works fine). In parallel, I have an event structure that's queuing for real-time feedback from settings changes I have laid out on the front panel (ex. change of state).

 

Here's the problem: as soon as I enter the "Oscilloscope Settings" state by pressing a Boolean button on the front panel to get me there, the front panel locks up... No event has triggered by this point and, even if it did, I've already deselected the "Lock panel until the case for this event completes" checkbox in the event structure menu.

 

So WHY is my front panel locking up now? Thoughts anyone?

 

 

0 Kudos
Message 1 of 9
(4,178 Views)

The execution of the state shown will not complete until one of the events defined for the event structure occurs. There is no timeout on that event structure so it will wait forever for an event.

 

AND

 

The execution of the state shown will not complete until the internal while loop completes. If END is false when the while loop starts running, it will run forever.

 

Other comments: 

Loops inside a state of a state machine often are indications of a poorly designed state machine. For example having separate states for the oscilloscope Stop, Read, and Close functions eliminates the need for the nested loops.The Read Waveform state would be repeated until the Stop button is pressed.

 

Event structures usually should not be in a state machine. They typiclaly are in a parallel loop as in a Producer/Consumer architecture.

 

Lynn

0 Kudos
Message 2 of 9
(4,157 Views)

Thanks for the quick reply Lynn.

 

I'm aware of the notes in your response. The "Stop" button was actually just a quick experiment; usually the "Exit" boolean is connected to the inner while loop's stop condition... but even that button locks upon entering the state. It's not the stopping of the while loop or execution of the event structure I'm worried about - it's the locking of the front panel. I can't do anything with the state, not because it'll run forever without interjection, but because the front panel locks up and I'm left without the option to interject and stop the while loop/ execute an event.

 

See what I mean? I just need to know why the front panel is locking up.

0 Kudos
Message 3 of 9
(4,130 Views)

We cannot tell from the images. The reason will be in some setting or part of the code which is not visible.  Please post the VI.

 

Lynn

0 Kudos
Message 4 of 9
(4,122 Views)

Here you go. It runs off a Yokogawa DAQ, so you won't be able to run the VI unless you remove the initialization code. But at least you can scroll through the settings and perhaps spot what I'm missing.

0 Kudos
Message 5 of 9
(4,115 Views)

P.S. I had the code working great in the current architecture, with the exception that I added local variables and visibility-property nodes recently, got some message prompt, clicked on the prompt before reading it (it was a long day, and yes I realise that was stupid, haha), and now the front panel locks up when first entering the "Oscilloscope Settings" state.

 

Perhaps this info helps. And thanks for your help btw Lynn 🙂

 

0 Kudos
Message 6 of 9
(4,107 Views)
Solution
Accepted by topic author ryanjhartnett

Read the Detailed help for event structures.

 

It strongly recommends that only one event structure be used in a VI. There are times when more can be used effectively but great caution and thorough understanding of the structure are required.

 

The problem is that you have multiple event structures in different cases of the state machine and they are set to respond to the same events.

 

When the Set Oscilloscope button is pressed, the event structures in both the Acquisiton Menu and Home Screen states receive the event. Both lock the screen, but only one of those cases can run. It may transfer control to the Oscilloscope Settings state, but the other event structure responding to that same event keeps the panel locked.

 

The solution is not to unlock all the event cases. Generally the default is the best setting. The best solution is to switch to a Producer/Consumer (Events) architecture. That uses two parallel loops. The Producer has the one and only event structure and passes the commands to the Consumer loop via a queue.

 

You probalby want the mechanical action on the buttons to be Latch When Pressed. Put the terminals inside the respective Value Changed event cases and the local variables become unnecessary.

 

Lynn

Message 7 of 9
(4,093 Views)

Wow, what a clear and detailed explanation. Thanks Lynn!

 

I see what you mean, and now I'm on my way to fixing the architecture to Producer/Consumer.

 

Thanks again, and take care 🙂

0 Kudos
Message 8 of 9
(4,089 Views)

Just to emphasize, this is one case where the documentation really does a good job. Please read up on the event structure.

 

Lynn

0 Kudos
Message 9 of 9
(4,086 Views)