All insights
Insights Technical brief

Your PLC already has everything it needs to handle more I/O - without touching the programme and without proprietary hardware

8 min read 1558 words
Your PLC already has everything it needs to handle more I/O - without touching the programme and without proprietary hardware

You are designing the long-lifecycle variant of a well-established machine and you realise the PLC rack is full. You have counted the available I/O three times and the answer is always the same: eight relay outputs and four digital inputs are missing. The obvious solution is an expansion module from the PLC manufacturer. The quote comes back and, between the module, the proprietary bus cable and the configuration licence, the cost has already quadrupled beyond what you expected.

There is an alternative that many machine builders discover far too late: a distributed I/O module with Modbus RTU or TCP, which connects to the PLC via RS-485 or Ethernet, is configured using the Modbus functions already present in the controller firmware, and requires no closed ecosystem whatsoever.

This article explains how the solution works from a technical standpoint, where the real economic advantage lies, and how to choose the right module before placing an order.


Why the limit is not the PLC, but the rack

Modern PLCs, whether Siemens S7-1200, Schneider Modicon M221, Allen-Bradley Micro820 or any other mid-range controller, support Modbus RTU or Modbus TCP as native protocols or via function blocks already included in the firmware. This means the controller is already capable of acting as a Modbus master, reading and writing registers on remote nodes, without libraries to purchase and without modifications to the existing programme.

The real bottleneck is physical: the number of slots available on the rack and the cost of the proprietary modules that fill them. When the machine grows, or when you need to handle a variant with more solenoid valves, more sensors or an additional station, the only route many engineers consider is through the original PLC vendor. But that route carries a price that rarely surfaces in early quotations.

The hidden cost of proprietary expansion

Beyond the module price, proprietary expansion brings with it:

  • The backplane or local bus cable, often specific to the rack model
  • An update to the hardware project inside the development environment
  • In some cases, an additional licence for remote I/O configuration
  • Lead times tied to a single supplier

None of these costs is necessarily prohibitive on a single machine. Across a line of machines, a retrofit project or a multi-year contract, they become a variable that is difficult to keep under control.


How a Modbus distributed I/O module works

A Modbus remote I/O module is a standalone DIN-rail device that exposes physical inputs and outputs (digital, relay, analogue) via a Modbus RTU interface over RS-485 or Modbus TCP over Ethernet. From the PLC’s perspective, it is simply a Modbus slave node with a unique address and a documented register map.

On the PLC side: a few lines of code

Configuration on the PLC side is straightforward. In Siemens TIA Portal, for example, you use the MB_MASTER block (for RTU) or MB_CLIENT block (for TCP), both already included in the standard library. On Schneider, the READ_VAR or WRITE_VAR function with the Modbus protocol is available at no extra cost. On Allen-Bradley, the MSG instruction handles both protocols.

In practice:

  1. Assign a slave address to the module, typically via DIP switch or web interface
  2. Configure the communication parameters on the PLC: baud rate, parity and stop bits for RTU, or IP address and port 502 for TCP
  3. Write the function calls to read Coil Status (FC01) or Discrete Inputs (FC02) for inputs, and to write Coils (FC05/FC15) for relay outputs
  4. Map the returned data into the programme variables you already use

There is no library to import, no GSD file to load, no hardware configuration to add to the project. The existing PLC programme remains untouched, unless you want to add the logic that uses the new I/O.

On the module side: the parameters that actually matter

The simplicity of the protocol does not mean all modules are equivalent. There are parameters that determine whether a module will behave reliably in an industrial environment:

  • Galvanic isolation of inputs: opto-isolated digital inputs protect the module and the RS-485 bus from stray voltages that are common in plant environments with motors and inductive loads
  • Relay switching capacity: a 5 A relay at 250 V AC is not the same as a 10 A relay, particularly when you are driving solenoid valves or contactors directly
  • Communication watchdog: if the bus drops, the module must bring its outputs to a predefined safe state, not hold the last known state indefinitely
  • Supply voltage range: an industrial module must operate reliably from 9 to 30 V DC, not only at the nominal 24 V
  • Operating temperature: inside compact control panels, temperatures can exceed 50 °C in summer

A real comparison: proprietary expansion vs. open Modbus remote I/O

Consider a concrete scenario: a machine with a Siemens S7-1200 PLC that requires 16 additional relay outputs to control an integrated washing station.

Proprietary route: Two SM 1222 modules (8 relays each) at roughly 350-400 euros apiece, plus the bus cable, plus the time needed to update the hardware configuration in TIA Portal. Estimated total: 900-1,100 euros, with lead times subject to the Siemens distributor.

Open Modbus route: A 16-relay Modbus RTU module over RS-485, wired with a screened twisted-pair cable costing a few euros per metre. The MB_MASTER block is already in TIA Portal. Configuration time: under an hour for an engineer familiar with Modbus. Module cost: significantly lower, with the added advantage of being able to choose from multiple suppliers.

The economic benefit grows with the number of machines and the need to manage variants. If the washing station comes in two versions (8 and 16 outputs), the Modbus route requires only a different module, not a different programme.

If you wish to compare the two approaches in relation to your specific infrastructure, Book a technical call with the Selio team before finalising the specification.


RTU or TCP? It depends on where the module is located

The choice between Modbus RTU RS-485 and Modbus TCP Ethernet is not a question of absolute performance: both protocols are suitable for the vast majority of machine control applications. The choice depends on the machine’s topology and the existing infrastructure.

We have explored this comparison in depth in the article Modbus RTU vs Modbus TCP: which to choose, but the practical guideline is as follows:

  • RS-485 with Modbus RTU is the natural choice when the module is located in the same control cabinet as the PLC or within 100–200 metres, when the infrastructure lacks Ethernet switches, and when the cost of cabling is a factor. An RS-485 bus can support up to 32 nodes on a single segment without repeaters.
  • Ethernet with Modbus TCP is the better option when the control cabinet is already connected to an industrial network, when you also want to access the module from a SCADA system or a supervisory PC, or when the distance exceeds the practical limits of RS-485 without repeaters.

There is no single correct answer. There are parameters that need to be assessed on a case-by-case basis.


Practical checklist before ordering

Before selecting a distributed I/O module, answer these questions. They are not theoretical: each one has a direct impact on compatibility and reliability in the field.

How many additional I/O points are actually needed? Allow for a margin of 20–30 per cent. A machine that starts out with 8 relay outputs tends to end up with 10 or 12 over the course of its lifecycle. A 16-point module costs only slightly more than an 8-point one and saves you a second installation.

What is the nature of the load on the relay outputs? Inductive loads (solenoid valves, contactors, small motors) wear out the contacts more quickly than resistive loads. Check the rated current and, if possible, choose relays with silver-alloy contacts.

Should the inputs accept AC or DC voltages only? Some sensors and limit switches in older control panels operate at 24 V AC. A module with opto-isolated AC/DC digital inputs can handle both without the need for intermediate adaptors.

What is the distance between the PLC and the module? For RS-485, check whether bus termination is required (120-ohm resistors at each end). For long distances or environments with high levels of electromagnetic interference, consider the TCP-over-Ethernet version with a shielded cable.

Does the module have a configurable communication watchdog? This is a minimum safety requirement for any industrial application. If the master stops communicating, the outputs must switch to a safe state within a user-defined timeout.

What baud rates does the PLC master support? For Modbus RTU, 9,600 and 19,200 bps are standard. 115,200 bps is supported by many modern PLCs and reduces latency on buses with many nodes.


Conclusion

Expanding a PLC’s I/O does not necessarily require staying within the original manufacturer’s ecosystem. A distributed I/O architecture based on Modbus RTU or TCP is technically sound, cost-effective for machines with long lifecycles or subject to variations, and does not require any changes to the existing programme.

The key is to choose modules with the right electrical specifications for the application, not simply the cheapest module available. A relay that fails after 100,000 cycles on an inductive load costs far more than the initial price difference.

The choice of protocol, bus topology and I/O sizing are one-off decisions that will shape the machine for years to come. It is worth getting them right from the very first iteration.

Cookie Settings

This website uses cookies. You can choose to allow or reject certain types of cookies hereunder. More information about our use of cookies can be found in our privacy policy.

These cookies allow core website functionality. The website won’t work without them.

These cookies serve to collect usage statistics, with anonymised IP, that help us improve the website.