Sharing variables between llbs or lvlibp in

[Tanner!]

Fair enough. If you are looking for a good example of an LLB-based plugin architecture I've recently been playing around with the new right-click shortcut menus in 2015. There is a tool that creates a new template LLB and the developer adds their functionality to a handful of VIs. I would say it's worth looking at to see how they approached it.

[littlesphaeroid]

Sam, thanks this gives me some good ideas, esp the part about wiring in user events to the ppl. I'm already using user events more and more for passing messages araound, so I could start using them to write to an action engine that handles my data colleciton (another thing that each test has to do and which I'm a little stuck on).

Thanks!!

[Alexander_Sobolev]

I would suggest llbs.

My understanding that packed libraries, dlls, exes are better for independent tests that do not exchange data between them and main application.

Dynamically call test.vi from main application, unload it after test is done. Next test.vi can use the same file names as the first one, but different vis. Unless main vi and test use _different_ files with the same name you are fine. You can use globals to pass data. Each test will connect to main.vi global even if global with the same name is included into llb. Obviously test1 only globals will unload when it quits and test3 vi can not use it... if you do not load global file global1to3.vi dynamically and keep it's reference opened through main.vi.

But you should be carefull if sharing type defs (and classes) and modify different tests with time.

[littlesphaeroid]

My current approach used llbs for the reasons you mention. I will slowly migrate to another approach. My current thinking is to pass a variant wire around tha tests can put shared data on as needed, and in this case I can use the ppl approach. But the remaining challenge it to have globally configured hardware accessible to all tests. I tend to avoid passing wires all the way down to low level functions like digital outputs. 

[Sam_Sharp]

---

@Alexander_Sobolev wrote:

I would suggest llbs.

---

From my understanding, llbs are an old library format and lvlibs/PPLs were brought in to replace them (I mean you only have to look at the clunky LLB manager to see it's an archaic feature!). A google search for "llb versus lvlib" brings up results to that effect (e.g. here).

Unfortunately, some of the caveats of PPLs make them slightly harder to work with (e.g. passing data around) which is why it is understandable to fall back to LLB but if you're writing plugins - you want to provide compiled code, not your source code.

LLBs are OK for distributing source code as a single file (but even then, VIPM is better).

---

@littlesphaeroid wrote:

My current thinking is to pass a variant wire around tha tests can put shared data on as needed, and in this case I can use the ppl approach.

---

Using a DVR of a variant and wiring the DVR reference into the test plugin would allow you to do this. Passing the actual variant around (unless your return it when the test is done) won't work because the wire contains the data, not a reference to the data (i.e. if you split the wire and modify one of the branches, the change won't appear in the other branch...). You could do this using an FGV, but because of the way PPLs work, you would need to put the FGV into it's own PPL and have your application and plugins use the version from the PPL.

[littlesphaeroid]

"You could do this using an FGV, but because of the way PPLs work, you would need to put the FGV into it's own PPL and have your application and plugins use the version from the PPL."

At last! Sam, this is the answer to my question. It seems that what you are saying is that if I have a PPL called by the sequencer/top level application and then by the plugins, the plugins will use the value of the functional global already in memory (and I assume also, this works for regular globals). This is great and gives me an idea of how to move forward with PPLs.

[Sam_Sharp]

Exactly, any dependencies you want to share between the main application and the PPLs, need to be built into a separate PPL and then you replace the VIs with the ones from the "dependencies PPL" in both your main application and the plugins.

[Alexander_Sobolev]

>> From my understanding, llbs are an old library format and lvlibs/PPLs were brought in to replace them (I mean you only have to look at the clunky LLB manager to see it's an archaic feature!). A google search for "llb versus lvlib" brings up results to that effect (e.g. here).

My problem with lvlib(p) was sharing data between main shell executable and modules. LLBs provide this - it calls the same subVI, already called by main.exe.

Technically in my case it is shared instrument control, not simply data, so it can not be done with wires or shared variables.

And yes, main exe and llbs are built from different projects.

>> LLBs are OK for distributing source code as a single file (but even then, VIPM is better).

LLBs are not for distributing source code  - since projects have been introduced.

>> look at the clunky LLB manager to see it's an archaic feature!

Clunky LLB manager is a debugging tool - to check if you are missing files in llb. Console window is also archaic looking, it is usefull, so it does not matter.