Built plugins on RT only able to run in the run-time-engine when depending on lvlib

[Mads]

When I have plugins that are to be loaded dynamically on an RT target, I typically build the application and plugins (in llb files), and deploy them once, to make sure the plugins are on the target when I then continue working on the code of the main application (this obviously needs to be redone if I actually make changes that break with the plugins last deployed*). When I run the main code it will then be able to locate the plugins and will launch the top-level VIs in the llbs dynamically. Without doing the build and deploy first the plugins would not be on the RT target...

Now this works fine until one of those plugins depend on an lvlib. There are a lot of threads here where the issue is that the plugin will not load when run from the executable, and those issues are typically caused by the lvlib not being sufficiently included in the executable, making the plugin fail to find its dependencies. This is not my problem though - I make sure the lvlib is fully included in the executable, OR the dependencies are included in the llb of the plugin using them.

My problem is that when the main code is run from the IDE, and it finds and launches the built plugin in the llb on the RT target - the plugin does not recognize the lvlib anymore (NI_AAL_SigProc.lvlib in this case). This happens even if I make sure the plugin did not get any of the lvlib files included in the llb *and* the main loads the VI used by the plug into memory prior to loading the plugin.

Now the plugin obviously is compiled in this scenario, and when that is done it might be expecting the lvlib to be in the namespace that it is put in the executable...So that might be the whole issue (?). I of course do not make any (intentional at least) changes to the lvlib that might cause a break, as it is a standard vi.lib component...

Perhaps I could solve it by not distributing the plugins to the target initially through a build and deploy, but rather by transferring them (note that I normally separate compiled code due to using SCC, so that might also become an issue then)...A bit cumbersome and less flexible, but doable.

But is there a better way to do this that should work with my way of putting plugins in the right place on the RT target?

(If this was not on an RT target the plugin location would be the same for the IDE as for the executable so no issue then.)

[Mads]

One solution I have found to the issue is to make sure the Std Deviation and Variance.Vi from NI_AAL_SigProc.lvlib is loaded into memory by the main VI, prior to calling the dynamic VI (which needs that VI due to it use of the AC and DC estimator from NI_AALPro.lvlib).

So, it is as if the plugin when built is fixed to load the Std Deviation VI wherever that was put during the build, and is unable to find it when run from the IDE even though the VI is is still available the same place (locally, in the llb or executable (with all support files etc included)).

Or, perhaps it finds it, but the VI is then incompatible with something (another copy of the lvlib loaded in memory by the main VI due to its use of other VIs from that lvlib?) when called from the IDE. This is then resolved by loading the Std Deviation VI into memory from the main up front instead, forcing it to origin from the same lvlib as used by the main when in the IDE...(?).

Putting a static call into the main VI, just to make sure things load OK in the IDE as well, is of course a solution. It would be nice to better understand what exactly is going on under the hood though. The situation seems to be aggravated by a detail about lvlibs that I have not grasped yet.