LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
Showing results for 
Search instead for 
Did you mean: 

probe dequeue

The idea is pretty simple. When I probe an enqueue, I don't want to just see what is being placed on the queue, I want to see where that value is being de-queued.


I have a large legacy project which has a lot of inter-process communication. Queues are used for a lot of this. When I look at code where an element is enqueued, my debugging or code review comes to a screeching halt because I don't know where the data is being dequeued. The project does not use named queues.


This is mostly not a matter of a GUI process communicating with a command and control process in the same VI. It is more of a matter of dynamically loaded drivers passing data back to one of several other processes as conditions change.


I think that I can figure this out with the Trace Toolkit, but it would be cooler if I could just put down a probe and have it tell me where the Dequeue is. (If there were some kind of design time tool that I could use to map the Queue references this would be the coolest of all.)


I know adding a picture helps get the idea across, so here is a fast mock up. Note the red circle in the lower right.

Dequeue Probe Example

Knight of NI

I don't see how NI can possibly make your idea work.  For one, while not recommended, it is possible to have multiple dequeue functions for a given queue reference.  What should the probe indicator show?


Probes should show information about the data that is on the wire during execution.  Information that is related to our your program is architected (e.g. where queue references are used) does not belong in a probe indicator.


Possibly the probe indicator would show which ever instance of the dequeue actually dequeued the element that was enqueued. Possibly it would show all the dequeues that have used the same reference as this would be very important information to a developer. It seems like wiring two dequeus to the same reference accidently would be a difficult to debug situation in any moderately sized project.


Let's not get hung up in details. The essence of this idea is to give the developer immediete information about how dequeues and enqueues are related. If you think a probe is inapropriate then what tool do you suggest as a substitute?


As for impossibility, you can already connect these dots by using the Desktop Execution Trace Toolkit which keeps track of enqueue and dequeue and which VIs they happen in. The down side is the bookkeeping to match the Queue reference numbers. Since there is already a computer involved, why not automate this process?

Active Participant

In a more general sense, it seems that you're asking for a probe that attaches to an item of data, rather than to a wire, and tracks in through the program execution.  I think that's worthy of some discussion.  Here's a few possibilities I could see:


  • Imagine if you now put a breakpoint on that DataProbe, and were able to single-step through all computations on that data, but everything else ran normally.
  • Or if there was a buffer duplication, that probe was also duplicated, so you could track memory allocations in the debugging process, not just showing the "dots".  That seems useful for not only queues, but also arrays, and objects.
  • A "history DataProbe" could retain a buffer of changes to that data, so rather than needing to place probes before and after a computation, it would accumulate a scrollable array of changes.

I could imagine some of those things being very useful in debugging.

Example Gatekeeper
Status changed to: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

DNatt, LV R&D