LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Path inside Packed Project Libraries

I have packed some plugin based on stage.lvlib into PPL, it is called by top level exe/project and works fine. Then I have used subVI from folder that is parallel in hierarchy and that have not been used before. This leads to different path to plugin interface files, conflicts in the calling vi. 

Projects\

      \Plugins

            \stage\stage.lvlib::control.vi

      \Math\subvi.vi

path to control.vi

when subvi.vi is not used: stage.lvlibp\control.vi

when subvi.vi is used: stage.lvlibp\stage\control.vi

It works, i can resolve conflict, it loads control.vi, but is there a good way to avoid it? 

 

 

0 Kudos
Message 1 of 4
(1,790 Views)

Hey Alexander,

 

Just to clarify, has this entire project been built into a PPL, or has stage.lvlib been built in a PPL that's now getting called within the larger project? And how is control.vi referenced within the project, both from the top-level and the subVI where you get the resolve conflict dialog? I'm assuming the top-level VI that can call control.vi without issue also later calls this subVI, and that's where you get the issue? 

 

Cason

Applications Engr., NI

Cassandra Longley
Staff Technical Support Engineer - FlexRIO, High Speed Serial and VRTS
0 Kudos
Message 2 of 4
(1,744 Views)

Control.vi is inside PPL, main VI (separate project) calls it from PPL only, never from original location. 

 

@Case_in_Point wrote:

 I'm assuming the top-level VI that can call control.vi without issue also later calls this subVI, and that's where you get the issue? 

 

Main.vi can call subVI.vi separately, but it will not conflict, since SubVI.vi (as subvi of control.vi) inside PPL has different name. Also library browser and project tree does not show subvi in lvlibp, I guess it is set as private during build.

 

Conflict appears because control.vi changes path inside PPL. 

I have attached this example, if you open main.lvproj -> main.vi, it shows warning - after I rebuilt plugins/stage/stage.lvproj into PPL/stage.lvlibp with subvi. In real project there was a conflict, not warning.

 

0 Kudos
Message 3 of 4
(1,731 Views)

Ah, so, the issue is that the top-level Main VI calls PPL>>Control.VI>>SubVI.vi in one instance and also calls Math>>SubVI.vi on another instance, right? It's trying to call the exact same SubVI along different paths in different instances. When you share a specific sub VI amongst multiple different modules in a project, it's best to keep them in a specific Shared area. If you had a seperate Shared folder, that had SubVI.vi in it, then Main could call it direclty from Shared, and Control inside the PPL could call it from Shared as well. See point 2 in the help on making PPLs: https://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/converting_packed_libraries/

 

Our of curiosity, which labview version did you build the PPL in? I tried to open it back in LV 2012 and still got a "this PPL is built for an earlier labview version" message.

 

Cason

Applications Engr., NI

 

 

Cassandra Longley
Staff Technical Support Engineer - FlexRIO, High Speed Serial and VRTS
0 Kudos
Message 4 of 4
(1,679 Views)