The prices of alphanumeric and graphic human-machine interface (HMIs) have fallen dramatically in the past few years. Programming these HMIs has also gotten considerably easier, thanks to drag-and-drop integrated development environment (IDEs) that often automatically import PLC and PAC tags. These developments have led to HMI installations on even the simplest of machines.
At its simplest, an HMI offers a simulation of buttons and indicators, maybe error and status messages. At its most complex, an HMI provides a graphical view into a process or machine. The more sophisticated HMIs are beginning to offer two-or-more-finger control. This allows the user to zoom into a graphical image to produce more detail, like zooming in on a Web page or photograph on your smart phone. If a process of a machine is showing a fault or alarm, using the zoom function allows the user to identify the exact part creating the alarm. If a motor is overheating, zooming into the motor from a larger overview graphic can give the operator or maintenance person real-time information about the cause of the trouble. Taping the motor may provide present temperature, current draw, histograms of operating conditions, the part number of the motor or even a link to a video for replacement instructions. The limits are the imagination of the design engineer and the development budget.
HMIs were once typically connected to some control device in a one-to-one configuration. Modern HMIs can connect to multiple devices and systems, such as multiple PLCs, the plant’s manufacturing execution system (MES), field service management (FSM) system and Web pages generated by data from Industrial Internet of Things (IIoT) smart devices. All of this information can be leveraged to create powerful diagnostic aids.
IIoT devices often have many built-in diagnostic functions. Most offer a Web-page interface to view these features. If the desire is to display the information within the context of existing HMI pages, some programming may be required to cull the specific items of interest and place them on the HMI where desired. Examples of the code required may be included in the device’s instruction manual or in white papers available for download.
Even on less powerful HMIs, the controller’s digital and analog inputs and outputs, with detailed comments, can have their states reflected on screen. Some HMI and controller combinations can display the controller logic on screen. This allows a maintenance person to quickly troubleshoot logic and I/O issues without having to log into the controller with a computer. Displaying the actual logic within the controller is usually limited to having the controller and the HMI built by the same manufacturer. If the machine or process operations can be broken into distinct steps or states, a process-flowchart HMI screen can be developed that indicates the current status and can aid in diagnosing problems.
A great deal of information and many theories are available on alarm management. Generally, alarms are broken into at least three categories.
- Immediate-stop alarms are conditions that indicate an unsafe condition or a condition that requires the machine or process to be immediately stopped—emergency stops (e-stops), open gates, loss of power to some sections, circuit breaker trips or any condition that puts the machine into a state that is unsafe or cannot allow the machine to complete its current cycle or process.
- A cycle-stop alarm will allow the machine to complete the current cycle but not allow another one to begin until the cause of the alarm is addressed—low raw material, some conveyor jambs, motors starting to overheat or specific operations, such as a pneumatic cylinder extending, taking slightly longer than expected.
- Warnings occur when a condition that should be addressed exists, but the operations can proceed without damage—hoppers getting full, excessive blocked or starved times or low oil pressures caused by a plugged filter.
Often, one alarm condition can generate several individual alarm conditions. It is important to capture the initial condition and indicate that it is the cause of the secondary conditions. Alarm management can be a tricky balancing act. It is important to detect and act upon critical alarms while at the same time not creating nuisance alarms.
Just because you can doesn’t mean you should. I have personally been involved with projects that cost hundreds of thousands of dollars and hundreds of person-hours creating very detailed alarming and troubleshooting tools, only to have the project implemented and the maintenance people not ever use the tools created for them. The customer always gets what the customer asks for, correct? An engineer designing a project that includes HMI-based troubleshooting aids would do well to talk with the people who will be maintaining the equipment to find out what they will use. Training the customer and the maintenance people after the project is implemented is crucial. Tools serve no purpose if they are unknown or unused.
About the author: Thomas Stevic
