Edge Computer Gateway Application in the Acquisition of CNC Machine Tool Data

• 1
  What decides success before you buy hardware
• 2
  What an Edge Gateway Actually Does with CNC Machine Tool Data
• 3
  Interfaces: What Each Control Family Gives You
• 4
  Choosing Signals: Which CNC Machine Tool Data Earns Its Bandwidth
• 5
  Sampling Rate, Network, and Time Sync
• 6
  Where the Edge Gateway Approach Does Not Fit
• 7
  Interface Options at a Glance

An edge computer gateway sits between the control and the network. It reads registers, counters, and program state from the CNC, normalizes them into a common model, and forwards them upstream. It is not a historian and it is not a PLC. Its job is translation and buffering at the point where the machine meets the plant network.

The distinction matters because most failures blamed on 'the gateway' are actually source problems. If the control exposes only a serial port running a proprietary protocol, the gateway can still read it, but at a slower rate and with fewer tags. If the control has no external data option fitted, no gateway on the market will help.

In practice, one gateway covers one to eight machines. Beyond that, the CPU load from protocol parsing and the Ethernet run length start to work against you. Splitting into two gateways is usually cheaper than buying a faster box.

• 1
  ReadPoll registers or subscribe to a data stream from the control.
• 2
  NormalizeConvert vendor tags into one namespace with fixed units.
• 3
  BufferHold 4–24 hours locally so a network drop does not lose data.
• 4
  PublishSend upstream over OPC UA or MQTT at the rate the consumer needs.

FANUC controls with the Ethernet option expose FOCAS, which returns spindle speed, load, feedrate, program number, tool number, and alarm history at roughly 10–100 ms depending on how many tags you poll. Polling 40 tags at 50 ms is realistic on a modern 0i or 30i series. Polling 400 tags at 10 ms is not.

Mitsubishi and Mazak typically need MTConnect or a vendor adapter. MTConnect gives you a clean, XML-based stream with a defined schema, which is why it maps well to dashboards. The trade-off is latency: agent-based collection often lands in the 100–500 ms range unless you tune the adapter.

Siemens 840D and similar controls speak OPC UA natively on newer builds. That removes the translation step entirely and is the cleanest path if your fleet is mostly Siemens. Older 810D and 840D sl builds may need an option license before the server starts.

The uncomfortable case is a control with no Ethernet port and no fieldbus card. Some builders charge a license fee to enable the data interface. That last point is worth checking against the machine's option list before you commit to a gateway model.

• 1
  FOCASFast, tag-rich, FANUC only. Needs the Ethernet option.
• 2
  MTConnectVendor-neutral schema. Agent adds 100–500 ms latency.
• 3
  OPC UANative on newer Siemens. No adapter, lowest overhead.
• 4
  Modbus TCPCommon on older mills. Limited to what the PLC exposes.

Start from the decision you want to make, then work backward to the signal. Tool wear prediction needs spindle load and cutting time at 50–100 ms. OEE reporting needs run state, cycle count, and stop reason at 1 s. Quality trending needs axis following error and coolant state, which most controls expose only as alarms.

A common mistake is to collect everything a control will give you. A 5-axis machine with 400 tags at 100 ms produces about 4,000 values per second. Multiply that across 20 machines and you have a network problem, a storage problem, and a dashboard nobody reads.

Pick 15 to 40 tags per machine. If a tag does not feed a report, an alarm, or a model, leave it out. You can always add it later; removing a tag after eighteen months of data collection is harder because people build habits around it.

• 1
  Tool wearSpindle load, feed override, cutting time. 50–100 ms.
• 2
  OEERun state, cycle count, stop code. 1 s is enough.
• 3
  Process driftAxis load, temperature, coolant pressure. 200–500 ms.
• 4
  MaintenanceAlarm history, servo current, lube cycle. On change only.

Sampling rate sets your data volume, and data volume sets your cost. At 100 ms with 30 tags, one machine produces about 300 values per second, or roughly 26 million values per day. Compressed and stored as deltas, that is manageable. Stored raw, it is not.

Use deadband filtering on analog tags. Spindle load that moves less than 2 percent does not need to be sent. This alone can cut upstream traffic by 60 to 80 percent on a stable process without losing the events you care about.

Time sync matters more than most teams expect. If the gateway clock drifts from the control clock, cycle times look wrong and event sequences scramble. Point the gateway and the control at the same NTP source and check the offset monthly. A drift of two seconds is enough to make a stop-reason report useless.

• 1
  DeadbandSuppress analog changes below 2 percent of range.
• 2
  NTPSame source for control and gateway. Check monthly.
• 3
  Buffer depth4–24 hours local queue for network outages.

If the control has no data port and no option card, stop. A protocol converter or an option license may be needed, and in some cases the builder never offered one for that model. No port and no option means a closed control, and no amount of edge hardware fixes it.

If you need sub-millisecond synchronization across axes for motion analysis, an edge gateway is the wrong layer. That work belongs on the drive bus, not on Ethernet. Gateways are for production data, not for servo tuning.

If the plant network is a flat, unmanaged switch fabric with no segmentation, adding twenty gateways will expose that weakness fast. Plan VLANs and a separate data path before you scale past a pilot cell.