Major Meltdown wrt to Queue Behaviour

[AlexA]

Alright,

Attached you'll find a zip of the current project I'm writing. I've got an insane error where an "error" message (a simple string + variant cluster) is loaded into a control queue. When previewed before dequeued, it shows up fine, when dequeued proper it's blank and causes a meltdown.

Steps to reproduce:

1) Fire up "Main Separate Sub VI"

2) Run the Code

3) Look for "Start Calibration VI" on the front panel, bottom left hand side, under a comment that says "Debugging commands only" and hit the button.

4) Watch the sparks fly...

5) Use the abort button to kill the code

Note: I think I've set up the VI path right for the calibration VI, if not, change it to an absolute path which points to wherever it ended up.

So the error you should see, is that a pop up appears saying "The case does not exist in the Sub VI Control Loop please check your spelling" which is my default typo handling case. What's happening is that the calibration VI is looking for a data queue it can latch onto, as it can't find any, it registers an error with the host code, passing the error code along with it's name back to the host. The error code is then loaded onto the common error handling line of the "Sub VI Status Handling" loop and caught by the error handling case at the end of each iteration of that while loop. This is when things get funky.

As mentioned above, the enqueue operation doesn't time out, the "Error+Variant" data message is loaded onto the queue, when the queue is previewed shortly before it's supposed to be dequeued, it shows the element contained within (the "Error + Variant" thing). Once dequeued the message is blank, causing the loop to go into it's default typo handling behaviour.

So my question is obvious I guess. Why in the blue blazes is the "Error" string blank upon dequeue?!

P.S. As a quick side note, I use the exact same method of catching errors within the Calibration Sub VI in it's own control queue. It works clearly as this is how the error is caught and passed back to the host code in the first place.

Queue Error Example.zip

Edited September 29, 2011 by AlexA

[Ravi Beniwal]

Hi Alex,

In your FPGA Control Loop, you have the error wired to a shift register on the while loop. In case of an error, you are enqueuing an error command, but are also passing the error from that iteration f the while loop to the next through the shift register.

So in the next iteration, the Dequeue Element sees the error wired in. It does not execute to pass on the "error" message you enqueued, instead it passes the control with an empty deueued element, which of course will give you an empty string. That is why the loop goes to the default typo handling case.

Fix: either do not use a shift register for error on the while loop, or clear error in the "Error" case, where you are enqueuing the "error" message, so that the Dequeue element can work properly and see this message.

[AlexA]

Hey Ravi,

Thank you very much! I didn't know queues behaved like that (error input true to the queue returns a blank element). That's really weird, why not just have it return nothing, i.e. no dequeue and pass the error cluster?

Once again, thanks for your help!

Kind regards,

Alex

[Ravi Beniwal]

I didn't know queues behaved like that (error input true to the queue returns a blank element). That's really weird, why not just have it return nothing, i.e. no dequeue and pass the error cluster?

Hi Alex, that is exactly what the dequeue element did. It did not dequeue any element and returned "nothing". Nothing in case of a string is an empty string. Also, it passed the error cluster, which is why the error kept circling through the loop and it couldn't even read the Exit message and you had to abort the VI.

[asbo]

I didn't know queues behaved like that (error input true to the queue returns a blank element). That's really weird, why not just have it return nothing, i.e. no dequeue and pass the error cluster?

I don't really understand what you're expecting. A terminal has to pass a value, like on a case structure: each case must wire out a value for every tunnel or you enable default value on unwired. It simply can't pass "nothing", how would LabVIEW know how to handle a wire that could sometimes be "nothing"? This is why the default value being returned makes sense. You can either implement error handling to skip the dequeue if there's an error or use code that will catch when it's been passed a default value.

As an aside, I wish that the Obtain Queue node would use the value of the data type wired in as the default value for that specific queue instead of the default value for the data type.

[Daklu]

As an aside, I wish that the Obtain Queue node would use the value of the data type wired in as the default value for that specific queue instead of the default value for the data type.

Easy enough to implement by extending LapDog.Messaging or rolling your own wrappers.

[asbo]

Easy enough to implement by extending LapDog.Messaging or rolling your own wrappers.

Aye. However, I don't use queues often enough to justify either approach ... yet.

Idea'd it, just for kicks.

[Daklu]

Aye. However, I don't use queues often enough to justify either approach ... yet.

Really? What's your main mechanism for inter-loop communication?

[asbo]

Really? What's your main mechanism for inter-loop communication?

Typically, our projects use an architecture based fundamentally on user events. Despite a little bit of setup on the front end, I've grown to like it quite a bit, which is why I rarely find the need for queues/notifiers/etc.