LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can I use data value references with a functional global?

Solved!
Go to solution
Can I use data value references with a functional global?  I am trying, but it causes problems:  I run the attached VI with "new DVR" selected.  Then I run it again with "return array" and I get the error 1556: "The reference is invalid. This error might occur because the reference has been deleted."  It seems to have forgotten the DVR, but I thought it should be stored in the shift register.

Another odd thing: In my VI, if I try to connect the wire shown in "something strange", then the type changes (from U16 array to DBL), i.e. it doesn't recognize the type referenced by the DVR.

I want to pass a very large 4-dimensional array between parallel loops with a functional global. To avoid memory problems, I want to use a DVR and in-place element structures. If that's not allowed in Labview, I will try passing it through a user event or notifier. Any problems with those alternatives?

Thanks.

0 Kudos
Message 1 of 11
(4,977 Views)

I do not have LV2010, so I could not look at your code.

 

I would "guess" to say that the code may have closed the reference and later you are trying to use it again.

References are only valid as long as they are opened. 

In some cases, a reference is closed (if the property is set to do so) after calling it.

 

Check through your code to see where the reference is closed and if the code tries to use the reference value after it has been closed.

Message 2 of 11
(4,975 Views)

I only intentionally close the reference in the "return array" case.  In fact, that is the case the gives the error when I run the VI a second time (after running the VI with "new DVR" selected the first time) .  My best guess is that the reference is automatically closed when the VI ends on the first run.

 

I've attached an image of the three cases I mentioned.

 

Thanks.

0 Kudos
Message 3 of 11
(4,957 Views)

One test would be to string three instances of the vi (putting in "error in/error out"  to force execution order), and probe the data between them (or bring it out to an indicator at the calling vi level). I have seen cases, as with ".NET" references (handles) where manually running the functional global doesn't work, the handle becomes invalid, whereas string instances of the vi together, using their error clusters, and running them showed that as long as LabVIEW was running the reference remained valid.

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 4 of 11
(4,940 Views)

Some of the cases (2 of them) do not have the reference wired through, so it uses the default value, which is 0 / invalid.  In one instance, after closing the reference, the old reference or no reference (default) might be okay, except if called later.  What about the third state called "something strange"?  You should have the reference wired to the output tunnel.

 

Now, another situation is that the global variable actually did not save the last reference value.  What you could do is probe the reference value that gets written to the Golbal and see if you read the value when you call it again.  The exercise would be for you to see if you get the value you were expecting.  In any case, you may discover that using a Global Variable for references may not be the way to go.  Maybe I should not suggest this before knowing more what you are attempting to do and why you need a Global to hold the reference value, but you might consider some other approach, such as using a Functional Global, or simply having your references in a cluster that is wired to shift registers.

 

Another thing to add is to test the reference to see if it is valid. Use "Not a Number/Path/Refnum".

0 Kudos
Message 5 of 11
(4,927 Views)

Thanks for your replies.

 

LV_Pro:  it looks like you are correct that the FG does not work by itself (run twice in succession with cases "new DVR" followed by "return array"), but if I connect two sub-VI copies with an error cluster inside a single main VI, then it behaves correctly (attached image).

 

Ray:  I still have my other problem though, and this gets at Ray's question: The reason two of the cases are not wired through is that when I do wire one or the other through, the type associated with the DVR automatically chages to DBL (from U16 array).  So in the end, I can't write my functional global VI.

 

My intention is to do array operations on a large 4 dimensional array (hundreds of MB if possible) without creating too many (preferably any) copies of the array.  I think I can do it with in-place element structures and a DVR.  The array operations would be contained within the functional global (not a regular global variable), which will also allow me to pass the array/DVR between parallel loops.

 

Allan

0 Kudos
Message 6 of 11
(4,910 Views)
Solution
Accepted by topic author bracker

I got a response from an NI applications engineer on this topic, and it looks like it may be a problem with Labview.  They are looking into it, so I'll go ahead and close this discussion.

 

Thanks for the help,

 

Allan

 

0 Kudos
Message 7 of 11
(4,894 Views)

If there is a bug, please post back and give us some details so we can try to reproduce it.

We report bugs and obtain CARs (Corrective Action Request), so that they are tracked for future repair.

0 Kudos
Message 8 of 11
(4,853 Views)

Hello,

 

I have indeed replicated the behavior, and compiled a video capture demonstrating this to the R&D team. This information has been applied to Corrective Action Request #247142. This number may be used in reference to future release notes for progress on this specific issue. 

 

Thank You, 

Patrick Corcoran
Application Engineering Specialist | Control
National Instruments

0 Kudos
Message 9 of 11
(4,826 Views)

I can't play with the code, so I can't comment on a bug or no bug, but you should definitely pass the reference back into the SR. If for some reason the type propagates incorrectly (which shouldn't happen), you can use a typecast to force the reference back to its correct data type.

 

Also, you should probably move the DVR creation primitive into the New case, because now you're creating a new reference with each run of the VI.

 

Lastly, the reason it didn't work independently would have to do with the way LV handles references - a reference is automatically destroyed when the VI hierarchy it was first created in goes idle, so if you run the VI by itself, the reference is destroyed as soon as the VI stops, because it's a top-level VI and having it stop makes the hierarchy go idle. This is relevant to all types of references (including the .NET references mentioned earlier).


___________________
Try to take over the world!
Message 10 of 11
(4,795 Views)