Wire class conflict when using LVLIBP

[Ironman_]

LV2015
I made a project , with 1 single Actor ("ActorModBusPolling").

Then I buildt the packed lib.

In anothe project, I add my packed lib, then drop the actor class, 2 property set, and call launch root actor.

I have a wire class error.

WHY? IMHO it's a BUG! It can't be wire class conflict, because my object DERIVES from Actor class.

PS: If I add the library as source, it works. WTF!?

If I add the LVLIB file it works, but LVLIBP no.

[Oli_Wachno]

Have you checkeg the class Hierachy diagram?

Does your LVLIBP-contained Actor inherit from the Actor class?

 Have you build the LVLIBP including the Actor class?

[Ironman_]

Does your LVLIBP-contained Actor inherit from the Actor class?

Yes

 

Have you build the LVLIBP including the Actor class?

Not explicitly.

Everything is in "include if referenced", also "dependencies"

It's the first time I use lvlibP , I don't know what's wrong

[wrkcrw00 · Accepted solution]

One of the things I learned when messing with PPL's and AF is that a packed class is a distinctly different class than it's source equivalent. Even though one is directly built from the other, LabVIEW seems them as different. Thus you can't mix and match PPL and source of the same actor in a system.

When you build a packed library, it needs a packed version of actor framework.lvlib. Either it's built into your PPL actor, or it has to be built separately and your actor class must inherit from the PPL version before creating it's own PPL. If you want to keep them separate you must remove dependent packed libraries in the build spec of your actor PPL. Consider a plug in architecture - all the plug-in's must inherit from the same base actor framework.lvlibp, otherwise you'll have this class conflict. It's not an easy system to manage. I eventually decided against PPL's because I'm using the same source code on multiple target types. Managing PPL's for that is...not fun.

[Oli_Wachno]

@Ironman:

what has happend in your case: Actor Framework is packed into your LBLIVP resulting in a different namespace.

This means that the AF VIs you are taking from the BD palette are referencing to a different library, as such to a different object.

That's the reason, the object wires are broken.

There are some threads around this group discussing the usage of LVLIBP usage together with AF.

I am also using this approach, yet it takes some time to get the idea and avoid pitfalls

[Ironman_]

this is DLL hell again guys

NI should fix it

[Oli_Wachno]

There will be a better solution in NXG.

After all, it is not really as bad as DLL hell: some things to be taken care of, yet there's only one LVLIBP loaded into memory at a given time.

You might want to check this for more information on PPLs / LVLIBPs

[Ironman_]

If I have a "module" (actor or whatever), that does a specific thing (for example: at startup, getting all required files and configurations from network folders), what is the best practice to manage its updates?

for example: I develop a "version 1", it works, and some softwares use it.

Then a month later, I find a bug OR I want to add a feature, so I will recompile it.

What are the best practice to avoid problems and avoid older software break?

Maybe deploy  with "app-style" ? (that is all the software and libs are in a folder/app/silo)

[bienieck]

Any update here? How to replace lvlib with a ppl without class wire conflicts?

[CaseyM]

---

@bienieck wrote:

Any update here? How to replace lvlib with a ppl without class wire conflicts?

---

Using the "Replace with..." dialog should help a lot, but it doesn't change the cause of the issue:

@wrkcrw00 wrote:

One of the things I learned when messing with PPL's and AF is that a packed class is a distinctly different class than it's source equivalent. Even though one is directly built from the other, LabVIEW seems them as different. Thus you can't mix and match PPL and source of the same actor in a system.

When you build a packed library, it needs a packed version of actor framework.lvlib. Either it's built into your PPL actor, or it has to be built separately and your actor class must inherit from the PPL version before creating it's own PPL. If you want to keep them separate you must remove dependent packed libraries in the build spec of your actor PPL. Consider a plug in architecture - all the plug-in's must inherit from the same base actor framework.lvlibp, otherwise you'll have this class conflict. It's not an easy system to manage. I eventually decided against PPL's because I'm using the same source code on multiple target types. Managing PPL's for that is...not fun.

---

You still may need to change your actors to inherit from the PPL actor instead of the vi.lib one, etc. Using something like LV Solution Builder can help with managing and building PPLs but there are always going to be challenges.