Queue Reference on a DVR?

Hi All,
I am trying to track down a bug in my code to no avail (so far). I wanted to check if my problem is caused by a 'feature' in LabVIEW while I continue to tear (whats left of) my hair out.....
Here is what I'm doing:
I create my 'communication queues' in my toplevel vi. These are unnamed. My toplevel vi is a queue-based state machine. I'm using OO by reference. Therefore the place where I've stored my reference is Object>DVR>Cluster>queue reference.
Using the toplevel.vi I kick off a user interface. I do this by using Static VI reference>SetVal to pass the object/DVR value to the UI and then >Run (wait til done false) to start the UI.
And here's the problem: when put an element on the toplevel state-machine queue using the UI its not received by the toplevel state machine.
Here's what I've looked at to try and find out what the problem is
The element is placed in the queue with no errors
The references are valid
One this I did notice is that when I probed the reference hex numbers they are different - my understanding was creating a new queue reference by name would give two different references to the same queue in memory (and so they have to be closed). But in my case I only create one reference to the queue, put it in my DVR and remove it as needed.......so what are the values different?
I've used this same architecture already in this project but in this case I didn't put the queue references on the DVR - instead I opened new references by name whenever I communicated between modules. This worked fine......but I'd prefer not to restrucutre my code if I can avoid it!
If anyone can offer suggestions that I can check or indeed if this is a 'feature' which has come up before I'd appreciate any comments,
Thanks,
Dave
Solved!
Go to Solution.

Hi All,
Please disregard the comments about the reference hex numbers being different - I built a very simple test program to make sure performance was correct and found that it was. In my test code both reference numbers are identical as should be expected! Its a common/garden bug causing my problem not a LabVIEW 'feature'......just gotta find the bugspray now!
Dave

Similar Messages

Opening/Closing Queue Reference By Name

I'm curious if opening and closing a queue reference to put information onto the queue, using the queue name -> obtain queue -> enqueue -> release queue(Non Force) is problematic. I thought i saw a thread a long time ago that opening/closing a reference to a queue over and over could lead to a memory leak, even if the original queue never was released. Obviously, i'm ignoring the general pass the wire(by value) correct labview way.
Instead of opening/closing using the queue name i could also wrap the queue reference in a FG after originally creating it and work on the reference that way. Ignoring the "right way to do it" are there still downsides, other than programing correctly, to open/closing queue reference's in this fashion such as memory leaks.

PaulG. wrote:
I have never heard of any unwanted consequences of repeatedly opening and closing any reference. The trick is to make sure a reference gets closed when no longer needed. I don't see any reason not to implement queues the ways you describe. I've done all three and haven't had any issues that I know of. If opening and closing a queue reference repeatedly caused a memory leak that would be considered a bug.
I have to disagree here. A couple of years ago I was using a DAQmx Write with "autostart" option set to TRUE in a loop (ca. 100ms timing) to constantly make sure, that in application standby my Digital Outputs kept the values they ought to have. This reproducibly caused a blue screen on Windows after 6 hours of the program running in standby. As it turned out, LabVIEW was using a new reference to the task for every call of the Write, because with autostart set to TRUE it had to create the task beforehand and close it afterwards. After the mentioned peroiod of time, LabVIEW ran out of reference numbers, as the support explained to me.
Of course, even LabVIEW Help says to avoid using autostart=TRUE with DAQmx VIs in a loop, but only because of the overhead the repeated Create and Clear is consuming. Naturally, I have learned that the hard way now.
So - Create the reference once, use that same reference all the time (FG is fine, I think - I use this method for obtaining my logfile reference all over the place!) and close it only, when you don't really need it anymore.

When do VI and queue references become invalid?

Hi all,
I have a fairly complicated problem, so please bear with me.
1) I have a reentrant SubVI (let's call it VI "Assign") that has an input cluster of (VI ref, queue ref) (let's call the cluster type "Refs"). If the VI ref is invalid (first execution), the VI ref and queue ref are assigned values and are passed on as an output cluster of same type. (The VI does other things too, but for simplicity only this is important.)
2) The VI that calls VI "Assign" (let's call it VI "Store") is not reentrant and has a local variable of type "Refs" that is wired to the input and output of VI "Assign". This VI effectively stores the references. The references returned by VI "Assign" are always valid right after the call, but after the problem condition described below, they are invalid at the start of all calls before they are passed to VI "Assign".
3) VI "Store" is called by multiple non-reentrant VIs, so the local variables of VI "Assign" retain their values (Has been tested and verified to retain their values). The VI causing the problem in this case is a template VI of which multiple copies are launched (let's call it VI "Template").
The problem is that the moment an instance of VI "Template" is closed, the queue reference becomes invalid, although the actual variant value of the reference remains the same. The VI ref can become invalid or not, depending on small changes, but is always reproducible. I assume there must be some similarity between VI and queue refs. After spending some time researching, the Labview help states for the Open VI Ref component "If you do not close this reference, it closes automatically after the top-level VI associated with this function executes." In this case I assumed it means that the moment the reentrant VI "Assign" finishes, the references will get cleared ?? So I made a non-reentrant VI (let's call it VI "NR Assign") that only assigns values to the references and VI "Assign" now calls this VI (It effectively does what I described VI "Assign" does). I keep this VI alive by using it in a VI which never terminates and since it never terminates, the references should never become invalid. Anyone still following? This didn't solve the problem though. If I reproduce the same scenario using only one instance of the template VI, it works just fine. Furthermore, the VI and queue references are never closed, to aid analysis of the problem. Can anyone shine some light on what happens when a template VI terminates? Could this be the problem?
Unfortunately I cannot include the code.
Thank you whoever is able to make sense of this.
Christie

Christie wrote:
Hi all,
I have a fairly complicated problem, so please bear with me.
1) I have a reentrant SubVI (let's call it VI "Assign") that has an input cluster of (VI ref, queue ref) (let's call the cluster type "Refs"). If the VI ref is invalid (first execution), the VI ref and queue ref are assigned values and are passed on as an output cluster of same type. (The VI does other things too, but for simplicity only this is important.)
2) The VI that calls VI "Assign" (let's call it VI "Store") is not reentrant and has a local variable of type "Refs" that is wired to the input and output of VI "Assign". This VI effectively stores the references. The references returned by VI "Assign" are always valid right after the call, but after the problem condition described below, they are invalid at the start of all calls before they are passed to VI "Assign".
3) VI "Store" is called by multiple non-reentrant VIs, so the local variables of VI "Assign" retain their values (Has been tested and verified to retain their values). The VI causing the problem in this case is a template VI of which multiple copies are launched (let's call it VI "Template").
The problem is that the moment an instance of VI "Template" is closed, the queue reference becomes invalid, although the actual variant value of the reference remains the same. The VI ref can become invalid or not, depending on small changes, but is always reproducible. I assume there must be some similarity between VI and queue refs. After spending some time researching, the Labview help states for the Open VI Ref component "If you do not close this reference, it closes automatically after the top-level VI associated with this function executes." In this case I assumed it means that the moment the reentrant VI "Assign" finishes, the references will get cleared ?? So I made a non-reentrant VI (let's call it VI "NR Assign") that only assigns values to the references and VI "Assign" now calls this VI (It effectively does what I described VI "Assign" does). I keep this VI alive by using it in a VI which never terminates and since it never terminates, the references should never become invalid. Anyone still following? This didn't solve the problem though. If I reproduce the same scenario using only one instance of the template VI, it works just fine. Furthermore, the VI and queue references are never closed, to aid analysis of the problem. Can anyone shine some light on what happens when a template VI terminates? Could this be the problem?
Unfortunately I cannot include the code.
Thank you whoever is able to make sense of this.
Christie
All LabVIEW refnums do get deallocated automatically when the top-level VI in whose hierarchy the refnum was created goes idle (stops executing). You will have to make sure that the creation of a refnum is done inside a VI hierarchy that stays running for the entire time you want to use that refnum.
Rolf Kalbermatter
Message Edited by rolfk on 06-27-2007 11:52 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Mini-Nugget Creating Typedef'd queue references

Transfering typedef'd data using queues used to be tedious if the typedef changed and the transfering queue reference is passed between VI's using controls. The tedious part was updating all of the controls for the queue ref since they would not be linked to the typedef of the data the queues transfers. This Nugget exaplains how to create a queue ref that is tied to a type definition.
1) Drop an obtain Queue
2) Create, drop, and wire a typedef of the data that will be transfered by the queue.
3) pop-up on obtain Que output and select "Create Control"
4) Find created control and pop-up to select Advanced >>> Customize
5) In control editor use the control palette >>> "Select a Control ..." and browse to the typedef from step #2
Note:
A) The typed must be dropped on the pink boxes
B) The marching ants around the queue ref control confirms you are dropping in the correct location.
6) Save the queue ref control as a type def.
If you look at your hiearchy you will see that the typedef'd queue ref is using the type def from step #2.
I hope this helps!
Ben
* This works in LV 8.6 but not in LV 7.1. I am not sure in which version the feature was introduced.
Message Edited by Ben on 11-11-2008 02:21 PM
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Solved!
Go to Solution.
Attachments:
Drop_Obtain_Que.JPG ‏19 KB
Drop_n_Wire_Typedef.JPG ‏21 KB
Drop_TypeDef_in_Control.JPG ‏41 KB

That sounds about right. I started doing this about LabVIEW 7.0 when I started using single-element queues for reference objects. I always used the "create control, customize, save" method for creating the strict typedef reference, since it did not update correctly by itself in 7.0. There were a lot of changes made in 8.0, some of which resulted in some fairly nasty crashes and hangs on type propagation (always modify your cluster with nothing else open in 8.0). These were fixed in 8.2. At this point, type propagation seemed to work OK. However, I have been through a lot of versions of LabVIEW and have learned never to trust my memory on things like this. Try it. If it works, you are good .
This account is no longer active. Contact ShadesOfGray for current posts and information.

Queue Reference Based issued

Hi all..could anyone tell me how i should fix the problem that i am struck here? I try to implemented an queue on my own. but i change sth in that queue.. i try not to use isEmpty() to keep track of the element in my queue..(it work fine if i use isEmpty()....) instead of using size() to keep track if it is an empty stack...but i got a little bit problem here..it call the exception automatically..and i am not expecting this result
=========================
javac QueueTest.java
Exit code: 0
java QueueTestThe queue is empty
0 1 2 3 4 5 6 7 8
EmptyQueueException on peek:queue empty <<- error occur here.ithould not appear.
Exit code: 0=====================
expected result
=========================
javac QueueTest.java
Exit code: 0
java QueueTestThe queue is empty
0 1 2 3 4 5 6 7 8
Exit code: 0=====================
my code is as following
QueueTest
public class QueueTest
     public static void main(String[] args)
          QueueReferenceBased aQueue = new QueueReferenceBased();
          if(aQueue.size() == 0)
          //if(aQueue.isEmpty())
               System.out.println("The queue is empty");
          for(int i=0; i < 9; i++)
               aQueue.enqueue(new Integer(i));
          try
             //while (!aQueue.isEmpty())
             //while(aQueue.size() != 0)
             while(aQueue.size() != 0)
                  System.out.print(aQueue.peek() + " ");
                  //System.out.print(aQueue.size() );
                  aQueue.dequeue();
            // System.out.print(aQueue.size() );
          //aQueue.peek();
          catch( EmptyQueueException eqe)
               System.out.println("\n" + eqe.getMessage());
}===
QueueReferenceBased
// File: QueueReferenceBased.java
// Author: Chi Lun To (Ivan To)
// Created on: June 5, 2007
public class QueueReferenceBased implements QueueInterface
private Node lastNode;
private int numberOfItems = 0;
public QueueReferenceBased()
      lastNode = null;
// queue operations:
public boolean isEmpty()
    return lastNode == null;
public int size()
       return numberOfItems;
public void enqueue(Object newItem)
{ // insert the new node
    Node newNode = new Node(newItem);
   // if (isEmpty())
    if(lastNode == null)
// if(size()==0)
           // insertion into empty queue
          newNode.setNext(newNode);
    else {
          // insertion into nonempty queue
          newNode.setNext(lastNode.getNext());
           lastNode.setNext(newNode);
    lastNode = newNode; // new node is at back
      numberOfItems++;
public Object dequeue() throws EmptyQueueException
      // if(!isEmpty())
//if (!(size() == 0))
if(lastNode != null)
           // queue is not empty; remove front
           Node firstNode = lastNode.getNext();
           if (firstNode == lastNode)             // special case?
                    lastNode = null;                  // yes, one node in queue
          else
                    lastNode.setNext(firstNode.getNext());
                    numberOfItems--;
          return firstNode.getItem();
    else {
          throw new EmptyQueueException("EmptyQueueException on dequeue:" + "queue empty");
} // end dequeue
public Object peek() throws EmptyQueueException
      if(lastNode != null)
      //if (size() != -1)
      // queue is not empty; retrieve front
      Node firstNode = lastNode.getNext();
      return firstNode.getItem();
    else {
      throw new EmptyQueueException("EmptyQueueException on peek:"+ "queue empty");
} // end QueueReferenceBased===
the code u could omit ..but just for better unstanding ..thx
node
public class Node {
private Object item;
private Node next;
public Node(Object newItem) {
    item = newItem;
    next = null;
} // end constructor
public Node(Object newItem, Node nextNode) {
    item = newItem;
    next = nextNode;
} // end constructor
public void setItem(Object newItem) {
    item = newItem;
} // end setItem
public Object getItem() {
    return item;
} // end getItem
public void setNext(Node nextNode) {
    next = nextNode;
} // end setNext
public Node getNext() {
    return next;
} // end getNext
} // end class Node====
QueueInterface
public interface QueueInterface
//public boolean isEmpty() ;
public int size();
// Description: Determines the number of elements in a queue.
//                    In other words, the length of a queue.
// Precondition: None.
// Postcondition: Returns the number of elements that are
//                        currently in the queue.
// Throws: None.
public void enqueue(Object newElement);
// Description: Adds an element at the back of a queue.
// Precondition: None.
// Postcondition: If the operation was successful,
//                        newElement is at the back of the queue.
// Throws: None.
public Object dequeue() throws EmptyQueueException;
// Description: Retrieves and removes the front of a queue.
// Precondition: Queue is not empty.
// Postcondition: If the queue is not empty, the element
//                       that was added to the queue earliest
//                       is returned and the element is removed.
//                       If the queue is empty, the operation
//                       is impossible and QueueException is thrown.
// Throws: EmptyQueueException when the queue is empty.
public Object peek() throws EmptyQueueException;
// Description: Retrieves the element at the front of a queue.
// Precondition: Queue is not empty.
// Postcondition: If the queue is not empty, the element
//                        that was added to the queue earliest
//                        is returned. If the queue is empty, the
//                        operation is impossible and QueueException
//                        is thrown.
// Throws: EmptyQueueException when the queue is empty.
} // end QueueInterface=====
public class EmptyQueueException extends Exception
     //Parameterized constructor
     public EmptyQueueException( String s )
          super( s ); //inherits the existing functionality of the Exception class.
}

i try not to use isEmpty() to keep track of the
element in my queue..(it work fine if i use
isEmpty()....) instead of using size() to keep track
if it is an empty stack... and this is a complete red herring. isEmpty() just returns size() == 0. The two are completely equivalent and there is no possibility that one worked when the other didn't.

GOOP queues and other stored references

need to ask this because Im not at the target machine to try it myself until Monday.
Re Endevo by ref Goop Wizard 3.0.5
I am using queues in process objects.
WHen I create the object I create the queue and store the queue reference in the attributes of the object.
Then I use the queue for controlling public status and shutdown functions etc..
Question is the following.
I ran into a glitch today whereby the queue refs and some other refs go invalid while the Goop repository is showing "live" objects.
The values of the refs are intact but they are invalid
Anyone have any Idea what I am describing?
Thank You
PS: I hope this isn't simply Labview not running. How can that be when I am using the object inspector. I don't yet get it.

No I do not think it is an error.
It turns out the queue and DAQ Task references go invalid because of the relationship of the endevo GOOP object to LabVIEW. (or so it seems) I think it is because the VI that created the object goes idle and so LabVIEW assumes the ref is no longer needed (despite any options settings. )
I am seeing the objects in the Goop repository however references to queues and Data acquisition tasks are invalidated as
soon as the VI that uses them goes idle.
It does not seem to afffect field point references or VIsa com ports and also all other data in the goop object seems fine. I guess thats because FP and VIsa are only strings
Its a real snag to me because I did not see it coming. Now I have to create the queue and reestablish the Daq tasks to insure it is valid
after the create method even if the object exists.
I prefer to use the create or look up existing feature of the method because it gives a lot of flexibility.
Thank You

Control/file references closed and reused

See attached example. I realized that you can reuse a control reference even after it is closed, and this does not applied to file reference. Why is that?
Kudos and Accepted as Solution are welcome!
Solved!
Go to Solution.
Attachments:
refclose.vi ‏14 KB

I didn't look at the example, but the general answer is simple - a control reference simply points to an existing control. As long as the control is still around (because LV keeps it around), closing the reference does nothing, because LV still needs it and it knows that.
A file reference, on the other hand, is something that you create yourself. Closing the reference also releases all the resources used by that reference, making it invalid. The same would apply to other type of references, such as DVRs, queues, TCP refnums, etc.
Try to take over the world!

VI Fails to send queue elements

I am trying to use a queue to send data from my pulse train subVI to my main VI.
After my pulse train completes, I send a TRUE boolean via the 'Enqueue element' which goes to the 'Obtain Queue' and then to the Dequeue Element to acquire and log data.
I am not sure why the data is only sent the first time, and not consequentially.
I've tried the same with the Notifier to no awail. I am not sure if this is an issue in my SubVI or my main VI.
I am not sure if this is correct? Do I need to release the reference or something?
Thanks!

belopsky wrote:
Thanks - I tried that in a while loop, also tried probing the queue prior to it - would this probe list all of the elements queue up?
If so, the additional elements never enter the queue....
Probing the queue reference will not show the elements in the queue.
If you are sure you are not getting more elements in your queue, then it is a problem with your producer loop. Are you sure that loop isn't waiting for a message in order to do something that would then add an element to your queue?
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Releasing Queue in Producer Consumer model

I am having a VI which reads data from ethernet,writes to disk,processes and displays. Since lot of processing and displays are there, I am converting it to a Producer- Consumer model so that no data is lost.
I am using 2 loops. IN the Producer I am doing the UDP read and Write to disk functions.and use the enqueing also.In the Consumer loop I am dequeing it and do all the processing and displays.My idea is to avoid any data loss in UDP reception and file writing.
My confusion- where to use the release queue?from the Producer or Consumer ? In a third loop ? Should it be in a sequence structure ?
How to set the loops stop conditions ?
My requirements for stopping - when I press the stop button the program should stop completely(the Consumer loop should stop only after dequeing and processing all the data in the queue). If i don't press the stop button the whole program should run continuously (if data does not arrive for some time it should wait without time out-i am using -1 for the time out condition in UDP read.)

Here is the ultimate Producer-Consumer loop. It queues a stop command when the stop button is pressed. This ensures that every element is dequeued and processed before the bottom loop stops. The last queue data to get processed is the stop command because after you press the stop button, the top loop stops enqueueing more elements.
If your data type is other than a string, you can create something to represent stop, like NaN for a numeric.
Notice the shift registers. This is good practice. Every loop starts with an error out of the previous loop. If an error occurs, it is passed on to the next loop iteration. Also, if an error occurs in the consumer loop, the loop stops. It is good practice to put shift registers on the queue reference also, but not necessary in this case. If you use a For loop, and the loop iterates 0 times, the output of the queue reference would be a null reference, and the Release Queue would not release the queue. With While loops, they always iterate at least once, so it isn't necessary. Its just good practice to make a habit of using shift registers so you don't forget when using For loops.
Notice also that the error in to the Release Queue is not wired. If there were an error, the Release would not take place. All errors are merged at the end to report exactly where an error occured. A timeout is included in case an error prevents the stop command from being enqueued or dequeued.
- tbob
Inventor of the WORM Global
Attachments:
ProducerConsumer.vi ‏53 KB

Best way to link queue type to data typdef

I am using "Obtain Queue" to create a multiple queues from multiple TypeDef formated data clusters. I want to then put these queue references in a cluster of their own so I can refer to them where necessary in my code. When I modify the data types by editing the corresponding typdefs I would like for the queue references to change accordingly. In other words I think I need to link the queue references to the data typedefs. What is the best way to do this?
For instance, If I create a cluster of queue rerences using bundle by name I would have to create an input cluster with a format that would update as I change my origianl data typedefs. Can this be done, and if so how?
Possibly the "problem" is due to my dsire to have a nice "bundle by name" cluster for clarity in my code. I suppose if I used an array this isn't a problem. That is not as elegant a solutions, but I guess elegance is sometimes in the eye of the beholder.
Any suggestions?
Solved!
Go to Solution.

Did you replace any constants that you had on the block diagram with the typedefed version? All instances that you ar eusing need to use the typedef.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Queue data sharing between multiple LabVIEW Executables

I have 2 LabVIEW Executables(Exe) where one Exe produces data and other one consumes the same. Is there anyway I can use a single queue reference for the same ? First Exe obtains the queue reference number and stores the reference number in V.I.G where as the second Exe read this reference number from this V.I.G. The error from the second VI dequeue was invalid queue reference.
Is there anyway I can share the same data between different exes with the functionality of a queue ?.
Solved!
Go to Solution.

Ben wrote:
Each exe is mapped into its own memory space so refs to resource in one context will not work in another but...
If you exposed an Action Engine in one instance to be used via VI server Invoke Node from the other, the AE (Note: it will be running in the server context) could queue the data in behalf of the client.
Plese note:
If the server porcess goes idle all of its resource will be invalidated (including the queue) but a ref to the AE will still be valid. In this case the enqueue op will fail so you have to code to account for this situation. (been there done that )
This smae approach will work in any network architecture where VI serve can be used. I used this approach about 10 years ago (minus the queue) to allow control of a factory floor from a laptop with a internet connection.
Ben
Do you think the same must work with following scenario:
1. LabVIEW Exe calling a data acquisitio thread dynamically(VI Server) and enqueue the data into a Queue with reference in VIG.
2. Same Exe calling a TestStand Engine and one sequence inside that calling the same queue to dequeue the data.
3. Remember that the LabVIEW adapter I use with TestStand is LabVIEW Run-Time Engine(Not development system)

Queue Issue, reentrant/multiple calls

I have a slight problem using queues. I've read the posts that are close to my problem but i haven't figured out how to solve my case.
I have a "main window" where i want the queue to show constantly. Then i have 5 places that can add values to a single queue to be tested with a specific equipment. Even if i use 1 name for the queue the reference when obtaining the queue changes (read in a post). So i'm not able to modify 1 queue from 4 different places. I don't think it's appropriate to link from the "main window" the queue reference into the 5 places it should modify them.
So how should i solve my case? With reading the queue status from a Global Variable (not good solution)?
Attachments:
1.png ‏19 KB

When you open a queue by name you get a different queue ref to the same queue.
So you should be able to load the queue inside your subvi and post messages to the main VI without passing the reference around.
Be aware queues are bound to the application instance and you can't use them in a different app instance.
Just make sure that you keep the queue alive. So don't close it immediatly after writing to the queue.
Ton
Message Edited by TonP on 07-26-2007 01:20 PM
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas
LabVIEW, programming like it should be!

How to implement a configurable queue datatype?

I have an LV6.1 application that uses queues to transfer cluster data from one VI to another. I want to be able to (re-)define the cluster make up in one place, and have both the sending VI and the receiving VI adapt. As a relative newbie, am I missing a well known way of effectively defining a datatype and then using it in several VIs?
If it makes it any easier, the variable part of the cluster is a 2 dimensional array, whose size may change. Otherwise the cluster makeup is fixed.
On a related point, how do I pass a typed queue reference from one VI to another? I've found that if I wire a queue ref, then change the queue type, I have to delete and rewire the ref to get rid of errors?
Ian

Yes, it's a reference to the original cluster. Try these "new" VI version: when you choose (with go!) to dequeue the elements, the value visualized is the value actually present on the front panel (which is the object referenced), while with the "pass value" version, all the values are visualized.
Bye, L.
Attachments:
new_queue_ref.zip ‏32 KB
queue_value.zip ‏35 KB

Is it possible to get the element data type of a Queue from itself?

Hi everyone,
i have a Q that has a cluster as element data type.
now when i want to enqueue
i'll use bundle-by-name
and for that i'd have to have my data-type present
(long cable from whereever (possibly from where i obtained the Q).
my question is,
whether there is a method/property-node/something that allows me to
wire the Queue Refnum into it and receive the element-data-type,
so i can then input into the top of bundle-by-name?
(i really dont want to have that cable all over the place)
the reason i ask here is that
the help for the outgoing Queue Refnum from the Obtain Queue method,
shows the element-data-type and so i hope there might be a solution.
thx for your time
and cheers
j
Solved!
Go to Solution.

If I understand your question correctly, the answer is "Yes, it's very easy ..."
The answer is "Preview Queue". Here I create a Queue of some mysterious type (it's a cluster having a Thing and a Center, but you don't know that yet). I take the Queue reference from whereever I can find it and pass it into Preview Queue Element. I take the output and use it to define my cluster in Bundle by Name.
Two caveats. This copies the first element of the Queue into the cluster, so you probably need to be sure to define all of the elements of your cluster. But what if the Queue is empty (as mine is, above, as I just Obtained it) -- well, that's why 0 is wired into the TimeOut input, since I do not want to wait "forever" (-1) for the empty Queue to have an element! Turns out that even in this case, you still get the correct Cluster elements!
Neat, huh?
Bob Schor

Named Queues in Queeued Message Handlers

I have a question as it pertains to the Producer/Consumer design pattern and using Queued Message Handler.
I know it's a good idea to to name the queues, but it confuses me as to WHY I need to name it. I've never seen an example to where the named queue is used in the BD other than when naming the queue, is there? I've always used a strict type-def Emunerated Control to control my states in the consumer. Isn't this enough? If someone could shed some light, I think it would go a long way to making some of my programs more robust.

In LabVIEW, an application instance (sometimes also referred to as a context) is something which represents a fully enclosed "area". Anything inside this area is unique to it and can't be accessed directly from any other application instance. This includes things like queue references, VI references, loaded VIs in general, etc. Some of these things can be accessed through established APIs (for instance, VI server does allow you to access other instances, but the queue primitives don't). Note that if you load the same VI in two projects and modify it in one of them, the VI in the other will not be updated until you press the green arrows sync button which appears when you do this. Essentially, you get two copies of the same VI in memory.
Applications instances in LV include:
Every target in every open project.
Every executable.
Instances that LV or other toolkits use (like the application builder, which loads the files in a separate instance or the main LV instance, which is used if you don't have a project open). I think the main reason these are used is to prevent collisions.
Note that this is very different from actual namespacing (i.e. libraries like lvlib and lvclass) in that this is something transient. It's created by opening more than one project at a time, but it doesn't affect the VI itself. Libraries do affect the VI itself, because the VI knows which library it belongs to and it's something that sticks with it. That's real namespacing and the result is the fully qualified name which is made up of the owning libraries names and the VI names. You don't need more than that, because the FQN is only relevant inside the application instance (i.e. if you do an Open VI Reference, you need to give a FQN, but you also need to provide an application reference).
That was a bit stream of consciousness (I can never spell that word correctly) and I didn't understand the actual question, so hopefully it was clear enough.
Try to take over the world!

Queue Reference on a DVR?

Similar Messages

Maybe you are looking for