Link to Packed Project Library in Application

[smidsy]

Hi All,

 

I have an application that uses PPL (Packed project library). During the build process of my application LabVIEW copies the PPL to build/My App Folder/data. I can run the application afterwards. If the PPL is deleted or moved later from this ../data/ directory I no longer can run the app.

 

Is there a way to dynamically link and load PPL from another location?  I've tried using viSearchPath for this but unfortunately it doesn't work. 

 

Thanks,

Nikita.

 

also posted here http://forums.ni.com/t5/LabVIEW/Create-a-link-to-PPL-Packed-Project-Library-in-Application/td-p/3555902

[Tim_S]

There is a means to dynamically load a PPL, but probably not the way you are using it. I expect you've dropped VIs/classes from the PPL right onto your block diagram.

If you are using classes, then you would need to have a parent class built into a PPL that both the application and the dynamically loaded child object use. The parent object gets used throughout the application code and the child object gets loaded at run time.

If you are using VIs, then you use it like any other VI with VI server.

[smithd]

It sounds like you've dropped VIs down on your block diagram and the compiler is statically linking everything. To be able to load from a dynamic library path you'd need to use VI server to get references to the functions you want to call. This palette lets you find a lvlibp and get exported functions: https://zone.ni.com/reference/en-XX/help/371361N-01/glang/packed_library_palette/

One thing that may work, as horrifying as it sounds: You could load your main code dynamically using VI server and before doing that, use VI server to dynamically load the packed project library and all exported functions at the new path. Because you've manually loaded them into memory, when vi server tries to load your main function it should find the copies of the lvlibp already in memory and say "oh sweet I don't need to load this". Or, because lvlibps are half-baked it may just collapse in on itself in a black hole of misery. One or the other.

And of course the best question is why you want to do this. Whats your use case?

[smidsy]

Hi Tim_S, Hi smithd,

  On 12/12/2016 at 4:13 PM, Tim_S said:

I expect you've dropped VIs/classes from the PPL right onto your block diagram.

Expand  

Yes, that is what I did. I have my parent classes from PPL dropped on my block diagram in the application. I have also few child classes that are dynamically loaded using the mentioned Packed Library palette. 

  On 12/13/2016 at 5:02 AM, smithd said:

Whats your use case?

Expand  

Parent classes are stored in few PPLs (Core PPLs). Child classes are also stored in few other PPLs (Plugin PPLs). They are loaded dynamically.

I plan to have more than one application on one PC that uses Core PPLs and Plugin PPLs. I also plan to update the functionality (fixing bugs, extending functionality etc.) in both Core and Plugins PPLs in the future. Basically I don't like the idea of having the same identical Core PPLs spread across application folders on a PC. Even if I put core functionality in one PPL, I still have the problem with updating this PPL in every app folder. 

 

  On 12/13/2016 at 5:02 AM, smithd said:

You could load your main code dynamically using VI server and before doing that, use VI server to dynamically load the packed project library

Expand  

This sounds promising, I will try! 

What do you guys think of using Soft Links to directories on Windows? Basically it works right now with my apps and it does what want. 

[Tim_S]

OK, I understand what you're doing better now.

I have multiple applications using the same base objects as well. My solution was to have a common subdirectory for the base PPLs from where all the applications are installed. For example, the applications would install in:

    C:\Program Files\My Company\

and the PPLs are in:

    C:\Program Files\My Company\Plugins\

The configuration and dynamically loaded files are in the common application directory, so reside under:

   C:\ProgramData\My Company\

This generally follows Windows application layout. The files that would regularly change (configuration, project-specific plugins) do not require special or elevated permissions, so UAC is not an issue. NI's installer is able to handle this without too much work, so life is good.

Looking back, one thing I would probably have done differently is each application would be in a subdirectory and the PPLs in an adjacent "Common" or "Shared" subdirectory.

[Rolf Kalbermatter]

If your packed library is really just a wrapper around your child class implementation, a better way would most likely be to employ a default naming scheme for the PPL name that follows the class name. Then using "Get Default Class from Path" you simply load the class into memory at runtime and cast it to the Base class and then you can call all the Base class methods and properties from that and the dynamic dispatch will make that the child methods are invoked.

[smithd]

  On 12/13/2016 at 1:59 PM, rolfk said:

If your packed library is really just a wrapper around your child class implementation, a better way would most likely be to employ a default naming scheme for the PPL name that follows the class name. Then using "Get Default Class from Path" you simply load the class into memory at runtime and cast it to the Base class and then you can call all the Base class methods and properties from that and the dynamic dispatch will make that the child methods are invoked.

Expand  

this definitely sounds like the easiest route assuming you never need to call a child directly.

 

Its worth mentioning that I've had issues with updating PPLs in the way you intend with regards to classes. This was in 2013 and they've done a ton of work on ppls since then, but I'd strongly suggest doing a proof of concept where you make a few minor changes to your parent classes without recompiling the exe or other ppls. That is, exe v1.0, childclass.lvlibp v1.0, parentclass.lvlibp v1.1. I found that very often I had to recompile both the parent and children for it to work, which is obviously less than ideal. I hope this has been resolved.

[smidsy]

Tim_S,

  On 12/13/2016 at 1:06 PM, Tim_S said:

each application would be in a subdirectory and the PPLs in an adjacent "Common" or "Shared" subdirectory

Expand  

Yes, I agree, this would be the best solution to the problem with having multiple apps referring to one set of Core PPLs. Each application build process though needs to copy all static Core PPLs to its own  ..\Shared\ folder. 

Edited December 14, 2016 by Nikita Prorekhin
Plugins renamed to Shared

[Rolf Kalbermatter]

  On 12/14/2016 at 2:54 AM, smithd said:

Its worth mentioning that I've had issues with updating PPLs in the way you intend with regards to classes. This was in 2013 and they've done a ton of work on ppls since then, but I'd strongly suggest doing a proof of concept where you make a few minor changes to your parent classes without recompiling the exe or other ppls. That is, exe v1.0, childclass.lvlibp v1.0, parentclass.lvlibp v1.1. I found that very often I had to recompile both the parent and children for it to work, which is obviously less than ideal. I hope this has been resolved.

Expand  

My experience with this is that under Windows it is pretty easy and non-problematic but if you end up having numerous class hierarchy levels that depend on each other and build the various classes all into its own PPL you have to be careful if you do this for Linux realtime targets. For some reasons only known to I don't know who, if you for whatever reason rebuild one of the base class packed libraries you absolutely have to rebuild every depending class packed library or LabVIEW will start to complain that the depending classes can't be loaded. I have no idea what the reason is, I did assume that a packed library is an isolated container that only exports its public interface to the outside world, so as long as nothing on the signature of the public methods changes this should be a no-brainer, but that doesn't seem to be the case for NI Linux RT targets.

I didn't seem to have these problems on Windows nor VxWorks realtime targets.

Edited December 14, 2016 by rolfk

[ShaunR]

  On 12/14/2016 at 9:45 AM, rolfk said:

if you for whatever reason rebuild one of the base class packed libraries you absolutely have to rebuild every depending class packed library or LabVIEW will start to complain

Expand  

I don't blame them for this. Linux is a house of cards and probably the best way to have some confidence that something might work from version to version or distro to distro is if you statically include your entire execution environment (like Steam). Even then it's a 50/50 chance that some nutter hasn't broken an ABI that you overlooked.

Edited December 15, 2016 by ShaunR

[Rolf Kalbermatter]

  On 12/15/2016 at 8:55 PM, ShaunR said:

I don't blame them for this. Linux is a house of cards and probably the best way to have some confidence that something might work from version to version or distro to distro is if you statically include your entire execution environment (like Steam). Even then it's a 50/50 chance that some nutter hasn't broken an ABI that you overlooked.

Expand  

I'm not sure you can blame Linux for this. Packed Library is an entirely LabVIEW specific feature. It's basically a ZIP archive with an executable header for reasons I don't know. It definitely is not instantiated through OS loader code, so the executable header looks mostly be tacked on for version resource purposes. It seems unneccessary.

The entire code in packed libraries is LabVIEW specific code, the precompiled executable code for the VI and optionally the VI diagram for debugging purposes. The loading and linking of these code resources is done entirely through LabVIEW itself. So what the problem with packed libraries on NI Linux RT systems is, I have no idea.