Application of the TDE industrial gateway in the acquisition of CNC equipment data

A TDE industrial gateway is a small industrial computer that sits between the machine control and your network. On one side it talks to the CNC over the control's native interface, usually Ethernet, RS-232, or a fieldbus. On the other side it speaks MQTT, OPC UA, or an HTTP API to a server or cloud broker. The gateway is not a sensor. It does not measure spindle vibration or coolant flow by itself.

That distinction matters during specification. When the Fanuc, Siemens, or Mitsubishi control already exposes a data port, the gateway reads registers and tags directly. No external sensor is mounted. When the control is older and closed, the gateway has to rely on PLC signals, current clamps, or relay contacts to infer cycle state. The two cases need different wiring, different tag maps, and different acceptance tests.

One unit usually covers one machine or a small cluster. The arm inside the cabinet is short, and running long serial cable across a shop floor invites ground loops. Wi-Fi is common for retrofit jobs, but a wired drop is still the default when the machine is stationary.

• 1
  Open controlGateway polls the control's data port directly. Cleanest tag set.
• 2
  Closed controlGateway reads PLC I/O or external sensors. Cycle state only.
• 3
  Mixed fleetOne gateway per protocol family keeps tag maps readable.

The protocol list determines whether the gateway is a drop-in or a project. Fanuc controls answer over FOCAS, and the gateway pulls tool offsets, spindle load, program number, and alarm codes from the same interface. Siemens 840D uses OPC UA or a proprietary port. Mitsubishi, Mazak, and Heidenhain each have their own dialect. MTConnect is the neutral option when you need one schema across a mixed floor.

For discrete signals, Modbus TCP and Modbus RTU still cover most older equipment. A gateway with two serial ports and one Ethernet port handles three generations of machinery in the same cell. OPC UA is the better choice when the data has to land in an MES or SCADA system that expects typed variables rather than raw registers.

Sampling is where most projects go wrong. Polling every 10 ms on a bus that also carries servo commands will cause timeouts and dropped frames. Match the poll rate to what the process actually needs. Spindle load for tool-wear tracking does not need faster than 100 ms. Alarm capture needs event-driven push, not polling.

• 1
  FOCASDirect read on Fanuc. Tool offsets, load, alarms.
• 2
  MTConnectOne schema across mixed brands. Extra translation layer.
• 3
  ModbusOld machines and PLC signals. Discrete and register data.
• 4
  OPC UATyped data into MES or SCADA. Heavier stack.

A gateway that forwards every raw sample will flood the network and the historian. Edge filtering is not optional on a real floor. The usual pattern is to buffer locally, compute a small set of aggregates, and publish only those. Average, minimum, maximum, and standard deviation over a one-second window cover most tool-wear and cycle-time questions.

Event-driven messages handle alarms and state changes better than polling. When the control raises an alarm code, the gateway pushes it once with a timestamp. That record is small and worth keeping forever. Continuous spindle-load curves are large and usually only worth keeping at reduced resolution after a few weeks.

Store-and-forward matters when the network drops. A gateway with local storage keeps buffering during an outage and replays when the link returns. Without that buffer, a five-minute network fault leaves a hole in the cycle-time record and the shift report cannot be trusted.

• 1
  Aggregate firstPublish 1 s windows, not raw samples.
• 2
  Push eventsAlarms and state changes go immediately.
• 3
  Buffer locallySurvive network outages without data loss.

Cycle-time data answers the first practical question: which machine is actually the constraint. Once the gateway reports cycle start and cycle end reliably, the gap between scheduled and actual run time becomes visible per machine and per shift. That gap is usually larger than expected and often sits in setup, not in cutting.

Spindle-load trends support tool-wear decisions. A gradual rise in load at the same program and material points to edge wear or chip packing. The threshold is machine-specific, so the first weeks of data are calibration, not control. After that, a load alarm can trigger a tool change before a surface-finish problem appears on the part.

Alarm history is the cheapest win. Grouping alarm codes by machine and by shift shows which faults repeat and which are one-off. A repeated servo overload on one axis is a maintenance signal, not a data problem.

• 1
  Constraint findingActual run time versus scheduled, per machine.
• 2
  Tool-wear trendLoad rise at fixed program and material.
• 3
  Alarm groupingRepeat faults by machine and shift.

The gateway does not replace a vibration analyzer or a spindle-mounted accelerometer. If the goal is chatter detection or bearing-fault diagnosis, the sampling rate and sensor placement are wrong for a gateway that polls control registers. Buy the right instrument instead.

A single machine with one operator who already logs cycle times on paper does not need a gateway. The setup cost, tag mapping, and network change will exceed the value for a long time. Start where the machine count and the shift pattern make manual logging unreliable.

Finally, the gateway is not a security appliance. It should sit on a segmented network with a firewall rule that allows only outbound traffic to the broker. Data diodes and one-way gateways exist for a reason, and a gateway with a full TCP stack is not one of them.

• 1
  Not for diagnosticsChatter and bearing faults need dedicated sensors.
• 2
  Not for one machineSetup cost beats the value at very small scale.
• 3
  Not a firewallSegment the network and restrict outbound traffic.