What actually happens when a machine is connected.
One data point followed from spindle to screen: what is read, why the timestamp step matters more than the rest, and the four ways collection quietly goes wrong.
This article follows a single data point from the machine to the screen. It is deliberately non-technical: if you want sampling intervals and timestamp integrity, read CNC machine data acquisition instead. If you want to know what is actually happening when someone says a machine is 'connected', start here.
From spindle to screen.
The important step is the third. A reading timestamped where it occurred survives a network interruption; a reading timestamped on arrival produces a timeline that looks plausible and is wrong after every reconnection.
For a CNC that can be read over the network, the useful material is machine state — running, idle, stopped — along with cycle timing, part counts and whether an alarm condition is present. Where the control and its options allow, operator login can be included so activity is attributable.
For machines that cannot be read, the same picture is assembled from discrete signals. A contactor tells you the drive is energised; a counter tells you a part completed; a stack light tells you the machine is calling for attention. Less detail, same shape.
What is deliberately not collected is anything the plant has not agreed to. There is no program content, no drawing data and no write access. Integration is read-only in both directions of that phrase: the system reads, and it does not act on the machine.
Two ways data leaves a machine, and why it matters to you.
| Model | How it works | Where you see it | Practical consequence |
|---|---|---|---|
| Polled | The monitoring system asks the machine at a set interval | Most CNC controls and Modbus devices | Resolution is bounded by the interval. Events shorter than it can be missed unless the machine latches them. |
| Event-driven | The machine or device reports when something changes | Digital inputs on a gateway; some modern interfaces | Better resolution for short events, at the cost of needing somewhere reliable to send them. |
| Hybrid | Frequent polling for state, event capture for edges | Typical of a mixed floor | What most real deployments end up doing, because machine populations are mixed. |
The interval is too coarse
A six-second stop on a machine polled every ten seconds may never appear. On floors where micro-stops matter, this is the difference between finding the loss and missing it.
Timestamps applied on arrival
Any network hiccup shifts events. The record looks continuous and is quietly wrong, which is worse than an obvious gap.
No buffering at the edge
A switch reboot becomes a hole in the day. Data held locally until the server acknowledges it removes the whole class of problem.
Counts inferred rather than counted
Where a real counter exists, use it. Inferred counts are estimates and should be labelled as such in any report that leaves the plant.
Three questions separate a serious answer from a demonstration. What is the sampling or polling interval, and is it configurable per machine? Different machines justify different intervals. Where is the timestamp applied? There is only one right answer. What happens to data during a network interruption? If it is discarded, your timeline has holes exactly when the plant was busiest.
None of these questions require you to know how any specific control works. They are about the integrity of the record, which is the part you will rely on when the number is disputed.