How Do I Keep My Windows Measurement Systems Up To Date

This is part of a series of posts looking at configuration management for measurement systems. See part 1 for more details.

Typical Windows Applications

When working on Windows applications, we expect the following statements to be true (most of the time):

The PC may get used for other tasks.
The software is manually run, and the end-user interacts directly with it during use.
IT control some or all aspects of the base system.

These assumptions are important as they impact some of our approaches.

Dependencies Just For Us

Every LabVIEW application has at least one dependency that needs to be on the system. The LabVIEW Run-Time Engine. Also, we will typically have hardware drivers such as DAQmx or NI-RIO.

To keep everything in sync, use installers built with LabVIEW to install all dependencies in a single installer. You can also include 3rd party installers (with a few workarounds).

The installer should also include (or your software should be able to generate) additional configuration files, directories required and access rights.

The installer approach then meets our goal from the previous post of being able to commission a new system very quickly without room for human error.

But The Installers are Huge!

Large installers are a significant downside. Installers with the runtime engine tend to be around 300-400MB and including DAQmx will easily top 1GB. The large size will cause a problem if the end-user has a poor internet connection.

Historically we produce two installers. One installer has all dependencies and a lighter "update" installer with just our application. This dual installer approach risks mistakes but avoids this downside when you know you only have an application update.

The other solution is to look at the NI package technology. I'm yet to deploy a solution with it, but I will be looking at it for future projects.

NI package manager allows you to create a package for your application with links to dependency packages. As long as the end-user has an internet connection, then it can download additional drivers on the fly (if required).

Dependencies Out Of Your Control

Windows deployments (or deployments to general-purpose machines) have a significant limitation which is that external programs may be out of your control.

A frustrating example of this is Microsoft Excel where there is a breaking change meaning some versions will crash LabVIEW if using the report generation interface. However, Excel is typically installed and updated by IT.

This scenario means you must be prepared to work with IT and understand their software update policies. Alternatively, question every external dependency. Is there a version that you can control instead? For example, could you use a PDF generation toolkit to generate reports instead of Word or Excel?

Automation

Automation tends to be a lower priority on Windows machines since they are attended.

However, you may want to make it easier on customers by using an update server to give notifications when new updates are available. You can build this into your software or use an off the shelf solution such as BLT from StudioBods

For central control, you may be able to work with IT to use their existing software centre systems or look at tools like SystemLink from NI.

Unattended Systems

What about unattended systems? Look out for a new article in the next couple of weeks on real-time systems and steps for automating their configuration.