HMIs and Multi-Platform Communication
Most every industrial plant or facility, including probably yours, has PLCs and other controllers of varying makes and models. There are a few ways to link them, but using the HMI is usually your best bet.
The simplest method is hard-wiring one controller to another, but it’s also the most limited. Connecting inputs and outputs is clear in concept, but it severely limits the amount of information communicated among controllers. It also makes any changes difficult as each modification requires new wiring, and in some cases additional I/O modules.
The second method is to link the controllers using protocol converters. Model A PLC won’t be able to talk directly to Model B PLC, so a protocol converter will be needed. While this method might work for some applications with just two controllers, it gets messy quickly for all other installations.
The third method is to use the HMI as the hub for all communication among controllers. This is the most powerful approach, and it generally requires no extra hardware, software or even wiring since each controller usually requires connection to an HMI for operator interface.
Let’s look at how to implement communication among controllers via an HMI, and at why this method is best for most applications.
Can We Talk?
In the past, high-price leaders in the automation arena were able to limit the connectivity of their automation system components and lock you into their brand, but user demands forced the move to open systems. This means you can now link almost any controller to just about every HMI, usually through Ethernet.
Ethernet has the great advantage of being able to carry multiple protocols simultaneously on one network, making it feasible to link many different controllers to one HMI on a single Ethernet network. For example, let’s say controllers A, B and C all have Ethernet ports but use different communication protocols such as Modbus TCP/IP, EtherNet/IP and simple Ethernet IP. That’s not a problem, since one HMI can still talk to all three in spite of the protocol mix.
Are You My HMI Type?
We’ve been talking about HMIs, but this generic term actually encompasses two main options. The first is embedded HMI, like AutomationDirect’s C-more®, and the second is PC-based HMI, like AutomationDirect’s Point of View®.
As you may have guessed, an embedded HMI runs on an embedded operating system (OS). Compared to a PC-based OS, an embedded OS requires much less processing power and memory because it’s dedicated to a single function, in this case hosting the HMI software. A PC-based HMI is just what it sounds like, with a PC and its OS hosting the HMI software.
An embedded HMI is a much lower cost solution than a PC-based HMI, and provides other benefits such as greater longevity for the OS and application. Embedded HMIs are also becoming more powerful, and should be considered for all but the most demanding applications. And, the cost savings from using an embedded HMI may allow you to add additional HMIs to increase operational efficiency and improve safety.
Embed That HMI
Some suppliers sell embedded HMIs with limited and proprietary protocol options to force you to use their controllers. But we take the opposite approach, supplying our embedded HMI as an open platform with multiple communication ports and built-in support for a wide variety of communication protocols—allowing you to connect our embedded HMI to the widest range of controllers.
We mentioned protocol converters before as a way of communicating between controllers, but an embedded HMI can serve the same purpose at a lower cost as it can simultaneously communicate with different brands of PLCs, functioning as a “protocol bridge”. This keeps your cost low because the HMI is pulling double duty, providing operator interface and acting as the communication hub for the entire automation system.
An embedded HMI can be configured to pass values back and forth among different controllers using multiple protocols, and it’s much more powerful than a protocol converter as it can handle many different protocols simultaneously.
Our C-more embedded HMI can talk to eight of the top PLC brands using 25 different communication protocols, but if these capabilities aren’t sufficient, then a PC-based HMI is the next step up.
With a PC, it’s possible to add a virtually unlimited number of communication ports. The PC can be ordered with multiple ports, and more can always be added by plugging a new card into the PC bus.
Our Point of View HMI software, and to be fair, most PC-based HMI software, has built-in support for hundreds of different communication protocols, providing the maximum in communication capability.
Tag, You’re It
With either an embedded or PC-based HMI, the use of tags helps connect different controllers. When utilizing tags, the programmer creates meaningful tag names used directly in the controllers, as well as in the HMI software. In the worst case this will require entering the controller tag names into the HMI software manually, but in many instances it’s possible to import tag names automatically from the controller to the HMI.
For example, our C-more HMI can import the tag name database from our P3000 PLC, and it also has support for Rockwell Automation’s ControlLogix® EtherNet/IP Tag Messaging. This feature allows you to quickly import your PLC tag database into the HMI. C-more also supports direct import of the Rockwell Automation RSLogix® 5000 tag name database. Direct import of tag names eliminates the need for manual data entry of tag names into the HMI software, with no mapping or translations required.
Point of View supports a much wider range of controller tag name import, making it a better fit for applications with many different controllers of multiple makes and models, particularly when the controllers contain hundreds of even thousands of tag names.
Whether the choice is embedded or PC-based, using the HMI as the hub for communications among controllers will usually be the lowest cost option, and it will always provide more functionality and flexibility than hard-wiring or protocol converters.