Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does a plugin architecture need to compile AF into a PPL?

Solved!
Go to solution

This might be an obvious question. I'm trying out PPL's for the first time with an AF project. I need to separate out my "main" code from my "specific tests" code, and I'd like to do it with PPLs so I can install a single file on test computers to add capabilities.

 

I'm mostly understanding the concept behind creating and using PPL's, but what I don't understand is why do all of the AF PPL Plugin tutorials begin with creating a PPL of the AF itself? I understand that normally a PPL will pull in all of its dependencies and I don't want each of my plugins to contain their entire AF, but obviously it doesn't pull in literally everything. I don't have to bundle, say, the Math palette into a PPL before creating my own.

 

Is it something to do with maintaining queues across all plugin scopes?

 

Thanks for the help.

0 Kudos
Message 1 of 6
(1,952 Views)

I'll throw a little followup question to provide some specific context for my question:

 

I use MGI's Panel Actor throughout most of my GUI-based AF applications. I find it to be a fantastic tool that saves a lot of fiddling with references. Using this tool is as simple as telling my new Actor to inherit from MGI Panel Actor.lvclass. This inherits from MGI Monitored Actor.lvclass, which inherits from Actor Framework: Actor.lvclass.

 

The abstract plugin I'm going to make needs to be a subclass of the Panel Actor, and I'm a little confused as to what all specifically needs to be baked into a PPL so I can create plugin actors based off Panel Actor.

 

Do I need a PPL for AF, then another PPL for Monitored Actor, then another PPL for Panel Actor, then another PPL for Abstract Test Actor? That seems a bit unweildy and I feel like I'm missing something conceptually.

 

Also, it seems like now I have to modify the MGI actors to point at the PPL version of AF. Is that correct? I suppose I could modify the MGI actors and create a single PPL containing both the Panel Actor and Monitored Actor (which I can use across multiple projects), then one final PPL for my Abstract Test Actor.

0 Kudos
Message 2 of 6
(1,945 Views)
Solution
Accepted by topic author BertMcMahan

It's the namespacing. When you build a PPL that includes the AF (or the Math function), they all move to a new location inside the PPL with a new namespace, like MyPPL.lvlibp:Actor Framework.lvlib:Actor.lvclass. If you build plugins pointing to AF source code, each plugin's copy of the AF is considered a unique independent library. That's fine for (e.g.) the Math functions, but it wrecks LVOOP because technically none of your plugin PPL Actor classes share a common ancestor. And more important is the common Message.lvclass.

 

When you build your Actor Framework.lvlibp, I'd recommend including everything. Make an .lvproj with auto-populating folder that includes everything from vi.lib/Actor Framework. Always Include everything from that folder. By the way, it is critical that your PPL be named Actor Framework.lvlibp with the space, or LabVIEW will throw a slow painful tantrum.

 


@BertMcMahan wrote:

Do I need a PPL for AF, then another PPL for Monitored Actor, then another PPL for Panel Actor


The purist answer is yes. The AF PPL issue taints everything it touches. But really you can get away with making a PPL of your closest common ancestor. I haven't used the MGI tools, but it sounds like you could make a PPL of MGI's Panel Actor, which would implicitly include everything else. But if you have other Actors that don't inherit from MGI Panel Actor... you'd probably need to go all the way up the stack to PPL the AF itself.

Message 3 of 6
(1,934 Views)

Ahh, I see, thanks. I didn't realize that a PPL couldn't actually use libraries of the thing that called it, but I suppose it makes sense now that I think about it. Since everything is (potentially) compiled in the caller, then a PPL can't be guaranteed to have the things it needs.

 

So just thinking out loud here... I'll need to create the AF PPL at a minimum, and I'll also need to create a PPL with my Abstract Test Actor, which uses the MGI Actors. This means I'll need to modify the MGI Actors to point to AF.lvlibp, which will be a big pain (I think I'll need to do some scripting here since the Replace with PPL function is buggy, ugh). I think that would be the minimum viable solution here, as I don't plan on needing anything other than the Abstract Test Actor and the AF itself.

 

I believe this means that I can still use everything "upstream" from my Abstract Panel Actor as long as I include that PPL in the project, but there are great odds I'll need to use Panel Actors in unrelated projects in the next couple months so I should go ahead and do it "the right way" and make a PPL for just the MGI tools.

 

Thanks for the tips!

0 Kudos
Message 4 of 6
(1,908 Views)

Well dangit. I got everything figured out for porting the MGI toolkit to use AF as a PPL, and there wound up being five VI's with their block diagrams removed, meaning I can't update their references to use the AF PPL (as far as I know).

 

I've reached out to MGI to see if they have a solution, but I wanted to post it here since there doesn't seem to be any other online discussion of the MGI Panel Manager toolkit with AF PPL's.

0 Kudos
Message 5 of 6
(1,899 Views)

Followup: MGI was extremely helpful and quick to respond. Apparently, those few VI's had gotten corrupted somehow and LV thought they didn't have block diagrams. I did an uninstall/reinstall on the MGI package and everything seems fine now.

0 Kudos
Message 6 of 6
(1,889 Views)