Order the Modbus TCP variant of a compact remote I/O module when the runtime's feature list names a Modbus TCP master and the licence covers it. Set static addresses in one /24 subnet, enter TCP port 502, and take every offset from the module's own register map. Leave EtherNet/IP for plant-standard jobs, after the scanner and the EDS import check out.
A compact Ethernet remote I/O module is the tidy way to add points to a small CODESYS controller that has run out of on-board terminals. Buy the Modbus TCP variant. It asks nothing unusual of the vendor, only a published register map, and a soft CODESYS runtime on a single-board Linux controller already speaks it when its feature list says so. The EtherNet/IP variant of the same module families works only when the runtime includes a scanner and the licence covers it, which is a check to finish before the box arrives. Below are the three purchase checks, the protocol options in one table, a bench example worked through the addressing arithmetic, and the questions that sort a good module from a dead end.
The three checks that decide the purchase
Protocol support. Open the store listing for your exact runtime and read its feature list. The listing for the common single-board soft runtime names a Modbus TCP master and slave alongside the Modbus serial master and slave. Other runtimes ship the Modbus TCP master as a separately licensed client, so only the feature list printed for your runtime counts. This one check separates a purchase you can build on from a two-hour surprise.
Licence coverage. The same listing prints the demo rule: without a licence the software runs for two hours and then stops. Two hours is shorter than most commissioning days, so plan the activation into the purchase, not into the first fault. A stop right at the two-hour mark looks exactly like a network fault, because every point dies at once and nothing warns you first. Read the licence state in the runtime's device entry after activating to confirm it took.
Addressing values. Modbus TCP carries the unit ID and the register offsets in your project, and every value comes from the module's own manual. Coils, discrete inputs, input registers and holding registers are four separate address spaces, and in each of them the first point sits at offset zero, so enter the offset the map shows for that function code and add nothing for the function itself.
A manual printed in the 1-based convention shows 10001 for the first discrete input and 40001 for the first holding register; subtract 10000, 30000 or 40000 and enter an offset of zero. Set the unit ID the manual gives for TCP mode, and if a connection refuses to come up on 1, try 0 once before rewriting anything, because some TCP adapters answer only to 0. If a green connection still delivers zeros, run the checklist in CODESYS showing 0 for Modbus TCP analog values, and remember that a REAL analog value spans two 16-bit registers, laid out end to end in sending a REAL value in a 12-byte TCP telegram.
The options, and what each asks of the runtime
| Variant | What the runtime needs | What you enter | Pick it when |
|---|---|---|---|
| Modbus TCP | Modbus TCP master in the feature list, licence covered | Module IP, TCP port 502, unit ID, per-channel function code and offset | First choice: any vendor module with a published map works |
| Modbus RTU over RS-485 | Modbus serial master in the feature list, a free serial port | Port and baud, slave address, offsets | The cabinet already has RS-485 runs and no switch nearby |
| EtherNet/IP adapter | Scanner in the runtime, its licence, an EDS import | Connection parameters from the EDS | The plant standard is EtherNet/IP and both checks pass |
| PROFINET device | PROFINET master support, a GSDML import | Device name and IP | The plant standard is PROFINET |
The last two rows are description-file protocols: the runtime learns the module from a vendor file, and the import has to finish cleanly before the first download works. The PROFINET case walks the same path as the GSDML import into the CODESYS device repository, so that walkthrough is a good rehearsal for either row. If you are weighing the EtherNet/IP row, read a scanner EDS import and array mapping walkthrough first, so the first import on your own runtime is a known quantity.
Example: 16 points on a packing bench
Scenario: a packing bench needs 16 photo-eye and door-switch inputs and 8 reject-chute solenoid outputs. The controller is a single-board Linux unit running a CODESYS runtime with its Modbus TCP master licensed, and the bench has one small Ethernet switch.
Network. Set the controller to 192.168.10.10 with mask 255.255.255.0 and the module to 192.168.10.51, both static. The check: 192.168.10.10 AND 255.255.255.0 gives 192.168.10.0, and 192.168.10.51 gives the same 192.168.10.0, so both addresses sit in one /24 and need no gateway. Add the Modbus TCP master under the controller's Ethernet entry and a slave under it with the module address and TCP port 502.
Map. A manual of this kind lists discrete inputs on function code 02 and coils on function codes 01 and 05, with the first channel at offset zero and the map printed zero-based. Enter 16 input channels at offset 0 and 8 output channels at offset 0. Size check: a function code 02 read of 16 points returns 16 bits; 16 divided by 8 is 2, so the reply carries 2 bytes of status. Set the unit ID the manual prints for TCP mode.
Timing. Poll the inputs every 100 ms. On this bench a request and its reply take about 3 ms across the switch, so a change at a photo-eye reaches the logic at most 100 ms plus 3 ms, about 103 ms, after it happens. If the process needs faster eyes than that, shorten the poll or move those points onto the controller's own terminals.
Proof. Toggle input 7 by hand and watch exactly one mapped bit change in the online view. Force each output once, confirm the right solenoid pulls in, release the force. Then leave the bench polling for two and a half hours with the licence active: the demo clock runs out sooner, so a bench still answering past the two-hour mark is licensed and yours.
When to pick something else
Modbus RTU over RS-485. If the cabinet already has RS-485 runs and the points sit close together, a serial module avoids new Ethernet cabling. The runtime needs its serial master in the feature list and the controller needs a free serial port; setting up a serial port for CODESYS on Linux covers the port side.
EtherNet/IP. Take this row when the plant standard is EtherNet/IP or the module must also serve a scanner you do not control. Confirm the scanner in the feature list, confirm its licence, and budget a clean EDS import as part of the job, as the walkthrough linked above shows.
Local terminals for safety. Points in a safety function, or any interlock that must act within a few milliseconds, stay off polled Ethernet. Response time there is the poll interval plus the reply time, and it moves with network load. Those points belong on the controller's own terminals or on the machine's safety relays.
What to ask the vendor before you order
- The register map for the exact variant you are buying, with the function code and start offset for every point, and whether the offsets are printed zero-based or 1-based. Maps differ across a family, so ask by model number.
- The unit ID the module uses in TCP mode, and whether you can change it.
- The DC supply voltage range, so the cabinet feed matches the module.
- How many simultaneous TCP clients it accepts.
- What the outputs do when the Ethernet link drops, and whether that state can be set per output.
Recommendation: Order the Modbus TCP variant when your runtime's feature list names a Modbus TCP master and the licence covers it. Set both addresses static in one /24, enter TCP port 502, take every offset and the unit ID from the module's own map, and activate the licence before the first commissioning shift. Order the EtherNet/IP variant only when the plant standard demands it and the scanner licence plus a clean EDS import are confirmed on your exact runtime first.
Questions
Does the two-hour demo clock also apply once the runtime is licensed?
No. The clock belongs to demo mode only; once the licence is active the software no longer stops at two hours. To confirm the activation took, check the licence state in the runtime's device entry and leave the system polling for two and a half hours, past the documented demo period. The store listing for your runtime prints that period exactly.
How fast should I poll remote I/O points?
Match the poll interval to the process: 100 ms suits photo-eyes and anything an operator reacts to, while 1 s is enough for counters, temperatures and levels. Every point's response time equals the poll interval plus the reply time, so halving the interval halves the staleness. Poll the points you only log slowly, to keep the link quiet.
Can I leave the controller and the module on DHCP?
Set both addresses static. A lease that renews to a different address mid-shift stops the polling dead and looks exactly like a module fault, and hunting it costs more time than the static configuration takes. If site policy forbids static addresses, create reservations on the DHCP server so both addresses stay fixed.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.