Designing a LabVIEW Human Machine Interface (HMI) for Increased Safety and Readability

National Instrument’s LabVIEW software is a powerful tool used in industry and academia for data measurement, collection, and machine control. Depending on the packages installed, LabVIEW can act as a simple data logger and provide simple control for devices, collect data rapidly (such as measuring the shockwave pulse from an explosion), or control entire industrial systems, providing the user with updates on the system status as required. 

The software easily integrates with many third-party hardware components, other software platforms, and uses various IEEE standards. While this is convenient, one of the best features of LabVIEW is its graphical language and its ability to create intuitive graphical user interfaces (GUIs) and human-machine interfaces (HMIs).

However, with great power comes great responsibility. Just because LabVIEW lets the programmer create a GUI a certain way doesn’t mean the programmer should create it. To make an effective HMI/GUI, the programmer must consider the end-user. 

Often, the end-user is initially the programmer; but as the system grows, or the programmer moves on to other projects, the LabVIEW Virtual Instrument (VI, or the LabVIEW program) will be handed off to someone else, most likely a control operator. Therefore, the GUI and the code should be well-documented and intuitive.

 

LabVIEW Virtual Instruments (VIs)

LabVIEW programs are called Virtual Instruments, or VIs, because their purpose has been to replace a physical piece of hardware. A technician no longer needs to bring a separate function generator, oscilloscope, multimeter, or others; instead; they can use a laptop and LabVIEW VIs to simulate each of these devices.

The front panel of LabVIEW VIs simulates this type of device. In general, the STOP button or power button should be located in the lower left-hand corner, as that is where most desktop instruments have their “power” button. A big, red, easy-to-see “emergency stop” button should be included, which will shut down all equipment.

Controls and indicators should be grouped by device. If the LabVIEW controls multiple instruments, each device should have its own set of controls. The use of “decorations” on the front panel can help visually group these items.

 

Figure 1. LabVIEW front panel monitoring four reactors.

 

Figure 1 shows a front panel monitoring four reactors. There is a big “emergency stop” button, a power button, and a waveform chart for displaying the temperatures. While the temperatures are displayed in ℃, the tank heights are in percent. Percents, arbitrary values, and a combination of color-coding and text can be used to protect proprietary quantities. 

For chemical and fluid flow, the GUI can be designed to show some of the key interconnects, piping, and valves so that the control operator can monitor (at least qualitatively) how a process is performing. 

 

LabVIEW Data and Supervisory Control (DSC) Module 

At a glance, they can see the position of all of the valves, whether fluid is flowing, and so on. If the Data and Supervisory Control (DSC) package has been installed, there are more options for these front panel controls and indicators.

 

Figure 2. A screengrab of the Data and Supervisory Control (DSC) module in LabVIEW. Image used courtesy of National Instruments

 

Figure 2 shows the DSC module allows for more controls and indicators, some of which will be similar to chemical engineering piping and instrumentation diagram symbols or pipes and physical devices that the operator will recognize. 

 

Potential Blockers in LabVIEW

Designing LabVIEW Button Text

In LabVIEW, a potentially misleading option allows the programmer to cause buttons to display different text for different button status. 

One of the most misleading problems with buttons is understanding the text that programmers place on buttons. For example, if a button is pushed, it shows one text, and if it is unpushed, it shows a different text. Programmers may label the buttons with text, hoping that it will clear up the button’s function. Typically, the programmer changes the text on the button to reflect its current status, and therein lies the confusion.

 

Figure 3. These are two identical buttons; when the button is pressed, it reads “LEFT,” but when released, it reads “RIGHT.” 

 

Suppose there was a button that activated a solenoid that positions equipment to the left or the right. The programmer envisions the button to read “LEFT” when the solenoid is in the left position, and “RIGHT” when the solenoid is right. Sounds reasonable? 

Now, picture an operator who wants to move this solenoid to the right. The software has the button labeled “LEFT.” Does the operator push the button currently labeled “LEFT” to move the solenoid to the right? How does a tired or stressed operator handle this button?

A redesign of the GUI can combat this problem. For example, a simple LED indicator on the front panel, labeled “Right?” can help in a pinch. A better redesign would show the process flow and highlight the right branch of the process. At a glance, even the tired or stressed operator could determine the solenoid position and how to change it, if needed, in an emergency.

 

Figure 4. A LabVIEW VI showing two tanks feeding a mixer.

 

In figure 4’s example, one of two tanks feeds a mixer. Instead of pushbuttons, a slider switch indicates which tank is in use. Also, notice the two LEDs labeled “Flow?”. At a glance, an operator knows which tank and pipe system are feeding the mixer.

 

Color-coding LabVIEW Virtual Instruments (VIs)

Color-coding is great and should be included in the code. Color schemes should be chosen to represent the nature of the system. For example, suppose there is a thermocouple being used to measure the temperature of a process. In that case, blue can show the temperature is too cold, green when the temperature is in range, yellow as it approaches the upper limit, and red when it is over temperature.  

When in doubt, green means go, yellow means caution, and red means danger. However, do not rely entirely on color-coding for GUI design. Use other cues to alert the control operator about issues. There are many types of vision impairments, including various color blindness, that will not allow the control operator to distinguish these colors.

 

Figure 5. DC voltage gauge on a VI’s front panel.

 

Instead of displaying just the voltage and changing the color of the text, the gauge in figure 5 gives a visual cue of the acceptable range. The vision-impaired operator can see the needle moving to the right side of the graph when there is a problem. 

To account for colorblindness, programmers can use position and text to indicate problems. Outside of programming, stoplights are positioned such that the red light is always either at the top or to the right of the stoplight cluster, and green is the opposite. Visual status alerts can be arranged in the same familiar manner.  

For pipes, wires, and plumbing, do not rely on color code (not even LabVIEW’s built-in scheme), but instead apply labels liberally to indicate what is flowing through the pipe or wire, as well as a direction. As an example, a programmer should color the hot water coming into a heat exchanger red, and cool water leaving the heat exchanger blue. Still, they should also place a label on each pipe, indicating the material, direction, and flow.

Use LabVIEW VIs to simulate measuring tools within your control system. Sometimes, when using the GUI/HMI, you may run into an issue such as button text and color-coding. These points should help mitigate those issues and help you design a more efficient system.