Lifetime of a reference of .NET constructor

[FraggerFox]

Hello all,

I have a .NET constructor node inside LV2G, and I execute a certain set of functions from external .NET dll.

I have three cases:

1) Initialize - Which gives us the .NET reference which could be used with invoke nodes to execute external dll functions, which will execute only once in my app

2) Execute - Takes the reference from above and execute some function

3) Get Reference - Just reads out the .NET reference

Now, if I use this LV2G in different VIs, with the Get Reference case, I could see that the reference becomes invalid after a while (It shows Ref is no longer valid on probe, even if I keep executing some functions continuously)

Maybe I am missing on some basics here, but has anyone come across such problems in their applications?

-FraggerFox!

[FraggerFox]

To add to the above post, my top-level application calling this LV2G is always running.

[Yair]

...my top-level application calling this LV2G is always running.

It doesn't need to just be "calling" the VI. It has to be the first one calling the VI, because the hierarchy which controls the lifetime of a reference is the hierarchy it was created in.

Another option which might be relevant is that somewhere you close the reference explicitly.

[FraggerFox]

The VI in which the reference is first created is always running, however, I found that a dynamic call to other VI later in the stage, which uses the same LV2G to execute some commands, and which runs only once and stops, causes this issue. Logically, this should not happen, since, as said, "the hierarchy which controls the lifetime of a reference is the hierarchy it was created in."

[Yair]

If you call the init case in the new hierarchy, you'll get a new reference, which is owned by the new hierarchy, and presumably replaces the original reference, since you only have a single shift register to hold the reference. Once the hierarchy goes idle, the new reference is automatically cleared and you get your error.

[Rolf Kalbermatter]

If you call the init case in the new hierarchy, you'll get a new reference, which is owned by the new hierarchy, and presumably replaces the original reference, since you only have a single shift register to hold the reference. Once the hierarchy goes idle, the new reference is automatically cleared and you get your error.

Most likely you don't want to call the Constructor Node at all after the first initial call from your Top Level routine. Proper solution would be to separate the Construction of the object from any other initialization that you might want to do from your plugin. A quick fix would be to wrap the Constructor Node into a case structure that is selected by the Not A Number/Refnum primitive, This will create the refnum anyhow the first time around (and even if it got somehow invalid in the meantime, which it shouldn't anymore).

[FraggerFox]

If you call the init case in the new hierarchy, you'll get a new reference, which is owned by the new hierarchy, and presumably replaces the original reference, since you only have a single shift register to hold the reference. Once the hierarchy goes idle, the new reference is automatically cleared and you get your error.

I am not re-initializing the VI during dynamic call, but just using the "execute" command case from the LV2G. Logically, it should pick up the same reference from the Shift Register, execute the method, and keep the reference in memory. In my case, as soon as this dynamic VI is executed, the reference becomes invalid, though its hirearchy hasn't been initiated in the dynamically called VI.

Any Ideas?

[Yair]

Any Ideas?

No, I'm pretty sure what you're describing should work. The only things I can think of are either that you have a bug or that .NET behaves differently.

The only thing I can suggest at the moment is the same thing that Rolf did (assuming it's possible in your case) - check the reference inside the LV2G and if there's an error, get a new reference.

[Aristos Queue]

You say "a dynamically called VI". If you called it by using the "Run VI" method, that's a separate VI Hierarchy. If you called it using the Call By Reference node, that's the same VI Hierarchy.

(Note for LV 2011 users: If you use "fire and forget" mode with the Asynch Call By Ref, that's the same as Run VI method and so is a separate VI Hierarchy. If you use "fire and collect" mode, that's the same VI Hierarchy.)

[Rolf Kalbermatter]

I am not re-initializing the VI during dynamic call, but just using the "execute" command case from the LV2G. Logically, it should pick up the same reference from the Shift Register, execute the method, and keep the reference in memory. In my case, as soon as this dynamic VI is executed, the reference becomes invalid, though its hirearchy hasn't been initiated in the dynamically called VI.

Any Ideas?

Yes! An invisible wiring error? It's about 99.99% of the cases for me when I see such strange behavior. The wire looks as if it is coming from the tunnel but in reality comes from some other place, that resets the reference. Or there is a tunnel that uses default data if not wired, and another one on top that caries your reference from that case but goes nowhere. That is one reason that I really think twice before enabling the "Use default Data" on any tunnel.

[FraggerFox]

You say "a dynamically called VI". If you called it by using the "Run VI" method, that's a separate VI Hierarchy. If you called it using the Call By Reference node, that's the same VI Hierarchy. (Note for LV 2011 users: If you use "fire and forget" mode with the Asynch Call By Ref, that's the same as Run VI method and so is a separate VI Hierarchy. If you use "fire and collect" mode, that's the same VI Hierarchy.)

If I use a Run VI method which is using the LV2G which is already initialized before in another hirearchy, and having a valid reference in its SR (I am not re-initializing the .NET constructor in dynamically called VI, I am just reading the reference out of SR), does that mean that it would still be loaded in a different hirearchy and would have an invalid reference? I think it shouldn't?

[Aristos Queue]

If I use a Run VI method which is using the LV2G which is already initialized before in another hirearchy, and having a valid reference in its SR (I am not re-initializing the .NET constructor in dynamically called VI, I am just reading the reference out of SR), does that mean that it would still be loaded in a different hirearchy and would have an invalid reference? I think it shouldn't?

Hierarchy which *uses* the reference doesn't matter at all. Only the hierarchy that *creates* the reference matters. If the hierarchy that creates the reference goes idle, the reference will be invalidated, even if it is in use in another hierarchy. This is the defined behavior for all refnums in LabVIEW. The LV2G will still have the same actual number stored in it, but that number won't be a valid object any longer.