Event structure inside a case structure

[holomorph]

Hi,
I've got a problem w/ my porgram, and managed to boil it down to this simple example.  The program basically hangs if you change the Numeric value when the boolean is false.  I don't understand why.  I suspect it has to do with the way event structures are treated, but if someone cou please explain this I'd be greatful.

Also, now imagine I have 7 numeric controls, handled by 7 cases in that event structure, and I actually want to do things in response to the value change for each.  Can someone suggest an elegant way to do that?  I thought what I had here was a good design, but apparently not.

Bjorn

(I'm using labview 7.1)

[altenbach]

It is generally a bad idea to place event structures into cases. Events structures need to be able to breathe.

Maybe you can redesign your program and place the case structure inside the event structure, for example? (Also have a look at the online help for the event structure, especially the link "caveats and recommendations for using events ".)

Detailed analysis:

Your event case for the numeric is set to "lock front panel until event completes".  If you change the numeric while the case is false, the evet structure cannot execute, so the front panel locks forever. The observed behavior is as expected. All clear? 😄

In addition, if the case is false, the main loop spins at nearly infinite rate, consuming all available CPU. Place a small wait to be more cosiderate to everything else running on your rig. 😉

[Matt_W1]

Put the case statement inside of the event structure.  Generally you should have one event structure per VI.

What causes the lock up is that the value change event is set to lock the front panel until it is handled. So you click the button the front panel locks waiting for the event to be handled. But since the value of the boolean can't be change by the user during the lock, the event structure will never be reached and the front panel stays locked. Note that when the front panel is locked the VI is still running in the background and it can change the front panel, but all the things the user tries to do are queued up waiting to run when the lock ends.

You could edit the event to not lock the front panel, but that is generally a bad idea and should only be done with care and a really good reason (since it allows events to be processed out of order, and some other stuff I'm probably forgetting). Another option is to dynamically registry and unregistry the events, but that may be more complicated than just putting the case statement in the event structure.

[edit]I got distracted in the middle of writing, so I didn't see altenbach's response untill after I posted[/edit]

Message Edited by Matt W on 10-18-2006 08:39 PM

[holomorph]

Thanks for the replies,

I figured I could probably put the case inside the event structure and it would work, it just seems. . .ugly.  This is because since I'm handling seven different cases, I'd have to put a case inside each one of the events, which seems kind of rediculus compared to one outside. 

I agree disabling locking of the front panel is not ideal, but good to be reminded of the option.

I was hoping there was a simple way to just not have the value change event caught/processed when the boolean is false, but maybe there isn't.

[altenbach]

I still don't understand what you are trying to do.

What is the purpose of the case structure at all (in the example, it certainly serves no purpose)??? Why do you need a case structure inside each event case? There are many possible alternatives, depending on the desired functionality, you could for example place the case structure after the event structure.

Just take two steps back and rethink your desing from scratch. 🙂

[holomorph]

In this case I have seven heater controllers that I am setting the set point for.  They are connectev via a serial over ethernet device which may or may not be powered up.  If it is powered up (the true case), and I change one of the set points on the front panel, I want it to adjust the set point of the corresponding controller.  However, if the device is not powered up, trying  to communicate with it causes my program to hang for 20-30 seconds, so I obviously want to avoid that.