Actors with Multiple Packed Project Libraries

[AristosQueue (NI)]

I knew that the inlining bug had been fixed. I had resisted posting that anything had improved because I thought the community scope was still an issue so it didn't seem worth it to say that we had made things better. You're saying that you successfully built? I hadn't even tried because the community scope CAR was still open. But perhaps that CAR is more narrowly tailored than it is currently written? Hm...

As for the modification you're still making to Launch Actor.vi... somehow I missed that earlier. What exactly are you doing to fix the problem? Post #24 makes clear the problem that you're seeing but not the solution that you found.

[komorbela]

Hi,

About the modification to Launch Actor:

- get the Actor.vi static VI reference out of the case structure (but keep it wired)

- make SubVI of the case structure

- make the SubVI private, so it cannot be seen when using the packed project library (ppl)

- build the ppl

I guess the problem was that LabVIEW used the general VI ref value as "default" value in the case structure, and coerced the static VI reference to "default". By using this trick, there is no difference between the two cases, so no coercion takes place.

click on the image to see the steps in animation:

And about the build: Yes I could build a PPL using this trick only. And I use it as the source of my other PPLs in my development... and in my executable. So it works through the full development lifecycle

[LVB]

AQ,

Could you create an experimental fork that includes komorbela's fix?  I would like to install this over the default LabVIEW 2013 AF which generates corrupted actor PPLs.  It would be really great if this could be rolled into SP1.

[AristosQueue (NI)]

His fix is not always sufficient. It works most of the time, but it depends upon the order that the VIs load into memory, sometimes still fails. I am 85% confident that we'll have a full fix for this in LV 2013 SP1 (requires modification to LV's editor, not just a G code change), so I'm going to hold off until then.

[komorbela]

Hi AQ,

Good to know that my suggestion does not work 100% of the time. Could you tell me more about it? Does it mean that

1. I am not 100% guaranteed to build a functional PPL, but if I succeed to build one, it will always work?
2. or even if I have a functional PPL it may fail to function randomly on some loads?

I really hope it's the 1st case, because I would like to use the generated PPL(s) in a product.

[AristosQueue (NI)]

komorbela wrote:

1. I am not 100% guaranteed to build a functional PPL, but if I succeed to build one, it will always work?

To the best of my knowledge, yes. It's just a load ordering problem, I think ... if it happens that the files end up in memory reversed during the build, there may be a problem ... I'm not actually working on it myself. If I hear more, I'll let you know, but I am very confident that if your build works, it really works.

[dsavir]

Hi,

If my exe uses actors as well, should these non-lvlibp actors also inherit from the actor.lvlibp used in chunk 1?

Thanks,

Danielle

[AristosQueue (NI)]

dsavir: Yes if you want to have any interoperability between them ever.

[dsavir]

Thanks AQ.

Is the creation of actor.lvlibp easier in LV13 SP1, or should I follow the directions above and hope for the best?

Thanks,

Danielle

[dsavir]

Creating an actor famework.lvlibp in LV2014 is a snap. No modifications needed! Thanks AQ!

However, the message maker doesn't work with actors that inherit from actor framework.lvlibp. Being way to lazy to start writing all the messages from scratch, here is the Plugin Actor Message Maker.

Thanks,

Danielle