Sam Sharp GDevCon#2

Efficient Working with Databases in LabVIEW – GDevCon#2

In August 2019 at the Repertory Theatre in Birmingham, I gave a presentation at GDevCon#2 discussing working with databases in LabVIEW. The videos from the event have now been edited and uploaded to the GDevCon YouTube channel.

The playlist with all of the great content from GDevCon#2 is here –

In the presentation I offer some hints & tips for working with databases in LabVIEW (best practice, security). Then I propose a method for speeding up development by applying techniques learnt from Yii’s (a PHP Framework) ActiveRecord implementation. Finally, I demonstrate an OO-based LabVIEW ActiveRecord implementation and some scripting tools I have developed for generating the classes automatically from a database schema.

You can find the video of my presentation and the presentation slides below:

Presentation Video
Presentation Slides

If you have any questions about the presentation please leave a comment below. If you would like to discuss whether MediaMongrels Ltd can help streamline database communications then feel free to get in touch.

MAKE-ing with LabVIEW - Part Three

MAKE-ing with LabVIEW & Raspberry Pi: Part 3 – Raspberry Pi Setup

In Part 3 of this series on using the Raspberry Pi with LabVIEW I will be configuring a Pi 3 B and installing the LINX Toolkit on it. I will also cover some handy hints & tips when setting up the Raspberry Pi.


This guide is based on the official set up guide from the Raspberry Pi foundation – found here.

We’ll be setting up the Pi with the latest Raspbian OS package downloaded from the official Pi website and then installing the LabVIEW Run-time.

The Raspberry Pi website offers Raspbian and NOOBS – NOOBS is an easy way to download and try out different OSes for it but it takes up more space on your SD card and may prevent things like configuring it to run headlessly (without a display). I also expect that only Raspbian is supported by the LINX Toolkit.


For the initial setup, you’re going to need the following:

Equipment required to configure a Raspberry Pi.
Time to gather your tools to harvest the Raspberry Pi!
  • Raspberry Pi: The LINX Toolkit officially supports the Pi 2/3 but I will provide an update or a separate post on other targets such as the new Pi 4 and the Pi Zero W.
  • Power Supply: For the Pi 2/3 you need a MicroUSB with an output of at least 2.5A and 3.0A USB-C for the Pi 4.
  • >=8GB microSD card: You can use a blank/formatted card or you can buy microSD cards with NOOBS (the Raspberry Pi OS launcher) preinstalled. The SD card will be the disk drive of your Raspberry Pi so will contain the OS and all of your programs/files – it’s worth getting a decent Class 10 SD card or above.
  • SD Card Reader: You’ll need to format & install the OS image using another computer with an SD card reader. You might also need a microSD to SD adapter.
  • Screen and Keyboard/Mouse: Recommended for the initial setup but read the hints & tips at the bottom of the post to learn how you can set up the Raspberry Pi without these and use SSH and/or VNC to access the Pi remotely.
  • Ethernet Cable / WiFi Credentials: To install the LINX Toolkit / LabVIEW Runtime to the Raspberry Pi it will need to be connected to the internet (to download the LabVIEW Runtime) and be on the same network as your LabVIEW 2019 installation (to configure/setup the Raspberry Pi and to deploy code to it).

Of course, you’ll also need your laptop/PC with LabVIEW 2019 and the LINX Toolkit installed – as discussed in Part 2.

How to: Set up a Raspberry Pi for LabVIEW

  1. Download the Raspbian OS

    Go to the download page for the Raspbian OS and download the latest Desktop edition (at the time of writing that is Raspbian Buster). There are three editions of the OS available:
    Desktop: The main OS installation that includes a GUI desktop. The GUI can be turned off to improve performance later.
    Desktop and recommended software: As per the ‘Desktop’ download but includes additional preinstalled applications (e.g. for education/programming purposes) – find out more about what’s included here.
    Lite: This is a minimal OS installation without any desktop functionality – you have to use the command-line interface. You can install the desktop support later if you want.Raspbian Download Options

  2. Install the OS to the microSD card

    The easiest way to prepare the SD card for your Raspberry Pi is to use balenaEtcher – a multi-platform GUI tool that can format and install the Raspbian OS image to the SD card. Alternatively you can use Win32DiskImager. Note that this will format/wipe the SD card.
    – Download and install balenaEtcher from here. It will automatically open.
    – Select the Raspbian OS image file you downloaded in the previous step (you don’t need to extract the .zip file).
    – Select the correct drive for your SD card.
    – Click ‘Flash!’ to begin. The process will take around 5-10 minutes.
    The instructions for writing the image to the SD card can also be found here.Install OS image using balenaEtcher

  3. Connect your Raspberry Pi

    Now you have your SD card prepared, you can install it and connect everything up.
    – Install your SD card to the underside of the Raspberry Pi
    – Connect your mouse/keyboard to the USB ports
    – Connect your display(s) to the HDMI port(s)
    – (Optional) Connect an ethernet cable from your Raspberry Pi to your network / router

  4. Turn on the Raspberry Pi

    Connect the power supply to the Raspberry Pi. You should see a red LED on the Raspberry Pi board and after a few moments you should see raspberries on the display and the Raspberry Pi will boot to the desktop.

  5. Configure the OS

    When it has finished booting, a wizard will appear to allow you configure the basic settings on the Raspberry Pi like the language, timezone and WiFi settings (if present).
    – Firstly, enter your country, language and timezone.
    – On the second screen you can enter a new password for the ‘pi’ user account and make a note of it – you’ll need it.
    – Thirdly, if your Pi has onboard WiFi (e.g. a Pi 3, 4 or Zero W) then you can connect to it now
    – Lastly you can check for updates to the OS and applications. The wizard will then prompt you to reboot the Pi if required.
    Raspberry Pi Setup Wizard

  6. Hooray!

    If you made it this far – congratulations, you now have fully functioning Raspberry Pi computer!

    If you ran into any issues – check out the official troubleshooting guide or the Raspberry Pi help forums.

  7. Enable SSH

    SSH allows you to remotely access a command-line prompt on the Raspberry Pi. This allows you to enter linux commands to access/control the Raspberry Pi. It’s also required by the LINX Toolkit to install the LabVIEW run-time and deploy projects to the Pi.

    In newer versions of Raspbian it is disabled by default (to protect against hackers).

    Open the Raspberry Pi Configuration utility from the ‘Preferences’ menu, open the ‘Interfaces’ tab, click ‘Enable’ next to SSH and then click OK.

  8. (Optional) Enable GPIO Hardware Peripherals (SPI/I2C/Serial)

    The GPIO pins on the Raspberry Pi support a number of protocols/interfaces but they need to be enabled so they can be used from the LINX Toolkit. You can enable these peripherals from the Raspberry Pi Configuration screen as shown above.

    If enabling the Serial Port interface, make sure that Serial Console is disabled so that the port is accessible in LabVIEW.

    At the time of writing, the LINX Toolkit supports I2C on pins 3&5, Serial on pins 8&10 and SPI on pins 19,21&23. See the pinout here for more information.

    Note: All of the GPIO pins are 3.3V – directly connecting any signal >3.3V will likely damage the GPIO functionality of the Raspberry Pi.

  9. Install the LINX Toolkit / LabVIEW Run-time (Method 1: Wizard)

    Note: The first beta version of the LINX Toolkit had a number of bugs that mean the installation fails – either apply the fixes at the bottom of the post first and come back here or try the Manual method below.

    Update 10/10/2019: NI have updated the LINX Toolkit to Beta 2 which fixes using the Wizard to deploy the LabVIEW Run-time to the Raspberry Pi and adds official support for the Raspberry Pi 4. I have updated the article reflect this.

    – Open the Target Configuration Wizard from ‘Tools -> MakerHub -> LINX -> LINX Target Configuration…”

    – Enter the hostname/IP, username and password for the Raspberry Pi and click ‘Connect’

    – Click the ‘Install Software’ button and then click ‘Install’ – this will perform the required configuration on the Raspberry Pi and install the LabVIEW run-time. This will take a few minutes.

    After the installation is complete, the ‘Installed Version’ should show something like 19.X.X (for me at the time of writing it is 19.0.1-2).

  10. Install the LINX Toolkit / LabVIEW Run-time (Method 2: Manual)

    The manual installation method is to use a terminal or SSH session on the Raspberry Pi and run the following commands:
    echo "deb [trusted=yes] binary/" | sudo tee -a /etc/apt/sources.list
    sudo apt-get update
    sudo apt-get install lvrt19-schroot -y

    The first line you only need to run once to set up the LINX Toolkit repository on the Raspberry Pi. The 2nd and 3rd lines retrieve the latest package versions from the repository and then install the ‘lvrt19-schroot’ package which has the LabVIEW Run-time.

  11. Run the Example Project

    If everything has gone smoothly so far you should now have the LabVIEW Run-Time installed on your Raspberry Pi.

    You can test it out by pressing the ‘Launch Example’ button from the Wizard which will generate a example project and configure the IP address of your Pi for you.

    If the ‘Launch Example’ button doesn’t work, you can copy the template project from C:\Program Files (x86)\National Instruments\LabVIEW 2019\vi.lib\MakerHub\LINX\Private\Templates\Raspberry Pi 2 B to another folder, open the project and change the IP address to match your Pi and then run it. To do this, right click on the Raspberry Pi target in the project and go to ‘Properties’, then update the IP Address field and click OK.

    You can then ‘Run’ the VI, the code will be deployed to the Raspberry Pi and if you have an LED to hand you should be able to toggle it by connecting it to the correct GPIO pin.

  12. Congratulations!

    That’s it! You’ve now configured a new/blank Raspberry Pi with the latest Raspbian OS image, configured it for remote access, installed the LINX LabVIEW Run-time and run the sample/template project.

Hints & Tips

Remote Access – VNC

Once you have done the initial setup of the Pi and it is connected to your network, you might not want to keep a display/mouse/keyboard attached to it. The solution is to enable VNC – it’s the Raspberry Pi equivalent to remote desktop and allows you to view and control the Raspberry Pi remotely.

The first step is to enable the VNC server on the Raspberry Pi using the configuration tool (or via sudo raspi-config). You will then need to install the VNC Viewer which you can download from here.

Once installed, you can enter the hostname/IP address of your Raspberry Pi and then connect using the same username/password as SSH.

Accessing the Raspberry Pi via VNC

Headless Raspberry Pi (no display)

If you don’t have a mouse/keyboard/screen available for the initial setup, you can still setup and configure your Pi over the network.

You can do this by modifying the contents of the ‘boot’ partition of the SD Card on your computer after you have written the Raspbian OS image to it.


If you need to use the Pi over WiFi, you can confgure the WiFi credentials by creating a file called wpa_supplicant.conf in the ‘boot’ partition of the SD card. Its contents will then be copied over to the Raspberry Pi when it boots up.

The file needs to look like this:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev


You will need to fill in the country code, SSID and pre-shared key. Ensure that the file has Linux line endings (LF or ‘\n’ instead of CRLF ‘\r\n’).


Create/copy a file called ‘ssh.txt’ (case-sensitive) onto the ‘boot’ partition of the SSD card. The contents of the file doesn’t matter.

Enabling SSH on the Raspberry Pi via the SD Card
Enabling SSH via the SD card boot partition

Other Configuration Options

After setting up the WiFi and enabling SSH, you should be able to boot up and then SSH into the Pi. You can try connecting to the default hostname ‘raspberrypi’ or check your router/network settings to find its IP address.

Once you have connected via SSH, you can run sudo raspi-config to access a terminal-based configuration editor which allows you to change all of the settings of the Pi as per the initial setup etc.

Raspberry Pi terminal configuration utility.
Raspberry Pi Configuration from the terminal (looks pretty oldschool!)

Controlling the LabVIEW Run-time

The LabVIEW Run-time runs as a service on the Pi, to start/stop/restart it you can use the following terminal commands:

sudo systemctl [stop|start|restart] labview.service

This can be useful in case you want to ‘reboot’ LabVIEW without restarting the Pi. Note that this will abort any currently running LabVIEW VIs that are running on the target.

Fixing the LINX Toolkit Beta

Update 10/10/2019: The LINX Toolkit has now been updated to Beta 2 on the NI Software Technology Preview – the fixes below are no longer necessary to install the LabVIEW Run-time to the Raspberry Pi. This update potentially breaks the ability to create Real-Time Applications (rtexe) in LabVIEW 2019 – performing a repair on LabVIEW Real-Time from NI Package Manager fixed this for me.

At the time of writing the LINX Toolkit Beta is just a copy of the 2014 version of the Toolkit. It has not been updated or fixed to work with LabVIEW 2019 and newer Pi Targets.

Fortunately I have been able to resolve most of the issues to get the Wizard working to install the Toolkit and launch the examples. This requires changes to some of the VIs to update it for the new LabVIEW Run-time for the Pi.

Most of the VIs are located in C:\Program Files (x86)\National Instruments\LabVIEW 2019\vi.lib\MakerHub\LINX\

Remove LabVIEW 2014 Prompt

Open LMH-Linx.lvlib:System and change the string in the case structure from “2014” to “2019”. This will remove the dialog that appears when opening the dialog that you’re using the wrong version of LabVIEW.

Remove LabVIEW 2014 check from LINX Toolkit
Remove LabVIEW 2014 prompt from LINX Toolkit in System

Update for 2019 LabVIEW Run-time

Open LMH-LINX.lvlib:Install LV and change the package name to ‘lvrt19-schroot’:

Updates to the Install LV Support VI.
Update the ‘Install LV Support’ VI

Open LMH-LINX.lvlib:Add MakerHub and modify as follows:

Updates to the Add MakerHub Feed VI.
Update the ‘Add MakerHub Feed’ VI

Open LMH-LINX.lvlib:Check Target LV Package and change the package name to ‘lvrt19-schroot’:

Modifications to the Check Target LV p
Package Version VI.
Update the ‘Check Target LV Package Version’ VI

Note: It will still show the latest version as the LV2014 version but it doesn’t affect the installation

Add Raspberry Pi 3 (& 4?) Support

The library detects the target type according to the CPU name retrieved from the cat /proc/cpuinfo command. This is different for the Raspberry Pi 3 (and also the Pi 4 and maybe the Pi Zero etc.).

To add support in the Wizard for new targets we need to do the following:

  1. Determine the CPU type on the Raspberry Pi by running cat /proc/cpuinfo in a terminal or via SSH. At the end of the output it will show a line saying something like Hardware: BCM2835. This is the CPU type used by the LINX Toolkit wizard.
  2. Open LMH-LINX.lvlib:Get Device and add a new entry for the Raspberry Pi you are using (e.g. 3/4):
  3. To fix the ‘Launch Example’ button in the Wizard, we also need to modify it to use the Raspberry Pi 2 B example files. Open LMH-LINX.lvlib:Script Example and modify as follows:

If you want to look into the LINX Target Configuration VI, you can open it from the Tools menu and then press ‘Ctrl+.’ to abort the VI. You can then look through its block diagram. Be aware that any changes you make might be overwritten by a new version of the Toolkit. Feel free to leave a comment if you’ve made any other useful changes!


This has been quite a long post, but we’ve now covered everything required to setup a Pi for use with LabVIEW. I’ve also provided fixes for the current Beta version of the LINX Toolkit so you can use the Wizard to install the LabVIEW Run-time and provided some hints & tips for remotely accessing the Raspberry Pi and for setting up the Pi without a mouse/keyboard/screen attached.

In the next post, I’ll go into some details about some of the on-board communications methods on the Raspberry Pi. I will cover network communications and serial ports. Tune in next time!

MAKE-ing with LabVIEW & Raspberry Pi: Part 2 – Installing the LINX Toolkit

In Part 2 of this series on using the Raspberry Pi with LabVIEW, I’ll be looking at installing the latest beta of the LINX Toolkit with LabVIEW 2019. In Part 1 I introduced the series, some of the reasons why you might want to use a Raspberry Pi with LabVIEW and I introduced the Storm Monitor project I’m going to be working towards over the course of the series.


For the majority of this series I will be using a Raspberry Pi 3 Model B+. I’ll also be using LabVIEW 2019 so you’ll need to have that installed. You’ll either need to have purchased LabVIEW, be using an evaluation version or wait for the free LabVIEW Community Edition. I’ll be using the latest beta version of the LINX Toolkit (as of 26/09/2019).

LINX Toolkit for LabVIEW

The LINX Toolkit is a free LabVIEW Addon (made by NI’s MakerHub) that allows you to write LabVIEW code on the Raspberry Pi. It also allows you to use an Arduino as an IO device with LabVIEW. You can’t write LabVIEW code that runs directly on the Arduino (take a look at the TSXperts Arduino Compiler).

With the LINX Toolkit you can add the Raspberry Pi as an additional target in a LabVIEW project. You can then download/deploy that code to the Raspberry Pi.

Until recently, the toolkit was only supported on LabVIEW 2014 but part of the LabVIEW Community Edition announcement was that NI would be updating the toolkit to work with LabVIEW 2019 onwards. A beta of the new version for LabVIEW 2019 is through the NI Software Technology Preview.

Note: Since this is beta software, it may be unstable (it is definitely buggy since it’s just a re-packaged version of the library for LabVIEW 2014) and may cause crashes. I don’t recommend installing it on your main development PC – you have been warned!

How to Install the LINX Toolkit

  1. Apply to the NI Software Technology Preview

    Apply here. It may take some time for your application to be approved but once you have been accepted, you will have access to the NI Software Technology Preview Community which gives you access to pre-release versions of NI Software, including the LINX Toolkit.

  2. Find and Download the Toolkit

    Once you have access, go to the LINX Toolkit Discussion (link) on the Software Technology Preview Community and download it from the ‘LabVIEW 2019 LINX Toolkit Beta Download’ thread.

  3. Install it!

    The download is a .iso disk image file which you can mount in a virtual CD-drive by right clicking on the file and selecting ‘Mount’ or by double-clicking on it. You can then install the toolkit by opening the ‘LVLINX2019’ drive and double clicking ‘Install’. This will install the toolkit using the NI Package Manager. Follow the instructions in NI Package Manager to install the toolkit – it should only take a few minutes.

  4. That’s it!

    After NI Package Manager does its thing, you’ll then be able to launch LabVIEW and access the LINX Toolkit from the LabVIEW Tools Menu:


In this short post (because I cannot add multiple how-to’s) I have covered how you can setup and install the beta of LINX Toolkit for LabVIEW 2019 using NI Package Manager (NIPM). I will update the post as new updates to the LINX Toolkit are released by National Instruments.

In the next post I’ll be setting up/configuring the Raspberry Pi for use with LabVIEW and offering some hints & tips for using it.

MAKE-ing with LabVIEW & Raspberry Pi: Part 1 – Introduction

This is the first part in a series about using the Raspberry Pi with LabVIEW and the LINX Toolkit. It follows the announcement of the release of the free LabVIEW Community Edition from National Instruments.


I recently posted about the big news from National Instruments that they would be releasing a free LabVIEW Community Edition in 2020 with a beta/preview version available later this year.

Of course, as an NI Alliance partner I use LabVIEW professionally on a daily basis so LabVIEW being free for non-commercial use doesn’t really affect me but the updates to the LINX Toolkit are very interesting – namely that it can now be used in commercial applications. Of course, making LabVIEW free will help to grow its adoption as a language which is definitely a good thing.

To celebrate this announcement, over the coming weeks and months (as I find the time) I am going to be posting a series of articles about using the LINX Toolkit with the Raspberry Pi in LabVIEW.

Over the years I have built up a pretty extensive collection of Raspberry Pis and various bits of useful hardware to that allow a Raspberry Pi to interact with the outside world as you might using LabVIEW and DAQmx/cRIO etc. The goal of these articles is to help you get started with the Raspberry Pi and LabVIEW and to show you some of the things you can do with it.

Raspberry Pi 4 Promo
The Raspberry Pi 4 was launched in June 2019.

An extra bonus to this is the recent launch of the Raspberry Pi 4 – the latest Raspberry Pi board with a more powerful processor (1.5GHz quad core, 1/2/4GB of RAM, USB 3, onboard Wifi/Bluetooth and Gigabit Ethernet. Although not officially supported by the LINX Toolkit yet, I’ll be having a go at getting it up and running with LabVIEW.

MAKE-ing with LabVIEW & Raspberry Pi – Series Topics

I haven’t fully planned out each article but over the course of the series I’d like to cover the following:

  • Getting Started with the LINX Toolkit, Raspberry Pi and LabVIEW
    • Installation & Configuring the Raspberry Pi
    • Building and deploying your first application
    • Raspberry Pi 4
  • On-board communications
    • Networking (TCP/IP over Ethernet/WiFi)
    • Serial / RS-232
  • Data Acquisition / Interacting with the real world
    • Analog I/O
    • Digital I/O
    • Other Sensors
  • User Interface / Display Options
    • Nextion Touch Screen
    • LabVIEW NXG Web Module (which will also be available for free with the Community Edition)
    • Configuring the Raspberry Pi to run a web-page in Kiosk mode
Raspberry Pi hardware and sensors.
Some of the Raspberry Pi hardware we’ll be using over this series of articles

That covers the basics (and there’s a lot there already!) but some other topics I could cover include GSM/GPS. the Pi Zero, using an Arduino as an additional I/O device, Bluetooth communications etc. – please leave a comment if there’s something you’d like me to cover and I’ll try to include it in a future article.

Prerequisite LabVIEW Knowledge?

For this series I’m going to be assuming that you are already fairly familiar with LabVIEW but that are maybe new to the LINX Toolkit and using it with a Raspberry Pi. If you’re new to LabVIEW (maybe you’re checking out the free Community Edition – great, welcome!) then I would suggest starting here or here to learn some of the basics first.

Why use a Raspberry Pi?

The main reason for using a Raspberry Pi is that it is a low-cost and small form-factor computer with plenty of GPIO pins increasing its hardware capability. As an open-source platform, there are 100s of sensors, hats (addon boards), cases and display options available.

Some commercial applications that might be suited to a Raspberry Pi could be:

  • Low-cost low-channel count data acquisition system (e.g. monitoring a handful of analog inputs where timing/accuracy aren’t critical)
  • Headless monitoring system (to monitor a system and report data to the cloud)
  • Low-cost HMI / display module (instead of using a PC alongside a CompactRIO, for example)

Of course, while a Raspberry Pi can be a neat low-cost solution for a headless data acquisition system, it definitely doesn’t replace NI’s other platforms like the sbRIO/CompactRIO or PXI. These systems still have their place as they offer things like:

  • Deterministic control applications with LabVIEW Real-Time and high-speed control/processing with LabVIEW FPGA
  • CompactRIO C-Series modules and PXI cards offer a much wider range of input/output options and much higher measurement specifications (e.g. ranges, resolution, accuracy, channel counts etc.)
  • CompactRIO is a robust/rugged platform that can operate in industrial environments

For this series of articles, I’m going to be exploring the Raspberry Pi’s capabilities through my own hobby project – a storm/weather monitoring station.

Application: Raspberry Pi Storm Station

Most of the time when I’m learning new technologies, I like to have an application in mind as it gives me something to work towards. For this Series, I’m going to be looking at building a Storm Watcher / Weather Station. This is very much a hobby project but it will demonstrate a number of capabilities

Here’s a rough idea of what I want it to be able to do:

  • Temperature, Pressure & Humidity Measurements
  • Lightning Detection (using one of these)
  • On-board display of measurements
  • The ability to push measurement data to the cloud
  • Retrieve current/forecast weather information
An exploded view of a Raspberry Pi with a touchscreen display case.
Raspberry Pi case with a 3.5″ Touchscreen

Why? My mum is a keen weather watcher and often uses websites like this one to see where there are storms etc. – I thought it would be a nice little project so she can start detecting her own storms. The Raspberry Pi is ideal for this as it’s a low-cost piece of hardware with built-in WiFi and there are lots of options for small displays etc.

Up Next: Part 2

Stay tuned for Part 2 where we’ll get started with installing and configuring the necessary software on our PCs. For this we’ll be using LabVIEW 2019 and the latest beta version of the LINX Toolkit.

Free LabVIEW™ for everyone – LabVIEW Community Edition coming soon!

One of the most newsworthy aspects of GDevCon#2 was a very special announcement from National Instruments that they would be releasing the LabVIEW Community Edition – a free version of LabVIEW™ Professional for non-commercial use.

Yes, that’s right…

You will be able to download and use LabVIEW™ for FREE!

Read more

Midlands LabVIEW User Group: Malleables, Pragmatic Test Rigs and Code Reviews

On Monday, I was at the latest meeting of the Midlands LabVIEW User Group at the MTC in Coventry (across the road from the AMRC for the IIoT event a few months ago).

Lovely day to learn LabVIEW!

I was presenting on Malleable VIs but also up on the projector alongside me was Ian Billingsley from CCS presenting on their pragmatic approach to test rig design using LabVIEW/TestStand and Peter Horn from NI with ‘Code Reviews for Teams that don’t have time for Code Reviews’.

Ian Billingsley – CCS

First up was Ian – his presentation was very interesting as it is always good to see how others are customising TestStand. It looks like they have found a robust and adaptable architecture that allows continuous monitoring of the test rig along with controlling it from TestStand. There were also some interesting discussions about when/why you should use TestStand and the benefits of building a simulation interface into your software. If you didn’t make it to the MLUG meeting, he will be giving a revised version of the presentation at GDevCon in September.

Peter Horn – National Instruments

Second up was Peter talking about how Code Reviews are a Good Idea™ and that if you don’t currently do code reviews, you probably should. You don’t have to implement some huge process where you sit down for 3 hours and get grilled on every wire bend. I believe in the benefits of having someone else look at your code – both to improve software quality and as a learning exercise for the reviewee/reviewer. The key message of the presentation was that you have to find a process that works for you/your team (whether that’s formal/informal/tool-driven code reviews) and to nurture the appropriate culture for them within the team (it’s not to pick faults).


Finally, I gave my presentation on Malleable VIs – an introduction to Malleables and some practical examples of how I have used them in my code. I demonstrated some examples from my previous blog posts but also some fresh examples with the Type Specialisation Structure introduced in LabVIEW 2018. Whilst preparing the presentation, I discovered an obvious workaround to the property node limitation of Malleable VIs – just wrap the property node calls into a SubVI!

Here’s a sneak peak from the presentation of a Malleable VI that can set the enable/disable state of a scalar/array of controls – using a scalar/array of ‘Enabled/Disabled/Disabled and Greyed Out’ enums or booleans:

Set Enabled State.vim – Various supported use cases of the Malleable VI for enabling/disabling controls.

You find find the full slides from my presentation as a PDF here: Malleables in the Wild – MLUG 2018

In Summary

LabVIEW User Group meetings are a great way to network with and learn from fellow LabVIEW developers. Thanks to Argenta for organising another successful MLUG.

Just don’t ask us to take the CLAD exam any time soon! (We had some CLAD practice questions to work through as the coding challenge this time around – I’m blaming our poor performance on the lighting / projector!)

Custom Property Loader Plugins in TestStand

Update 30/10/2018

This was going to be part of a series but unfortunately, as mentioned below, there was a lack of available documentation and I ended up implementing a workaround – it was a much simpler solution that could be easily tested. I created an action step which pulled the limits/parameters from the database and wrote them to a temporary CSV file which is then loaded by a Property Loader step. I’d probably only suggest implementing custom plugins at this stage if you were releasing/selling an addon/customisation for TestStand where it would make the time investment worthwhile. Of course, hopefully in TS2017 the documentation will be available to make the process much easier.


In this series of blog posts, I’m going to be talking about how to create a Custom Property Loader Plugin for TestStand using LabVIEW.

I have a custom database schema that doesn’t follow the NI database format that the built-in property loader plugin supports. We have separate tables for limits/test configuration parameters and options for product/test specific limits/parameters. In the last few years, NI has changed aspects of the TestStand Engine to allow more customisation of the various aspects by the use of plugins (e.g. process model plugins, report generation, property loader plugins). The advantage of using a custom property loader plugin is that it allows us to use our custom limits/parameters database but also use the other built-in options as an alternative (e.g. for off-site use at a contract manufacturer without access to the database).

Unfortunately, I couldn’t find much documentation on the subject (NI says that the documentation is coming for TestStand 2017) so figured I’d suffer through the hard work and post it so you know what to expect if you intend on creating custom property loader plugins for TestStand.

For the first part of the series, I’ll start by giving an overview of what a property loader is (and what it does), why you should use it, how to create a custom plugin from the template and give an overview/reference of the VIs / ActiveX objects that make up a custom property loader plugin. In subsequent parts, I’ll be building up my plugin by modifying the VIs to talk to my custom database schema (and the challenges that may come along with it).

Our custom property loader plugin will be talking to a database – but the process should be similar for files – just replace any instance where I’m referencing a database with your custom file IO.

For reference, I’m running TestStand 2016 SP1 and LabVIEW 2017.

Loading Properties in TestStand

Before going into the details of creating a custom property loader plugin (CPLP?! CPP?!) I wanted to just give a quick overview of the various components/mechanisms of loading properties in TestStand.

The main use case for a property loader is to load your test limits and/or test parameters from a file or database at run-time. This gives you the following benefits:

  • You can modify/update limits without modifying the sequence files (of course, you need an appropriate change management system)
  • All of the limits/parameters are in a single location (e.g. a file/database table rather than having to check individual sequences/steps) – this makes checking/validating/updating the limits/parameters easier
  • You can load different sets of limits depending on certain conditions – by specifying the file by expression, you can use different sets of limits/parameters depending on the UUT being tested (e.g. similar products in the same family but with different characteristics)
  • Using a centralised database or network-shared file for the properties means that all test stations use the same limits for testing

Natively, TestStand supports comma-separated (.csv), Excel and tab-delimited text (.txt) files and loading properties from an NI TestStand database schema. There’s plenty of information online and in the TestStand training materials about using the built-in plugins (e.g. here, here and here).

The property loader can import any property to just about any TestStand component (that has properties) – the most useful ones are step properties (e.g. to set limits) and sequence variables (e.g. sequence/sub-sequence Locals, StationGlobals etc.). You can also use aliases so that your parameters/limits have sensible names and then these are automatically mapped to the appropriate steps/properties in your sequence.

There are two ways to use property loaders – a property loader step in a test sequence and using the import/export properties dialog in the TestStand tools menu.

It is important to mention this because our custom property loader plugin will not only load and apply properties from the database, but it should also work with the import/export properties dialog as well.

Property Loader Step

The Property Loader Step in TestStand allows you to load properties at sequence/execution run-time by dropping a Property Loader step into your sequence and configuring it on the Step Settings and Source Settings panes of the Step Settings.

Import/Export Properties Dialog

You can also use the import/export properties dialog to manually import/export properties to/from a property loader source. This is useful for generating the initial source data in the correct format (e.g. set the properties in the TestStand environment, export and then load the data in the property loader step) and for verifying the source data. You also use the Export function of the dialog to generate an aliases file (.pla).

As with the Property Loader Step type, you can select the Source for the properties and configure whether to load all of the properties, or just select properties (using the Property Selector pane).

Creating A Custom Property Loader Plugin

The only documentation I could find on creating custom property loader plugins was this small snippet of information which says to copy one of the existing template plugins as the starting point and go from there. So I guess we’ll just dive in then…

Duplicating the Template Plugin

Shipping with TestStand 2016 SP1 is a selection of sample plugins for various programming languages/environments (CVI, .NET, VisualStudio and LabVIEW). You can find these in <TestStand Install Directory>\Components\PropertyLoader\Templates (i.e. C:\Program Files (x86)\National Instruments\TestStand 2016\Components\PropertyLoader\Templates).

The documentation says to copy the template plugin to <TestStand Public>\Components\PropertyLoader\<YourPluginName> directory – initially I couldn’t get the plugin to load following these steps and after a support request with NI it seems that you have to copy and rename the template .llb file to <TestStand Public>\Components\PropertyLoader\ (i.e. C:\Users\Public\Documents\National Instruments\TestStand 2016 (32-bit)\Components\PropertyLoader\MyPlugin.llb) rather than having it reside in a sub-folder. The PropertyLoader folder in <TestStand Public>\Components probably won’t exist if this is your first attempt at a custom plugin – so you’ll need to create it.

You’ll end up with something like this:

The next step is to configure our new plugin by modifying the inside our fresh plugin .llb file:

Modifying the plugin information for the custom property loader plugin

The VIs themselves are reasonably well documented (most of them are empty stubs though) – here we need to set up the basic information (some fields only apply when loading files e.g. ‘extension’) for TestStand to identify it. You need to change the ID (by default it’s a GUID but I think you can use anything as long as it’s going to be unique to your plugin).

The ‘Type’ field has the following options which are fairly self-explanatory:

  • SourceType_Database: When you choose this, the Step Settings for the property loader step allows you to specify/configure a database connection
  • SourceType_File: As above, but it prompts you for a file path to the file containing your properties
  • SourceType_Custom: I tried to set the enum to SourceType_Custom to see what happened but it just produced an error in TestStand (see below) so I’m not sure if there’s something else that needs to be configured/set first to get this one to work. I guess you’d use this for anything that isn’t a file or a database? Ideas on a postcard please!

That’s OK – I didn’t want to create a SourceType_Custom plugin anyway…

After populating the fields and launching TestStand, you can then drop a Property Loader step into your sequence and you should see your newly created plugin in the Source Type drop-down:

‘Hacking TestStand by Code Injection’ – Available at all good bookstores soon!

Of course, at this point it doesn’t do anything but we’ve at least managed to get it to load and register the plugin. Time for a beer (or other beverage of your choosing)! Next we’ll take a deeper look at what’s inside the template plugin.

Exploring the Template Plugin

Opening up the .llb of the plugin we’ve just created, we find the following VIs:

Contents of a LabVIEW Property Loader Plugin

I’ve already discussed the which sets the metadata/information about the plugin that TestStand uses to populate the plugin in the source type drop down box.

Let’s take a look at the VIs in the template plugin and their functionality…

Custom Property Loader Plugin VIs

Name Description If ‘SupportsBrowseSource’ is set in OverrideOptions (see below), this VI is called when the user clicks the ‘Browse Source’ button – for files this could launch a file dialog or for a database it could be to select a specific set of tables.

Called when you select the ‘Configure’ button on ‘Plugin Options’ (see below). You could use this VI to launch a dialog where the user can set/configure any plugin specific options for import/export. This is similar to creating a LabVIEW dialog for configuring a custom step type. Called when the user hits the ‘Help’ button in ‘Plugin Options’ (see description). Used when a property loader ‘Export’ is called from the import/export dialog – this is the main VI that exports the current property values back to the property loader source (e.g. file/database). If ‘OverrideImportExportSummary’ is set, then you can also return a custom summary text to display the status of the export operation. The reverse of (see below) – if you have the ‘OverrideAlias’ set then this can be used to perform an export of the aliases to a custom aliases format. By default, you configure aliases from the Import/Export Properties dialog and these are then automatically exported (as an XML .pla file) when you perform the export. Called before to read the source and retrieve only the property loader groups information and the properties within that group. This data is used when importing all of the source data (so the plugin knows which properties to load i.e. all of them), determining if a property exists in the source, populating the property selector (for the import/export dialog) and for specifying the properties for the Import operation. Used when a property loader ‘Import’ is called (either through property loader step or the import/export dialog) – this is the main VI that retrieves the properties from the file/database to apply them to the steps/sequence properties. If ‘OverrideImportExportSummary’ is set, then you can also return a custom summary text to display the status of the import operation. If ‘OverrideAlias’ is set in OverrideOptions (see below), this VI allows you to write custom behaviour for loading the alias names. Aliases allow you to match up variable/parameter names in your property loader source with their matching counterpart in the test sequence (e.g. variable/property name) – there’s documentation and an example of using aliases here. Overriding the default functionality allows you to load/configure aliases as part of your custom plugin (e.g. generate them dynamically or from your property source), rather than specifying them in an aliases file (.pla). Used to set override flags/options which control certain options for the plugin (e.g. to allow the user to view the source data and browse for the source). The list of options/overrides are detailed in the ActiveX reference below. Defines the basic metadata about the plugin when it’s loaded into TestStand (e.g. name, description, type, plugin ID). Creates/initialises the available plugin specific options. Generates a summary text of the plugin specific options as shown in ‘Plugin Options’ (see description). Specifies the number of different source types that the plugin supports. I’m not quite sure what this means and the template plugin returns 1 (i.e. the plugin supports one source type). I’m not sure if this means that a single plugin can support multiple types (but it’s not obvious how to specify them) – maybe this is reserved for future use? Called by the Sequence Analyser to allow the creation of a custom VI to check the status of the source during sequence analysis. This could be to check for a correctly configured database connection, check properties are available etc. and return an error if the analysis fails. Used to launch a dialog to ‘browse’ the source data (e.g. view the source file, browse database tables).

Custom Property Loader Plugin ActiveX Components

The VIs all interact using ActiveX methods/properties (as with any other custom LabVIEW components for TestStand), here is a brief overview of the main ones that are used in the VIs.

Name Description Properties Methods
PropertyLoader.PropertyLoaderContext A reference to the instance of the property loader containing generic configuration parameters for the instance and references to the TS Engine and Sequence (i.e. the location of the PropertyLoader). AliasLocation
PluginSpecificOptions (PropertyObject) PropertyObject containing the plugin specific options. (See TS.PropertyObject) (See TS.PropertyObject)
PropertyLoader.SequenceFileLoader Contains the list of properties to import which are then updated with the property objects once loaded. AliasNames
PropertyLoader.ImportOptions Contains the user-configured options for the import operation. ImportAllDataFromSource
PropertyLoader.ImportPropertyItems Container for the list of properties in the property source. Count Clear
PropertyLoader.PropertySourceGroups Container for the list of groups in the property source. Count Clear
PropertyLoader.AliasNames Contains the aliases used for the import/export operation – used when overriding the default plugin alias functionality (using OverrideAlias). Count Clear
PropertyLoader.OverrideOptions Contains the options for overriding/enabling certain functionality for the custom plugin. OverrideAlias
PropertyLoader.PropertyLoaderPluginInfo Contains the basic metadata about the plugin. Description
PropertyLoader.ExportOptions Contains options for exporting properties to the source. StepIdUniqueLookup N/A


That’s enough for Part One. I’ve covered an overview of how Property Loaders work, why you would want to create a custom plugin and how to create your very own custom property plugin and load it into TestStand. I’ve also provided some reference material about the VIs and ActiveX objects that make up a custom plugin. In Part 2, I’ll begin customising the VIs to work with a custom database schema.

MediaMongrels Ltd Custom TestStand Solutions

If you’re looking for a bespoke test system and are considering using TestStand, why not get in touch and see if MediaMongrels Ltd can help. We are an NI Alliance Partner with Certified TestStand Developers and we have experience of architecting test systems from the ground up (including custom process models, Operator UIs, custom database recording) to provide flexible and configurable test frameworks for your component and system tests.

Malleables VIs: Practical Example Part 2 – Malleable Class Adaptation & Practical Application

This is the second of a two part post about the use of Malleable VIs in a practical project – rewriting a test system to use TestStand. In Part One, I introduced the project and the decision to use LabVIEW OO and Hardware Abstraction Layers to allow an easy switch between Simulated and Physical hardware in the test sequence.

In this part, I will discuss the implementation in more detail and how I am using the Class Adaptation feature of Malleable VIs. Class Adaptation allows me to create a malleable VI that can act on unrelated classes (i.e. no inheritance between them). I believe in Computer Science terms, this qualifies as some sort of Mixin.

Read more

Introduction to Malleable VIs in LabVIEW

In my first LabVIEW-related blog post, I wanted to talk about a new feature introduced in LabVIEW 2017 – Malleable VIs. I will give an introduction to Malleable VIs, discuss some of their benefits/limitations and show some examples of how Malleable VIs can improve code reuse. I’ll expand on this post with more examples in subsequent posts.

The Problem

Malleable VIs are designed to implement ‘generics’ in G, a feature which can be found in other languages (e.g. C#), allowing you to create functions where the data type is not defined in the function and is determined either at compile or run-time. The use of generics allows you to improve code reuse since you can write a function once for many data types. If you find yourself writing (or copying+pasting) very similar VIs where only the data type on the connector pane is different, you probably want to have a look at Malleable VIs.

Before Malleable VIs, this was done in one of two ways:

Method 1 – Polymorphic VIs

The first method of supporting multiple data types is to use a Polymorphic VI, but I consider it to be cheating – essentially creating a separate VI for each data type you need to support. This leads to large numbers of VIs that have to be maintained, most of which are essentially the same but with different data types on the terminals to avoid coercion.

As an example, here is the OpenG Sort Array function. This is a polymorphic VI that sorts a 1D or 2D array of most LabVIEW datatypes (e.g. numeric types, strings, paths). This leads to 33 different VIs – the polymorphic VI itself and the ~32 VIs that support the different data types.

OpenG Sort Array Function

Of course, if you wanted to sort an array of a datatype not supported by the OpenG Sort Array function, such as clusters, enums etc. then you would need to create an additional Sort Array VI for your data type to do so.

Method 2 – Variant Polymorphism

If you look at the functions of the OpenG/MGI toolkits, there are many VIs which take in and pass out a variant. Since a variant is a generic data type (it can hold any type of data at run-time), LabVIEW will automatically coerce any data type to a variant at the connector pane terminal boundary. This allows you to wire anything into a variant terminal, perform some operation on the data and then return the variant out. Inside the VI, however, you must handle the different data types (e.g. by type-casting) and it also requires the user of your VI to type-cast the variant back to the initial data type.

Below is an example of how this method is currently employed in the OpenG Read INI Section VI. The VI has a variant in (to define the expected data type/default values) and returns a variant which then has to be converted back to the original type.

OpenG Read INI Section VI – Variant Polymorphism

The Solution – Malleable VIs (.vim)

Introduced in LabVIEW 2017 was the new VI extension ‘.vim’ for Malleable VIs. With VIMs, the data types on the connector pane can adapt to any valid input (i.e. any data type where the VI can still compile / no broken run arrows).

In the following sections, I’ll show a basic and an intermediate example of Malleable VIs which should help to explain the concept.

Basics – Stall Data Flow.vim

I think most LabVIEW developers have at some point found themselves creating a VI like ‘Delay with Error Wires’ or ‘Tick Count with Error Wires’ for adding delays or benchmarking their code. Even if you haven’t, you’ve probably found yourself putting a sequence structure frame with a Delay primitive inside it and a wire going through. One of the Malleable VIs included in LabVIEW 2017 is Stall Data Flow.vim which replaces the ‘Delay with Error Wires’ with a VIM that can delay data flow on any wire type – making my VI ‘delay with error wires’ VI redundant (good!).

Stall Data Flow.vim – Examples

The content of the VIM is very simple – exactly the same as what’s in my ‘delay with error wires’ VI shown above but if you look at the examples at the bottom, any data type passed in is passed out without coercion dots – so you can use it with any data type. That’s the basic principle of the Malleable VI.

Intermediate – The Type Selector – Increment Array Element(s).vim

The next aspect of VIMs I want to introduce is the Type Selector. The type selector is a new structure specifically for VIMs that isn’t currently available on the palettes (as of LV2017 SP1 – probably coming in LV2018). It allows you to handle cases for specific input data types. The simplest example of which is to allow for a terminal to be a scalar as well as an array – as is the case in Increment Array Element.vim.

Increment Array Element VIM – Type Selector Structure

LabVIEW checks each case of the type selector until it reaches the first one that is valid (i.e. compiles), and it uses that as the implementation for the case. If a scalar is passed in, the VIM increments just the specified index and if an array of indexes is passed in, each element is incremented in a for loop.

To take it slightly further, there is also a ‘match type’ node which breaks the type selector case if the data types do not match, giving you another tool for handling specific cases in your VIM, but I won’t go into those here.

Advanced – Coming Soon!

There are also more advanced uses for VIMs (to do with using Malleable VIs as OOP interfaces, and some examples with sorting of arrays using custom sort functions) but I won’t go into those in detail as this is just an introduction. Stephen Loftus-Mercer from NI (AristosQueue) gave an excellent presentation at the CLA Summit in Madrid in which he showed many examples of Malleable VIs. There are some examples included in LV2017 SP1 and some more that should be shipping with LabVIEW 2018.

  • examples\Malleable VIs\Basics\Malleable VIs Basics.lvproj
  • examples\Malleable VIs\Class Adaptation\Malleable VIs – Class Adaptation.lvproj

If you have access to the CLA Community, he has posted a further example here.

My Example – INI Configuration API

One of the immediate use cases for Malleable VIs that jumped out at me was for creating a re-use library for handling INI configuration files. In many of my projects I use INI configuration files when I need a simple human-readable configuration file format. I use the OpenG configuration file functions, but I wrap them into a ‘Load Configuration’ and ‘Save Configuration’ VI with a type definition that contains the contents of the file. Here is what it usually looks like:

Load INI Configuration – Type Definition

This VI loads the INI file and if it (or some keys) can’t be found, uses the default values specified. It then writes the settings back to the file (which is useful to create the file on initialisation of the software). I create a ‘project-specific’ version of this VI (i.e. with a different cluster type definition) since I want to keep my top level block diagram (where I load the settings) simple.

Now, with Malleable VIs I have created the following:

Load Settings – Reusable VIM

I now have a reusable API for loading/saving INI configuration files (with the initialisation code), I can easily see the path/default values on the calling VI but I don’t have to convert the variant back to my settings type on the calling VI (and no coercion dots!).


Malleable VIs currently have one major limitation – they must be set to ‘inline’ in the execution properties. While this might not seem like a big deal at first (e.g. you have to disable debugging, no automatic error handling and must be shared/preallocated reentrant), this is actually more of a limitation than you might think – some LabVIEW nodes cannot be used in inlined VIs. According to the LabVIEW documentation, inline VIs cannot contain ‘certain’ block diagram nodes – the help mentions Property Nodes and Invoke Nodes (but there are others – I couldn’t find a list!). There is a flat restriction that inlined VIs cannot contain property nodes or invoke nodes (this includes class property nodes, even though the accessor VIs can be inlined). This unfortunately rules out many potential use cases for them – for example for UI manipulation.

Below is an example of something I thought would be a great candidate for a Malleable VI – something which sets VI properties on a bunch of control references. This Malleable VI would allow me to wire in either a scalar or array of control/indicator references and set some property (e.g. visible, disabled etc.) on all of them at once.

Set Disabled Malleable VI – Not possible due to inlining restriction

There is a LabVIEW Ideas exchange post about the issue, but with the inlining restriction of Malleable VIs I think it is more relevant now than ever so please go ahead and +1 it.


I think Malleable VIs are a really neat feature included in LabVIEW 2017 and I hope that this post goes some way in helping you to understand them and unlock their potential in your LabVIEW programming. It was a bit of a shame to discover I can’t use them to replace some of my UI utility functions, but I see that there are still plenty of other uses for them.

I’m very interested to hear/see how others are using Malleable VIs in their code – so if you have any examples/ideas then it would be great to hear them – please leave a comment below!