LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dependencies in vi.lib and user.lib loading from wrong location

Solved!
Go to solution

Hi,

 

I'm having a weird issue trying to load a project in LabVIEW 2013. Whenever I open the project folder, it keeps looking for files in vi.lib and user.lib in the wrong place. Instead of looking in C:\Project Files (x86)\National Instruments\LabVIEW 2013\vi.lib, it looks in C:\Program Files (x86)\National Instruments\Targets\vi.lib

 

Loading.PNG

 

I have to manually browse for every single file in the vi.lib and user.lib directories, and point each one back to the real folders. But in the project folder itself, every file I just loaded says it's still in conflict. When I try to resolve the file conflicts, they disappear for a second then come back.

 

I can't seem to make LabVIEW look for the functions in the normal vi.lib and user.lib directories, it keeps adding Targets into the destination.

 

I tried doing a mass recompile, and that didn't do help at all.

 

When I load the project, select a few dozen files from vi.lib and user.lib, do a Save All, close the project, then re-open it, I need to reconnect every single file again.  It still looks for everything in ..\Targets\vi.lib instead of just ..\vi.lib.

 

This isn't happening for every project either, just this one it seems.

 

The files are located in the right place according to the path underneath "Loading". If it says it's in <vilib>:\Waveform\WDTOps.llb\WDT Number of Waveform Samples DBL.vi, it's actually there. The file path on top is right, I don't know why LabVIEW isn't finding anything.

 

Any idea how I can get this project to stop looking for vi.lib in the Targets folder?

0 Kudos
Message 1 of 5
(5,535 Views)

I've managed to get the errors to stop by copying the vi.lib and user.lib folders into the Targets subfolder.

 

Seems like a weird solution though...

Message 2 of 5
(5,513 Views)
Solution
Accepted by topic author ng1902

@ng1902 wrote:

I've managed to get the errors to stop by copying the vi.lib and user.lib folders into the Targets subfolder. 


This could be dangerous and cause issues.  If it is possible post your project.

 

When I saw this type of thing in the past it was usually because of a broken dependency that I didn't really need.  I'd suggest going through your dependencies (in the project) and looking for items with odd glyphs showing errors.  Try to find why those are dependencies and remove the unused code, or links to the missing code.  Then resolve all conflicts, and do a save all.

 

In the past this happened when I tried copying a project as a new project, then modified the code ripping out what wasn't needed, but there was always some code in a disabled structure that couldn't be loaded causing some kind of project linkage issue.

Message 3 of 5
(5,507 Views)

I did two things to fix the issue:

 

I apparently didn't have the 2013 Real-Time Module installed. I think everything which was being called by a cRIO in the project was causing errors. When I installed the Real-Time module about 90% of the VIs which were being called from the wrong location started loading correctly. I have the Real Time 2014 module installed, I (incorrectly) assumed I had 2013 installed too.

 

A couple files in the project explorer were still being loaded from the wrong locations. If I opened the dependencies in the project explorer and browsed for the correct file, it just reset back to the old location. I did Find Callers on the misplaced dependencies to see which VIs were calling them, opened the offending VIs, and then a propmpt came up letting me choose the right location. After linking the subVIs to the proper location within the calling VIs, they started being called properly.

 

Did a Save All after that and everything is loading properly!

 

I also removed the copy of vi.lib and user.lib I made from the Targets folder, so that won't cause me issues down the line.

Message 4 of 5
(5,472 Views)

I had the same issue and it was resolved by installing Real Time Module.

Message 5 of 5
(4,555 Views)