10-06-2016 04:33 PM
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
Solved! Go to Solution.
10-06-2016 04:39 PM
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?
10-06-2016 04:55 PM
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
10-06-2016 06:56 PM
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.
10-06-2016 06:56 PM - edited 10-06-2016 07:13 PM
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.
10-07-2016 09:12 PM
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
10-10-2016 05:16 PM
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
10-10-2016 05:27 PM
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
10-10-2016 06:13 PM
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
01-24-2017 02:04 AM
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.