Problems converting Actor Framework to PPL in mature application

[Mike_Le]

So I'm trying to convert Actor Framework into a PPL in a project with ~70 Actors. After I created the packed project library and tried to do "right-click --> replace with packed project library" on Actor Framework.lvlib, LabVIEW replaced every instance of Message Enqueuer.lvclass labels with "Actor Framework:Message Enqueuer". So this broke basically every class as unbundle by names for any given nested actor's enqueuer now point to labels that do not exist.

Even worse: for methods of all my old Message classes, the front panel terminals still pointed to the original Actor Framework.lvlib Message.lvclass. I suspect that front panel controls/indicators were not updated to point to the PPL?

Manually fixing this in all 70 Actors' private data and message classes is something I would very much like to avoid. I ended up reverting all the changes.

Does anyone have a guide on how to safely replace Actor Framework with a PPL in a large existing project?

I'm using LabVIEW 2016 SP1.

[Oli_Wachno]

Hi Mike,

I have switched to a PPL of AF quite a while ago (LV2013). I don't remember having seen issues when switching over the application (by then ~20 Actors). Yet maybe I have (somehow) forgotten ...

I can only provide ideas on where to look.

1.) Does you AF PPL really contain all classes / VIs you need? (I remember having seen issues, when creating the PPL). Ours looks like this.

2.) Do you use any special Path settings in our environment, which might cause hickups?

3.) Have you already played / tinkered with the lvproj file in an editor to manually force some dependencies? Not that this is recommended, yet sometimes it helps.

BTW... do you have AF as an implicit dependency or as an explicit project item?

Another situation, to prove the benefits of SCC  

[Mike_Le]

Thanks for the response, Oli. It's encouraging that other people have managed it, so I know it should be possible.

1) Yes, I followed the instructions from the following thread and moved the Time-Delayed message and a few other messages into the lvlib first:

https://forums.ni.com/t5/Actor-Framework-Discussions/How-to-build-a-PPL-including-Actor-classes-mess...

2) There are no special Path settings in the project.

3) I have not tried tinkering directly with the lvproj file. I guess I could give that a try next.

Yes, source control saves the day once again.

[Taggart]

A simple scripting VI would probably solve your problem.

[Mike_Le]

---

@Taggart wrote:

A simple scripting VI would probably solve your problem.

---

I was considering that, and maybe I'm being an idiot here, but what would the script even do? How would it figure out what the original label needed to be after doing the right-click replace with PPL?

Or are you suggesting I replace the right-click replace with PPL functionality with my own script?

[cbutcher]

I think Sam's suggestion was more that you carry out the normal replace with PPL, then that when you have mismatched bundle/unbundle by name nodes, you write a VI which scans through (all VIs/selected VIs(project provider probably needed for that)/specified path VI(s)) and replaces the incorrect generated name with the correct name.

I've had this problem sometimes (but not always) when switching but only in smaller projects, so I've just fixed it manually. I don't remember but think the names are fixed at least for the source. If the target name varies based on the class, you could perhaps either allow a pattern to check, or look for things with the appropriate class, or if ambiguous, do nothing?

I'm sorry that I don't remember how and why I encountered this or perhaps I could suggest a way to modify the lvlib dependent project to avoid it...

[StefanLemmens]

I have upgraded a large project with many actors to ppl actors by using a script. 

It is similar to going from step 3 to 5 in this example/tutorial I created, so probably not exactly the same as what you need.

However the common steps that need to be done are :

1. Get reference to your project
2. Recursively list all items
3. Modify actors to inherit from actor inside "Actor Framework.lvlibp"
4. Modify message classes to inherit from Message class inside "Actor Framework.lvlibp"
5. Scan all vi's for subvi's that are located in ..\vi.lib\ActorFramework and replace those with the same subvi from within "Actor Framework.lvlibp"
6. Scan all vi's for typdefs that are located in ..\vi.lib\ActorFramework and replace those with the same typedef from within "Actor Framework.lvlibp"

Unfortunately my conversion tool does a lot more than just these steps since it also adds project related stuff, so I can not share this.

But I attached 2 vi's that might help you to figure out the last 2 steps and a screenshot on how you can modify the inheritance.

Hope this helps.

Best Regards,

Stefan Lemmens

Intersoft Electronics

[Taggart]

I had in mind more of what Christian is suggesting: Use the builtin functionality and use scripting to clean up afterwards, although Stefan's idea would also work.

[Mike_Le]

Thanks for the feedback, all.

At some point in the next couple weeks, I'll give Stefan's option a try.

I'm still not clear how Christian/Sam's suggestion would work. For example, let's say I have this working code prior to the PPL replace:

After the replace, I end up with something like this:

How would a script know what to update the unbundle by name to? The original label data is lost in the class private data. This example is fairly simple so there are only two enqueuers, but I have cases with a dozen nested actors.

[Taggart]

I did not understand the problem correctly.  That would be difficult.

How about this?

1. write scripting code that captures all the labels for the private data elements for each of your classes.  Write them to a file.

2. do your replace.

3. Write a simple script that reads the file and resets all the private data elements.

That should work.