More effecient workflow for converting common classes to PPLs and then updating the multiple projects that use them to the PPL variant

[matt.baker]

I'm in a world of pain right now trying to migrate classes that do not belong to a library, to a packed library equivalent for multiple projects.

To generate the class PPL, I do the following:

1. Add the raw class to a new library with the same name in isolation.
2. Create a PPL build spec and build it.
3. Commit this state in the common class's Git repo.
4. Checkout/revert to the previous state to before the it was part of a library.
5. Open the next library that uses it.
6. Add the same class in stage 1 to a library and save it to ensure the links don't get broken.
7. Use the replace with packed library feature.
8. Do this for all dependencies to be replaced with PPLs (sometimes stage 4 of the process below as well).
9. Go back to stage 1 and do the same for this class.

To fix the project where these common classes are used, I do the following

1. Revert all of the library changes to how the project would normally open (back to just classes).
2. Open the project and re add the classes back to libraries to avoid breaking links.
3. Replace with packed library.
4. Lose the will to live when LabVIEW decides to only replace some of the occurrences with the new PPL version.
5. Try it a few more times to be sure. Some times this seems to work if I do the libraries in another order.
6. Curse NI, and manually try to replace the dependency links with the PPL variant.

<rant>

It's taking a whole day to do one project due to LabVIEW's woefully inadequate 'Replace with packed library' feature refusing to update many items after multiple attempts. No errors or feedback to the user, just 'Nope, not doing it' and silently failing. For the failed items I have no choice but to manually replace each vi, ctl etc. with the packed equivalent which is extremely time consuming and error prone.

It's also taking a long time (over a minute in some cases) when adding the class to a library or switching it to a PPL as it goes away and silently updates links without any useful feedback to the user (the spinning loading cursor does not count). This also hangs the UI and generates the not responding prompt sometimes. Right clicking on an item in the project to bring up the context menu can also cause LV to hang indefinitely (I've left it over 10 minutes to see if it would ever complete).

The more items I try to do in one hit the slower it will obviously go, but then at the other end I have to add the classes to libraries more times. I.e. In theory I could load up all of the projects in one super project and do all of the actions once, but LabVIEW would probably crash.

There has to be a more efficient workflow compared to the one I'm using for achieving this from my starting point? If you have any helpful ideas, I would be extremely grateful if you could share them.

The sooner I can get rid of this software, the better... </rant>

[matt.baker]

Slightly related: Are there any built-in tools that allow a class/library/llb etc. to be completely swapped out for another instance including all VIs, type defs etc. that match the names of the target class (omiting the container name) project-wide (including dependencies) and semi-automatically?

Original item Class 1.lvclass

• Class1.lvclass
  • Method 1.vi
  • Method 2.vi
  • Type def 1.ctl

Target item: Library 1.lvlib:Class 8.lvclass

• Library 1.lvlib
  • Class 8.lvclass
    • Method 1.vi
    • Method 8.vi
    • Type def 1.ctl
    • Type def 2.ctl
  • Class 6.lvclass
    • Foo.vi
    • Bar.ctl

In this example I would expect the following

Class 1.lvclass:Method 1.vi → Library 1.lvlib.Class 8.lvclass:Method 1.vi

Class 1.lvclass:Type def 1.ctl → Library 1.lvlib.Class 8.lvclass:Type def 1.ctl

Class 1.lvclass:Method 2.vi → No action

[cbutcher]

---

@matt.baker wrote:

Slightly related: Are there any built-in tools that allow a class/library/llb etc. to be completely swapped out for another instance including all VIs, type defs etc. that match the names of the target class (omiting the container name) project-wide (including dependencies) and semi-automatically?

---

Built-in -> no-ish?

This link might be useful to you (although it doesn't exactly solve your problem - it instead carries out the "Replace with Packed Library" but programmatically): Unit-Testing-a-built-PPL

From there, you could perhaps look at scripting a more complex tool that carries out some of your steps.

When I've had need to do what you're doing, I usually do it in far fewer steps, but I also by the sounds of it have far fewer projects!

For me, it becomes something like (and I haven't taken notes, so apologies if this is impossibly inaccurate):

• Build my new PPL (your first few steps)
• Go to a library that uses the PPL. The class is loaded into memory (not PPL copy)
• Add the PPL to the project. This will not conflict, because they have different namespaces. Nothing is replaced though...
• Manually (with quick drop and Ctrl+P(+Shift?)) replace some instance of the non-library class with the PPL-enclosed class. Everything breaks as classes conflict!
• Save all and close project.
• Delete/move/rename the source code lvclass so that it won't be found
• Reopen the project. Oops! No way to find the class. But now it might update to the other one? (probably not).
• Spam my way through all the missing bits via Dependencies > myMissingClass.lvclass > Why is this in dependencies? > double click > change with Ctrl+P, then Ctrl+G (not quick drop) to get next item highlighted (from previous list of why in deps - this is a generally useful shortcut to go to the next found item from any of these Find > Callers/SubVIs/Why in deps etc)
• Cry a bit inside...
• ???
• Profitttssss....?

So I'd say if you have a lot of projects and a lot of intended PPLs, the scripting might be worthwhile!

[matt.baker]

Thanks for the suggestion!

I'll give the rename/delete a try, but as you said it probably wont work (I think I already tried this and it failed spectacularly, but will double check).

The projects load in about 2000 items with most of them from custom common libraries/classes (~140 libraries total to be PPL'd I think) so fixing the missing items is unmanageable without some kind of automation.

There are approx. 10 active projects and around 40 in total that may need updating at some point, all using the same libraries.

I did think about the scripting option, but then started thinking by the time I've created something suitable/semi-reliable, would it have been just as quick to do it manually (although I might have had a breakdown by then haha). May have to go down this road though.

Thanks again

[Ben]

It could make it worse...

Tools >>> Advanced  >>> Clear Compiled Object Cache

May help if LV is looking at the cache instead of your desired changes.

But if does not work, it could introduce even more delay.

Ben

[matt.baker]

Thanks Ben. That's a very good point.

I did try that previously and it did appear to correct some of the links the next time I opened the project. It took a while recompiling everything on access, but got there eventually.

I've just tried deleting the non PPL libraries and relinking the files and it worked better than expected.

Keep finding more broken features in LabVIEW IDE: Unable to right click on broken type def (contained missing classes) and select Open type def as it's greyed out.

Almost finished one whole project now which I need back up and running asap (could always revert, but want PPLs in next release).

[matt.baker]

---

@matt.baker wrote:

     3. Replace with packed library.

     4. Lose the will to live when LabVIEW decides to only replace some of the occurrences with the new PPL version.

---

Okay, I'll take some of that back and blame myself for this . I renamed a few classes before packing them which meant that LV couldn't resolve them. The lvlib can be any name, but the parts inside must remain the same. Would have been helpful if LV had given some sort of warning/message to explain why though, instead of silently failing.

[Mark_Yedinak]

In our environment we have approximately 170 PPLs with a hierarchy 11 levels deeps. First, I highly recommend that you use MGI's solution explorer to aid in the build process. Depending on changes made, you may need to rebuild quite a few PPLs if something changes.

Anyway, what we end up with lots of projects. We start at the lowest level PPLs, those that are not dependent on any other PPLs, and build them first. We generally call this "Level 0". With solution explorer to you can build solutions of solutions which means you can define the build order of your PPLs. Once all of the Level 0 PPLs are build, move to the next level. Level 1 will be PPLs that will use any number of Level 0 PPLs. Within these projects you begin to use the "Replace with PPL" to now include your PPLs. Do this for all of the Level 1 libraries. Move to the next layer and repeat the process.

We will have a solution file for each PPL. We will also have a solution file for each Level. Finally we have a solution file containing all of the levels, building them from the bottom up. When defining "levels", it means that any PPLs at level "x", can only include PPls from levels "x-1" and below.

It can be a tedious process to do the conversion, but once done it works fairly well. When I am in the transition phase, I duplicate the original source to a new folder location and then do the conversion there. It makes life easier.

See our presentation from NI Week regarding effectively using PPls. 

[matt.baker]

Thanks for the detailed reply, Mark! Some excellent info which I'll be sure to use.

I came across your presentation yesterday morning, from a post in another thread about PPLs, but haven't had a chance to watch it yet. I'll go and have a watch of this now and digest the info - I've skim read through the presentation slides which were useful.

I think my maximum PPL hierarchy depth is currently about 6-7. Build automation will definitely be the best solution.

[matt.baker]

After much frustration I managed to build a semi-working 'Find and Replace' tool that allows the user to specify a project, have it search through all items in the project (purposely excluding dependencies), open each compatible type, perform multiple regex searches/matches on all the VIs/type defs/classes etc. (including if they are nested in non-typedef containers) and then replace it with another specified type based on regex style lookup list.

Will hopefully be able to release this at some point when it's a bit more user friendly and dependencies are sorted.

Saves so much time when updating projects and libraries with new dependencies.

Proof of concept