04-11-2012 12:33 PM - edited 04-11-2012 12:35 PM
I have a major problem.
I've just converted two of our (very very large and thus impossible to post) software loads to labVIEW 2011; previously, these source codes were in LabVIEW 6.1. For some reason, I am getting numerous "This VI cannot access the referenced item in private scope" errors throughout my code. It seems like a significant portion (or maybe all) references to anything in a ".llb" file has been, for lack of a better word, infected with this property.
I do not know or care about "scope". We keep our source codes isolated, maintain copies of all needed libraries for each source code, and so on. I'm aware that this defeats the purpose of having libraries; I'm also aware that this is a very common problem with libraries. I suspect that this scope feature is in some way related. Don't care.
I need every VI and control to be able to access everything else associated with the project. I do not have any existing class definitions that are visible within my project. I know nothing about class definitions. I just want to be able to compile my code so I can find out what has broken with the conversion to 2011 (things always break when converting to new versions; 99.9% of the stuff works correctly but there's always something).
I do not consider "go through every single individual VI, control, and file inside each llb and change the access one at a time" to be acceptable. Even if I did, I don't know how to do that.
I've been able to convert LabVIEW 8.2.1 source code into 2011 without encountering this problem, but I run into a very large conversion time (it takes at least 3 days; I do not understand why, though it appears to be related to the "config" family of VIs, which we use extensively. I would like to know how to fix that problem as well, but that's not really on topic.
Please help.
04-11-2012 01:06 PM
Hi Bob,
If it is OK in LV 8.2.1 and you get the errors in latter versions then I suspect at least one of the problems is something that set me off big time when I found it.
When the config file functions were rewritten NI only offered public versions of the config file functions that were on the palette prior to the re-write.
In my case I had used the "Save" function that was part of the llb but was NOT on the palette. Every VI that used that function broke due to the change.
In my case, I had to replace the "Save" with a Close followed by an Open to ensure the data wa savd to disk within the limitations of the new version.
I still wince every time this topic comes up. It has also driven me to "avoid like the plague" any function that is not on the palette to avoid being bitten again.
I realize this reply does not make your life any easier re: the upgrade path.
Take care,
Ben