Choosing an EtherCAT I/O replacement CODESYS accepts

Which EtherCAT I/O can you swap in without rewriting the project?

Any EtherCAT slave family that ships an ESI device description your CODESYS master accepts, offers 8- or 16-channel 24 V digital terminals to build 32 inputs and 32 outputs, and holds the configured bus cycle your fastest inputs need is a software drop-in. Drop-in means the device tree's I/O section changes and the application logic does not. The hardware, the terminations and the mounting all change.

Three checks decide it, in this order:

1. Bus: is the replacement an EtherCAT slave set with a usable ESI file?
2. Cycle: does the controller hold the configured bus cycle with the new slaves counted in?
3. Pulse: does the input filter plus one bus cycle sit under the shortest pulse any sensor produces?

Each check has a pass condition and a measurement. The sections below carry them in order.

Does the replacement have to stay on EtherCAT?

Yes. The project survives unchanged only when the new I/O speaks EtherCAT to the same master: the frame still takes the same path, your 64 points ride in one frame, and the limits stay where they are today, in task timing and input handling.

One frame leaves the master's port, runs through slave 1, slave 2 and so on to the last slave, and returns. Each slave strips its output data and inserts its input data as the frame passes. Thirty-two inputs pack into 32 bits, 4 bytes, and thirty-two outputs another 4 bytes, so payload is never the limit at this size.

What bus cycle time can your controller hold?

Set the bus cycle and the I/O task to the target value, go online, and read maximum cycle time plus jitter against the configured cycle: the swap holds when that sum sits inside it, and 100 µs is a controller decision before it is an I/O decision.

The cycle is produced by the EtherCAT master's cyclic task, so that task's configuration sets the floor before any I/O family does. Configure the cycle, connect online, and read the task statistics: average cycle time, maximum cycle time, jitter. Say the statistics read 60 µs maximum and 15 µs of jitter at the configured cycle: 60 + 15 = 75 µs, leaving 425 µs of headroom. The same 75 µs against a 100 µs cycle leaves 25 µs, which is thin, so treat 100 µs as reachable only when the statistics hold it after the new slaves are counted in.

Dedicate one Ethernet port to EtherCAT. HMI, OPC or engineering traffic sharing that port adds jitter no I/O choice can remove.

How fast must the digital inputs be for your shortest pulse?

Budget the shortest pulse as input filter time plus one bus cycle when the I/O task is synchronized to the bus, and add one more task cycle when it runs free; a fixed 3 ms filter rejects any sub-3 ms pulse before the bus is involved.

Latency stacks in this order: the terminal's input filter, the wait for the next frame pass, the task cycle that reads the process image, then the program scan behind it. The rule assumes the worst case, an edge arriving just after that slave's frame has passed, so the filtered state must still be high one full cycle later to ride the frame. The filter is the part you control: read its value, and whether it is configurable, in the module datasheet or the startup SDO parameter list, and take the shortest real pulse width from the sensor datasheet or an oscilloscope.

A time-stamped input latches the edge time locally and the timestamp rides the frame, so a pulse narrower than the bus cycle survives; Distributed Clocks synchronizes the modules' clocks so those timestamps stay comparable.

Worked example: will a 120 µs pulse be captured on a 100 µs cycle?

No at 500 µs, yes at 100 µs. A 3,000 µs filter plus the current cycle is a 3,500 µs floor, so a 120 µs pulse dies in the filter; a 10 µs filter with a synchronized 100 µs cycle needs only 110 µs, and 120 µs clears it.

Scenario: a part-present sensor on a fast slide closes for 120 µs at 24 V, the plant wants it counted, and the project runs a 500 µs bus cycle with the I/O task synchronized to the bus.

• Case A, standard input at the current cycle. Take a common 8-channel 24 V input module whose datasheet prints a fixed 3 ms filter, a widespread default. Floor = 3,000 µs + 500 µs = 3,500 µs. The pulse is 29 times shorter than the floor (3,500 ÷ 120 ≈ 29), so the module never reports it.
• Case B, fast input with the cycle tightened. Floor = 10 µs + 100 µs = 110 µs. The pulse clears it with 10 µs to spare, an 8% margin on the pulse width.
• Case C, task not synchronized. Add one task cycle: 10 + 100 + 100 = 210 µs. A 120 µs pulse misses, so synchronize the task or specify a time-stamped input.

Decision: order fast input channels, set their filter to 10 µs, run the I/O task at 100 µs synchronized to the bus, and prove it with the pulse count test below. Any pulse under 110 µs gets a time-stamped, latching or counter input whatever the cycle is.

How do 32 inputs and 32 outputs fit a module family?

Two 16-channel input modules and two 16-channel output modules cover 32 and 32 with four modules plus the coupler; what decides the order is the output current table and the field supply feed, both read from the datasheet before you buy.

Families split channels differently: 8-channel modules mean four of each, 16-channel modules mean two of each. Count the result against the coupler's maximum station length and the port you will expand through.

Levels under 24 V work too; match the sensor and actuator levels to the module before ordering.

Which I/O qualifies, and when should you buy something else?

Search the catalogs of controller vendors whose products run CODESYS and filter for EtherCAT slave I/O with a published ESI file; if your fastest response is honestly several milliseconds, a simpler remote I/O with a slower cycle is the better buy.

Ask each candidate vendor for four things:

• An ESI file for every module you are quoting, and a clean import into the device repository, tried before the order.
• A passed EtherCAT conformance test, so the state machine and the working counter behave on your master.
• EMC and temperature ratings equal to the cabinet the old modules lived in.
• The filter, current and feed values from the tables above, printed, not promised.

For a non-safety function, a lower-cost family is a valid candidate once it clears the same checks. Safety functions stay on certified safety I/O behind a safety-rated master; standard modules never take that role.

Buy something other than EtherCAT when the controller cannot hold the cycle after the new slaves are counted in, when a vendor has no ESI file, or when nothing in the plant switches faster than a couple of milliseconds and a 0.5 ms cycle is already generous. When the current family's lead time is the reason for the swap, qualify two families in parallel and keep the second documented as a fallback.

How do you swap the I/O section and keep the logic unchanged?

Install the new ESI files, add the slaves under the same EtherCAT master in physical order, rebind every channel to its old variable name in the I/O Mapping tab, and delete the old devices; logic that uses named variables never changes.

1. Export or screenshot the current I/O mapping table. Note every variable bound to a channel and every direct %IX or %QX address in the code.
2. Install the vendor's ESI files through Tools → Device Repository and confirm each new module appears.
3. Add the new slaves under the existing EtherCAT master in physical order. Set fixed station aliases where the modules support them, so the address never depends on position.
4. Rebind each channel in the I/O Mapping tab to the same variable names. Logic through global variable lists needs no edits; hard-coded addresses need remapping.
5. Set the bus cycle and the I/O task interval, task synchronized to the bus.
6. Enable Distributed Clocks on modules with time-stamped inputs, and set the fast-input filter from the pulse math.
7. Delete the old plug-in devices from the tree, download the project, and drive the master to OP, the operational state.
8. Prove the mapping before field wiring goes live: force inputs from the development environment and watch the logic respond. How CoDeSys forcing works in the PLC cycle covers what forcing can and cannot touch.

How do you prove the swap holds timing?

Five measurements close the job: every slave in OP, a working counter with no incrementing frame losses, maximum cycle time plus jitter inside the configured cycle, a counted pulse test, and an oscilloscope shot of input-to-output delay.

A missed count in the pulse test is an input-path problem, back to the filter math. If pulses reach the logic but vanish on a screen, that is a refresh problem, covered in why an R_TRIG pulse never shows on the HMI screen.

Recommendation: Stay on EtherCAT and gate the order on the ESI file: no published ESI your master imports cleanly, no order. Build the point count from 16-channel 24 V modules, start the bus at 500 µs, tighten to 100 µs only where the online task statistics hold it, and run the I/O task synchronized to the bus. Specify a time-stamped, latching or counter input for every pulse shorter than the filter plus one bus cycle. If nothing in the plant switches faster than a few milliseconds, hold the starting cycle and spend the difference on a second qualified family as a lead-time fallback.

Questions