How to Gather Machining Data From CNC Machines

• 1
  Key takeaways
• 2
  What data you actually need to gather machining data from CNC
• 3
  Pull built-in data from the CNC controller first
• 4
  When to add IIoT sensors instead of relying on the control
• 5
  Wire a DAQ system that survives a machine shop
• 6
  Move data into MES or ERP without losing meaning
• 7
  Step by step: gather machining data from CNC in 7 steps
• 8
  Which CNC data collection method fits your machines

Most shops start by asking which sensors to buy. That is the wrong first question. Write down the three decisions you want to make with the data. Typical answers: catch a tool before it breaks, explain why a cycle ran 22% long, and prove to a customer that a critical dimension held. Each decision needs different signals, different sample rates, and a different retention window.

For tool-life decisions, spindle load and program segment number are enough on most jobs. For cycle-time decisions, you need program number, feed override, rapid position, and alarm history from the controller. For quality evidence, the data comes from the inspection side, not the spindle: CMM results, in-process gauging, or a recorded final inspection with the part serial number.

Once the decisions are written down, the signal list usually shrinks. Shops that skip this step end up with 40 tags streaming into a database and nobody looking at them. A 6–10 tag set that someone checks every morning beats 40 tags that nobody owns.

One more constraint: data you cannot tie to a part number or work order is nearly worthless later. Decide how the machine will know which job is running before you install anything. On most controls that means reading the active program name, or asking the operator to scan a traveler at setup.

Modern controls are the cheapest data source you have. Fanuc FOCAS, Siemens 840D via OPC UA or the 828D interface, Haas MNet, and Mitsubishi CNC-Net all expose spindle speed, feed rate, override percentages, program number, block number, tool number, and alarm codes. None of it requires opening the electrical cabinet.

On a Fanuc 0i or 31i, FOCAS over Ethernet gives you a polling interface. Read spindle load, axis positions, and the alarm list on a 1–5 second cycle. That rate is fine for utilization and cycle-time work. It is too slow for chatter detection, so do not try to stretch it.

The main limitation is age. Machines older than roughly 10–12 years often have a serial port or no port at all, and the vendor library may not support your control revision. Check the software option list before promising a customer that a 2008 lathe will report live data.

Controller data also stops at the cabinet door. Coolant flow, coolant temperature, hydraulic pressure, and ambient humidity are invisible to the control. If your process drifts because the coolant concentration drops, the controller will not tell you.

• 1
  FanucFOCAS library over Ethernet; poll at 1–5 s for utilization and cycle time.
• 2
  SiemensOPC UA server on 840D sl; tag browse is straightforward, no vendor DLL.
• 3
  HaasMNet or the Haas API; good for job status and alarm text.
• 4
  Legacy controlsCheck option bits and port type first; budget for a gateway if the port is RS-232 only.

Add sensors when the control cannot see the variable that is hurting you. Three cases come up again and again. First, tool condition on deep pockets or hard materials, where spindle load is masked by the rest of the cycle. Second, thermal drift, where the part grows 8–12 μm over a long run and nobody knows why. Third, coolant health, where concentration and flow fall off between maintenance days.

A clamp-on current transformer on the spindle motor feed is the least invasive retrofit. It gives a usable load proxy in about an hour per machine and needs no PLC change. Accuracy is coarse, maybe ±5%, but it is enough to see a tool loading up.

For vibration, mount a piezoelectric accelerometer on the spindle housing or the fixture, not on the sheet-metal cover. Cover panels ring at their own frequency and you will chase the wrong peak. A 100 mV/g sensor with a 10 kHz bandwidth covers most milling chatter and broken-tool events.

Temperature and flow sensors are cheap and slow. A PT100 or thermocouple on the coolant tank and an inline flow meter on the return line will explain a lot of dimensional drift for a few hundred dollars per machine. Sample these at 0.1–1 Hz.

Rule of thumb: if the controller already reports it, do not duplicate it with a sensor. Duplicated signals cost money and create two versions of the truth that will disagree during a customer audit.

DAQ hardware in a shop has to deal with 24 V inductive loads, coolant mist, and vibration. That rules out hobby boards in an open enclosure. Use a device with channel-to-channel isolation, screw terminals or spring cages, and a DIN-rail mount inside a sealed box.

For slow signals, a 16-bit module at 10–100 Hz per channel is plenty. For accelerometer channels, you need simultaneous sampling at 10–50 kHz per channel, which means a separate high-speed card or a dedicated vibration module. Do not multiplex a vibration channel; the phase error kills your analysis.

Cable routing matters more than people expect. Run sensor cable in a separate tray from 3-phase motor cable, cross at 90°, and use shielded twisted pair with the shield grounded at the DAQ end only. A 4–20 mA loop is more noise-tolerant than a 0–10 V signal over distances beyond roughly 3 m.

Power the DAQ from a separate circuit from the spindle drive if you can. Shared circuits put switching noise straight onto your analog inputs, and the symptom looks like random spikes that only appear during acceleration.

• 1
  Slow channels16-bit, 10–100 Hz, isolated, for temperature, flow, and pressure.
• 2
  Fast channelsSimultaneous sampling at 10–50 kHz for vibration and spindle current.
• 3
  Signal typePrefer 4–20 mA over 0–10 V beyond 3 m of cable.
• 4
  ShieldingGround the shield at the DAQ end only; cross power cable at 90°.

Raw tags are not useful to production planning. Before data leaves the machine, map each tag to a name a planner understands: WorkOrderID, PartNumber, CycleTimeActual, ToolID, ScrapReason. If a tag name is C1_AI_17, nobody will use it.

Use OPC UA as the transport where you can. It carries data types and units, so a temperature tag arrives as a float in °C rather than a raw integer that someone has to scale correctly in three different places. MQTT is a good fit when you have many machines and a lossy network, but you must define the payload schema yourself.

Timestamp at the edge, not at the database. If the DAQ or gateway stamps the sample when it is read, you keep the true sample time even when the network is down and the buffer flushes later. Add the machine ID and the part number at the same moment.

Keep raw data for 30–90 days and push 1-minute or per-cycle aggregates to MES for the long term. This keeps database growth predictable and keeps the operator-facing screens fast. In our own plants we run 127 high-precision CNC machines, and the difference between a usable dashboard and a dead one has always been the aggregation policy, not the hardware.