Error 1026 "VI Reference is invalid" after upgrading from LabVIEW 2015 to LabVIEW 2016

[TulaRen]

I have just upgrade to LabVIEW 2016 from LabVIEW 2015, and have encountered an "Error 1026".

The main program calls a sub VI which has a VI server reference "This VI" wired to a Refnum output on the pane. This Refnum output from the sub Vi is then used to get the "vi name", which is used as an input in "Open VI Reference" node. The program works fine in LabVIEW 2015.

For some reason, in labVIEW 2016, this Refnum output from the sub Vi returns a "Not A Refnum", which when used to get the "Vi name", issues a "Error 1026". On the other hand, if I open the sub Vi first (so it is in the meory), and then run my main program, it works fine.

Can someone explain what has changed between LabVIEW 2015 and 2016 that may lead to this issue.

Thanks.

Ian      

[natasftw]

It's more likely to be a difference in your installation than it is in the change from 2015 to 2016.

How do you link to the file?  Is it an absolute path?  Is it relative?

Are you able to share your two VIs so we're able to debug ourselves?

[TulaRen]

The sub Vi contains some company confidential info that I am not able to share, but it should be clear in the attached screen capture what I try to do using VI refnum.

Thanks.

Ian

[TulaRen]

It appears when called as a sub VI, "This VI" node in the vi returns an error. I cannot understand how this can happen and how to fix it.

[TulaRen]

It appears when called as a sub VI, "This VI" node in the vi returns an error. I cannot understand how this can happen and how to fix it.

[TulaRen]

I think this is a LabVIEW 2016 bug.

Attached is a very simple LabVIEW example program. 

"Ver 2016 -with error" : if you run the "Main 2016" in LabVIEW 2016, it returns "error 1026"

"Ver 2015 -No error": same as "Ver 2016 - with error" but saved to LabVIEW 2015 version. When running in LabVIEW 2015, returns no error.

Can NI fellows confirm?

Thanks.

Ian 

[RandallCrandall'sCandleHandle]

I have reproduced this issue and I am researching to find a reason this could happen.

A potential workaround for you though: if you do not pass in the VI Server Reference(VSR) to the property node, it will also default to This VI. I ran your example using this instead of with the VSR, and it did not seem to have any problems.

Cheers,

Ryan

[TulaRen]

Ryan

Thanks for comfirming the issue. I donot understand your workaround, can you elaborate in a little more details, maybe a sample example?

What I really want to do is to get the vi path/name of the subvi so it can be used in an asynchronous call. I run the subvi in a normal call first, quit immediately and pass the vi path/name info as an output, then I use this to make asynchronous call. I do not want to hard-code the file name because it may change.

Thanks.

Ian

[RandallCrandall'sCandleHandle · Accepted solution]

This code will result in the sub VI being output in "reference out" instead of needing to use the VI Server Reference as an input to the property node. You can just remove the VSR from the reference in.

Cheers!

Ryan

[Florian.Ludwig]

Is there a CAR for this?

I'm having the same issue on LV 16.0, Win 7 64 bit.

The workaround works for me too - but I fear this may affect me in many places I haven't noticed yet.