To PPL (Packed Project Libraries) or not to PPL – Part 1

Welcome to LabVIEW Journal!  The Field Architect team is thrilled to be working with teams of talented and creative engineers throughout the US, helping them tackle the next software challenge. With NIWeek 2011 around the corner, it seems fitting to discuss a LabVIEW 2010 feature.

We are working with one team that faces a few issues related to the deployment of updated API’s (Application Programming Interfaces, or libraries, or groups of VIs with a specific task or responsibility).  This group is well organized with clear roles and responsibilities for specific libraries that are rolled into a larger test application.  However, the clean handoff and distribution of updated code has been cumbersome.

Enter Packed Project Libraries (PPLs)

A packed project library is simply a compiled .lvlib that contains all of the .lvlib’s VIs and allows the user to call the public VIs in a manner that is identical to the use of the original .lvlib.

Assume that someone is tasked with writing an analysis library that will be used by a broader team.  The developer places all of the code in an .lvlib (recall that an .lvlib is simply an xml file that references the VIs which actually reside on the computer’s file system).  The team has jointly defined the interface to the library and as such, public VIs are provided for their use.  The implementation details that may change over time remain buried in private VIs.

Create a Packed Project Library – .lvlibp 

1.  Ensure code is complete, reviewed, and tested.  Check that VIs have proper access scope.  The developer selects access scope by right clicking on the VI in the project.  Public access scope allows any VI to call the .lvlib’s VI.  Private access scope ensures that only VIs that are also members of the .lvlib can call the VI.

2.  Create a build specification and run it. PPLs are not an ideal distribution format for libraries that will be changed or modified fairly regularly.  Once compiled, the process can not be reversed.  This is on par with DLLs and EXEs.  The process moves in one direction.  Compiled code cannot be reverse engineered into the original source.  Some may consider this a drawback, others may deem it a benefit.  The developer of the library can easily modify the source in the original .lvlib and subsequently recompile and redeploy.

3.  Distribute the PPL to team members.  What were formerly public VIs of the .lvlib, are now called Exported VIs in the .lvlibp.  They are used in the calling code in the same manner as the public VIs of the former .lvlib.

4.  Initially transition to the .lvlibp.  You can right click on the .lvlib and select the option to replace with a Packed Project Library.  This feature is included to facilitate the transition to using PPLs.  No feature is included to reverse the process, see below.

Ensure Better Software Development Processes

In summary, PPLs are an elegant solution for the smooth deployment of a group of VIs from the developers of those VIs to the team who will be using the code.  One .lvproj is used for PPL development and then the PPL could be utilized in unlimited projects. Those who are using the PPL cannot edit the VIs and have no exposure to the private VIs.  PPLs force us to implement a few practices that we often skip: ensure code is complete, reviewed, and tested.  Then deploy the code.

As noted above, once you convert calling code  to use a PPL, LabVIEW does not have a native mechanism to revert the calling code such that it now points to the original .lvlib.   Rumor suggests that a very enterprising Applications Engineer at National Instruments wrote code to revert back to *.lvlib.  However reverting breaks the original intended use case for PPLs.  As bugs and features are needed in the PPL, it is the developer’s responsibility to make changes to the .lvlib, retest, rerun the build, and distribute it to the team.

Easily Update Libraries called by a Test Application

Once the test application has been deployed as an exe, updating to a new PPL is straightforward.  The build specification for Test.exe allows the developer to select the directory in which the PPL will reside.  Updating to a new version requires a simple copy of the new PPL to the Test.exe’s directory, replacing the old file.  As such, Test.exe is not modified thus saving the time to revalidate. Test.exe must be rerun to call the new version of the PPL.

Look Under the Hood

Let’s consider the use case in the previous paragraph.  What would happen if developers where not using PPLs?  Answering this question requires that we dive into the details of how the LabVIEW execution system works. One of the nuances of LabVIEW is that a change in a subVI can cause calling VIs, potentially numbering in the hundreds, to be forced to recompile.  Changes that force the recompile include modifications to the inplaceness algorithm of the subVI or specific changes to the connector pane.  (Brian Powell might comment on the inplaceness algorithm in a future post, provided the community vigorously asks him to do so). When PPLs are not used, the calling code would detect the changes and force the recompile.

So what is happening in the LabVIEW execution system once PPLs are in use?   The execution system now recognizes that a difference exists between expected state of a PPL subVI and it’s newer state (different inplaceness etc.).  So the caller is intelligent and when changes occur, it uses a VIServer-like methodology to call the subVI that is part of the PPL.  As such the caller has the responsibility to do what ever is necessary, potentially copy data, etc., so that it can call the subVI in it’s newer state without the recompile.  All of this is transparent to us, the users of the PPL.  Without the forced recompile, many users may experience the benefit of reduced build times.

Address the Issues With Hierarchies of PPLs

We’ve covered the basics.  Now we move to a more complicated situation that we encountered.   Let us consider the use case in which LibaryA.lvlibp calls LibraryB.lvlibp. When LibraryA is first compiled to a PPL it will place LibararyB.lvlibp in a support directory.  This is fine, until Test.exe will call both LibraryA.lvlibp and directly call LibraryB.lvlibp.  Building Test.exe requires that a new copy of LibraryB.lvlibp be placed in a support directory, thus two copies now exist.  Fully describing this scenario and the potential solutions will be detailed in a future post. However, it did convince us that PPLs are not yet perfected.

Talk About Your Experiences

As Brian noted in his post, we are utilizing this forum for an honest conversation about our challenges and the best solutions moving forward.  We look forward to your comments, commendations, and criticisms about Packed Project Libraries.  Your ideas and feedback will help drive improvements to this and other features.