PPL Support in Actor Framework Project Provider

[justACS]

The Actor Framework Project Provider became an official part of LabVIEW with the release of LabVIEW 2015.  This new version of the provider included a number of exciting new features, not all of which were mentioned in the release documentation.

One such feature is limited support for PPL versions of the framework.

A few members of the community have tried building a PPL of the Actor Framework library.  One challenge they face is the loss of tool support, because the tools all point to the version of AF in vi.lib.  For example, say you have an actor that inherits from a copy of actor.lvclass inside a PPL.  You right click on a method of that actor and select Actor Framework » Create Message.  Your new message class will inherit from the version of Message.lvclass in vi.lib. It will not work with your actor, because your actor expects messages that inherit from the version of Message.lvclass in its PPL.  Broken wires and Error 1448 messages will abound.

Without tool support, AF development becomes, well...  "Tedious" is too mild a word.

Support in LabVIEW 2015

We initially addressed these issues in LabVIEW 2015 by allowing you to point the provider at your PPL, instead of at vi.lib.  To do so, add the following token to your LabVIEW INI file:

AFProjectProvider.PPL="<Path to your AF PPL>"

Be sure to include the quotation marks.

Please note that this change is global; all of your AF projects will be affected unless/until you disable the token.  At some point in the future, I want to look into making this a project-specific setting, but I can't say when I will be able to do so.

Support in LabVIEW 2016

The global option we released in 2015 quickly proved to be too coarse-grained for practical use in distributed applications, so LabVIEW 2016 introduces support for a unique PPL for every supported computing target in your project.

To use this new feature, simply create a PPL for the target and add it to the project.  The AF right-click menus will automatically point to the PPL.

If you have an actor that uses PPL that you wish to include in your project, just add the actor.  The PPL will appear in that target's dependencies, which is enough to redirect the AF tools.  I do recommend that you pull the PPL into the project itself, just for clarity.

You can only have one PPL per target.  If you have more than one, you will get error messages when you attempt to create actors or message classes.

The INI token we introduced in LabVIEW 2015 still works.  However, as soon as your AF PPL appears in the project or its dependencies, the new code will take precedence.

Both versions of PPL support require that the shipping AF remain in vi.lib, and that the template message classes remain unmodified.

Let me emphasize that the tools outlined here only address a subset of the issues surrounding the use of an AF PPL.  If you choose to pursue this, there will be other pain points.  We know of at least one:  Quick Drop and the palettes will still point to vi.lib.  Others remain to be discovered.

Please feel free to use the comments section of this document to identify any issues or best practices you discover.

(Edited 9/16/16 by niACS to include updates for LabVIEW 2016.)

[justACS]

Here's a note, with an important tip at the end, about how all this works:

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.

[LGallegos_]

Is there anything that would remove the AFProjectProvider.PPL token from the INI file?

I've had to add it back to the INI file a few times, but I wasn't sure if this was expected behavior or if I'm doing something wrong.

[justACS]

Yes.  The token will be removed if the PPL path becomes invalid, and you use any of the features of the project provider that refer to the PPL (which is pretty much all of them).

The idea is to prevent failures if you delete the PPL without removing the token.

[LGallegos_]

Is there anything else? My PPL hasn't been modified and has been located in the same directory for a few weeks, but the token is still removed.

[PBD_ctrl]

I am running into the same issue.  I've seen it happen about 5 times but I can never figure out the rhyme or reason.  Any chance dependencies of the AF PPL could be making it invalid?  Does invalid mean not present on disk or do you actually load the PPL in memory to check it?

[justACS]

Theer are three conditions where the token will be deleted.

1)  If the token is not found in the INI file. Yes, this is odd, but it saved me an extra case structure, and should be harmless.

2)  If the token is found, but its value is an empty path or not a path.  The VI that returns the token's value returns an array of paths.  I check the zeroth element, because there should only be one element in the array.  If the token value is ill formatted, I can see a possible problem.  IIRC, the string in the file should be a comma-separated list paths, with each path in a quote.

3)  If the file specified by the path does not exist.

The check gets done in several places throughout the provider:  any time we check to see if something is an actor (which is any time you right click on something in the project), when you create an actor, and several times during message construction.  So that token gets touched a lot.

I suspect a poorly formed token value to be the culprit.  Can someone please send me their token value, either by posting here or sending me a PM?

If anyone can replicate the conditions under which they lose their token, I can look into it, and file a CAR if appropriate.

[PBD_ctrl]

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

I am using the hidden gem tool to modify the LabVIEW.ini during my VIP installation process.  I works fine for awhile and then just majically disappers.  Adding the key back manually fixes the issue.

[PBD_ctrl]

Offline the issue of disappearing token got resolved.  Did that fix ever make it into LV2015 sp1?

[justACS]

Are you saying you no longer see the behavior?

We did nothing specific about this issue in 2015 SP1.

[MathieuSteiner]

Hi

I have been reading this, and must say I'm quite lost. Would I be facing a similar issue (http://forums.ni.com/t5/Actor-Framework-Discussions/Getting-error-1055-when-overriding-Actor-Core-in...) ? I'm not using any Actor Framework.lvlibp though

Any insight/help is welcome

Thanks

 Edit: Alright. Here is what I did that "helped". I packed the Actor Framework.lvlib into some "Actor Framework.lvlibp"

Then, I explicitely added "Actor Framework.lvlibp" in my abstract (and concrete) plugin project, and changed inheritance of my abstract plugin class in order to point to "Actor Framework.lvlibp:Actor.lvclass" instead to the one in .lvlib. Since I'm in LV 2016, I didn't modify the LabVIEW.ini file, and I am now able to create an unbroken "Actor Core.vi" override in my concrete plugin. Is it the way it is supposed to work ?

[justACS]

If I follow your description, then yes, that's how it's supposed to work.  And, specifically, as of 2016, you no longer need to edit LabVIEW.ini.

[MathieuSteiner]

Thanks for confirming this point

Let's say I want to use some existing code from a project that uses the library in vi.lib (typically the code from Monitored Actors)

Is there any "easy" way to update the whole existing project to have it point to my PPL actors' classes and methods in instead of the ones in vi.lib ?

Edit: Well. When opening the code I want to transform, I can go to the project dependencies. From there, I can see the "Actor Framework.lvlib" (pointing to vi.lib) and if I right-click it, I can replace it with a PPL. After having done that, no issue with the actor scripting tools. I notice in my case, that there are still a (very few) actors stuff dependencies in the project: "Time-Delayed Send Message" stuff (2 x vis and 1 ctl). I assume those are not part of the "Actor Framework.lvlib".

Two questions at this point:

1. Is there any list of such code pieces that are actor related AND NOT part of the original "Actor Framework.lvlib
2. Why is there actor related stuff that is not part of the library ? Is this still in some beta stage ?

Note: because they are considered advanced vis ?

[justACS]

1.  The contents of these folders are not inlcuded in Actor Framework.lvlib:  Batch Msg, Reply Msg, Report Error Msg, Self-Addressed Msg, and Time-Delayed Send Message.  If you need them in your PPL, you will need to make your own lvlib that contains them.

2.  Actor Framework.lvlib is the core of the framework - you can't build actors without this set in its entirety.  The items in the other folders are optional - you may need them in any given project, or you may not.  If you don't use them, we don't want to force you to include them in your projects.  (In the case of Reply Messages, we want you to make the explicit choice to include them, since they are *very* corner-case.)

[MathieuSteiner]

Thanks for answering my question. It turns out that indeed, it works great including some in my PPL

[Angelo_Philips]

Hello,

I am working with Labview 2019. 

When I create a new actor, by default labview points to the actor framework inside a packed library I have developed using this tutorial:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015A6NSAU&l=en-GB , and that's fine.

But, when I cannot create messages for methods that are inside my new actor. When I right click on the method, there is not the Actor Framework option on the menu.

I have tried to add the token on the ini file, but it does not work.

Do you have any hints ?

Thanks