LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

dynamically called vi, TDMS invalid file reference

Solved!
Go to solution

Hello,

 

I cannot explain a strange behaviour, I hope someone can give me a hint.

First of all, do not ask why I need this way to go, I just would like to understand why it happens.

 

We have a FGV which has 3 actions: Init, Write data and Close. This operates on TDMS files. The init action creates a TDMS file reference which is stored in a shift register to be ready used by the Write and finally the Close cases.

All is OK, if I use this FGV simply in a main VI directly from the block diagram. So I can init, write data, and finally close the TDMS file.

 

However, for a certain reason, a new requirement appeared: to be able to "Init" and "Close" the TDMS file using the FGV, but from inside a dynamically called VI (a pop up window which is not allowed to stop the execution of the caller).

So in the main VI, I dynamically call another VI using the Async call (flag x80, "call and forget" methode), and this dynamically called VI fires the TDMS FGV.

When I probe the TDMS file reference, I can see it gets its value properly after the "Init" case was fired. After this "init" happened (from the dynamically called VI), a location in the MAIN VI starts to call this FGV with the "Write" enum action. I can see via the probes, that the Write case gets the very same TDMS file ref number what was stored in the shift register after the "Init" case.

But even though, the VERY first TDMS Write function throws a "TDMS file reference invalid" error msg! How can it be possible, if the file reference is OK and the same as the one created by the "Open TDMS file" function in the "init" case?

 

I repeat, if I execute the "init" action also directly from the main VI, not from a dynamically called third VI, all is OK, it works.

 

I hope my explanation is not too bad 🙂

Thanks for any hints, and if no idea, I will try to recreate/reproduce this behaviour in a test project which is small, and I will post it...

0 Kudos
Message 1 of 6
(3,162 Views)

I just created a small example. Here it comes!

 

MAIN_BD.png

0 Kudos
Message 2 of 6
(3,152 Views)
Solution
Accepted by topic author Blokk
The problem is that when the dynamically called vi stops any references it opened go invalid.

To see what I mean, modify the dynamic vi to delay like 30 seconds before it stops, the saving loop runs fine until the dynamic vi stops, then the error comes back.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

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

For help with grief and grieving.
Message 3 of 6
(3,137 Views)

I have still lots of things to learn 🙂

Could you clarify further?

"The problem is that when the dynamically called vi stops any references it opened go invalid."

Hmm, this dynamically called VI does not open any reference. It executes the FGV which creates and stores the TDMS file ref inside its shift register. You mean, even the FGV which is called from this dynamic VI, "loses" its reference, it goes to invalid? How can this problem be avoided? I mean, to avoid that if we call an FGV from a dynamic VI, it loses its opened references? I always thought an FGV is a safe storage even between VIs? Not in this case...?

 

Thanks! I learn something new now 🙂

0 Kudos
Message 4 of 6
(3,130 Views)
This is why I structure programs with a separate launcher and put things that open references of any kind in process VIs that I know won't be stopping -- or at least won't stop until the program as a whole does.

Sometimes a lot ends up in the exception handler process because it is always the first to.launch and the last to quit.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

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

For help with grief and grieving.
0 Kudos
Message 5 of 6
(3,127 Views)
FGVs are safe for most things, but references are different. For example, as you noted the numeric value doesn't change. It just isn't pointing to anything useful anymore.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

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

For help with grief and grieving.
Message 6 of 6
(3,123 Views)