Recommendations for LabVIEW RT development using DQMH

Tips for developing DQMH on RT systems

Recently I’ve been asked if I have any tips that LabVIEW developers should be aware of when developing a LabVIEW application for an RT platform (ie. cRIO, sBRIO, IC, etc), and using DQMH.

This article shares some of our recent experiences in developing RT applications, here at Wired-in Software. Many of the recommendations are simply good RT practices, and should be considered regardless of whether you’re using DQMH or not.

Debug, debug, debug

For me, the single most important thing with developing for RT, is to add plenty of debug hooks into your application. Debug driven development is a good philosophy when developing LabVIEW RT applications. This is because when you develop in RT, you may have challenges such as no UI, or no ability to use the standard LabVIEW debug tools in a Cloneable module. You have less visibility in the application during runtime.

At Wired-in, we make extensive use of the Status Updated broadcast message in all modules, and have these funnel through to an Event Logger module that dumps this to a CSV file, and is also displayed to a Text control (size limited to say 10000 characters to avoid memory issues) for viewing (if using Embedded UI, or via a Remote Panel). With extensive use of Status Updated, we can paint a picture of what the software is doing. We also bundle the Error Reported broadcasts into the CSV file to capture errors.

We have a cute little trick to quickly pack up the controls/indicators into verbose fields. We use the Bundle (not bundle by name) function to pass in whatever fields we need of any data type (except refnums – be sure to convert these to strings first), and then use the “To Variant” VI, and then use the Flatten to JSON String vi (we use the JKI JSON). This is a simple way to create a string of all those data fields (with their names included) automatically. Very handy for adding quick debug to your application, and to ensure the right values are being passed around and your software is functioning correctly.

Other logging options available on the market include:

• • HSE Logger
  • Neosoft Syslog

There are many more options!

Embedded UI or not?

Some NI RT targets support an embedded UI. Some don’t.

To have an embedded UI, the target must run NI Linux Real-time on an Intel chipset (ie. Not Phar Lap or VxWorks), and must have a display connector onboard. The following targets that support an embedded UI, include:

• IC-31xx
• cRIO-903x
• cRIO-904x
• sbRIO-9609
• sbRIO-9628
• sbRIO-9629

More details can be found in this NI Knowledgebase article.

If the Embedded UI is available on your RT target, then you can use event structures to catch UI activity by the user – the way we’re used to doing things in LabVIEW for Windows. Take full advantage of the Embedded UI when developing and debugging. It may not be needed for the deployed environment, but it is invaluable during integration.

The Embedded UI can be enabled via NI MAX.

If Embedded UI is not available, then you cannot capture events via Event Structures. Instead, you’ll need to poll any button press changes, and feed into a Case structure to act.

For systems not supporting Embedded UI, I highly recommend considering Remote Panels. However be warned they can be awfully flawed in how you go about setting them up. But once setup, they can give you a user interface – especially when running as an executable. The drawback with Remote Panels, much to the dissatisfaction of IT departments, is that they need Microsoft Silverlight and Internet Explorer to run. You cannot use Remote panels with Google Chrome or Microsoft Edge.

Things to remember:

1.  Follow the process documented in this link to setup a Remote Panel.
2. The Web Publishing Tool is really only designed for Windows, and not RT. It will generate a www file, but you’ll need to edit the file afterwards (see bullet points below). To deploy the www files, we include them in our RT Exe Build Specification. Note that the destination directory (on NI Linux RT systems) for www files is /var/local/natinst/labview/www.
3. If you upgrade from one version of to another, you’ll need to update your www files to work with the new version of LabVIEW. Important keys to ensure are updated are (as shown for LabVIEW 2019):

RT –> Windows Communications

There are many ways to share data between your RT or Windows application. Examples include:

• • HSE Generic Network Modules
  • Simple Messaging, or just plain old TCP/IP or UDP.
  • Shared Variables

You may consider not using a Windows application, instead using something like Systemlink or SystemlinkCloud to transfer your files/tags/messages to. The NI Skyline API provides an interface to Systemlink (which uses HTTP client protocol) to communicate with Systemlink.

Deploying Shared Variables

We don’t use Network-published Shared Variables often, but they are one method to communicate between RT and Windows applications.

Our recommended design is to host the network shared variables on the RT system, not Windows. By doing this, the RT application will not error out if the network drops out.

Things to watch out for when it comes to using Shared Variables:

1. There is this KB article, but I found it did not work for me.
2. It takes a while for Shared Variables to launch with a standalone application. I advise that you have a preliminary process constantly polling one of your network published shared variables on your RT application. It will continue to throw an error until it has launched. Once launched, you should be ok.
3. Disable Auto-deploy, and then manually deploy from your project.

If using Shared Variables, a design consideration is to keep all shared variables used within only one DQMH module. So all external communications feeds in/out of one DQMH module.

The NI Distributed System Manager is your friend. Make sure you have it open when using/debugging Shared Variables.

Limited disk space

File management is important in RT. Usually a cRIO has 4GB onboard. If you’re using DAQmx to log data to disk, this will run out really quick!

At Wired-in, we have a file management function running as part of our Datalogging module. As soon as the file location exceeds a certain disk amount, we start deleting the oldest files until we come back under the threshold. You want to avoid the local disk filling up, because the cRIO can go into in unrecoverable state that can only be recovered at the source (for instance with a USB connection).

We also recommend using an onboard SD card for extended data logging if necessary.

File transfer

We use WebDAV to transfer files off our RT targets.

The cRIO install package includes the WebDAV Server be default.

Log your files to /home/lvuser/natinst/LabVIEW Data (for Linux RT), as per the suggestion here: 

We then have a WebDAV client DQMH module running on a Windows machine, and it periodically checks the data log file location on the cRIO, and brings down files.

A few things to watch out for:

1. Allow a minimum age of the files you want to bring down. You don’t want to drag a file down that is currently still being written to. For instance, if you are creating a new file every 10 mins, you may want to ensure a file is ~15 minutes old before you bring it down.
2. The WebDAV delete function is unreliable. Sometimes it works, and sometimes it doesn’t. We opted not to use this, and have the cRIO manage its file disk space (see above in Limited disk space).
3. The WebDAV should keep track of which files its brought down so that it doesn’t keep bringing the same files down over and over again.
4. We originally tried to create an archive directory on the cRIO to help the WebDAV know which files can be dragged down, but this proved to be unreliable and the cRIO was crashing often.

Helper Loops

RT systems typically need to run 24/7. Helper loops are good for control applications or having a control state machine running.

Keep your project clean

Don’t have any broken VIs in your libraries/dependencies. They can get deployed as part of an exe, and break the exe (but it all runs fine in Dev env). This includes broken states in State Machine charts tool.

Run the DQMH Validation tool – I got caught out when I opened up an old project. It ran fine in Dev mode, but caused issues as an exe. I simply ran the DQMH Validation tool, to bring it up to the newer DQMH version, and this resolved the issue.

API Tester Considerations

When you create a DQMH module, it will create the API Tester by default. You will need to create an RT API Tester manually.

At Wired-in, I put a big text note on the front panel of the original API Tester to remind me to use the RT API tester! I wouldn’t delete the default tester though, else running the DQMH Validation tool will raise an issue.

Deployment challenges

One approach to deployment is to build an exe from every DQMH module’s API RT Tester, and simply run that as a Startup.exe. This will allow you to prove that each module deploys in its own right to the RT target successfully, and is an important step prior to building an entire application. Start with the lower level modules first, and work your way up to the application level.

Once you have an exe running, this would be a good time to download the RAD utility to create an image of your RT target, for safe keeping.

IT considerations

Make sure that the networks are free, so that WebDAV, TCP/IP, UDP, etc are accessible. You may need to involve your IT department to assist with this. We’ve had issues where the IT department needed to allow certain ports in their stringent firewall setup.

FPGA considerations

I recommend keeping FPGA interaction isolated to one DQMH module. This helps with testing, and you can also set the DQMH module to a simulation mode so that you can test the rest of your RT application.

If your application is more geared towards data-logging, it may be worth considering DAQmx (instead of FPGA) to read the samples. DAQmx can go up to 5KHz.

FPGA is perfect for deterministic control applications.

Start with the basic I/O Read/Write Control VIs from the FPGA Interface pallete, and then optimise (ie. Interrupts, FIFOs, etc).

Where possible, build simulation into your FPGA code (ie trigger pulses, encoder counts, analog signals), so that you can test your software when not connected to real hardware.

For more advanced simulation (ie. simulation of PID controlled processes, Wired-in have developed electronics to model the outputs).

About Wired-in Software

Wired-in Software are located in Melbourne (Australia), and an NI Alliance Partner that specialises in LabVIEW-based automated test and measurement applications, including systems that can do machine vision, monitoring and control, and embedded products.  We are focused on helping our customers transition to be Industry 4.0 ready, by building intelligence into our applications.  For more information, feel free to contact us for a no-obligation chat, or continue to peruse our website to learn more.