I/O count is where most specifications start, but it is rarely where they should end. A controller that only just fits today becomes the reason a line cannot be extended two years from now.
Start with I/O, but do not stop there
Counting inputs and outputs is straightforward. Add the digital sensors, the analogue measurements and the relay outputs, then add a margin. The margin is where most specifications go wrong: 10% looks prudent on paper, but a single added station on a conveyor can consume it entirely.
We normally plan for 25% spare capacity on machines that are expected to change, and 20% on machines that will not. Expansion modules are cheaper than a controller swap.
The cost of one spare I/O module is almost always less than the labour of re-commissioning a machine around a controller that ran out of room.
Scan time decides more than you expect
Scan time is the interval in which the controller reads inputs, executes logic and updates outputs. For most packaging and conveyor work, anything under 10 ms is comfortable. Motion control, high-speed counting and safety interlocks tighten that budget quickly.
- Simple sequencing and interlocks: 10–20 ms is usually fine
- Conveyor tracking and reject gates: aim for under 10 ms
- Coordinated motion or high-speed counting: 2–5 ms, and check jitter
Manufacturer figures are measured on a benchmark program. Your logic, your communication load and your interrupt routines all add to it, so treat the published number as a ceiling rather than a promise.
Motion requirements change the shortlist
A controller with two axes of pulse-train output covers a surprising number of compact machines. The moment you need coordinated motion, electronic camming or more than four axes, the shortlist narrows and the price step is significant.
S-curve profiling matters here. Reducing jerk extends belt and bearing life, and on semiconductor or delicate packaging lines it is the difference between a machine that runs and one that damages product.
Communication options you will actually use
Most compact controllers offer some mix of serial, Ethernet and fieldbus. The right choice depends less on raw bandwidth than on what already exists in the plant.
- Modbus TCP — simple, well understood and usually enough for HMI and SCADA traffic
- EtherNet/IP — sensible when the plant is already standardised on it
- PROFINET — strong for deterministic device-level control in mixed-vendor plants
Whichever you choose, keep the machine network and the plant network separate. A controller that shares a subnet with office traffic will eventually see a scan overrun.
A short specification checklist
Before you commit to a controller, confirm each of these against the machine you are actually building rather than the machine you were quoted:
- Total I/O plus a realistic expansion margin
- Worst-case scan time with your logic, not the benchmark
- Axis count, motion mode and jerk requirements
- Protocols already in use elsewhere on site
- Memory-card support for field updates and recovery
- Spare-part availability over the machine's expected life
Specified this way, the controller stops being the constraint. It becomes the part of the machine you stop thinking about, which is exactly what a good one should be.
