EXE loads LLB - when do VIs, who exist in both, crash?

[Nils_Thomsen]

Hi volks,

i have an  issue with our test environment, what simplified is an exe that is loading a LLB dynamically and jumps into the code in the llb and waits for it's execution.

As the "parent" exe will not be build in the same interval as the "child" LLBs, it might happen that shared VIs from the EXE and the LLB have different revisions.

Until now, we figured out this is no issue at all as long as the I/Os of the same VI do not mismatch. It's simply using the first of both versions what was loaded at first (hence the same VI that is found in the EXE) and will use the same VI for the LLB, as it's already in memory.

What does not work, if the I/Os of the VIs are different as labview will not know, which one to use. It will load the LLB with a broken arrow.

Yesterday I changed the frontpanel of one of those VIs, that will not affect the I/Os. Both versions have the same inputs and outputs, but the LLB-VI has another element on the front panel, what is not used so far. Just a plain placeholder.

And even with that minor change the execution will be broken.

So my question is: How does labview determine if a VI is "the same" and will use the already-in-memory-version of the same VI from the EXE and what changes are not allowed, as they will cause the conflict?

Changes in code will not affect the ability to run the VI but so far I thought it's only when the I/Os are different.

[wiebe@CARYA]

AFAIK, LabVIEW simply won't load a VI if a VI with the same name is in memory.

So if your exe has a VI A, and the LLB has a VI A, the exe's VI A will be used. If the LLB expects a different VI A, the LLB will fail to load.

Although you didn't ask, I suppose the answer is: "use a PPL".

IIRC, If you exclude external resources from the PPL, the problem will be more or less the same: the PPL expects a VI that's different in memory.

The reason a PPL is (more) robust is that 1) the PPL requires strong name spacing (as the PPL can only be build from a .lvlib) and 2) a PPL will normally (by default) contain all it's dependencies in it's compilation.

I'm not at all happy with the difficulties of refactoring toward PPLs. It's much easier when designed with PPLs from the start, but your situation is where they're supposed to shine.