History and evolution of machine HMIs

From PanelView 1200-era hardware through touchscreen representations of physical controls

Key Highlights

  • Early machine-control HMIs relied on monochrome CRTs, fixed screen grids and bezel-mounted keys for navigation and data entry.
  • Touchscreens, higher-resolution displays and flexible graphics transformed HMIs from rigid interfaces into more capable operator-control platforms.
  • Machine-control HMI software evolved from mimicking physical push buttons, selector switches and pilot lights to providing configurable, dynamic screen objects.

The human-machine interface (HMI) has been around for a long time. My first encounter with an HMI was an Allen-Bradley PanelView 1200 CRT, now called the Classic. It was a cathode ray tube (CRT) in a beast of an enclosure. The choice of color was monochrome. Around that same time, mid- to late-1980s, I also did some work with an Eaton/Industrial Data Technologies (IDT) HMI called PanelMate. All three were the latest in technology at the time. As I recall, monochrome was the only choice; there were different colors of monochrome, but just one color could be selected to use for all of the screen objects.

HMIs of that vintage were grid-locked, meaning that one could place an object on the screen, but only in a dedicated location on a locked in grid. The objects were pre-defined and could not be modified in any format.

Navigation was usually via buttons on a touchpad that was located on the bezel around the outer edges of the CRT. The CRT itself was a display-only, and the operator could only make actions happen by using the touch pad to the side to move the screen highlight around the grid to highlight the objects. Once the correct grid was highlighted, the enter button would confirm the action.

Numeric entries worked in much the same way. Once the entry pointer was on the correct variable, the operator would manually enter a new value via the numeric keypad, also on the bezel outside the confines of the CRT itself. Function keys along the side and bottom of the display could be programmed to perform specific functions. Usually the ones on the bottom were used for screen navigation.

Anyone reading this description of an HMI from back then must think this is barbaric and antiquated, and, well, it was, but we didn’t think so at the time. Like anything in this life, we take what we are given and make it work to the best of our abilities. I look back fondly on those experiences and take great pride in what I was able to do with that “barbaric” system. Much could be done with the four basics—input (button), indicator (light), numeric and alpha entry.

Thankfully, HMI has come so much further. Primary to that is the physical format changing from CRT to light-emitting diode (LED) with variations matching modern television and computer monitors. Colors are practically unlimited and screen resolutions are such that screen objects are limited only by the practicality of a person being able to see the object on the screen.

Objects are no longer locked into the invisible grid on the screen and can be placed anywhere in the viewing area. Ironically, I still use some object placement tools to put most objects back into a grid pattern because it is pleasing to my eye. In fact, I get annoyed when an OEM or one of my own designers gives me a screen where similar objects are not aligned. One might call me old and barbaric, but I care about the aesthetics of the screen.

The evolution of the HMI has left us with a hardware device that is basically an industrial computer with a monitor either attached to or near it. What differentiates the various hardware/brand choices is the development software behind it.

Get your subscription to Control Design’s daily newsletter.

My view of HMI development software can be divided into two distinct groups. One group has evolved from legacy HMI hardware where the software was designed to direct the development to fit within the confines of the dedicated processor HMI. Think of the PanelView and PanelMate products, for example. Screens mimicked a control panel with push buttons, selector switches, pilot lights. Basically, the HMI was an electronic version of a control board in a factory. The second group of HMI development software is born from dedicated SCADA packages. Perhaps I over-simplify things, but I think of the former as machine control and the latter as process control. The situation is no longer that distinct, but we can talk about that later.

As mentioned previously, the legacy machine-control HMI products led to an evolution of software as the hardware evolved. These products used the screen to mimic the real-world controls that an operator would use when interacting with the equipment.

While improving the quality/clarity of the screen objects, they literally look like their real-world counterparts. A push button, with a label behind it, looks just like the actual button on a panel—a selector switch that, when pressed, toggles back and forth through the physical positions that the real version would have. Pilot lights turn off and on to mimic the status of, for example, a motor starter or a critical photo eye. Navigation buttons, formerly located on the bezel around the screen, become buttons on the screen with the advent of touch screen technology.

Later versions of the development software don’t abandon real life mimicking screen objects but add to the features by allowing the designer to change the color of the nameplate, for example, to further highlight the status of the object. Objects can flash to show action. Pressing a button will change the object on the screen to show a depressed image, and releasing it returns it to the normal raised image.

The evolution from monochrome CRTs and bezel-mounted controls to today's touchscreen HMIs changed not only what an operator interface looks like, but also what it can do. That evolution didn't stop with better displays and more sophisticated machine-control objects. The traditional lines between machine-control and process-control HMIs have blurred, and modern programming tools and a new generation of engineers are shaping what comes next.

About the Author

Rick Rice

Rick Rice

Contributing Editor

Rick Rice is a controls engineer at Trew Automation, a material handling manufacturer based in West Chester, Ohio. With over 38 years’ experience in the field of automation, Rice has designed and programmed everything from automotive assembly, robots, palletizing and depalletizing equipment, conveyors and forming machines for the plastics industry but most of his career has focused on OEM in the packaging machinery industry with a focus on R&D for custom applications. 

Sign up for our eNewsletters
Get the latest news and updates