From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

OpenG library keeps recompiling.

Solved!
Go to solution

I have a very annoying problem. I am using SVN for version control and have followed the recommendations to separate source from compile code. Whenever I use the OpenG library, however, I keep getting 'changes' on those VIs because they are recompiled. This only happens with the OpenG library VIs, all others are fine. I'm wondering if there is a way to avoid this?

 

OpenG Recompile.png

 

 

 

 

 

 

 

0 Kudos
Message 1 of 7
(2,446 Views)

I'm a little confused.  If you installed the OpenG Libraries using VIPM, they should have been saved in vi.lib, where they are "out of the way" of Subversion (at least that's the way my TortoiseSVN system has worked for the past decade).  I think the idea is that this is already "proven code" that doesn't need to be in a Repository (much like all of the VIs and functions that ship with LabVIEW live in C:\Program Files (x86)\National Instruments Software).

 

It is true that when you install OpenG for, say, LabVIEW 2018, you may be loading into LabVIEW 2018's vi.lib code that was last compiled in an older (but compatible) version of LabVIEW.  When you first bring this into a newer LabVIEW version and incorporate it into your code, I think LabVIEW "flips a switch" somewhat that says "Hey, we need to compile this when he saves the Project".  But I don't recall that any of the OpenG code went into any of my Repositories.

 

Could you have (somehow) mis-configured your Repository or the SVN "rules" for what belongs?  [This doesn't sound familiar to me -- while I'm a long-time user of Tortoise SVN and have used several SVN Servers maintained by others, I don't claim to be an expert on all of the fine details and "unusual" use cases of this software.]

 

Bob Schor

0 Kudos
Message 2 of 7
(2,399 Views)

Something's not right with the project.  Did you actually make the library part of your project and not a dependency?  Are you using a LabVIEW version different than LV 2017?  (If I remember correctly, you need to install VIPM packages for each version of LabVIEW so that it can go in the right user.lib folder.)  You shouldn't be using the user.lib (or any folder inside the LabVIEW version folder) from another LabVIEW version - you're asking for trouble if you do.

 

It shouldn't be "constantly recompiling" because it should have compiled for the version of LabVIEW you are using as part of the installation!

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 7
(2,384 Views)

Thanks for the responses. As you can see from my screen grab, the path to the OpenG library is "C:\Program Files (x86)\National Instruments\LabVIEW 2017\user.lib\_OpenG.lib\", which I think is correct. I did not explicitly add the library to my project so I don't know what is triggering the recompile? Likewise, I didn't do any special configuring of SVN. I'll try reinstalling using VIPM and see if that fixes it. Will update if it works.

0 Kudos
Message 4 of 7
(2,376 Views)

This doesn't really have anything to do with SVN. The OpenG VIs are not compiled for your current version of LabVIEW, so every time you open one of your VIs that contain them, the OpenG files recompile and your files will show as changed.  I'm guessing you haven't tried doing a Save All when that dialog comes up?

0 Kudos
Message 5 of 7
(2,370 Views)
Solution
Accepted by topic author Ricky77

Do you have VIPM installed on the machine in question?  If so, open it up and attempt to remove OpenG all the OpenG routines on the LabVIEW 2017 tab.  If that works, reboot and let VIPM reinstall them.

 

If that fails to work, you may need to clear out more stuff.  Whatever you do, don't go messing with the files in user.lib (it may be safe, but if it isn't, it will likely leave a mess).

 

The following will probably work:

  • Try to uninstall everything that VIPM installed.  If you can't, don't worry about it.
  • Open Control Panel and uninstall VIPM.
  • Search your C: drive for folders called JKI.  One of them may have a VIPM folder inside it, and in that there may be a list of installed packages (on my machine, this is in C:\ProgramData\JKI\VIPM, with ProgramData being a hidden file).  This is another "list" of the installed files -- you want to delete this list by deleting this folder.

I've had (not recently, but a few years ago) problems when I reinstalled LabVIEW (and VIPM) -- if the old database was still present, VIPM would say "Oh, you already have OpenG" (but I didn't have it, since I reinstalled LabVIEW).  The other thing to try (which is almost always safe) is to log a Support request with JKI -- they are very helpful.

 

Bob Schor

0 Kudos
Message 6 of 7
(2,366 Views)

Reinstalling the OpenG package in VIPM seemed to do the trick! I didn't have to uninstall VIPM, just the OpenG package.

 

Mancho was correct, I don't think this had anything to do with SVN. Seems like the install was corrupted somehow and causing a recompile every time (even if I hit 'Save All'). Everything is back to normal now. Thanks for the help!

0 Kudos
Message 7 of 7
(2,358 Views)