Digital I/O for legacy machines
The 20-year-old machine that still holds tolerance deserves a place on the dashboard too. Digital I/O brings machines without network-capable controls into the same live view as the rest of the fleet — honestly labeled for what the connection can and cannot see.
How an I/O connection works
Every machine, however old, has electrical signals that reflect what it is doing: a run-lamp circuit, a cycle-complete relay, an M-code output that pulses when a part finishes. A digital I/O connection taps those existing signals — read-only, at the terminals — and the gateway turns them into machine states and counts on the dashboard, exactly as it does for controller-connected machines.
| Signal tapped | What it yields |
|---|---|
| Run / cycle relay or lamp circuit | Running vs stopped state, downtime events, utilization. |
| Cycle start / end pulse | Cycle times and cycle counts. |
| Part-complete output (M-code / counter relay) | Part counts for production tracking. |
The honest limits
An I/O connection sees on/off, not meaning. It cannot tell why the machine stopped, which program was running, or whether an override is turned down — signals that exist only inside the control. Two consequences follow:
- Operators supply the why. Stop reasons on I/O machines come from a two-tap operator prompt, not from alarm codes — so the reason list must be short and in the operators' own words.
- OEE is partial. Availability and counts are solid; performance depth (override drift, in-cycle pauses) is not visible. We show what is measured and never estimate the rest into a prettier number.
The right mix: on a typical Indian floor most machines carry network-capable controls and connect natively — FANUC over FOCAS above all — while the oldest few join over I/O. Be wary of any vendor proposing I/O boxes for a whole fleet whose controls could have spoken for themselves.
Frequently asked questions
Can old CNC machines be monitored at all?
Yes. Machines whose controls cannot speak over a network can still report run/idle state and count pulses through digital I/O signals — typically taken from existing relays, stack-light circuits, or spare M-code outputs. It is shallower than a controller connection, but it puts the whole fleet on one dashboard.
What can digital I/O measure — and what can't it?
Reliably: running vs stopped, cycle start/end pulses, and a part-count signal where one exists. It cannot report alarms by name, program identity, override positions, or spindle load — those exist only inside the control. We label I/O-connected machines accordingly so nobody mistakes inferred data for controller truth.
Does connecting I/O signals interfere with the machine?
No. The connection reads signals that already exist — a relay closing, a lamp circuit energizing, an M-code output pulsing. Nothing is written to the machine and no logic is changed. The wiring is done at the signal terminals, machine powered down, in under an hour per machine in most cases.
Should I use I/O even on machines that have a network-capable control?
Almost never. If the control can speak — FANUC over FOCAS, or a machine with MTConnect or OPC UA — the native connection reads far more, with no wiring at all. I/O is the fallback for machines that have no other way in, not a shortcut for machines that do.