queue error handling

[Pappion]

From 2012 LabVIEW help for most Queue functions:

 "This node runs normally even if an error occurred before this node runs."

Tested True for Release Queue, but False for others: Enqueue, Dequeue, Status, Preview, etc..

They only produced the Enum U16 default "0" with no waiting.

So, this means my state machine needs 2 Error Cluster branches so I can cleanly power down and exit my test app.

Still would be easier if it worked like Help suggested. It would be better if Help was right too.

[Michael_78]

I agree the help IS wrong! I have never noticed this before. Asfor the behaviour, it is what I would expect.   I have seen many people say never wire the error terminals on queue functions, I have not decided which is the best approach, I think not wiring the errors is bad practice and the easy option, but wiring the errors needs very careful consideration.   I hope we get some more oppinions on this thread, and I suggest the documentation error is highlighted to NI for a CAR to be raised.

Michael.

[kbbersch]

I confirm this functionality and that the help is incorrect.  I believe this is incorrect functionality.  I also agree that not wiring the error terminals is not best practice but it looks like a good solution here.

While playing around with this I also noticed that something that I wasn't prepared for and am not sure if this is correct functionality or not.  If you wire a timeout value to the read queue function and it times out because nothing is placed on the queue what does the queue output?  Obviously the Timed out? boolean is true but if the data type is a typedef enum the output of the queue will be the first item of the enum.  I'm still thinking about this.  Is this proper functionality or not?

[billko]

---

@kbbersch wrote:

I confirm this functionality and that the help is incorrect.  I believe this is incorrect functionality.  I also agree that not wiring the error terminals is not best practice but it looks like a good solution here.

While playing around with this I also noticed that something that I wasn't prepared for and am not sure if this is correct functionality or not.  If you wire a timeout value to the read queue function and it times out because nothing is placed on the queue what does the queue output?  Obviously the Timed out? boolean is true but if the data type is a typedef enum the output of the queue will be the first item of the enum.  I'm still thinking about this.  Is this proper functionality or not?

---

Hmmm, I would think that you would have proper error handling and the only reason why an error would reach the node is because it was unhandled, in which case it is probably safer NOT to execute the queue function and then have the unhandled error finally force the queues to be released at the end of the loop.

[RavensFan]

The functionalities are correct for each of the functions.  The help file is wrong for each of the functions.

Most of the queue functions should have standard error functionality which means they run normally if there is no error coming in, but don't run and just pass the error through if there is an error.  So those functions should NOT have the 2nd sentence of "This node runs normally even if an error occurred before this node runs."

The  Release Queue function does not and should not have standard error functionality.  It should release the queue even if an error comes into.  The help says:  (I added the bold and italics for emphasis)

"With the following exception, this input provides standard error in functionality.

This node runs normally even if an error occurred before this node runs."

It looks like those same two sentences were just copied and pasted among all the help files to all of the other queue functions incorrectly.  The other queue functions should not have the "with the following exception," nor the second sentence.

The online help for LV 2013 looks like it is wrong also.  http://zone.ni.com/reference/en-XX/help/371361K-01/glang/create_queue/  Looking in the help file for LV 2009, the help files are correct.  The online help for LV 2010 and 2011 looks like they are stated correctly as well.

[kbbersch]

---

@RavensFan wrote:

The functionalities are correct for each of the functions.  The help file is wrong for each of the functions.

Most of the queue functions should have standard error functionality which means they run normally if there is no error coming in, but don't run and just pass the error through if there is an error.  So those functions should NOT have the 2nd sentence of "This node runs normally even if an error occurred before this node runs."

The  Release Queue function does not and should not have standard error functionality.  It should release the queue even if an error comes into.  The help says:  (I added the bold and italics for emphasis)

"With the following exception, this input provides standard error in functionality.

This node runs normally even if an error occurred before this node runs."

It looks like those same two sentences were just copied and pasted among all the help files to all of the other queue functions incorrectly.  The other queue functions should not have the "with the following exception," nor the second sentence.

I don't have access to LV 2013 at the moment to confirm it is still wrong.  Looking in the help file for LV 2009, the help files are correct.

---

After thinking on this awhile then reading that I agree with RavensFan.  The help file is wrong but the functionality is correct..  It reads the same in 2013 so it seems the incorrect help was simply carried forward.

[RavensFan]

---

@kbbersch wrote:

While playing around with this I also noticed that something that I wasn't prepared for and am not sure if this is correct functionality or not.  If you wire a timeout value to the read queue function and it times out because nothing is placed on the queue what does the queue output?  Obviously the Timed out? boolean is true but if the data type is a typedef enum the output of the queue will be the first item of the enum.  I'm still thinking about this.  Is this proper functionality or not?

---

That is correct functionality.  It is actually sending out the default value of the control.  It just so happens that most of the time, the default value of an enum is probably the first value.

The function as to return some value, and the default value is the most logical to return.

[kbbersch]

---

@RavensFan wrote:

---

@kbbersch wrote:

While playing around with this I also noticed that something that I wasn't prepared for and am not sure if this is correct functionality or not.  If you wire a timeout value to the read queue function and it times out because nothing is placed on the queue what does the queue output?  Obviously the Timed out? boolean is true but if the data type is a typedef enum the output of the queue will be the first item of the enum.  I'm still thinking about this.  Is this proper functionality or not?

---

That is correct functionality.  It is actually sending out the default value of the control.  It just so happens that most of the time, the default value of an enum is probably the first value.

The function as to return some value, and the default value is the most logical to return.

---

I was leaning this way as I couldn't see a way for the queue to output a null.

[Michael_78]

For the reason of default values, I ALWAYS make the first item in an enum used for states either Error or Exit rather than Initialise.  If an error gets unhandled at least I know about it and dont get wirerd behaviour which is difficult to debug- like re-initialising half way through a program.  If I have a string based state machine i generally assume and empty string came from a bad de-queue and handle as such, and i handle any other unknown string as a state typo.

Michael.

[johnsold]

Michael,

Good points.

Lynn