What I learned connecting 25 CNC machines to one platform

The brief was simple to state: 25 CNC machines, three production lines, one live view. Before the project, production data was collected by hand — an operator wrote numbers on a sheet, someone typed them into a spreadsheet at end of shift, and management read a report the next morning that described a factory that no longer existed.

Here is what the work actually involved, and what I would tell someone starting the same project.

The machines are not a fleet

Twenty-five machines sounds like a fleet. It is not. It is twenty-five individual negotiations.

Different vintages, different controllers, different firmware revisions of the same controller. Some expose a clean protocol. Some expose a protocol that is documented but implemented differently than the document claims. Some expose nothing useful at all, and the only honest signal available is a contactor you can watch.

Budget your time per machine, not per project. The twenty-fifth machine will not be faster than the first — it will be a different problem.

The easy signals are usually enough

There is a strong temptation to collect everything. Every axis position, every spindle load sample, every temperature, at the highest rate the controller will give you.

Resist it initially. For the first phase, the questions the plant actually wanted answered were:

• Is this machine running right now?
• How many parts has it made this shift?
• When did it stop, and for how long?

Those three questions carry most of the operational value, and they are answerable from low-rate, low-risk signals. High-frequency sensor capture matters later, when you are building condition monitoring on top. Starting there delays the moment the plant sees anything useful — and that moment is what buys you the trust to continue.

Data acquisition is a change-management project

The technical work was maybe half of it.

Automated acquisition changes what is visible. An operator who has been writing "running" on a sheet for years now has a screen that says the machine was idle for forty minutes. That is uncomfortable, and if it is introduced as a monitoring tool, it will be resisted — sometimes quietly and effectively.

What worked was framing it as a tool that answers the operator's own complaints. The system logs that the machine was waiting on material, so the argument about whether material is late becomes a question with an answer. Give people a reason to want the data to be accurate, and accuracy follows.

Design for the day the network is down

Factory networks fail in ways office networks do not. A welding rig starts up and a switch port drops. Someone patches a cable during a shutdown and a VLAN is different on Monday.

Every collection point buffers locally and forwards when the link returns. This was not an optimisation — it was the difference between a system the plant trusts and one it does not. The first time an outage produced a gap in the numbers, the reaction would have been "the system doesn't work", and that judgment would have stuck.

What it looks like now

Manual logging is gone. Machine status, throughput, and stoppages are visible live, on dashboards designed for control-room reading distance rather than desktop analytics. Problems surface when they happen rather than at end of shift.

Just as importantly, there is now a clean telemetry stream — the foundation that condition monitoring and predictive maintenance actually require. You cannot skip this layer. Models built on data nobody trusts produce predictions nobody acts on.

If I did it again

• Start with three machines, not twenty-five. Prove the path end-to-end first.
• Write the glossary before the code. Define "running", "idle", "part complete" with the people who use those words daily.
• Show the plant something useful within the first month, even if it is one line and three metrics.
• Assume every link fails and every machine is a special case. Both assumptions will be correct.