What Are the Functional Characteristics of a CNC Machine Tool Data Gateway

• 1
  How a CNC machine tool data gateway actually gets its data
• 2
  Protocol coverage and edge buffering are the first two functional characteristics
• 3
  Data normalization and machine state logic separate good gateways from bad ones
• 4
  Security and network isolation are the fifth functional characteristic
• 5
  When a CNC machine tool data gateway is the wrong tool
• 6
  Matching gateway capability to shop size and goal

A gateway is not a sensor package. It is a protocol translator plus a small historian. On a Fanuc control it opens FOCAS over Ethernet and polls registers that already exist: spindle load, axis position, program number, tool offset, alarm codes. On a Siemens 840D it reads the OPC UA server built into the control. On a Mitsubishi or Mazak it may need MTConnect or a vendor adapter.

None of this touches the servo loop. The gateway is a client. It asks the control for values the control already computed for its own display. That is why a gateway install does not change cycle time, feed rates, or tool life. If a vendor claims the gateway will optimize your cutting, ask which register it writes to. Usually the answer is none.

The polling rate matters more than most buyers expect. A 100 ms poll is fine for utilization and OEE. It is not fine for capturing a 40 ms spindle overload or a tool break. For event-level data you need the control to push, not the gateway to pull. That means alarm bits and PLC signals read at 10–20 ms, or a hardware tap on the I/O.

Data volume is modest. A single machine at 10 ms polling with 30 tags produces roughly 3,000 samples per second. Before compression that is about 100 MB per day per machine. A shop with 40 machines is looking at 4 GB per day. Plan storage and network bandwidth for that number, not for the marketing slide.

• 1
  Read-only by defaultThe gateway should never write to the control without a documented, locked procedure.
• 2
  Poll rate sets the use case100 ms for OEE; 10–20 ms for tool break and overload events.
• 3
  One protocol per familyFOCAS, OPC UA, MTConnect cover most installed controls.

Protocol coverage decides whether the gateway works on your floor at all. A gateway that speaks only MTConnect will not read a 1990s Fanuc 0M without a hardware adapter. A gateway that speaks only FOCAS will not read a Heidenhain TNC. Count your control families before you count features. Mixed shops usually need two or three protocols, not one.

Ask for the exact tag list per protocol. 'Supports FOCAS' can mean 8 tags or 400 tags. The useful set for a job shop is spindle speed, feed override, program name, cycle state, alarm number, tool number, part count, and axis load. If the gateway cannot expose feed override and program name, you cannot build a real OEE model.

Edge buffering is the second characteristic and the one most often missing. Networks drop. A gateway with 8 GB of local storage keeps writing during an outage and replays when the link returns. A gateway with no buffer loses that window forever. For a shop that runs unattended night shifts, buffer capacity is not optional.

Check the replay behavior, not just the capacity. Some gateways replay with original timestamps. Others stamp everything with the recovery time. The first is usable for OEE. The second corrupts your downtime analysis. Ask the vendor to show a 30-minute disconnect test with the resulting data file.

• 1
  Count control families firstFOCAS for Fanuc, OPC UA for Siemens, MTConnect as a fallback.
• 2
  Demand the tag listFeed override and program name are the two tags most often missing.
• 3
  Test the replayOriginal timestamps, not recovery timestamps, or downtime math breaks.

Two machines from different builders do not report the same way. One says state 3 is running. Another says state 3 is alarm. Normalization is the gateway's job. It maps every control's raw codes to one internal model: running, idle, alarm, setup, maintenance, off. Without this, your MES gets a spreadsheet of codes and no dashboard.

The hard part is not the mapping table. It is the ambiguous states. A machine in a tool change with the spindle stopped is not idle. A machine running a warm-up program is not producing. Good gateways let you write rules for these cases and see which rule fired. Bad ones force you to pick one code per state and live with the error.

Machine state logic also drives your OEE denominator. If the gateway calls a 20-minute setup 'idle,' your availability number is wrong by that amount every shift. Over a month that is hundreds of hours of phantom downtime. Engineers who trust the dashboard without auditing the state rules get burned once and then stop trusting it.

A practical check: pull one week of raw state transitions for one machine and count how many seconds sit in each state. If setup time looks like zero, your rules are too simple. Setup is real, it is just not a code the control emits by itself. The gateway has to infer it from program number changes and door signals.

• 1
  One internal state modelMap every control to running, idle, alarm, setup, maintenance, off.
• 2
  Rules must be auditableYou need to see which rule classified a given interval.
• 3
  Setup is inferred, not reportedProgram change plus door signal is the usual trigger.

A gateway is a computer on your OT network with a path to your IT network. That path is the risk. The correct architecture is one-way or tightly filtered: the gateway reads from the machine VLAN and publishes to a DMZ broker. Nothing on the IT side should be able to open a session back into the control.

Physical ports matter too. Many controls still run Windows CE or an old Linux build with no patch path. If the gateway sits on the same flat network as the office, a single phishing email can reach a 15-year-old control. VLAN segmentation and a firewall rule set are not optional extras. They are part of the gateway scope.

Credentials should be per-gateway, not shared. When a technician leaves, you rotate one credential, not the shop-wide password. Log every configuration change with a timestamp and a user. If your gateway cannot tell you who changed a tag mapping last Tuesday, it is not ready for a regulated environment.

For medical and automotive work, this links to your quality system. ISO 13485 and IATF 16949 both expect traceable records. Data pulled from a gateway into a batch record inherits that requirement. Keep the gateway's own audit log, and keep it for the same retention period as your inspection records.

• 1
  One-way by defaultMachine VLAN to DMZ broker; no inbound session to the control.
• 2
  Segment legacy controlsWindows CE controls belong behind a firewall, not on a flat network.
• 3
  Per-gateway credentialsRotate one credential, not the shop-wide password.

If your goal is to prove a specific part dimension, a gateway will not help. It reads machine state, not metrology. Use a touch probe or a CMM. A gateway can tell you the probe ran. It cannot tell you the feature is in tolerance. Keep those two systems separate.

If you have three machines and one shift, a gateway is often overkill. A clipboard and a manual log cost less and get read more often. The math changes around 10–15 machines, or when you need unattended shift data, or when a customer contract requires traceable machine records. Below that, the integration cost usually exceeds the benefit.

If the control has no data port and no PLC that can be tapped, the gateway becomes a retrofit project. You may need an I/O module wired to the stack light and the cycle-start relay. That works, but it gives you coarse states only: running, stopped, alarm. No program name, no feed override, no tool data. Decide whether coarse data solves your problem before you spend on a retrofit.

If the vendor cannot show you a live tag list from a control like yours, walk away. A demo on a lab machine with a modern control proves nothing about a 2011 VMC with a Fanuc 0i-MD. Ask for a site test, or at minimum a recorded session from a comparable control.

• 1
  Not metrologyMachine state data cannot prove a dimension.
• 2
  Below 10 machinesManual logging is often cheaper than integration.
• 3
  No port, no tagsStack-light retrofits give coarse states only.