Yet another Error 1 at enqueue

[Iron_Bars]

Hi guys,

I hope somebody can help me spot the bug in my VI (attached annotated png).

Hopefully the picture is annotated well enough to be clear. The weird thing is, this error (Error 1 at enqueue) does not occur when the acquisition duration is say 120s @ 1 MS/s, but when I tried 600s @ 100 kS/s, this error occurs. I have a sneaking suspicion that the 5644R can't do such a low sampling rate, but I was not able to find anything to that effect in the manual (maybe I missed it?).

Questions:

1) Why does this error occur? How do I mitigate it?

2) How can I improve my VI a)to reduce TDMS file size b)make it more memory efficient ?

3) Why do LV examples show the producer releasing the queue instead of the consumer?

Thank you!

PS* Thanks to Bob Schor for the empty array signal idea.

[Kevin_Price · Accepted solution]

Up in the toolbar of your block diagram window, right next to execution highlighting, is another tool called "retain wire values" which is also really useful for debugging.  You can run at normal speed, then go back and probe wire values after the fact.

I can't run your code as I don't have similar hardware (or even the corresponding driver -- all the device config stuff just shows up as a sequence of blank placeholder icons.)  But from *inspection*, here's my analysis of what's probably going on.

1. Error 1 for a queue function typically means the queue ref is invalid.  So we've gotta figure out how this could happen.

2. From experience, it's highly unlikely that the function "Obtain Queue" failed in the first place.  Either the queue ref going into the loop tunnels is valid OR the hardware config threw an error, and Obtain Queue outputs an invalid queue ref *and also* passes through the hw config error rather than Error 1.

    I figure it must be the former situation.

3. So now, how can a once-valid queue ref become invalid?  Well, it becomes invalid when it's released.  So how can *that* happen?

    The queue is released after the lower consumer loop terminates.  Termination happens if an empty array is received.

4. How might the producer send an empty array?  There appear to be 2 ways.

• The attempt to read data from the hardware device returns an empty array.  Perhaps this is due to an error while reading the hardware -- but you won't know because errors aren't being checked or handled anywhere in the upper producer loop.
• Either your elapsed timer fires or the "stop" button is clicked on the GUI.  This looks like your intended ending condition because you forcibly deliver an empty array to the Enqueue function.

5. Since you're puzzled by the error, I suppose it's probably that the hardware read is returning an empty array for some reason.  Maybe due to an error, maybe something else.  I'm not familiar with your device or it's API.  But that seems like the place to investigate.

-Kevin P

[Bob_Schor · Accepted solution]

I agree with Kevin's analysis -- is there any way the Function at 4. could produce an empty array?  You could put a probe on the array wire inside the False case of 5. and check it ...

Can't you get rid of those messy Frames?  You are using the Error Line (maybe too much -- do you really need two in each of the Producer and Consumer loops?  It does, I grant, keep the "alternating sequential flow" better organized, but (for example) if there's an error in the TDMS line, you might never know about it.  If you do want two Error Lines, branch them at the beginning, say, of the Consumer Loop and merge them at the end.  Look at how much neater the Consumer loop could look:

Notice no Frames!  Also notice that if the Queue is not Empty (the False condition), you use the Queue elements and write to TDMS.  What if the Queue is empty (meaning "the Array in the Queue is an Empty Array)?  Well, you are done, so close the TDMS file!  No need to hide it, and no need to write "empty data" to TDMS.

But then I noticed that this whose Code sequence is in another Case Statement -- what's the False case?  Well, you are doing another Dequeue.  Why?  There's some sloppy logic lying in wait here (not to mention that you are using abusing Stop with a Local Variable instead of using the Sentinel ... For Shame!

Bob Schor

[Iron_Bars]

Bob and Kevin,

Thank you for your time, tips and insights. I don't know why, but on rare occasions, the first frame written to the HW buffer is an empty array. This seemed to occur at low sampling rates (kS/s). However, it could have been the error wire mess I had going.

Aafter implementing your suggestions (remove frames and redundant case statements, consolidate error wires), this error no longer occurs, even at low sampling rates. This can be considered solved.

I will revisit this with better debugging when I get the chance. It was great to learn something new. Is there a "best practices" doc I can read to avoid such basic pitfalls?

PS:

Kevin: Installing NI-RFSA and RFSG drivers will enable those initialization blocks that show up as white boxes in your installation.