LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Too many Queues ??

Solved!
Go to solution

I have an application using three USB DAQ devices. USB6212 + USB6001 ( 2nos) 

A main VI handles all the DAQMx read / writes.

Data that is read ( AI and DI ) are passed by queues to other sub VIs.

Data that is to be written ( AO, DO) is sent from sub VIs to the main and written from it. And I also had to bring in a T/F case to prevent error pop up when the SUB VI that sends the data is off-grid when a non hardware operation is underway. 

 

Now if you see the image below the setup will be clear. But to me it looks pretty clumsy and too much of lines... any better and elegant method ??Queues_For DAQMx data.PNG

 

 

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 1 of 7
(2,966 Views)

Something I have done in the past is to take advantage of the fact that the queues can be named so you don't need the reference in most places - just the name.

I created a subVI that encapsulates the queue name, datatype and the obtain reference function. Then in most places I use the queue, I use that subVI to get the reference. This structure means I don't have to run queue references throughout the program.

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 2 of 7
(2,944 Views)

Your screenshot shows lots of duplication yet no subVIs or arrays.  Lots of wires but no clusters.

0 Kudos
Message 3 of 7
(2,929 Views)
Solution
Accepted by topic author MogaRaghu

I've done something similar to what Mike Porter describes.  I made an Action Engine that has all the Queue "actions" except DeQueue.  The Sub-VI has an Icon (of course -- all sub-VIs need Custom icons) that "names" the Queue, with the Default Action being "Enqueue".  My latest version of this had a check to ensure that there was a valid Queue Reference, and if there wasn't, did the Obtain Queue automatically.  There were three inputs:  the Action (default being "Enqueue"), the Queue "element" (used to Obtain the Queue or to Enqueue), and the Queue Size (only used in Obtain).  There were two outputs:  The Queue (used, often by calling the AE with a Status request just to get the Queue) for a subsequent Dequeue function (is it obvious why it is a Bad Idea to have the AE include Dequeue?  Think about it, and don't feel bad if it isn't obvious -- I learned "the hard way" that this was not good), and Queue Size (the only thing returned from a Status Request), which I almost never used.

 

I called these "Wireless Queues", because there were almost no visible Queue Wires anywhere in my Block Diagram.  It made things "neat", but you lost the mnemonic "feature" of visually seeing where the data were flowing (though having data flow "backwards" out the Queue Control was certainly jarring).

 

Now I rarely use Queues -- Channel Wires allow me to have my Metaphor and Neatness, Too.

 

Bob Schor

Message 4 of 7
(2,905 Views)

@Mike Porter

@Bob Schor

Good idea to encapsulate the  Queue creation and have it either as a Single SubVI for each queue or group all into an AE. Thanks.

And the Channel Wires - thats a new learning.  Maybe I will try them out also ... looks  simple and ability to pass meta data is interesting.  

Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 5 of 7
(2,886 Views)

@mikeporter wrote:

Something I have done in the past is to take advantage of the fact that the queues can be named so you don't need the reference in most places - just the name.

I created a subVI that encapsulates the queue name, datatype and the obtain reference function. Then in most places I use the queue, I use that subVI to get the reference. This structure means I don't have to run queue references throughout the program.

 

Mike...


I am also a big fan of this approach. I once inherited a large project that can only be described as a cluster-f*. All queues and notifiers were globally initialised and their references bundled into a huge cluster. Then the references were unbundled (by name at least) anywhere there was any [en|de]queueing. I would often find dequeuers but have to search for literally hours to track down all of its enqueuers and be sure I caught them all.

 

I ended up wrapping the queue entry points in SubVIs.

Now anyone can easily locate the entry points to any queue by right clicking the wrapper SubVI in the project and doing find all instances.

 

Message 6 of 7
(2,832 Views)

Do you need specific queues for each device? I'd go with a DO queue and send the device name as a parameter instead. The datatype would then be a cluster of String and boolean Array. You could probably combine most all the queues into one with a String+Variant cluster.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 7 of 7
(2,828 Views)