Remote I/O vs Centralised I/O: An Architecture Reference
Short answer
- Centralised I/O keeps every card in one main panel and suits small machines or short wiring runs, while remote I/O moves nodes to the machine and replaces long copper runs with a network cable.
- The choice usually resolves to the cost of wire and panel space: long runs, spread-out devices, or tight panel space favour remote I/O, while a large panel with short runs favours centralised I/O.
- The tradeoff for remote I/O is network dependency, because a failed network cable takes down the entire node, and IP20 blocks suit sub-panels while IP67 blocks mount directly on the machine.
When you are laying out a control system, the I/O architecture decision usually comes down to two questions: how much copper do you want to pull, and how much panel space do you have? Everything else—diagnostics strategy, environmental rating, hot-swap capability, and network configuration—flows from that initial choice between pulling every wire back to a central main panel or pushing the I/O out to the machine.
What is centralised I/O and when does it make sense?
In a centralised architecture, all I/O cards live in the main PLC panel. Every sensor, solenoid, and motor starter is home-run wired back to that single enclosure. The mechanism of failure here is straightforward: longer wire runs mean higher total resistance, more induced noise from adjacent cables, and a higher probability of mechanical damage at cable trays, pass-throughs, and connectors. You are also limited by the physical density of the cards and the backplane.
The advantage is simplicity. All your termination points are in one climate-controlled enclosure. Troubleshooting is a matter of walking to the panel, checking the indicator LEDs, and measuring voltage at the terminal block. You do not need a network connection or a laptop to see if a prox switch is open or closed. The disadvantage is the sheer volume of wire. A machine with 200 I/O points, each requiring a 14 AWG or 16 AWG conductor plus a common, results in massive bundled cables exiting the panel. The labour cost to pull, dress, and terminate those runs, plus the copper cost itself, often dwarfs the cost of the I/O hardware. You also need a physically larger panel to house the terminal blocks and cards, which eats floor space.
Centralised I/O makes sense for small machines, compact skids, or environments where the field devices are already clustered near the panel. It also makes sense when the machine environment is too harsh for on-machine electronics and you cannot justify a local sub-panel.
What is remote I/O and what is the tradeoff?
Remote I/O moves the I/O blocks out to the machine. Instead of running 200 individual wires back to the main panel, you run power, a network cable, and maybe a spare pair to a local node, and the node handles the local field devices. The wiring runs drop from hundreds of feet to dozens of feet, or even inches. You can source I/O modules and remote I/O from various vendors, but the architecture principle is the same: the network replaces the copper.
The tradeoff is network dependency. If the network cable fails, you lose the entire node, not just one wire. This means your network physical layer matters more. You need robust connectors, proper shielding, and careful routing away from VFD output cables and other high-noise sources. The network becomes a single point of failure for that node, so the quality of your fieldbus modules and gateways and the media they ride on is critical.
You also have to decide how to protect the electronics. If the node sits in a clean, controlled environment, an IP20 block inside a local sub-panel is fine. If it sits on the machine frame, exposed to washdown, coolant, or physical impact, you need an IP67-rated block that can survive directly on the equipment without an enclosure.
Should I choose IP20 or IP67 I/O blocks?
The choice between IP20 and IP67 is really a choice about enclosures and environment. IP20 blocks are standard DIN-rail mounted modules with screw or spring terminals. They go inside a panel. They are cheaper, denser, and easier to configure because you have a controlled environment. The panel provides the environmental protection. The downside is that you still need a panel, which means cost, space, and a door to seal.
IP67 blocks are sealed, overmolded, and designed to be bolted directly to the machine. They use quick-disconnect connectors instead of screw terminals. This eliminates the local sub-panel entirely, which saves space and simplifies mechanical design. The tradeoff is that you are putting electronics in a harsher thermal and mechanical environment. Vibration, temperature cycling, and chemical exposure all become factors. IP67 blocks also cost more per point than IP20 blocks, and if a single channel fails, you may be replacing the entire block rather than a single card.
The practical rule: use IP20 in a local sub-panel when the machine environment is nasty but the device density is high enough to justify a panel. Use IP67 when the environment is manageable, the device density is low, or the machine geometry makes a sub-panel impractical. For the field connections on either style, standardised sensor and actuator cordsets with M8 or M12 connectors eliminate termination errors and speed up commissioning.
How should remote I/O nodes be addressed and configured?
Every remote I/O node needs an address. How that address is set determines how maintainable the system is. The old method is hardware switches or dials on the block itself. You set it once, document it, and it stays. This is robust and visible—the address is printed on the device. The problem is that it requires physical access to change, and if someone swaps a block without setting the address correctly, the node either conflicts or disappears.
Modern blocks often support software-addressable nodes, where the address is assigned via the engineering software or a configuration file stored on a memory card. This is easier to manage remotely and allows for faster swap-out, but it introduces a dependency on the configuration file. If the file is lost or the wrong version is loaded, the node behaviour changes. The key is consistency: pick one method, document the addresses in the electrical schematics, and ensure spares are pre-configured or clearly labelled.
Configuration management also includes the I/O mapping. In a centralised system, the PLC knows exactly which physical slot holds which card. In a remote system, the PLC talks to a node, and the node's internal map must match the PLC's expectation. If a node is replaced with a different firmware version or a different I/O mix, the mapping breaks. This is why standardising on a single vendor and product family for remote I/O across a facility pays off. A vendor like Turck, for instance, offers both IP20 and IP67 blocks with consistent configuration tools, which simplifies training and spares management.
Does hot-swap reduce repair time on remote I/O?
Hot-swap is the ability to replace an I/O block without powering down the node or the network. In a centralised system, you typically power down the card rack, swap the card, and power up. In a remote system, hot-swap depends on the network protocol and the block design. Some EtherCAT and PROFINET blocks support hot-swap at the block level, meaning you can pull the block off the DIN rail, plug in a new one, and the network recognises it automatically. Others require a node reset.
For maintenance, hot-swap is a major reliability factor. If a node failure stops a production line, the mean time to repair (MTTR) is the time it takes to physically swap the block and restore communication. Hot-swap-capable blocks reduce that window. However, hot-swap only works if the replacement block is pre-configured or auto-configures via the network. If you have to set DIP switches or load a file, you add time and error potential. Always verify the hot-swap behaviour of your specific network and block combination before specifying it for a critical application. Not all blocks that claim hot-swap support it identically, and some networks require a brief interruption to re-scan the node.
What does an IO-Link master add to remote I/O?
IO-Link adds another tier to this architecture. An IO-Link master sits between the fieldbus and the IO-Link devices, providing point-to-point communication to smart sensors and actuators. The master is typically a remote I/O block itself, but instead of discrete inputs and outputs, it provides IO-Link channels. Each channel runs a point-to-point serial connection to a single device.
The advantage of IO-Link is that it carries parameter data, diagnostics, and process data over the same wire. You can read a sensor's health, change its filtering parameters, and get its actual measurement value without a separate analogue card. This reduces wiring further—instead of a 4-20 mA analogue pair per device, you run a single standard 3- or 4-wire cordset to an IO-Link master channel. The master then aggregates this data onto the fieldbus back to the PLC.
IO-Link masters are available in both IP20 and IP67 formats, following the same environmental logic as standard remote I/O. They are most useful when you have smart devices that provide diagnostic data worth collecting, or when you want to standardise on a single cordset type across the machine. For simple discrete presence detection, standard discrete I/O is still cheaper and simpler.
How do you choose between remote and centralised I/O?
The architecture decision usually resolves to economics and physical constraints. If your panel is already large and your field wiring runs are short, centralised I/O is simpler and cheaper. If your wiring runs are long, your field devices are spread out, or your panel space is constrained, remote I/O pays for itself in copper and labour savings. The network dependency is real, but modern industrial networks are reliable enough that, with proper installation and component selection, it is rarely the deciding factor. The deciding factor is usually the cost of the wire and the cost of the panel space.
If you need help sourcing or cross-referencing I/O blocks, fieldbus gateways, or cordsets for a specific architecture, KKM can quote those components to order.
Related reading: what a PLC is and how it works.
Worth a look next: Modbus RTU vs Modbus TCP: What Is the Difference?.
Need a quote on a specific part?
Request a QuoteFrequently asked questions
When should I use remote I/O instead of centralised I/O?
Use remote I/O when wiring runs are long, field devices are spread out, or panel space is constrained, because it pays for itself in copper and labour savings. Centralised I/O is simpler and cheaper when the panel is already large and field wiring runs are short. The deciding factor is usually the cost of the wire and the cost of the panel space.
What is the difference between IP20 and IP67 remote I/O blocks?
IP20 blocks are DIN-rail mounted modules with screw or spring terminals that go inside a panel, which provides the environmental protection. IP67 blocks are sealed, overmolded, and bolted directly to the machine using quick-disconnect connectors, which eliminates the local sub-panel. IP67 blocks cost more per point, and a single failed channel may mean replacing the entire block.
What are the risks of using remote I/O?
The main risk is network dependency. If the network cable fails, the entire node is lost rather than one wire, so the network becomes a single point of failure for that node. This makes robust connectors, proper shielding, and routing away from VFD output cables and other high-noise sources important. A replaced node with a different firmware version or I/O mix can also break the mapping.
How does hot-swap affect remote I/O maintenance?
Hot-swap lets an I/O block be replaced without powering down the node or the network, which shortens mean time to repair when a failure stops a production line. It only works if the replacement block is pre-configured or auto-configures via the network. Hot-swap behaviour should be verified for the specific network and block combination before specifying it for a critical application.