Losing control of Front Panel

[pete_dunham]

(LabVIEW 2010 in Windows 7)

I have a relatively simple program (a temper chamber profiler) that I am losing control of the Front Panel.

The program starts with an Event Structure in a loop where an event (Start Profile) will stop this loop and then data is passed to a state machine loop.

It is in the state machine loop that I completely lose control of my front panel. The only option available to me is the Abort button.

I have learned from past mistakes with this and have eliminated possible race conditions and have significant Wait (ms) vis in my state machine loop and subVI loops.

The Performance and Memory tool is not shedding any light on my problem.

Any ideas how to troubleshoot?

Thanks in advance!

[Tim_S]

Any ideas how to troubleshoot?

What do you mean by losing control?

Have you tried watching the front panel with highlighted execution?

Tim

[pete_dunham]

What do you mean by losing control?

Have you tried watching the front panel with highlighted execution?

Tim

I mean I can't click on anything.

Can't click on indicators or controls.

Can't access Window's "File" "Tools" "View".

Can't navigate to Block Diagram

But......

[bmoyer]

In the event structure, when you are editing an event, you may want to uncheck the "Lock front panel until the event case for this event completes" for most events (unless you want to disable any user action until the event is completed.

You also may want to consider 2 state machines. One for user events and the other for the temp chamber. You need to devise a way to pass the events from one to the other (most people use queues). LabVIEW has templates (located from the menu File-->New... under VI-->From Template-->Frameworks-->Design Patterns called (Master/Slave Design Pattern, Producer/Consumer Design Pattern (Data), and Producer/Consumer Design Pattern (Events). You may also want to look at the JKI state machine. Many people use that and are happy with its expandability.

Bruce

[pete_dunham]

I just found a solution.

For some reason it appears that my Event Structure was locking the Front Panel.

This is confusing since, according to LV's dataflow, this Event Structure should be done executing.

(Note that the loop containing the Event Structure had stopped and passed data to the next loop)

By wiring a constant to the TimeOut terminal on the Event Strucutre fixed this problem.

Is this a best practice that I missed?

[crelf]

For some reason it appears that my Event Structure was locking the Front Panel. This is confusing since, according to LV's dataflow, this Event Structure should be done executing.

Well, if the event structure is reached, it needs to either wait for an event, or timeout. I'm wondering if the loop you have isn't stopping, and it goes around again? Can you give us a screenshot? Or upload your code?

...a temper chamber...

I know a few people that could do with one of those

[pete_dunham]

...temperature... <BR>...code coming...

Well, if the event structure is reached, it needs to either wait for an event, or timeout. I'm wondering if the loop you have isn't stopping, and it goes around again? Can you give us a screenshot? Or upload your code? I know a few people that could do with one of those

[Ton Plomp]

Event structures are always active. They may not be executing, but if you have an event configured to 'Lock panel during execution', it will lock as soon as the event happens, this is by design.

One of the examples why this is necessary is a convoluted state machine where the event structure only executes every 5 seconds, and you have a mouse down event for a picture. Let's say that executing of this event takes 2 seconds. Now if you are in bad luck (or your users are impatiently), you can get numerous 'mouse down' events during the 5 seconds loop effectively killing your app (every event takes 2 seconds in which new events are started...

Ton

[pete_dunham]

You also may want to consider 2 state machines. One for user events and the other for the temp chamber. You need to devise a way to pass the events from one to the other (most people use queues).

I do agree with the above statement; this would be a preferred architecture. Nonetheless, this behavior was driving me crazy.

But it turns out I was missing something pretty fundamental. I have attached some VERY SIMPLE code to demonstrate my error.

Everything will go okay if you change the Start Profile control once. If so, the state machine loop (here just a simple case-inside a loop) will execute and the Front Panel is unlocked.

I was running into a problem if I clicked on the Start Profile control <event> in rapid succession.

If this happened, the loop would stop but the Event Structure would still have more events in it's "queue" to process. Thus, my Front Panel would lock up.

Changing this option in each event, per:

In the event structure, when you are editing an event, you may want to uncheck the "Lock front panel until the event case for this event completes" for most events (unless you want to disable any user action until the event is completed.

fixes the issue.

Again, this is a poor architecture to begin with, but at least I have re-educated myself on some Event Structure fundamentals.

Thanks for the input!

Event Structure Behavior.vi

[jzoller]

What do you mean by losing control?

...

Tim

I thought this:

http://screencast.com/t/Th1N0wVFm0G

... I need less caffeine, I think.

Joe Z.

[Tim_S]

I thought this:

http://screencast.com/t/Th1N0wVFm0G

... I need less caffeine, I think.

Joe Z.

Excellent! Do they perform Masochism Tango as well?

[jzoller]

Excellent! Do they perform Masochism Tango as well?

Sorry, you need XControls for that