The PLC Expansion Dilemma

Allen-Bradley® ControlLogix®, CompactLogix™, and similar control systems have become a corporate standard for many companies. As a control engineer, you are familiar with these systems and their architecture. You appreciate their strengths and understand how to best utilize them. And you're well aware that every expansion of the industrial PLC system, whether into new physical space or into new functionality, by necessity puts a strain on system performance.

This PLC expansion dilemma you face with each system change is more and more frequently tied to new demands on automation functionality. Today's more sophisticated automation applications often require more than the traditional scan inputs-->solve logic-->write to outputs approach. Incorporating connections to third-party devices, such as RFID and barcode readers, and involving more complex logic such as PID (proportional-integral-derivative) loop control, these applications place heavy, nontraditional demands on PLCs.

Of course any expansion of an industrial PLC system means the addition of I/O for new sensors and actuators. The PLC must scan the new I/O and run logic for it, which impacts processing power. But in comparison to existing I/O, the new sensors and actuators may demand proportionally more processing power because they are simply a different type of I/O.

Analog is a good example. Applications using many analog inputs and outputs require temperature conversion, thermocouple linearization, analog scaling and Engineering Unit conversion. All these new functional demands place nontraditional burdens on the central controller.

As functional demands for industrial PLC automation systems increase even while budgets shrink, you may be wondering if there are other ways to achieve system expansion.

An Alternative Approach

There is an alternative. Several decades ago, process control system vendors responded to the increased functional demands of analog I/O by creating the distributed control system (DCS).

The DCS model is different: instead of centralizing all system processing in one controller, it spreads out—or distributes—processing tasks to smaller, local systems. The intelligent processors at the I/O level handle many functions locally, leaving the central processor free to supervise the system as a whole.

This distributed intelligence is distinct from a distributed architecture. In a distributed architecture, local I/O systems are physically close to the devices they monitor and control, but they are still scanned and controlled by a central PLC. With distributed intelligence, the actual scanning and control is performed at the local I/O level by an intelligent processor—not another PLC with separate programming, but simply a processor that automatically performs several local tasks.

Not just a separate loop controller or a separate communication card, the local processor does a variety of communication and I/O processing jobs.

The idea of distributed processing power is a key concept not used by PLCs. While they have evolved to handle many additional functions, even the newest industrial PLCs are still hampered by their centralized architecture. Yet the increased demands of modern industrial automation applications are better served by distributed intelligence.


Learn more

Open Standards and Industrial Ethernet

Ethernet I/O

When Ethernet I/O was introduced in 1998, it was with the philosophy of using standard, open networks and protocols for industrial automation systems. In keeping with that philosophy, Ethernet I/O was designed to run on standard 10/100 Mbps Ethernet networks and the open Internet Protocol (IP)—both common standards used in most computer networks.

What that approach meant to customers was a significantly lower cost for system infrastructure. They could build control networks with off-the-shelf components—cables, routers, switches, PC—and simply plug their monitoring, control, and data acquisition hardware into it, with confidence that it would work. The physical elements of the network were readily available and subject to competitive pricing, and finding employees or integrators knowledgeable about network layout and design was not difficult.

Equally important, the use of IP as the network protocol for Ethernet I/O—either with UDP (User Datagram Protocol) or TCP (Transmission Control Protocol) at the transport layer—offered built-in flexibility to accommodate higher layers. Many useful protocols and applications that run on TCP/IP or UDP/IP already existed; support for them could be included when the market requested them.

Both the availability and lower cost of system infrastructure, plus the ability to connect with IP-based protocols and software applications, helped Ethernet I/O rapidly gain popularity among industrial automation users.

Multiple Protocol Support

Over the last ten years, support for multiple protocols has been added to Ethernet I/O. Because the hardware is built on standard technologies, additional protocol support usually requires only a firmware upgrade, not hardware or field wiring upgrades.

Some of these supported protocols include:

  • Modbus®/TCP for communication with Modbus hardware and software running over Ethernet networks
  • SNMP (Simple Network Management Protocol) for network management
  • SMTP (Simple Mail Transfer Protocol) for email
  • FTP (File Transfer Protocol) for file storage and exchange
  • EtherNet/IP™ for communication with Allen-Bradley PLCs and other systems based on this protocol


Allen-Bradley introduced EtherNet/IP™ in 2001. While the name sounds much like Internet Protocol over Ethernet, EtherNet/IP (note the capital "N") was actually a proprietary "Industrial Protocol" running over Ethernet. If plugged into a standard Ethernet network, hardware using EtherNet/IP is not compatible with normal network traffic.

EtherNet/IP was later made an open protocol, however, and is now supervised by ODVA (Open DeviceNet Vendors Association). EtherNet/IP incorporates CIP (Common Industrial Protocol), which is also supervised by ODVA and supported by many vendors.


Learn more

Enriching the Industrial PLC Control Network

What would be the advantage of expanding your PLC system with intelligent remote I/O? The distributed intelligence would not only reduce the additional load on the PLC but also accommodate new functional requirements and special applications, allowing the system to grow while still under the same PLC's overall control. In essence, you could enrich your A-B system by expanding its size and functional capabilities, and still be standardized on Logix PLC systems.

Like your IT department, which may, for example, be standardized on Microsoft® software and Dell® computers but chooses printers or other peripherals from other vendors for specific purposes, you can continue to use Allen-Bradley software, PLCs, and training and maintenance contracts while choosing another vendor for specific I/O needs. Supplementing your industrial PLC system with intelligent remote I/O gives you options that may work well for your application. And in times of tighter budgets, using intelligent remote I/O may cost less, too.

Opto 22, a company well known for manufacturing reliable, industrially hardened I/O, offers an intelligent remote I/O system called SNAP I/O™ that fully supports EtherNet/IP, the protocol used by many A-B PLCs.

Because SNAP I/O supports EtherNet/IP natively, engineers currently using Allen-Bradley PLCs can supplement their control networks and expand capabilities without concerns about communication and compatibility, without extra programming, and with little effect on PLC performance.

PLC Performance

PLCs usually scan remote I/O directly through a bus-coupler, which simply provides communication, not local intelligence. As we've seen, adding more I/O normally requires PLC resources both for scanning and for myriad functions such as counting, latching, thermocouple linearization, ramping, PID loop control, and so on. The addition of one or more PID loops can significantly impact system performance.

With Opto 22's SNAP I/O, however, all these functions and many more are distributed to the local I/O processor, which runs them independently. This intelligent I/O processor is called a brain. Sitting on the I/O rack, the brain is much more than a bus-coupler, offering not just communication but extensive local functions as well—including functions such as PID loop control that are more easily handled on the brain than on the PLC, because of their different design. With these functions independently handled at the I/O level, I/O point count can be added without significant impact on the PLC's performance.


To get this kind of local intelligence, you would expect to have to buy a supplementary PLC or mini-PLC and then program it with its own programming software. Opto 22's SNAP I/O brain, however, does not require programming; all of its functions are built in.

The SNAP I/O brain executes all of the following operations at the I/O level without additional programming:

  • Engineering unit conversion
  • Thermocouple linearization
  • Temperature conversion
  • PID loop control (up to 96 loops)
  • Serial device control (RS-232/485)
  • High-speed counting (up to 20 kHz, depending on the module and brain)
  • Quadrature counting
  • Analog scaling
  • Offset and gain (calibration)
  • Analog ramping
  • Output clamping
  • Filter weight
  • Minimum and maximum values
  • Digital and analog totalizing
  • Watchdog timeout
  • Time-proportional output (TPO)
  • Input latching
  • Pulse generation and measurement
  • Frequency and period measurement

A free I/O configuration utility is included with the brain. Once the new I/O is configured, the brain scans its local I/O, performs required functions, and waits for the PLC to pick up the data.

Communication and Compatibility

If communication with the PLC is lost, the brain continues to run PID loops and other functions locally, so a communication failure does not necessarily cause local processes to stop. If a process needs to be brought to a safe condition in the event of communication failure—for example, valves or pumps turned off—the watchdog timeout can be enabled to monitor communications, and the brain will set outputs to a predetermined level if a failure occurs.

Conformance-tested by ODVA's Test Service Providers®, Opto 22's SNAP I/O is completely compatible with Allen-Bradley PLCs using EtherNet/IP, including ControlLogix, CompactLogix, and MicroLogix 1100/1400.


About Opto 22 I/O

The Opto 22 SNAP I/O that engineers can now use to supplement an A-B system is widely regarded as exceptionally reliable, industrially hardened I/O. For example, its analog-to-digital and digital-to-analog conversion process is less susceptible to noise than other I/O on the market.

SNAP I/O includes not only digital and a wide range of analog modules, but also serial (RS-232 and RS-485/422) input and output modules. A single module contains from one to 32 points of I/O, depending on the model. Since many modules are software configurable, a single module can serve multiple purposes.

For example, a SNAP-AITM-8 module provides eight input channels, each of which is software configurable as Type B, C, D, E, G, J, K, N, R, S, or T Thermocouple or -75 to +75 mV, -50 to +50 mV, or -25 to +25 mV.

The Opto 22 intelligent remote I/O system consists of a rack that mounts up to 4, 8, 12, or 16 I/O modules and a SNAP I/O brain. Two brains are available, and it is easy to choose between them, because they have identical features except that one includes high-speed digital functions and the other does not.

Product Quality and Support

Product support for all products is free; no service contract is required. Quality is built into Opto 22 products, and every module is tested twice before leaving the factory in Temecula, California. The company does no statistical testing.

Because the company builds and tests its own products, Opto 22 guarantees all solid-state SNAP I/O modules for life.

Taking Advantage of the Options

With the new options provided by intelligent remote I/O, expanding your Allen-Bradley PLC system is no longer a dilemma. Instead, it's an opportunity to add functionality and explore opportunities while staying within your current system and within budget.


Learn more