The short answer
Remote I/O
Remote I/O places input and output modules in a separate panel, connected to the controller over a network, so that the controller reads and writes them as if they were local. The controller owns the logic; the remote rack has none, and its outputs go to a configured state when the connection is lost. It is the right choice for I/O in another panel in the same building or on a reliable fiber or copper link; for a site at the end of a radio or cellular path, a local controller with its own logic is the right choice, because remote I/O over an unreliable link is a station that stops when the link does.
Key points
- Remote I/O has no logic. When the link drops, the outputs go to their fault state and stay there.
- Use it across a building or a campus on a wired link. Use a controller, not remote I/O, at a site behind a radio.
- The update rate is a setting with a cost. Match it to the process, not the fastest the adapter allows.
- Configure every output fault state deliberately: off, hold, or a value.
- The adapter status and the connection status are tags the controller reads and alarms.
What remote I/O is
A controller chassis holds a processor and a few I/O modules. A plant has I/O in a dozen panels. Remote I/O is the arrangement that puts modules in those panels, each rack with a communication adapter instead of a processor, and connects the adapters to the controller over a network. The controller configures each rack as part of its I/O tree, reads inputs and writes outputs at a set rate, and the program sees the remote points as tags like any other. The rack itself does nothing but move data between its modules and the network.
That is the essential property. A remote rack has no program. If the network between it and the controller fails, the rack has no idea what to do beyond what it was told in advance: turn the outputs off, hold them, or set them to a value. The inputs are simply not read. A pump on a remote output, on a link that has failed, is either off or frozen in whatever state it was in until the link returns.
Remote I/O or a remote controller
| Question | Remote I/O | Remote controller |
|---|---|---|
| What happens on link loss | Outputs go to their fault state; no control | The site keeps running on its own program; SCADA loses visibility |
| Where the logic lives | In one controller, one program | In each controller; programs coordinated by design |
| Link required | Continuous, low latency, high reliability: copper or fiber | Any link that carries the data eventually: radio, cellular, fiber |
| Typical use | Panels across a plant, a building, a campus | Lift stations, wells, tanks, any site behind a wide area link |
| Cost | Adapter and modules | Controller and modules; a second program to maintain |
| Update rate | Milliseconds to tens of milliseconds | Seconds to minutes, by polling or report by exception |
| Commissioning | One program, one download | Two programs, two downloads, and the interface between them |
The dividing line is the link. A plant with fiber between buildings can put remote I/O anywhere on it. A collection system with radios to forty lift stations cannot: a station that stops pumping when the radio fades is a station that overflows in a storm, which is when radios fade. Remote sites get controllers.
The update rate
The controller and each adapter exchange data at a configured interval, called the requested packet interval on EtherNet/IP and by other names elsewhere. The interval is a setting, and it has a cost: each rack at each interval consumes network bandwidth and controller communication time, and a system with many racks at a fast interval can exhaust either. A pump station does not need its remote inputs every 5 ms; 50 to 100 ms is more than fast enough for motor control and level, and analog values are often fine at 250 ms or slower. Set the interval per rack from what the process needs, and leave the fast rates for the racks that need them.
Fault states
Every output on a remote rack has a configured behavior for loss of communication and for controller program mode. The choices are off, hold last state, and go to a defined value. The right choice depends on the load.
- Off
- The default and the right choice for most motor and valve commands. A pump that stops when the controller loses it is a known state.
- Hold last state
- For loads where an abrupt change is worse than continuing: a chemical feed that should keep going for the seconds it takes to reconnect. Hold becomes dangerous when the link is down for hours; combine it with a local timer or a hardwired backup.
- Defined value
- For analog outputs: a safe speed reference, a valve position that leaves the process stable.
Whatever the choice, it is made per output, recorded on the I/O list in the fail state column, and tested at commissioning by pulling the network cable and watching the outputs. A remote rack whose fault states were left at defaults has been designed by the module manufacturer.
Installation
- The network: a dedicated control network or VLAN, managed switches with the I/O traffic prioritized where the platform supports it, and no unrelated traffic. Ring or redundant star topologies where the platform offers them, with the recovery time understood.
- Fiber between buildings, always, for the surge and ground potential reasons on the surge protection page. Copper within a building, within the length limits, away from drive conductors.
- Addressing: a static IP per adapter from the network plan, on the network drawing and the adapter label, with the rack and slot layout on the I/O list.
- Power: the adapter and the modules on the remote panel supply, with the supply monitored, because a remote rack that loses power looks to the controller exactly like a rack that lost its network.
- Grounding and shielding per the platform installation manual; remote racks are more sensitive to noise than local ones because of the cable run.
- Spare capacity: spare slots and spare channels in the rack, as for any panel.
Diagnostics
The controller exposes the connection state of every remote rack as a status the program can read: connected, faulted, and often the module status within the rack. Those become tags, alarmed with a short delay so a momentary reconnection does not chatter, and displayed on a network status screen that shows every rack. The program uses the rack status to invalidate the data from that rack: an input from a faulted rack is not a zero, it is unknown, and the logic treats it that way. Switch port statistics and the adapter web page give the next layer of diagnosis when a rack drops: link errors, duplicate addresses, a cable, a power supply.
Frequently asked questions
- Can I put a remote rack at a lift station on fiber?
- On fiber that is reliable and owned by the utility, with the station accepting that a fiber cut stops it, yes, and it is done. Most utilities put a small controller there anyway so the station pumps on its own when the plant controller or the fiber is out of service. The cost difference is small and the independence is worth it.
- What is the difference between remote I/O and distributed I/O?
- Vendors use the terms loosely. Both mean I/O in a separate rack connected over a network to a controller that owns the logic. Distributed I/O sometimes means very small blocks mounted near the devices; the same rules apply.
- How many racks can one controller handle?
- The platform states a connection limit and a bandwidth budget, and the update rate multiplies the cost of each rack. A mid-size controller handles dozens of racks at moderate rates. The practical limit is usually the communication load, which the controller diagnostics report; keep it well under the ceiling so that adding a rack later does not push it over.
- Should the adapter be redundant?
- Some platforms offer redundant adapters, redundant media, or both. They are justified where a rack failure stops a critical process and the plant cannot wait for a replacement. For most utility panels, a spare adapter on the shelf and a ring topology on the network give most of the benefit.
Related topics
- PLC I/O SystemsDiscrete and analog input and output modules, sinking and sourcing, relay and transistor outputs, wiring conventions, and the module diagnostics that find field faults from the panel.
- EtherNet/IPHow EtherNet/IP moves control data: CIP over standard Ethernet, implicit I/O connections on a requested packet interval, explicit messaging, producer and consumer tags, and what the network has to provide.
- PLC ArchitectureHow a programmable logic controller is physically organized: the chassis, backplane, processor, I/O modules, remote racks, and what those choices mean for wiring, expansion, and failure.
- Surge Protection for Signal CircuitsProtecting 4-20 mA loops, discrete inputs, network cables, and radio feeds from lightning and switching surges: where surges enter, the device types and how they clamp, the grounding that makes them work, the resistance and capacitance they add, and where to put them at a remote site.
- Ethernet Device Drops OfflineAn industrial Ethernet device that disappears and comes back. Duplex mismatch, cabling, spanning tree, and the switch counters that identify it in minutes.
- I/O ListsThe document that ties the field to the controller: what every I/O list column means, how tags, terminals, and module channels are assigned, spare capacity rules, how the list drives the drawings and the program, and how to keep it true after commissioning.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.