Separating Compiled Code from VI breaks OpenG dependencies

[t.gru]

Hello everyone,

in an attempt to simplify our version control, I tried using the "separate compiled code from vi" option on one of our projects. I've used the "Mark Existing Items" Option in the Project properties.

At first everything seems fine. No more "pseudo" changes to the vi's. So I proceeded to commit the changes to git. The fun parts started once a colleague tried to open said project. The "old" project without the compiled code option worked just fine

While opening the project it starts to search for every single OpenG file used in the project and it seems to find them in the user.lib directory because there is no pop-up prompting me to locate the files! The OpenG files are listed under "Dependencies" as usual and can be opened from there. But the every single OpenG file in the source is replaced by the white question mark vi. Clicking on it brings up a Pop-up "Filename xx not found". The Labview Warning Window gives the message "Missing LabVIEW Tools Network Add-on" and "OpenG Libraries support for LabVIEW 2020" is missing. Which is clearly wrong.

Unfortunately I cannot provide the project but here are some things I've tried:

• Marking only a couple of source files with "separate compiled code from vi" works just fine. I've tried about 10. But we are talking about 1100 source files here. And its a pain because you always need to move the project to another system to see if a change broke the dependencies or not.
• This only affects OpenG libaries. Every other library from user.lib is fine
• Re-Installing OpenG libaries doesn't do anything
• Deleting compiled cache doesn't do anything
• Mass compiling user.lib doesn't do anything
• The problem is not related to a specific computer/labview installation. Its only working on the installation which initially separated the compiled code.

Any help would be appreciated

[t.gru]

Mass-Compiling the project comes up with this error message. 

Not sure where it gets "openg_error.lvlib" from. The OpenG folder looks like this.

[dkfire]

What version of the OpenG Error have you installed ?

Mine from version 6.0.0.26; 

See the lvlib in the folder. 

[rolfk · Accepted solution]

This is most likely related to different versions of the OpenG libraries being installed. Somewhere between 4.x and 5.x/6.x someone went through all the OpenG libraries and "librarised" them, meaning to put all the VIs into a library specific LabVIEW lvlib. Great idea in theory and moving source code from non library to library works actually pretty smooth but if someone then tries to load that code with an older OpenG library installed, things break completely.

You should make sure that everybody in your team uses the same versions of the OpenG libraries, otherwise things tend to go haywire. I have this regularly when working on different computers with different versions of OpenG and/or NI Modbus etc libraries installed.

[t.gru]

Thanks guys this solved the problem! I wrongly assumed that all OpenG Libaries are Up-to-Date because vipm did't show any updates. Sure enough i had the "lvlib" version on my computer and some older version on the others.

I still don't understand why this wasn't an issue without the "Separate Compiled Code" option but i am just glad it works now.

[Yamaeda]

Don't forget to mark as solved.

[softball]

Yes, Rolf deserves a healthy amount of Kudos for that knowledge sharing !

Now, LabVIEW is visual. But I would like an old fashioned text ( excel friendly ) formatted dependency listing including files and their location. Using a good editor it is easy to pinpoint misplaced files

VI locations was a hot topic in the 90'ties where VI's were routinely cross-linked between LabVIEW versions and poorly managed 'library' or 'shared code' locations. Much was solved by abandoning LLB's then.

Obviously these problems are still with us. Now just in another form.

My own method to manage this problem is to assign drive letters to the root location for a project and whatever locations it depends on, using SUBST. Three to five drive letters abstract dependencies making it 'quite' easy to do a cursory check be sure you access what you intend to access.

Anyone know a super tool solving this problem ?

I have noticed a recent tool called 'Dependency Inspector by PantherLAB' on VIPM. Anyone used it ?

Regards