Queue In Multiple Loops Locks Front Panel?

[Willy2a]

I have a program with two queues. Each Queue has its own while loop to de-queue, enqueue and perform various tasks. An event structure in a third while loop handles the UI. The only time the UI loop/event structure interfaces with the other two loops is to abort operation (flush the queues). Whenever this happens the front panel gets locked out. I can tell that the loops continue to operate normally (the queue loops behave correctly for an empty queue, and the UI loop goes to the timeout event). What is causing the front panel lockout and how can I prevent it? I do not have the "lock front panel" box checked on the "edit events" screen for the event structure. That shouldn't matter anyway since the event completes (goes to the timeout event) and the front panel is still locked. This happens if I flush either queue from the event structure and does not happen at any other time.

[blawson]

do you by any chance have a latching boolean for one of your events?  If so, its terminal must be inside the event structure case which reacts to it, or else it will not release, and the front panel will stay locked.

[Willy2a]

Nope, they are all "switch when pressed".

[altenbach]

I am not very good with long and complicated sentences. Could you show us some code instead? 🙂

[Willy2a]

Hmm, I made a simplified version to post here, but of course it works. The only difference I can see between the simple version that works (posted here) and the more complex one that doesn't, is that the queue handling is handled in a sub-vi (called by the various while loops). The more complex version works perfectly until I click an "abort" button.

[johnsold]

When you press an Abort button it flushes the queue.  In your Queue loops what happens if a queue is read while the queue is empty?  You do not test for timeout even though you have a timeout specified and you do not have a default case specified.  What is the default value of the Action enum?

You do not need both a Wait function and a timeout in the Queue loops.

Stacked sequence structures should be avoided because they hide code and defeat the advantages of dataflow.

Local variables should not be used where wires will work.

Lynn 

[Willy2a]

The default value of the enums and the case structures is "--Empty Queue--" which seems to work correctly in both the simplified and more complex versions. In other words the "--Empty Queue--" case is executed correctly in both VIs.

[Willy2a]

Perhaps I don't understand the Queue timout functionality correctly. Please expand on "You do not test for timeout even though you have a timeout specified and you do not have a default case specified." My understanding is that with a 10msec timout, the Dequeue function will wait at most 10msec for an element to be available in the Queue. If an item is available won't it execute immediately? Should I be going to the "--Empty Queue--" case based on the boolean timedout output from the dequeue function?

Message Edited by Willy2a on 12-22-2009 01:41 PM

[johnsold]

You do have a default case specified.  Because of the large number of spaces in the title "--Empty Queue--         ", I did not notice the default designation.  Sorry.

When a Dequeue function times out, the "timed out?" boolean is True and the "element" output is the default vale for the datatype.  You are right about the function returning immediately if data becomes available.  Typically the "timed out?" boolean is tested and the appropriate action is taken if no data is in the queue.  You have handled that with your default case.  If the timed out action needed to be different from the action produced by the default values of the element, then your method would not work.  For example if the queue element was a boolean and you did not want to change the value if the queue timed out, you would use the "timed out?" boolean to select a case which passed the old data through rather than forcing it to be the boolean default of False.

Can you set the dequeue timeout to 50 ms and eliminate the Wait function?  Or is it important to take the default action after 10 ms but still wait?

What is the purpose of the timeout on the Enqueue in Queue Loop 1 which does not appear in Queue Loop 2? Normally an Enqueue would only wait if the queue size was limited and yours is not.

Lynn 

[Willy2a]

The only reason for the 50ms wait is that at times there will 10-11 elements in the queue and I didn't want to max out the CPU running them all back to back. The queue should never be empty except for right after a flush.

The lack of a timeout in the second loop was just an oversight. I don't think I need a timeout for the Enqueue functions in either loop - as you point out.

Message Edited by Willy2a on 12-22-2009 03:34 PM