LabVIEW 2015 AF PPL

[PBD_ctrl]

I have decided to head into PPL land in the pursuit of greener pastures for plugins.  I work with many other other developers and so I would like to build AF into a PPL distributed via VIPM.  So far it appears to be pretty trivial in 2015 but I have run into a couple of snafus.

1. If I am going to distribute to many diffrent developers should my installer do a complete replace of standard AF with a PPL version or is it a better idea to distribute them along side each other?

2. What sort of hoops do I need to jump through to get this PPL to work on RT targets?  I am assuming a seperate specially compiled PPL is required here but I am looking for confermation and advice.

3. How do I handle pallete items like "Batch Msg.lvclass" which is not included in AF.lvlib?

4. Why the heck didn't LV 2015 ship with AF as a PPL?

thanks,

        -PBD

[justACS]

PPLs are new territory for the AF community.  So far, I know of only a couple of people have tried it.  I'll see if I can get one of them to comment here.

I don't have much to say about 1. 2. or 4.  For 3., I believe you can include additional components like Batch Msg by manually adding them to the PPL.  You'll want to do this, because Batch Msg won't work if you don't (it points to the wrong enqueuer).

[justACS]

PPL support documentation is here:

PPL Support in Actor Framework Project Provider

[PBD_ctrl]

This was helpful until it appears to have been pulled while I was working on a reply.

I tried what the documentation suggested and wasn't able to get it to work.  Every time I would try to create a message it would go searching for Message Enqueuer.lvclass and Actor.lvclass while trying to load Message Template.lvclass.

Thoughts?

[PBD_ctrl]

To help others trying to go through this procedure here is what I did to create a PPL and functioning palette.  I still am trying to work on getting the native AF project provider to stop searching for classes.  If somebody notices an issue with this procedure please call it out.

After I get all of the bugs worked out I intend to build this into a VIP.

Don't blame me if this doesn't work for you.

1. Close LabVIEW

2. Backup

Copy the following files/directories and place them in a save location where they won't get touched up.

• ...\vi.lib\ActorFramework
• ...\resource\AFDebug
• ...\menus\Categories\Data Communication\_actorframework_experttools.mnu
• ...\menus\Categories\Data Communication\_actorframework_msgqueuepair.mnu
• ...\menus\Categories\Data Communication\actorframework.mnu
  

3. Remove Shipping Version of AF

Remove the contents of the list below to avoid conflicts.

• ...\vi.lib\ActorFramework
• ...\resource\AFDebug

4. Open LabVIEW

Create a new project.                                                                                           

5. Fork Actor Framework lvlib

Copy your backup of Actor Framework.lvlib and AFDebug.lvlib.  Add them to your project. Forking the Actor Framework needs to be done because Actor Framework.lvlib that ships with LabVIEW does not contain the classes and VIs shown in the snip and AFDebug.lvlib.  I struggled to decide how to handle AFDebug.lvlib and ended up throwing into my fork of the Actor Framework.lvlib for lack of a better idea.

Add AFDebug.lvlib and the classes/VIs shown above to your customized Actor Framework.lvlib.

6. Build PPL

I recommend calling it Actor Framework.lvlibp

7. Generating New .mnu's

I wrote a simple VI to read in the mnu's that I backed up and then create a new identically named set that pointed to the lvlibp.  I then placed those in the directory that I pulled to originals from.  I was able to get every VI and class on the palette to work(simple does it open test not functional) except for "Init Actor Queues FOR TESTING ONLY.vi".  For some reason that VI was creating all sorts of weird issues so I removed it from my PPL and ignored it in the mnu remapping which ends up showing nothing on the palette(shouldn't be a big deal).  This is an annoyingly complicated process that I tried to hack around for awhile.  I tried methods using VIPM and LabVIEW but was unable to find a way around this remapping.

8. Modify LabVIEW INI

Add the following token => AFProjectProvider.PPL="C:\Program Files (x86)\National Instruments\LabVIEW 2015\vi.lib\ActorFramework\Actor Framework.lvlibp"

9. Restoring Orginal AF Install

Using the copy of the orginal AF install made in step 2 place the AF install back into it's orginal loaction next to your PPL.  This needs to be done so that the message make will function correctly.

[PBD_ctrl]

For those interested the problem with the Message Maker Provider can be resolved.  What you need to do is repair the templates that it is using.

...\resource\Framework\Providers\MessageMakerProvider\_Message Maker\_templates

I am not sure what how the INI token is supposed to work.  It seems as though something was left out or untested?  My plan at the moment is to ship the modified templates.

[justACS]

The post was blocked briefly by the moderator, but it's back now.

[justACS]

Did you remove AF from vi.lib and then set the INI token?  In other words, did you only have the PPL version of AF available when you tried to build message classes?

[PBD_ctrl]

Yup modifiying the token was the last thing I tried.  Does the name of the PPL name matter?  The first PPL I built was named "Actor Framework PPL.lvlibp".  I pointed the LabVIEW token at the PPL started up LabVIEW and then tried to build a message.  When it started searching for a VI/class I new something was wrong so I killed the process and started looking for answers.  I then decided to change the PPL name(by rebuilding and changing the INI) to "Actor Framework.lvlibp" thinking that maybe it would help.  It didn't and so I went about riffling through MMP and ended up manually changing the templates.  Any chance that my name switch affected anything?  I am guessing the only way to test this is to play with a virgin install of LV2015.

How does the token work?  Maybe I am over simplyfying something but I can't figure out how in the background changing the token would be able to modify those templates to depend on the PPL instead of the lvlib.  Just as if you where to open an Actor Framework project that was written with the lvlib but had the PPL installed instead it would create a huge mess.  Does the token also address this issue?  Is there a chance that because the PPL NI used to develop this feature doesn't match mine exactly that this remapping process didn't work?

[justACS · Accepted solution]

The provider creates a new message class by copying and renaming a template class, setting the inheritance of the new class, adding attributes, modifying the template Send VI, and then modifying the template Do VI.  (In scripting, you always start from a template, when you can.)

If you have set the token, the script that sets inheritance will make the message inherit from the version of Message.lvclass in your PPL, and the scripts that modify the template Send and Do will swap out all instances of Enqueue.vi and Actor.lvclass for their equivalents in the PPL, using the path you provided.  This means that the shipping AF needs to remain in vi.lib, and that you should not modify the template classes.

The PPL name should not matter, because you tell the provider about it when you set the token's value, and the fully qualified names of everything in the PPL will be different from those in the LabVIEW library.

I reviewed our test procedure for this feature, and we ran a pretty complete series of tests for all the permutations of actor and message creation with PPLs.  That said, it is a new feature, and we may well have missed somthing.

I recommend you restore AF to vi.lib, restore your templates, and give your PPL another shot.  I will be interested in hearing about your results.  It might be best to take any further detailed discussion off line (feel free to PM me), and then I will summarize our findings and recommendations on the post about the feature.