How CNC machine monitoring works: from controller to dashboard

Machine monitoring is the automatic collection of what your machines are doing — running, idle, in alarm — turned into numbers a human can act on: OEE, downtime by reason, parts produced against plan. The key word is automatic. If an operator has to write it down or click a button for the basic record to exist, it is a logbook with a screen, and it inherits every failure mode of a logbook.

What it is not: monitoring does not run your machines, does not change programs, and does not need to touch the control loop at all. Every serious system reads; none write. That distinction matters when IT and maintenance teams evaluate risk — see what your IT team will ask.

Everything on a monitoring dashboard traces back to one of three sources, and knowing which is which tells you how much to trust each number:

The best systems combine the first and third: the machine reports what happened automatically, and the operator adds why with two taps. The second source is a fallback for machines whose controllers cannot speak — useful, but a fallback.

How ThingConnect applies each method — including native FANUC/FOCAS integration, MTConnect, OPC UA, and digital I/O — is detailed in the connectivity hub.

The pipeline in a modern cloud-first system has four stages:

• Machines → gateway. A compact industrial gateway sits on the plant network and polls each controller in its own protocol. Machines never talk to the internet — only to this box, inside your firewall.
• Gateway → cloud. The gateway makes a single outbound, encrypted connection and streams events up. Outbound-only means no inbound firewall ports, which is the difference between a five-minute IT conversation and a five-week one.
• Buffering. When the internet drops — and in industrial areas it does — the gateway keeps collecting and stores locally, then syncs the backlog when the connection returns. No gaps in the record.
• Cloud → screens. Dashboards, andon boards, reports, and alerts are served from the cloud to any browser — the plant, the office, a phone. No server to maintain in the plant, and improvements arrive continuously instead of as annual upgrade projects.

For plants whose contracts or IT policy prohibit production data leaving the site, the same pipeline can terminate in an on-premise deployment instead of the cloud — typically an enterprise arrangement for larger fleets.

Notice how many of these exist only inside the controller. A power clamp can approximate the first row; nothing retrofit can produce the last four. That is the practical meaning of "depth of integration."

A stack-light tap or current clamp answers one question: is the machine drawing power? Everything else is inference, and the inference fails in familiar ways:

• Idle-in-cycle looks like running. A machine paused mid-program with the spindle warm draws power and shows a green light. Controller state says feed hold.
• Micro-stops vanish. The 30–90 second stops that add up to an invisible lost hour per shift are shorter than most power-inference smoothing windows.
• Slow running is invisible. A program running at 80% feed override is indistinguishable from one at 100% to a current clamp. The controller reports the override position directly.
• No part counts. Performance and quality — two-thirds of OEE — cannot be computed from an on/off signal, so they get estimated, and estimates drift toward optimism.

None of this makes retrofits useless — for a 25-year-old machine they are the only option, and knowing on/off beats knowing nothing. The mistake is building a whole plant's numbers on inference when most of the fleet could report the truth directly.

The technology part of a controller-native rollout is short: confirm each machine's controller model and network access, place the gateway on the plant network, map machines to it, and dashboards go live — days, not months, with no PC bolted to each machine and no wiring into cabinets for network-capable controllers.

The part that deserves the real attention is human: agreeing the downtime reason list (8–12 reasons, in the operators' own words), the shift and break policy (what counts as planned time — decide once, write it down, apply it everywhere), and ideal cycle times per part (from proven program times, not quotes). A vendor who deploys with you settles these in a working session; a courier-a-box vendor leaves them to become arguments later.

• "Show me live data from a controller like mine" — a demo on your controller generation, not a stock video.
• "Which of my signals do you read natively vs infer?" — ask per machine on your actual fleet list.
• "What happens during an internet outage?" — the answer should involve buffering, with a stated capacity.
• "Who does the connection work?" — you want engineers who deploy with you, not a shipped box and a wiki.
• "What does month 13 cost?" — subscription, per-machine, and what happens to your data if you leave.
• "Can operators use it in their first hour?" — if training takes a week, the floor will not use it in week two.