Event Structure - Lock Event: Does it Queue ?

[winterishere8]

I had couple of question related to this post in other posts but I thought I'd use a new one since it might be more relevant (others were related to local variables, and VI file sizes)

I have this event structure running about 10 different tasks. For some I would like to lock the panel when it runs. I used "Lock panel ..." but during the run, if you click on any boolean and menu ... for some reason it queues the task and performs it after the event is complete ... is there any way I can lock the event and not have any event queued ? Thnks !

[Rasputin]

Maybe there is a better way, but you can make like this.

Message Edité par Rasputin le 11-17-2006 04:54 PM

[SimonH]

Maximus00,

The LabVIEW 8.20 help explains the expected behavior of the "Lock front panel ..." option:

---

When you enable this option, LabVIEW temporarily defers processing of mouse clicks, key presses, and other user actions on that front panel when the event enters a queue, then processes the pending actions in the correct order after the event case for the event finishes execution.

---

So in this respect the behavior you are seeing is correct.

On the other hand I can see why you would want to do the behavior you describe.  One option would be something along the lines of what Rasputin suggested. 

Another possibility would be to use a queue in LabVIEW to store events that need to be handled.  When your event fires the code inside the event structure could decide whether or not that particular event needs to be serviced and add tasks to the queue accordingly.  Another parallel loop can then pull events out that queue and handle them.

I hope this at least gives you some insight as to how you could approach getting your desired behavior.

Regards,

Simon H
Applications Engineer
National Instruments

[Rasputin]

Simon,

As I said, I do not think that disabling the controls is the best solution. It seems too brutal for me
Are you proposing a producer/consumer architecture? Anything like the attached VI or you can propose an alternative other than flushing the queue?
Regards,

[SimonH]

Rasputin,

Your attached VI would be one way of implementing the producer/consumer approach I suggested.  The way I had in mind was to include some logic in the producer loop to prevent new events getting added to the queue when the front panel was "locked".  This way certain events (such as perhaps an emergency stop) could still be executed even if the front panel was locked if so desired.

I modified your example to show what I was thinking - let me know what you think about it.

~Simon

[winterishere8]

Thanks Simon. My requirement is something like: I just want one event executed at a time. Any other keyed events will be discarded. I used the crude way of disabling and enabling controls so user does not generate any event but that makes my VI large.

I found this method to work. Using a variable (0, 1). If an event is in progress, then I set the variable to 1. I use a case stmt inside every event to make sure no events can be fired if the variable is 1.

I kinda like the ideas about queue that you and rasputin have mentioned. I am using a queue (simple state machine), but for couple of events in my large VI. I am contemplating if I should go ahead and implement it for all events. Thanks  !

[johnsold]

It sounds like you could use a semaphore. It might be more efficient than your 0,1 variable because there are built-in functions to hanlde it. Semaphores can have a bit of a learning curve, so you may want to try some simple VIs simulating your real program until you see if they would work for you.

Lynn

[winterishere8]

Lynn

I've never used semaphores before. I read about it and saw an example. I got a brief idea. Is it possible for you to post a relevant example ? Also, what would be your opinion on this ?

I've used event structure with a bunch of enable/disable for booleans for my VI. Would it require a whole lot of effort to implement semaphores ?

[winterishere8]

Simon,
I looked at your vi lock_event2.vi and it looks like exactly what I need and which can be implemented with minimal efforts. One question is: on the Block Panel Event boolean control, I need to set it and reset at the start and end of every event respectively right ? In that way no other events are triggered ? Did I understand you correctly ?

Thanks

[SimonH]

If you were to change the value of the Block Panel Event boolean using a local variable it wouldn't fire an event so I'm not sure that would be the way to go.  I had intended that just to be an example control.

I have further modified the example to show how a custom user event can be programatically fired to signal that the front panel should be "unlocked" and that new events should be added to the event queue.  In the new example you will see that while the LED is flashing no events are queued.  Once the LED is done flashing it communicates to the event structure via a user event.

It may also be possible to change the value of the "locked?" boolean without requiring an event to do so.  I didn't explore this option but it may be a valid approach.

Also please remember that any example I have posted here is not meant to be incorporated into an application - I am merely attempting to demonstrate ideas and concepts.  It will be more beneficial for you to examine and understand how I programmed a certain behavior and then use those concepts to create your own application than to try to make my code fit into your application.

Regards,

~ Simon