LabVIEW WebSockets API – now Open-Source!

MediaMongrels Ltd are pleased to announce that we have taken the decision to make the LabVIEW WebSockets API Open-Source and the source is now available on GitHub.

Background

I was at NI Days Europe last week – mostly there to talk about LabVIEW WebVIs, show off my DemocracyBot and help out with the LabVIEW Community Booth (Short version: Great success!). I’ll post more about my time there in another post but the last session I went to on the Thursday was from Joerg Hampel (Hampel Software Engineering) and James McNally (Wiresmith Technology) on Open-Source projects.

Suit-wearing PC (Inner-Source) vs Hipster Mac (Open-Source)

Their session was to encourage LabVIEW developers to make their projects Open-Source and they showed a practical example of using GitHub to make a contribution to an Open-Source project – in this case the excellent G-CLI toolkit.

Suit-wearing PC (Joerg) vs ‘Hipster’ James M(a)c.
Photo Credit: Dani Jobe (@DaniJoeb)

You can access their presentation by clicking the button below:

I was so inspired by their excellent talk and NI’s decision to create the free LabVIEW Community Edition that I have decided to put the LabVIEW WebSockets API on GitHub and make it Open-Source (still under the MIT license).

WebSockets API on GitHub

You can access the public GitHub repository for the WebSockets library by hitting the button below:

I’ll also be using GitHub in future for support and issue tracking with the library – you’ll be able to see whether issues have already been reported and see progress on adding new features.

You’ll also get immediate access to new releases by downloading the VI Package from the releases page – I will still be publishing the packages to the NI Tools Network.

You’ll also be able to fork the library and contribute towards fixing issues and implementing new features.

Secure WebSockets (wss://) and LabVIEW NXG Support

If you’ve checked out the GitHub repository, you’ll see there’s already a couple of issues in there regarding support for Secure WebSockets (wss://) and LabVIEW NXG.

NI Days 2019 slide on the WebSockets API

Feel free to sign up for updates/notifications on those issues – with NI’s announcement that SSL/TLS support is coming to the TCP/IP VIs in LabVIEW 2020 I’ll be aiming to update the library to support Secure WebSockets in line with the LabVIEW 2020 release. Once these new functions are available in the LabVIEW 2020 Beta I will begin working on adding them to the WebSockets library.

Open-Source all the things!

In the coming weeks, I’ll be moving over all of my Raspberry Pi / LINX code over to the MediaMongrels Ltd GitHub account as well. You’ll be able to find a list of all projects

I encourage you to have a look at their presentation if you get the chance and also to contribute to Open-Source LabVIEW projects. I feel like GCentral is going to play an important part in finding reusable libraries and Open-Source projects in future.

Of course, if you see our open source code & projects and want to support them – the best way to do that is to hire us to work for you on your projects! Get in touch and see how we can help you with your LabVIEW Software and WebSockets applications.

MAKE-ing with LabVIEW & Raspberry Pi: Part 4 – User Interfaces with LabVIEW NXG WebVIs

In this post in the series, I am going to be how you can use a LabVIEW NXG WebVI as a user interface to a LabVIEW Application running on your Raspberry Pi. I’ll be using the MediaMongrels Ltd WebSockets API to communicate between the WebVI and the LabVIEW application.

But first, a quick note…NI Days Europe 2019

Apologies that there hasn’t been a post in a few weeks – things have been pretty busy for me in my day job (in a good way!) and also personally at home so I haven’t had a lot of time for writing articles.

I have been invited by National Instruments to present at NI Days Europe in Munich in a few weeks during one of their sessions on the LabVIEW Community Edition and the LINX Toolkit. In the background I have been spending quite a lot of time putting together a fun & bespoke demo for them using the Raspberry Pi which has interrupted my ability to work on the blog series.

Here’s a sneak peek of what I’m going to be demoing:

Can you tell what it is yet? 🙂

If you want to see my demo, come along to the ‘Introduction to the LabVIEW Community Edition’ session at 14:15 on Thursday of NI Days Europe (Agenda link).

I will also have some Raspberry Pi / LINX related demos stuff on the LabVIEW Community Booth in the Exhibition Hall:

LabVIEW Community booth @ NI Days Europe 2019

Finally – I have a hunch that National Instruments are going to release the beta for the LabVIEW Community Edition during NI Days Europe – so hopefully only a couple weeks to go until you can get your hands on some Free LabVIEW!

Introduction

In this post, I wanted to share one method for adding a user interface to your Raspberry Pi project.

During the course of this post, we’ll be combining LabVIEW 2019, LabVIEW NXG WebVIs, WebSockets and the LINX Toolkit to create a simple web-based user interface for a Raspberry Pi application.

Since LabVIEW applications running on the Raspberry Pi run in a similar way to a service (or a LabVIEW real-time application), we can’t simply show the front panel of a VI and have it displayed on the Pi. If we want to display data from our RPi application and/or allow someone to control it – we need to take a different approach.

I’ll hopefully talk in more detail about other possible methods in another post but for now we’re going to look at having a web-based user interface to our Raspberry Pi – and we’re going to do it with WebSockets and LabVIEW NXG WebVIs.

What is a LabVIEW NXG WebVI?

WebVIs allow us to write LabVIEW code in LabVIEW NXG that runs in a browser and it can talk to our Raspberry Pi using LabVIEW Web Services or WebSockets. You can see lots of examples and find out more on their demo/examples site here.

The good news is, National Instruments have announced that LabVIEW NXG and the NXG Web Module (used to create WebVIs) will also be available for free with the Community Edition coming in May 2020!

The Example – NXG WebVIs + WebSockets

In this example, we’re going to write a simple Raspberry Pi application that can display the current date & time on a web-based user interface:

Displaying data from a Raspberry Pi in a web-page using NXG WebVIs

While it’s quite a trivial/simple looking example, there’s quite a few steps involved so I’m going to keep the example itself quite straightforward.

To do this we will need to:

  1. Write our Raspberry Pi application in LabVIEW 2019
  2. Create our WebVI in the LabVIEW NXG Web Module
  3. Deploy our application and WebVI to the Raspberry Pi

I have chosen to use my LabVIEW WebSockets API to communicate between the Pi and the WebVI. WebSockets allows for low-latency asynchronous communication between the Raspberry Pi and the WebVI. LabVIEW NXG 3.1 added native WebSockets client support to the NXG Web Module which makes it really easy to communicate between LabVIEW and a WebVI using WebSockets.

You can use the link above to install the WebSockets API used in this demo/example using VI Package Manager.

Demo/Example Code – Available on GitHub

In the spirit of the LabVIEW Community Edition being free and available for everyone to use, I am going to putting all of my Raspberry Pi / LINX demo code onto a public BitBucket repository – you’ll be able to clone or download all of the demo code used in this series.

Access the public GitHub project using the button below:

Git Repo

Repo link for this demo: https://github.com/MediaMongrels-Ltd/Simple-Pi-WebVI-WebSockets

Requires installation of my WebSockets API from the NI Tools Network. Also requires LabVIEW NXG and the NXG Web Module.

Raspberry Pi Application – LabVIEW 2019

Our Raspberry Pi application in LabVIEW 2019 is quite simple – all it needs to do is listen for an incoming WebSockets connection and then periodically send the current date/time to the WebVI.

I’m using a simple state machine for this example – the Main VI loop starts by opening a TCP listener on the port we’re going to use for our WebSocket connection, listens for an incoming connection and if it’s a WebSocket Client connection, start sending the date/time as a string to the client.

The following screenshot shows the code for sending the WebSocket message to the WebVI:

Simple WebSocket Server State Machine

We’ll come back to LabVIEW 2019 again once we’ve created our WebVI as we’ll use the LabVIEW Build Specification to deploy our LabVIEW application and WebVI to the Pi.

Creating our LabVIEW NXG WebVI

The next step is to create our WebVI which will connect to the Raspberry Pi and display the date & time. For this we need to fire up LabVIEW NXG.

I have used a simple state machine again here for the NXG WebVI which will attempt to connect to the LabVIEW VI using WebSockets and then listen for incoming messages and display them.

NXG WebVI for reading & displaying WebSockets messages

The ‘GetHostname’ SubVI on the left-hand side uses the JavaScript Interface Node (JSLI) to call a custom JavaScript function to automatically get the IP address of the Raspberry Pi. You can read more about the JSLI here – it allows you to wrap custom JavaScript (e.g. 3rd party libraries or your own custom JavaScript code) into VIs you can call in a WebVI.

Once you’ve created your WebVI, you then need to ‘build’ it to generate the web (HTML/JavaScript/CSS) files that we can then transfer onto the Pi.

To do this, open the WebApp.gcomp and then click the ‘build application’ button:

Building a WebVI to generate our web files for deployment to the Pi

Once the build is complete, we can then find our WebVI page and its components in the builds folder.

Deploying to the Raspberry Pi

Now that we have our LabVIEW 2019 application and we have built our WebVI, we can now deploy both of these onto the Raspberry Pi.

The reason for deploying the WebVI to the Pi is so that we can access it remotely through a web browser and it would also allow us to access the WebVI from the Pi itself if we have a display attached (in another post, I will show some hints & tips on how we can set the browser to run in kiosk mode and open our web-page automatically on boot).

Deployment Options

There are two options for deploying the WebVI to the Pi along with our LabVIEW application:

  1. Using LabVIEW Web Services
  2. Installing and using the Apache Web Server on the Pi

For this example, I’m going to use LabVIEW Web Services as it is the simplest option – the downside is that the URL for getting to our WebVI is slightly longer (e.g. http://<pi hostname or IP>:<web service port>/<web service name> as opposed to http://<pi hostname or IP> . I’ll add some instructions for using the Apache Web Server in another post.

Creating a LabVIEW Web Service

The first step in deploying our web-page using LabVIEW Web Services is to add a web-service to the LabVIEW project and create a public content folder and point it at the files generated when we built our WebVI in LabVIEW NXG:

Add a Web Service to the Raspberry Pi in the LabVIEW Project
Adding a public content folder to our Web Service.

This will create an auto-populating folder in the web service. The files in this folder will be publicly accessible from the Web Service URL.

NXG WebVI in our Web Service Public Content folder.

Creating our Build Specification for the Pi

Next we need to create a deployment/RTexe of our LabVIEW 2019 application and add our Web Service to it. To do this, right click on ‘Build Specifications’ under the Raspberry Pi target and then select New -> Real-Time Application.

Add your Main VI as the Startup VI under ‘Source Files’ and under Web Services tick the checkbox next to the name of your Web Service so that it gets included in the build and deployed to the Pi. Make a note of the Web service name and HTTP port as you’ll need this to access the web-page hosted by the NI web-server.

Setting the Startup VI in the build specification
Including the Web Service in the build specification

Once you have done that, you can ‘Build’ the real-time application and then right-click on it in the project and select ‘Run as startup’ to deploy it to the Raspberry Pi and set it to run automatically when the Pi boots up. This means we don’t need to launch/run it from the LabVIEW project each time.

Setting the LabVIEW Application to run on boot

After the Pi has rebooted, we should be able to access our WebVI by going to https://<IP Address>:<HTTP port>/<Web Service name> – in the case of my demo project the URL was: http://192.168.1.16:8002/rpi/

We can also open up the page on the Raspberry Pi itself with the built-in browser:

Accessing our WebVI from the Raspberry Pi’s built-in web browser.

Note: Our LabVIEW application is only set up for a single WebSockets connection, so you can only have one page connected to the LabVIEW application at a time.

Summary

This fairly simple example demonstrates one method for adding a user interface to our Raspberry Pi using WebSockets and NXG WebVIs.

In a real application, we’d probably want to take this further to allow multiple simultaneous client connections and also add the ability to send data from the WebVI back to the Raspberry Pi.

I’ll be taking this concept a lot further for my demo at NI Days Europe. I’ll be sure to post something about it when I get back from Munich. If you’re going along – please come and find me and say hello!

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.

Introduction

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.

Prerequisites:

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] http://feeds.labviewmakerhub.com/debian/ 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.

WiFi

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
update_config=1
country=«your_ISO-3166-1_two-letter_country_code»

network={
    ssid="«your_SSID»"
    psk="«your_PSK»"
    key_mgmt=WPA-PSK
}

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’).

SSH

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 Check.vi 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 Check.vi

Update for 2019 LabVIEW Run-time

Open LMH-LINX.lvlib:Install LV Support.vi 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 Feed.vi 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 Version.vi 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 Type.vi 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 Project.vi 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!

Conclusion

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.

Prerequisites:

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:

Conclusion

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.

Introduction

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

Version 2.0 of the LabVIEW™ WebSockets API now available!

WebSockets API V2.0 now available!

MediaMongrels Ltd are pleased to announce the release of Version 2.0 of the LabVIEW™ WebSockets API on the LabVIEW Tools Network. This new version of the WebSockets API is the first major rewrite since its initial release and includes new features and some bug fixes.

Overview

  • Now with more objects! The library has moved to a simpler, object-oriented API to better distinguish between client/server connections. The underlying TCP/IP functionality has been replaced with a ‘Socket’ abstraction that includes socket client/server and socket listener classes with implementations for the NI VISA TCP/IP functions.
  • Read / Write VIs: The read/write VIs now handle text and binary data frames, ping/pong frames and fragmented messages.
  • Documentation: The library is now certified under the LabVIEW Tools Network program and includes detailed help documentation available from the LabVIEW help menu (Help -> MediaMongrels Ltd -> WebSockets API) as well as including a WebSockets Client Example for connection to 3rd party WebSockets Servers.
  • Paving the way for Secure WebSockets and LabVIEW NXG Support: The V2.X library rewrite paves the way for LabVIEW NXG support. The new Socket abstraction allows the NI VISA TCP/IP functions to be replaced

Full release on the LabVIEW™ Tools Network

The new version of the library has now been certified for the LabVIEW™ Tools Network – you can download the latest version from VI Package Manager here: Install LabVIEW WebSockets API (VIPM)

Screenshots

The screenshots below show the new API for a client and a server connection respectively.

Client API

Server API

Legacy API

Due to the rewrite, the new API breaks backwards compatibility with the previous version of the library. To minimise disruption when upgrading, Legacy API functions are included in the library. With the Legacy API, the VI calls remain the same as previous versions but the TCP/IP refnum wire has been replaced with a WebSockets API connection reference. Compare the Pre-V2.X to the V2.X Legacy API below.

WebSockets API Upgrade to V2.X with Legacy API functions

Release Notes

Major rewrite of the WebSockets library:
– New: Moved library to an OO approach for WebSockets connections (Client/Server Classes)
– New: Abstracted underlying socket functionality (e.g. NI VISA TCP) for future secure WebSockets support
– New: Added TCP socket listener for listening for server socket connections
– New: Simplified API
– New: Added high-level Read function which internally handles fragmented and Ping frames
– New: Added WebSockets Client Example VI and modified examples to use new classes
– New: Added unit testing to source repository
– New: Added detailed documentation (.chm file) to LabVIEW Help menu and added examples to NI Example Finder
– New: Added palette support for LV2020
– Fix: Fixed incorrectly applied timeout values (timeout = approx. maximum time until VI returns)
– Fix: WebSocket-Client-Key is now correctly generated as a random string rather than being a constant

Note: A backwards compatibility layer is retained for legacy applications allowing upgrade with minimal application changes. It is strongly recommended to update applications to use the new library VIs.

Sam Sharp – LabVIEW Champion 2019

It is a great pleasure to be recognised for your contributions to a community and as a LabVIEW Developer, there is no greater recognition than the LabVIEW Champions programme.

The LabVIEW Champions are an elite group of “individuals who demonstrate technical excellence and a willingness to give back to the community”. There are ~120 active LabVIEW Champions worldwide.

It is therefore a great honour that Sam Sharp, the founder of MediaMongrels Ltd, was admitted as a LabVIEW Champion in March 2019.

This great award comes from years of delivering successful LabVIEW projects and contributions to the community such as:

  • Presentations at User Group Meetings, the CLA Summit and GDevCon
  • Contributions to the NI Forums
  • Founding member of GDevCon (tickets for #2 in August are on sale now!)

Thank-you to NI and the community for this great achievement and a huge congratulations to everyone else that became a LabVIEW Champion in 2019. What a great community!

 

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).

Me!

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.

Introduction

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 PluginInformation.vi 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 PluginInformation.vi 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
BrowsePropertyLoaderSource.vi 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.
ConfigurePluginSpecificOptions.vi

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.

DisplayPluginSpecificOptionsHelp.vi Called when the user hits the ‘Help’ button in ‘Plugin Options’ (see ConfigurePluginSpecificOptions.vi description).
Export.vi 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.
ExportAlias.vi The reverse of ImportAlias.vi (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.
GetImportPropertyItems.vi Called before Import.vi 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.
Import.vi 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.
ImportAlias.vi 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).
OverrideOptions.vi 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.
PluginInformation.vi Defines the basic metadata about the plugin when it’s loaded into TestStand (e.g. name, description, type, plugin ID).
PluginSpecificOptions.vi Creates/initialises the available plugin specific options.
PluginSpecificOptionsSummary.vi Generates a summary text of the plugin specific options as shown in ‘Plugin Options’ (see ConfigurePluginSpecificOptions.vi description).
PropertyLoaderSourceFormatCount.vi 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?
ValidateImport.vi 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.
ViewPropertyLoaderSource.vi 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
Engine
IsUsingTool
Operation
SequenceContext
SourceLocation
TargetSequenceFile
N/A
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
PropertyLoaderGroups
SequenceFile
UserObject
GetLoaderObjects
PropertyLoader.ImportOptions Contains the user-configured options for the import operation. ImportAllDataFromSource
ImportToRelatedExecutions
PropertyNotPresentInDestinationAction
PropertyNotPresentInSourceAction
StepUniqueIdLookup
TargetSequence
N/A
PropertyLoader.ImportPropertyItems Container for the list of properties in the property source. Count Clear
Create
GetEnumerator
Insert
Item
Remove
PropertyLoader.PropertySourceGroups Container for the list of groups in the property source. Count Clear
Create
GetEnumerator
Insert
Item
Remove
PropertyLoader.AliasNames Contains the aliases used for the import/export operation – used when overriding the default plugin alias functionality (using OverrideAlias). Count Clear
ExistsAlias
ExistsLookup
GetEnumerator
GetExpandedPropertyLookup
GetItemByAlias
GetItemByLookup
Insert
Item
Remove
PropertyLoader.OverrideOptions Contains the options for overriding/enabling certain functionality for the custom plugin. OverrideAlias
OverrideImportExportSummary
OverridePropertyNotPresentInDestination
OverridePropertyNotPresentInSource
PropertyNotPresentInDestinationAction
PropertyNotPresentInSourceAction
RequiresPropertySelector
SourceLocation
StepUniqueId
SupportedProperties
SupportsAliases
SupportsBrowseSource
SupportsExport
SupportsGroups
SupportsImportAllData
SupportsViewSource
TargetSequenceName
N/A
PropertyLoader.PropertyLoaderPluginInfo Contains the basic metadata about the plugin. Description
Extension
FormatDescription
IconName
ID
Type
N/A
PropertyLoader.ExportOptions Contains options for exporting properties to the source. StepIdUniqueLookup N/A

Summary

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.