LabVIEW Industrial Automation Guide

How it can Help – with use cases

To make sure we’re on the same page when we say “LabVIEW industrial automation”, we’re NOT talking about test system automation using LabVIEW.  If you’re interested in that topic, see here.

LabVIEW can be used to help with your industrial automation needs divided into two main use cases: (1) machine control and (2) machine monitoring. It can either be embedded as the core brains for an OEM machine or piece of equipment, or bolted on to augment the core capabilities of the equipment.

Embedded machine/equipment controller – both the NI cRIO & sbRIO have an FPGA and RT processor. For this use case, the embedded system is controlling some aspect of the industrial machine/equipment.

• It might control the tight tolerance timing of a particular manufacturing process,
• it might dynamically adapt production of the part to improve product quality,
• or it might control the operation of a piece of industrial equipment out in the field.

Some examples of machine control applications include:

Machine/equipment monitoring – this could include generalized monitoring of a machine or it could be more focused specifically on condition monitoring (see our guide Is condition monitoring right for you?) which generally has the objective of improving machine up-time/reliability and/or reducing maintenance costs and production loses.  Some examples of machine/equipment monitoring applications include:

NI Hardware – we’re talking cRIO & sbRIO

If you’re interested in LabVIEW-based industrial automation, you’re likely going to need NI hardware in order to take advantage of tightly integrated I/O and deterministic processing.  This will usually take the form of either a CompactRIO or a Single-Board RIO /SOM.

Why would you choose one over the other?  Our recommendation would generally be to default to the cRIO unless a critical requirement drives you into the sbRIO.  There’s more details than provided here (feel free to reach out here if you want to discuss those details), but the decision process will usually be based on three criteria:

1. Size / envelope – if your application requires a small envelope, the cRIO form factor may just be too big and you’ll be forced to go the sbRIO route.
2. Production volumes – at some quantity, it’ll likely make more sense from a financial standpoint to use the sbRIO.
3. I/O availability – depending on how much of what you need from an I/O (including comm. interface) standpoint is available either as a module or part of the base unit, the custom board non-recurring engineering design costs may sway you one way or another.

We love the cRIO and use it a LOT.

LabVIEW Real-time & LabVIEW FPGA

Maybe you’re thinking you’ll be doing industrial automation with just a desktop PC-based LabVIEW application.  If that’s the case, we’re coming from two very different places.  The kind of automation we’re talking about here utilizes one or both of the RT & FPGA capabilities of LabVIEW.

LabVIEW RT & LabVIEW FPGA can perform similar sorts of tasks, with the main differentiator being time-criticality.  This tends to show up in the following ways, and the fuzzy division of timing generally looks as follows:

LabVIEW RT is more apt to help you with tasks such as:

• Supervisory state/mode sequencing
• System configuration
• Web server for thin client
• Slow control algorithms
• Fault condition handling
• Moderate synchronization of signal I/O without HW clocking

While LabVIEW FPGA can help you with:

• Fast control algorithms
• Low latency between input and output
• Tight synchronization of signal I/O with HW clocking
• Tight cycle-to-cycle determinism
• Operator safety and equipment protection from fault conditions (no operating system to get in the way)
• Multi-channel deterministic I/O (dozens of channels)

We’ve used LabVIEW RT for more than 1,000 solutions and LabVIEW FPGA for more than 700 solutions  (including test & embedded applications). Sorry, reading this sounds arrogant, but it’s not intended that way, just a proof point that we do have at least a clue when it comes to RT & FPGA usage.

LabVIEW Industrial Automation Gotchas

A PLC as a companion

While some might argue with this in some cases, we believe that there’s still a good place for a PLC as a companion to LabVIEW-based industrial automation applications.  Namely, handling the very low level safety or mission-critical aspects of operation.  Anything with an ESTOP, or safety-critical out-of-limit condition.  PLCs are so bullet proof.  Safety & reliability is what they do best.  Let them do their job.

A PLC as a Better Fit?

There are some situations where an inexpensive PLC could be used instead of a cRIO for dealing with logic signals or slow analog IO.  Of course, you’ll no longer be using LabVIEW as the core of your automation.  Make sure you have a driving reason to justify using a cRIO or sbRIO over a PLC.

User Interface – Don’t bite off more than you can chew

Everyone has experience with smartphone apps that have very intuitive UIs.  Users tend to think of those experiences when trying to communicate how they want their LabVIEW UI to look. Some of the LabVIEW controls are either lacking in capability or ability to customize relative to other programming languages.

One example is a table that allows different data types for each cell (string, numeric, enum…). There are a couple solutions in LabVIEW for this but they don’t look as nice. Sometimes a fancy UI isn’t worth the cost.

Another example is the tab control. You can set the tab control resize with a pane but you can’t have its contents resize with it. You’re also not able to add new tab pages during run-time.

If you’re not careful, you can end up spending more of your time programming UI features than any other part of the software.

Be careful about the size FPGA you select

When you’re developing with an FPGA, you’re essentially enabling various digital logic gates on the chip.  It’s hard to tell what size FPGA you will need until after you have a design that works.  There is not a good way to estimate the size of the FPGA needed until after the code is written. Maybe sometimes it’s obvious that you can get away with a smaller less expensive FPGA, like when all you’re doing is passing values between the IO and host. Other times you may think what you need to do is simple enough but you wind up needing to do a lot of division or increased clock rates and run out of resources. After the code is written you can try to compile for the intended target and if even after trying to optimize it doesn’t fit you can try the next one up and keep going until it finally fits. You then know what size FPGA you need.

If multiple systems are expected, consider prototyping with a device with a larger FPGA than you think you need.  After the prototype is proven you might be able to go with a cheaper cRIO for the deployed systems.

When it comes to drivers and libraries, don’t reinvent the wheel

Often drivers or libraries are written from scratch when there is something out there that already exists and will work. One example is Modbus drivers. There are a few implementations that have been created by NI and are available for free on their website. A little more time spent on research can save a lot of development and testing time.  Be mindful of buggy or incomplete drivers.

Not making error/event logging a top priority

Logging needs to be a first class feature. With headless controllers running for months at a time, it is very hard to diagnose issues, so having a robust log of both errors and events can help you reconstruct issues to support bug fixes. Don’t expect normal debugging tools to be helpful or even work at all for solving some of these transient issues.  Monitor key metrics (memory, CPU, disk space, etc.) to look for trends that could lead to crashes or undesirable controller states. Logging can play a key role here.

Not thinking through Deployment

Deploying one system can be pretty straightforward, but replicating that for many systems will get time consuming and tedious. You’ll want the ability to deploy/update/maintain many devices at once and monitor their status.

How to get Help

If you’re looking for help with using LabVIEW for your industrial automation application, there are two things you’ll need to do: (1) develop a good set of requirements and (2) find a vendor capable of helping you (you can reach out to us here if you’d like to chat).

Requirements – When it comes to requirements, this is one of the more challenging topics in the world of engineering.  It causes frustration from all parties involved.  Learning to write even decent requirements takes a fair amount of effort.  Sometimes people assume that LabVIEW is a simple tool and it should just work, when in reality it’s a complex development environment with powerful coding capacity that should be treated just like any other development environment, so requirements are very important.

The key aspects for good requirements are that they are (1) testable and (2) succinct.  We’ve considered creating an example set of requirements to serve as a starting point to work from (if you’d be interested in us creating an example set of requirements doc, let us know here), but for now, we’ve created a template for you to start from.  Go here to get it.

Finding a capable vendor –  check out this Outsourcing Industrial Embedded System Development Guide.  It shares 10 considerations before you have an embedded design company develop your industrial embedded monitoring or control system for you, including considerations like: How will the EDC support me once units are fielded? And How do I get a warm fuzzy that the EDC can solve my specific problem?