Why is my enqueue/dequeue in my producer/consumer pattern unreliable?

[jcannon]

Hi all,

I have having some issues with the enqueue/dequeue in my prodcuer consumer pattern where data is send to the enqueue in the prodcuer but is not dequeued in the consumer. This bevaviour is irregular and has no pattern for predicting this behaviour... Using the queue status vi, data is enqueued as the number of elements in the queue increases each iteration; but it is not dequeued... I have tried to flush the queue but this does not help... Eventually I get an out of memory error and the vi stops... I am dealing with up to 5M data in the queue, so I thought I may be queuing to quick... I tried to slow my loop speed down to from 500ms to 1000ms but this has made little to no difference..

VI is attached (enqueue is in loop 2 and dequeue is in loop 3)...

Any suggestions would be appreciated.

Thanks,

Jack

[Norbert_B]

Jack,

can i have your monitor? It must be as big as a factory wall..............

Honestly: increase your modularity and decrease the size of front panel and the block diagram!

That being said, i believe your problem is the design that you enqueue a new item only in e very deeply nested code segment. Obviously, you never execute that case. So you have to debug all the way up from the case structure including the enqueue function up to the while loop why that case is not executed as you expect that. As you have quite some boolean logic involved (time out, ...), this can easily take a lot of time esp with such an incredible huge diagram.....

Norbert

[jcannon]

Hi Norbet,

Thanks for the reply... Yes... The code is spaghetti... Something I need to work on..

Sorry, but I am not sure what you are saying.. The vis is a basic state machine that progresses in sequence.. Once a data file is opened, loop 2 will/should stay in the the outer PLOT state and the inner False state... So the enqueue is in the most current state... It is not accessed by jumping between a number of different states.. So I would not think debugging would be such a difficult task.

Not sure if this makes sense?

Regards,
Jack

[Norbert_B]

Jack,

you have two Enqueue functions in the whole VI, and two queues. So the only Enqueue feeding the "SubArray" is encapsulated in loop2 at a nesting level of 5....... you have to "pass" THREE case structures (the other two nesting levels are made up by another structure, namely the while loop 2) in order to call Enqueue. Are you sure that you will EVER pass all three conditions??

Norbert

[aputman]

Labview is hanging because the current has to travel so far thru the wires. 

Actually i think it is happening because you don't initialize the "main menu state" in Loop 3 so it assumes the last value that passed thru the shift register....which was most likely EXIT.  So that loop shuts down before it even starts.

---

@jcannon wrote:
Hi Norbet,

Thanks for the reply... Yes... The code is spaghetti... Something I need to work on..

Sorry, but I am not sure what you are saying.. The vis is a basic state machine that progresses in sequence.. Once a data file is opened, loop 2 will/should stay in the the outer PLOT state and the inner False state... So the enqueue is in the most current state... It is not accessed by jumping between a number of different states.. So I would not think debugging would be such a difficult task.

Not sure if this makes sense?

Regards,
Jack

---

[JÞB]

Norbert is right on it.  there is no way to reach the "False" case inside "Plot" so the condition that evaluates the boolean that drive the case around the enqueue just cannot be reached.

There is something VERY WRONG about using the "Timed out" outputs of Dequeue Element when the timeout is unwired.

E.G.:

You can try to flush but, nobody is "Getting off the pot" unless the queue is destroyed

Now lets talk about loop timing:

REALLY? a 1mSec timeout on the 500mSec Tick? and I won't pick on you too much about the boolean case structure to select a boolean condition.  Although, thats the boolean that drives the case with the unreachable enqueue element.

This code could be greatly simplified.

[aputman]

Jeff,

The OP says that the queue is receiving items but they are not being dequeued.  The false case inside PLOT is driven by a boolean constant.  It starts off true at the first iteration and is false when the menu queue times out and true when there is menu activity. 

It's not dequeued because the consumer loop is killed immediately upon start because EXIT was the last command in the uninitialized shift register. 

[jcannon]

Thank you all so much for your input... I am surprised about this give the messy state of the vi (possibly too hard for others to clearly follow?)... I will initialise the MAIN MENU command in loop 3 with something other than EXIT.... On that note, the EXIT command is the only command that loop 3 must respond to (it is only used to stop the loop)... I should proberly remove the MAIN MENU queue and just exit the loop when the dequeue is released (wire the dequeue error to the stop)....? Any concerns with that? I am building this vi so I can create an exe file that I can use to analyse my research data and will hopefuly be able to be used for a number of years... It analyses my data and writes it to file exactly how I waht it done... Better that any commerical software I could get... Given the size of the code and number of wires involved, would my best option be to get it working, then go back through and create as many subvis as possible, in order to reduce complexity and make it more readable? What you would suggest? I'll get back with an outcome following the initialization. Thanks again for all the suggestions and taking the time to look. Regards, Jack

[jcannon]

Hi Jeff, I am interested in what you said about using the dequeue time out... This queue carries MAIN MENU commands, which come an event structure in loop1... Hence, the queue only contains data when a menu command is selected by the operator; thus a time out is needed.. Ohhh... ok... I think I have it... If I shift the MAIN MENU enqueue outside the event structure then use a shift register on the while loop to retain most recent comment I can have the command sent to the dequeue each iteration; thus elimimnating the need for the time out...? Is that better? Thanks, Jack

[jcannon]

Hi all,

I have initialised the shift register; however, labview still hangs on occasions when I hit EXIT.... I think I have narrowed this down to instances when I EXIT immediately upon start-up before I load any data in the subarray enqueue... If I EXIT before loading data into the enqueue, loop 3 does not iterate as their is not data to process... A boolean indicator on the wire connecting the stop button in loop 3 is TRUE when I press EXIT; but the loop still hangs... Whe data is loaded into the subarry enqueue in loop 2 and therefore the dequeue in loop 3 is operating, the loop stops..

Any suggestions for how can fix this bug; other than load dummy data into the enqueue in loop 2 on EXIT.

Thanks for any suggestions.

Jack.