.NET DLL possible refnum issue?

[trebor89]

I have the following subVI which goes to an interfacing DLL .NET to communicate with some company hardware (via it's own .NET DLL too). This appears to run perfectly fine on it's own and when called from a higher level VI and with little additional programming also worked. As soon as increase the amount of logic on the parent VI, the DLL stops returning values correctly and the returned string is an ErrorException, meaning that the called library couldn't even figure out the error. the following 2 snaps are 2 working commands in isolation.

when added into the parent VI it all falls apart:

I think it must be something to do with binning the references properly at the parent VI (I am using close references on each subVI and I believe a new ref is made and destroyed for each subVI call) but I cannot narrow it down. I have tried using Trace tool, but it hasn't helped me understand the issue.

Any help really appreciated, Rob.

[rolfk · Accepted solution]

Are you by any change creating the refnum (running the Constructor Node) in a different top level VI hierarchy than your actual code execution?

The lifetime of LabVIEW refnums is tied to the lifetime of the top level VI in whose hierarchy the refnum was created. Once that top level VI goes idle, the refnum is automatically destroyed and eventhough the refnum (when probed as integer value) still has the old numeric value, the object it references does not exist anymore and the Not A Number/Refnum test node will also indicate that it is not valid anymore.

[trebor89]

Thanks Rolf. I think this might have been the issue and why I didn't manage to tie it down myself - I was seeing different refnum values on the probes so was perplexed. I thought I had removed all the higher level references but found one hiding and I think it was removing that (and admittedly some more tidying up of the interfacing DLL) which has resolved it. Painful.

Regards,

Rob