By Dan Hebert, PE, Senior Technical Editor
As a machine or robot-building automation professional, you’ve been hearing about open systems for years. But you probably have been frustrated if you tried to create an open automation system using components from competing vendors.
However, it looks like the worm is turning as automation pros like you use digital I/O networks as the wedge to pry apart proprietary controller-I/O bonds created by automation vendors.
Digital I/O networks were created by automation vendors to answer customer demands for reduced wiring, faster troubleshooting and easier modifications. Automation vendors made money because their more expensive digital products replaced discrete and analog components. Customers made money by taking advantage of the aforementioned benefits.
Vendors that make just one or two components of an automation system love open systems. For example, a vendor that primarily makes I/O wants one industry-wide interface between all controllers and all I/O.
Despite what they say in public, some vendors that make a wide range of automation products don’t like open systems. These vendors want to lock their customers into buying every possible automation component from them, and open systems are the enemy of that vision.
Vendors jumped on the digital I/O bandwagon for competitive reasons, and many initially did so by creating proprietary digital links. But competitive pressures forced them to adopt standard links, in particular Ethernet-based protocols. Doing this let the proprietary cat out of the bag and released the dogs of open I/O systems in pursuit.
In the bad old days, all controller I/O was local and plugged into the backplane or was connected by a short-range parallel cable. When remote I/O first was introduced, it was available only on higher-end controllers. I distinctly remember having to spend thousands more for a high-end, very-expensive PLC back in the late ’80s just to get remote I/O.
All remote I/O was connected by proprietary links and had to be purchased from the controller vendor. In the past few years, many PLC vendors have adopted Ethernet for communications between controllers and I/O. This has opened the door to true open systems where a controller from one vendor can be used easily with I/O from another.
An example of this is when Allen-Bradley PLCs are used with Opto 22 I/O. “Because our I/O natively supports EtherNet/IP, engineers can incorporate advanced I/O functionality into their A-B systems without worrying about communication, compatibility issues or extra programming,” says Tom Edwards, senior technical advisor at Opto 22.
Why would you do this rather than just use A-B I/O? According to Opto 22, the reason is intelligence. “Our Snap I/O has its own processor to handle time-critical or repetitive tasks like high-speed counting, input latching and PID loop control,” explains Edwards. “These tasks and many more are performed at the I/O level without programming.”
PLC vendors can provide some of this functionality, but, continues Edwards, “processing takes place centrally in the PLC. With our remote distributed I/O over EtherNet/IP, time-sensitive, processor-intensive tasks are off-loaded from the PLC, improving performance and keeping scan rates fast..”
Opto 22 claims that intelligence is the main reason why some builders use their I/O with Allen-Bradley processors. But there are many other reasons why industrial OEMs want to mix and match controllers and I/O.
First among them is to use best-of-breed components. No single vendor makes a controller-I/O combination best for all applications, so separating controller and I/O vendors gives machine builders more options to find the best products for their particular needs.
A second reason is cost. If an OEM is free to buy I/O from any vendor for the preferred controller, then I/O cost is driven down across the board.
A third reason is vendor preferences of the OEM’s own customers. Many customers specify the brand of controller because they don’t want to support controller programming across many different brands. But more passive components like I/O need less support and often are not specified. This can allow an OEM to save time and money by using one brand of I/O while adhering to customer controller specs.
