Download and Login to the NIWeek Mobile App

VIEW FIND BUILD

WEEKLY SCHEDULE YOUR SESSION YOUR SCHEDULE

More Information at ni.com/niweek

Mark Yedinak
CLA, LabVIEW Champion
Zebra Technologies

Yinhui Chen
CLA
Zebra Technologies
 Effectively
Using Packed Project Libraries

Packed project libraries (PPLs) are not as difficult to use as some would think. There are certain facts
you will need to know and understand to use them effectively and fully realize their benefits.
Agenda
▪ Background
1. About us

2. Our Design Goals

3. Our Design Achievements

▪ Understanding Packed Project Libraries

1. One Container
2. Two Concepts to Define
3. Three Key Factors to Remember
▪ Tips and Best Practices
Let’s begin
ZEBRA TECHNOLOGIES
About us

THE EDGE YOU NEED TO SUCCEED

Zebra empowers those on the front line in retail, healthcare, transportation and
logistics, manufacturing and other industries to achieve a performance edge - an
edge that translates to delighted customers, good patient outcomes and superior
business results.
Our Design Goals

As our development process matured, we desired a system level design and

architecture that was

❑ 1. Easy to share code between applications and developers

❑ 2. Easy to separate code from application to application

❑ 3. Easy to maintain

❑ 4. Easy to expand

❑ 5. Easy to apply/deploy the changes/fixes/enhancements automatically

Our Design Achievements

In our design
✓ 77 core libraries, 79 plugins, 7 application specific PPLs
✓ 2 large scaled applications utilizing PPLs and plugin architecture
✓ A dedicated source code control repository for PPL source code
✓ A dedicated source code control repository for compiled PPLs
✓ A general source code control repository for application source code
✓ The ability to extend functionalities of deployed applications without the need to rebuild
the applications themselves
✓ Continuous Integration using MGI Solution Explorer and Jenkins to manage the building
process on a dedicated build server
Our Design Achievements
Understanding Packed Project Libraries
One Container
What is a Packed Project Library?

“LabVIEW packed project libraries are project libraries that package

multiple files into a single file with a .lvlibp file extension. The top-
level file of a packed library is a project library. By default, the packed
library has the same name as the top-level project library.”
-LabVIEW Help
Packed Project Library
References for more details

▪ Using Packed Project Libraries in LabVIEW Projects – LabVIEW Help

▪ To PPL (Packed Project Libraries) or not to PPL – Part 1 – LabVIEW Field
Journal
▪ Packed Project Libraries – Part 2 – LabVIEW Field Journal
▪ Plug-in Architecture using Packed Project Libraries – Michael Lacasse
▪ Revealing the secrets of the PPLs – Jarobit Pina Saez
▪ Use PPLs to Build and Deploy Large, Scalable Applications and Get a
Head Start on GLLs in LabVIEW NXG – Matthias Baudot
Two Concepts to Define
▪ Library vs Plugin
▪ Library PPLs are static reusable packages for developing PPLs and applications
▪ Plugin PPLs are dynamically loaded libraries
▪ Development vs Runtime
▪ Development PPLs have debugging Enabled
▪ Runtime PPLs have debugging Disabled
Library vs Plugin
The hierarchies and relationships
Development vs Runtime
The properties and differences

Development Runtime
Debugging Enabled Debugging Disabled
Block diagram can be opened, code Block diagram cannot be opened,
can be debugged code cannot be debugged
Size is bigger Size is smaller
Three Key Factors to Remember
▪ The components of Paths (Internal Path)
▪ The file path in a PPL (Exported File Path)
▪ The limitation of the path length
▪ Loading paths of dependent PPLs (Relative Path)
▪ Exclude dependent packed libraries
The file path in a PPL
Why do we care about the internal path?
▪ Internal Paths are normally taken care by LabVIEW when building executables
▪ When working with PPLs, Internal Paths become exposed to users

Palette menu
>File I/O
>Adv File Funcs
>Packed Library
Understanding the Exported File Path
The file path in a PPL

▪ The exported file path can be expressed as an equation

Destination Directory in Build Spec (Source Code)

File System Location for Loading (PPL or Application)

Name of the Packed Project Library Internal Paths

Simplest Scenario
Exported File Path
1. When all VIs and dependencies are loaded within one directory, vi.lib or user.lib
Common Scenario
Exported File Path
2. When there are VIs or dependencies loaded from other directories
Extreme Scenario
Exported File Path
2. When there are VIs or dependencies loaded from other directories
Build Error
The limitation of the path length
Three Key Factors to Remember
Loading paths of dependent PPLs

▪ How do PPLs reference each other?

▪ How do all these paths relate to the file system?
▪ How to configure build specs?
1) Building PPLs
2) Deploying PPLs
Our Endgame

Dependent
PPLs

Target PPL
Loading paths of dependent PPLs are relative
How do PPLs reference each other?
Loading paths of dependent PPLs are relative
How do all these paths relate to the file system?
▪ The loading paths of dependent PPLs are relative to the root directory.
▪ The whole PPL hierarchy can be relocated, but the directory structure has to remain the
same.
Relative Path:
..\..\String Handling\JSON Toolkit.lvlibp
How to configure build specs?
File System Hierarchy Specifications
To organize PPLs in a file system with multiple folders, all dependent PPLs need to be
specified in build specification.

This way, the built PPL or Dependent

executable will know where to PPLs
load its dependencies.

Target PPL
Source Files
How to configure build specs when building PPLs Add Source Library
▪ To configure the build spec of a PPL and Executable, to Top-Level Library
1. Source Files

Dependent PPLs are not required

to be added to Always Included.
LabVIEW will calculate and include
all required dependent PPLs
automatically.
Destination Settings
How to configure build specs when building PPLs
▪ To configure the build spec of a PPL and Executable,
1. Source Files
2. Destinations
Create New Destinations for Containing Folders
How to configure build specs when building PPLs
▪ To configure the build spec of a PPL and Executable,
1. Source Files
2. Destinations

Create Destinations to specify the path

of Destination in File System Hierarchy.
Configure Source File Settings
How to configure build specs when building PPLs
▪ To configure the build spec of a PPL and Executable,
1. Source Files
2. Destinations
3. Source File Settings

Apply the Configured Destination

to PPLs in Source File Settings.
To save time, simply apply it to the
containing virtual folder.
Separate Projects for Executable and Installer
Distributing the application and Deploying the PPLs
▪ To avoid a LabVIEW build issue, create
1. Project with Executable build spec
➢ It contains source code and dependent Library PPLs
Separate Projects for Executable and Installer
Distributing the application and Deploying the PPLs
▪ To avoid a LabVIEW build issue, create
1. Project with Executable build spec
➢ It contains source code and dependent Library PPLs
2. Project with Installer build spec
➢ It contains the built executable and supporting files
➢ It contains all dependent Library PPLs and Plugins
One more thing to know
Distributing the application and Deploying the PPLs
▪ Executable and Installer build specs do NOT need to point to the same destination
1. Make sure Installer distributes everything to the right destination
2. Make sure Executable knows where to load everything it needs
3. Make sure Destination of Executable and Installer keep the same depth

Executable Destination:
C:\Test Automation\LabVIEW Executables\ZCAT Plus
PPL Destination Root:
C:\ProgramData\Zebra Tools This design works
because the executable
Installer Destination:
C:\Program Files (x86)\Zebra Tools\ZCAT Plus
uses relative paths to
load and search its
PPL Destination Root: dependent PPLs!
C:\ProgramData\Zebra Tools
What is the build issue?
Distributing the application and Deploying the PPLs
When the Executable and Installer build specs are in the same project, the Installer will bring along all
PPLs included in the Executable.
 Exclude dependent packed libraries
Three Key Factors to Remember

Disabled(Default) Enabled
Dependent PPLs will be Dependent PPLs will NOT
copied to destination be copied to destination
Tips and Best Practices
Employ SOLID principles
Tips and Best Practices

Single responsibility principle

Open–closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle

NIWeek2018 - TS1114 : SOLID Actor Programming – Dmitry Sagatelyan

Do’s and Don’ts
Tips and Best Practices

Do’s
▪ Separate shared functionalities into Library PPLs
1. APIs
2. Protocols
3. Abstraction Layers
4. Shared Utilities
▪ Use helper Library PPL to load Plugins
Don’ts
▪ Do NOT nest Plugins
▪ Do NOT have circular dependencies between PPLs
For example, ActorFramework.lvlib and AF_Debug.lvlib
A tool to manage the build process – MGI Solution Explorer
Tips and Best Practices

MGI Solution Explorer

An open source and free software that helps to manage projects and build any build specs
Strategies to manage the build process
Effective Building Process

Some simple rules and hierarchies have been developed to help managing
1. Create individual Solution file for each PPL project
2. Create a layered hierarchy of Solutions for Library PPLs
3. Create a flattened hierarchy of Solutions for Plugin PPLs
Layered Hierarchy of Solutions for Library PPLs
Strategies to manage the build process

1. Layer 0 – All PPLs that has no dependent PPL.

2. Layer 1 and up – All PPLs that has dependent PPLs from previous layer(s)
3. PPL cannot have any dependent PPL at same layer.

▪ PPLs at the same Layer can be built in any order.

▪ Running the Solution file containing all layers and build them from the lowest layer to the
highest. This means all Library PPLs can be built in a single solution and simply one
click.
Layered hierarchy of Solutions for Library PPLs
Strategies to manage the build process
Flattened hierarchy of Solution for Plugin PPLs
Strategies to manage the build process

1. One top level Solution file containing Solution for all Plugins of the same kind

▪ PPLs can be built with any order.

▪ Running the top level Solution can build all Plugin PPLs
Flattened hierarchy of Solution for Plugin PPLs
Strategies to manage the build process
NI Community
Questions?
Before you go,
take the survey.
Thank you