02-12-2015 02:49 PM
Sorry, linked wrong image.
02-12-2015 02:53 PM
If you've already removed the dequeue inside the case structure in the consumer loop, the next step is to make sure you're actually getting into the stop case in your consumer. probe the output of the dequeue and highlight execution. Do you actually go into that case?
02-12-2015 02:58 PM - edited 02-12-2015 03:00 PM
GarryG - I updated the jpg on the previous page to show the new Dequeue. I just grabbed the wrong image.
Here's the new VI if you want to run it yourself. You can get the controls from my first post.
Here is the front panel after Stop has been pressed. You can see that the state at the case structure is Stop.
02-12-2015 03:22 PM
Attach your control (typedefs).
02-12-2015 03:24 PM
They are the same as the ones in my first post.
02-12-2015 03:24 PM - edited 02-12-2015 03:25 PM
The problem is still there, you are trying to read a message from your queue AFTER you have read the stop message which is the last message in the queue so you are waiting for another message to arrive before you can stop the consumer. If you add a timeout to your second dequeue or simply remove it you should not have any problems.
Why do you need two dequeues in the consumer anyway? You are only going to be losing data by doing that, the appropriate way to do that would be to take the data retrieved from the first dequeue and pass all of that into the case structure to be handled.
You can tell that you are not getting into the case structure as your message string out is not updating.
02-12-2015 03:28 PM
Check out the updated code.
02-12-2015 03:35 PM - edited 02-12-2015 03:36 PM
OK, I think I'm getting this. Thanks Garry, it works now.
Updated code:
02-13-2015 07:13 AM
The lesson to be learned here is that you should only ever have 1 Dequeue Element for a given queue.