Receiving prompt to add interface class to project when dynamically loading child class in PPL

[croohcifer]

Hi all,

I have built a Motor Controller GUI application using a plugin architecture to support multiple motor controllers.  The GUI LabVIEW project contains my PPL interface, iMotorAPI.lvlipb, which contains my iMotorAPI interface class.  I have a MotorSimAPI child class (contained in a separate PPL, MotorSimAPI.lvlibp), which is a software simulation of the motor.  When I build that child class/PPL, I check the box to exclude dependent libraries, and I don't see the parent class/PPL in my child PPL build location when I build the child.  In other words, I think I'm building all of that correctly, and when I run the motor GUI application VI, everything works as expected. 

The trouble comes when I want to load the child class/PPL from a location other than its build location on disk.  I have a plugin folder in my <default data directory>\Motor Controller Plugins that contains an INI file that defines which child class to load.  (I set this up and define the plugin per-test-station since each one has a different motor controller.)  I also copy the required "child" PPL(s) for each test station to that directory.  Now when I run the same motor GUI VI and load the child PPL from this new <Motor Controller Plugins> location, "Get LV Class Default Value.vi" throws the following dialog:

Note that all of this is on my development machine in the development environment.  This behavior does not exhibit on my development machine or on any deployment machines when running the EXE.  (I don't have dev licenses on the deployment machines to test that case.)  I've only observed this running the motor GUI source code on my dev machine.

Now, I could simply run the child plugin from the default build location when in dev mode and from the copy in the plugin folder when testing the EXE, but if my understanding is correct, the PPL's location on disk should not matter, right?  I'm just trying to load the child class in the "child" PPL.  The parent class in the "parent" PPL is already a part of my motor GUI project, so I'm not sure why loading the child class is prompting me to add a duplicate of the parent to my project.

If I click "Cancel" on the prompt, I get error 43.  If I click Add, the code runs correctly, but a copy of my child PPL is added to my project, and I don't want this to happen.  (And curiously, the parent is NOT added as a conflicting dependency, as the prompt warns...)

Can anyone help clarify and let me know what I'm messing up or misunderstanding?

Thank you!

David

[crossrulz]

The thing with PPLs: Relative paths MUST be maintained.  So if you move your child PPL but not the parent, the child will no be able to find the parent.  What I have been doing with my plugins is have the parent and the child build into the same folder (\plugins\parent.lvlibp and \plugins\child.lvlibp).  Then you can move both around together and everybody is happy.

[croohcifer]

So then does that change in the EXE/runtime context?  I can move my child PPL anywhere on disk, and as long as I point to the right location, my EXE can load the child.  The parent at that point is just sitting in the data folder next to the EXE and is not moving around on disk to maintain a relative location to the child.

[croohcifer]

Is there anywhere I could find best practices on this?  I've found a lot of documentation on how to make plugins, but there doesn't seem to be much out there on distribution.  If the pathing really is different in runtime context than in the dev environment as I am experiencing, I can easily switch the path to the child PPL/class in my code based on whether or not the code is executing in the runtime engine.  Is that a good/common practice, or am I still misunderstanding something fundamental here about this architecture?

[crossrulz]

---

@croohcifer wrote:

If the pathing really is different in runtime context than in the dev environment as I am experiencing, I can easily switch the path to the child PPL/class in my code based on whether or not the code is executing in the runtime engine.  Is that a good/common practice, or am I still misunderstanding something fundamental here about this architecture?

---

What I do is I keep a "base path" for my parent class and its children.  I can then look for the class I actually want to load by name by looking for the class file or inside of a PPL.  I make it so all related PPLs just sit next to each other.

I haven't watched it yet, but Zebra Technologies had a couple of people talk about PPLs at NI Week.  It might be worth watching that presentation.

[cbutcher]

I saw the presentation - they discussed relative pathing and different Dev and install locations in some reasonable depth.