PPL Paths
As some of you may know, we host a Virtual Coffee on Tuesday mornings. It started out as a part of our local LabVIEW User Group ALARM. A bunch of us ALARM members would get together every couple weeks in person for coffee. When COVID hit, we couldn’t do that so we started meeting over Zoom. I figured since it was virtual we should open it up, so I invited a bunch of other LabVIEW friends.
A lot of very skilled LabVIEW developers show up regularly, including many LabVIEW Champions. We end up having a lot of very productive discussions. Recently we had a discussion about some of the pains of reusing PPLs across Real-Time targets. Luckily Stephen Loftus-Mercer happened to be there. He came up with a solution which he posted on the NI forums.
The Problem
The main issue with PPLs is that when you build them, they get compiled for a specific target. You can’t use them on another target. This makes reuse complicated.
First of all you have to have a different build for each target. This can get really complicated for RT targets since they can run Pharlap, VXworks or linuxrt in various bitnesses. You also have to account for cRIO vs PXI. That gets complicated but can be accomplished with a robust automatic build system and continuous integration.
The real challenge is how do you expose those PPLs to a developer? Imagine you create a reusable PPL. You want to use it for all your RT projects.You have an automatic build system so you have a PPL for each. That’s great! However, your end developer needs to know which piece of hardware it is going to run on in order to pick the right PPL.
Let’s say the developer gets it right and picks the right PPL. Now what happens if you want to take that VI he wrote that uses your PPL and use it on another project that uses a different RT target. You can’t do it without replacing the PPL. Same thing if you decide to upgrade to a newer cRIO or PXI chassis. As you can see this creates a bunch of problems.
The Solution
The first part of the solution is to have a robust automatic build system. Let’s assume you already have that. You still need to solve: How to make it easy on the developer to pick the right PPL for the target? and how to move code from one target to another without having to replace the PPL?
The solution is to use LabVIEW’s symbolic paths as explained in AQ’s post. Each target looks for VIs in different paths. You already know about .vilib and .instrlib that change depending on the version of LabVIEW. These symbolic paths for targets work simlarly.
What you need to do is use VIPM or something similar to take all of your various PPLs that you have built for each target and install each into the correct symbolic path for that target. While you are at it you can edit the palettes to make things even easier for your devs. Now your devs can just drop VIs from the pallettes and LabVIEW behind the scenes will automatically select the right PPL based on the target. Also moving VIs from one target to another should be as simple as drag and drop.
Join the Discussion
Want to join our Virtual Coffee? Use the button below to signup and get an email with the meeting information.
