LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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
0 Kudos
Message 1 of 5
(4,015 Views)


@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
My Blog
Message 2 of 5
(4,012 Views)

Hi Rolf,

Thanks for the reply.  That does explain why the queue references stop working.  However, why do the VI references sometimes work even after the VI goes idle?

To go one step back... the reason I want to keep these references in memory is because this reentrant VI is called all the time and whenever a dialog is displayed or something else blocks the User Interface Thread, this reentrant VI stops at "Get VI Ref", since it runs in the same thread.  Initially I just got new references every execution, but it's important not to have it stopping all the time.  Is there a suggested method of keeping references alive?

Christie

0 Kudos
Message 3 of 5
(3,994 Views)

Where are the references actually generated? Is it in "Assign", "Store" or in the vit?

What you might need to do is have the assignment mechanism running as a separate process which will get requests and send back the desired references.

Also, what's your actual goal? If we know that, we might be able to propose an appropriate architecture.


___________________
Try to take over the world!
0 Kudos
Message 4 of 5
(3,983 Views)
I have solved the problem.  I have a hierarchy of VIs that get launched and shut down in a certain order.  Each VI has a class that places it somewhere in the hierarchy.  I created a VI that is launched as a "critical" class, which allows it to remain open.  This becomes my "Assign" VI, which is the VI that generates the refs (your first question).  I communicate to it via a named queue.  I send to it the path of the VI and name of the queue I want refs for and also provide it a queue ref through which it can return the generated refs.  It's a bit of a roundabout solution, but works very well.
 
Thanks guys.
0 Kudos
Message 5 of 5
(3,950 Views)