LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Project Dependency Rises from the Dead

Solved!
Go to solution

Hi,

 

I'm working on a .lvproj that has been through many iterations and passed between several computers, which means that file dependencies have been pretty messy. I finally tidied the whole lot up recently but I'm having one last issue. I have searched through the forums for some reference to this but nothing quite matches my problem.

 

All of the conflicts have been resolved except for one, 'Scale MT.lvlib'. LabVIEW keeps referring to it's old location, which I've deleted. When I click 'Why is this item in dependencies' it lists three subVIs and when I open them I click 'Load with Selected' with the correct dependency path and the conflict disappears from the .lvproj. This all seems OK but if I close LabVIEW completely then re-open my .lvproj the conflict appears again. This just happens over and over and I'm not sure how to sort it. Any ideas?

 

Thanks in advance for your help,

Dan

0 Kudos
Message 1 of 6
(2,300 Views)

?

 

Ensure you are saving all of those three callers.

 

?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 6
(2,288 Views)

Hi Ben,

 

Cheers for the reply. I've had a go at saving all the VIs individually but as soon as I restart LabVIEW I get the same issue. 

 

Dan

0 Kudos
Message 3 of 6
(2,244 Views)

Maybe Mass compile, Save All or Force compile can help in this case?

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 6
(2,240 Views)
Solution
Accepted by topic author dml13

OK, I managed to fix it by playing around. I right clicked the conflicting item, 'Scale MT.lvlib' and clicked 'Load'. The conflict dialog then popped up and allowed me to choose the correct version for several items within the library. LabVIEW then crashed but when I restarted it the dependency was sorted.

 

I'm guessing the issue was that the conflicting items were actually inside the library, so replacing the library itself wasn't working in the background. I don't know how this all works in the background but for anyone who gets this sort of issue in the future, try checking out individual library items rather than the library as a whole.

 

Cheers,

Dan

Message 5 of 6
(2,237 Views)

Hi Yamaeda,

 

Thanks for your reply. I managed to fix the problem about one minute before this popped up, so I haven't tried the mass compile or save all. If I get dependency issues in the future I'll remember these ideas. Cheers.

 

Dan

0 Kudos
Message 6 of 6
(2,235 Views)