Probe provides incorrect information about Queue Status

[dbaechtel]

In LabVIEW 2009, the Probe provides incorrect information about Queue Status. I Obtained and Unnamed Queue, did a Flush Queue and the Enqueued  double precision zero values 5 times. A Get Queue Satus function shows 5 elements in the queue, but a Probe placed on the Queue Out (Queue Refnum) wire displays:

     "   [11] queue out     Unnamed - 0 enqueued elements  -   0xbd600008  "

I can not seem to get a Probe to properly display the number of enqueued elements when I place it on any of the Queue Out wires.

Why does the Probe display the wrong number of enqueued elements?

[tbob · Accepted solution]

---

@dbaechtel wrote:

Why does the Probe display the wrong number of enqueued elements?

---

Because its a bug.  I was able to duplicate dbaechtel's findings.  I tried probing at several places and got "0 enqueued" at all places.  Naming the queue does not affect the probe outcome.  This has got to be a bug.  The # elements in queue output from the Get Queue Status is correct however.

[TCPlomp]

A queue is limited to be used only inside the application instance that created the probe (I think that changed in 8.5 or 8.6).

Probes run in a private application instance, so they cannot be used to really see what happens inside a queue.

Creating a custom probe and getting the info should return an error on the status.

I think this is an unwanted side effect of a valid security measure by NI.

Ton

[dbaechtel]

The info that the Probe displayed about the Queue status is incorrect and misleading. It caused me to do some debugging that didn't need to be done. If it can't display accurate info, then it should display nothing at all.

I would be very helpful if it would display the number of enqueued elements properly.

[Ben]

i have to concur with Ton about the context of the probe vs the queue but I am wondering if we are looking at simantics issue (the meaning of words).

In very busy apps we may not be able to insert something into a queue (see queue status for number pendining insert) right away do to the size of teh queue being limited when created.

So I have to ask out loud:

Does that value tell us,

 how many elements are in the queue and can be dequeued

or

how many are waiting to be inserted?

I don't know the correct answer and only someone with access to the Ivory tower can tell us what value really means and then can we hob-nob re: its bugness.

Ben

[dbaechtel]

I think that the Probe should provide the same value as the Queue Status function does. Unless it provides more information, like how many are enquired and how many are waiting to be engueued.

Anything less would be confusing and would probably be misinterpreted.

[tbob]

What Ton said might be right, but that means that probing a queue is useless.  One would expect that probing a queue would give the number of elements inside the queue waiting to be dequeued, or even a list of what is in the queue.  After all the wording in the probe says "0 enqueued elements".  It doesn't say "0 elements waiting to be queued".  Maybe it isn't a bug due to what Ton said, but the information it shows is very misleading.  If it can't accurately display the number of enqueued elements, then it should not display that phrase at all.

[Hueter]

Hey guys

This probe behavior is not particularly helpful and I just wanted to let you know I have reported this to LabVIEW R&D for further investigation (CAR 248107).

Hunter
Applications Engineer

[AristosQueue (NI)]

---

@TCPlomp wrote:

A queue is limited to be used only inside the application instance that created the probe (I think that changed in 8.5 or 8.6).

Probes run in a private application instance, so they cannot be used to really see what happens inside a queue.

Creating a custom probe and getting the info should return an error on the status.

I think this is an unwanted side effect of a valid security measure by NI.

Ton

---

This is all false. Custom probes run in the same context as the VI that they are probing. They always have since we introduced probes in LV 8.0. They still do in LV 2010. Open the attached "RunMe.vi" on your machine, and then probe the only wire on that diagram using the attached custom probe. It should return TRUE no matter which VI you attach it to, indicating that the probe and the VI are in the same context.

I'm not sure where the other problems you're seeing are coming from. I'm going to have to take a closer look at this thread, but I can definitely say there isn't a problem with the probe and I seriously doubt that there's a problem with the Queue Status primitive if only because that hasn't changed in a long time, and we would've heard more complaints about it before now.

[AristosQueue (NI)]

Wow. I take it back. The Queue Status "elements" output appears to return an empty array going back to LV 8.5 -- that's in probes or anywhere else. 

Nevermind. I forgot to set "Return Elemetns?" input to "true." Once I did that, everything works fine.