CNC Machine Tool PLC Data Gateway

• 1
  Key takeaways
• 2
  How a CNC Machine Tool PLC Data Gateway Reads a Machine
• 3
  Which Signals Are Worth Collecting on a CNC Machine Tool PLC Data Gateway
• 4
  Where a CNC Machine Tool PLC Data Gateway Stops Working
• 5
  Sampling, Buffering and Data Quality on the Gateway
• 6
  Why Machining Suppliers Care About Gateway Data
• 7
  Choosing a Gateway Approach by Machine Age and Protocol

A machine tool already knows almost everything about itself. The NC kernel tracks axis position, feed override and program number. The PLC tracks door state, hydraulic pressure, chip conveyor, tool changer step and alarm words. None of that is designed to be read by an outside system, which is the whole problem a gateway solves. It sits on the machine network, polls the addresses the builder exposes, and republishes them in a form your MES, historian or OEE dashboard can consume.

The read itself is boring when the protocol is documented. On a FANUC control you might poll a set of data window registers or use FOCAS. On Siemens you read over PROFINET or OPC UA. On Mitsubishi and many older machines it is MC Protocol over TCP, or a serial link at 9,600 to 115,200 baud. The gateway translates each of these into one internal tag namespace, so the rest of your plant talks to one interface instead of nine.

What makes it engineering rather than plumbing is timing and meaning. A status bit is only useful if you know what it represents on that specific machine, at that firmware revision. A spindle load value means nothing until someone records what 100 percent looks like during a known cut. The gateway moves the bytes. Your tag dictionary decides whether those bytes become an actionable signal or a number nobody trusts.

Latency is bounded by the slowest link in the chain, and that is usually the PLC scan plus your poll interval, not the Ethernet cable. A 20 ms scan with a 200 ms poll gives you roughly 200 to 220 ms of staleness. For OEE and part counting this is invisible. For closed-loop control it is far too slow, and the gateway is the wrong tool.

• 1
  Poll, do not interceptPassive reads on documented addresses avoid interfering with the control loop.
• 2
  One namespaceMap every controller into the same tag naming scheme before you scale past a few machines.
• 3
  Record contextStore program number and tool number alongside the value, or the number loses meaning.

The practical limit is not bandwidth, it is ownership. Every tag you publish needs a name, a unit, a scaling rule and someone who will act when it moves. Teams that skip that step end up with a dashboard nobody opens. A defensible starting set is small: machine state, program number, cycle count, alarm code, spindle load and axis position for the part-critical axes.

Machine state is the tag people argue about most. Builders use different words for running, feed hold, optional stop, alarm and idle. If you map them freely you will get nonsense OEE. Define a fixed state model first, then write the per-machine mapping. Most controls expose an autostatus or run-status word that gives you the raw bits; the gateway should publish the raw value and the interpreted state side by side.

Alarm codes are high value and easy to get wrong. Read the alarm number and the alarm text if the control exposes it, and timestamp both at the gateway, not at the database. Clock drift between the machine and the server will otherwise corrupt every duration calculation you build later.

Position data is where people overreach. Streaming axis position at 100 Hz across 30 machines will flood your network and tell you little. If you need position, decide the question first: setup verification, thermal drift, or collision forensics. Each has a different sample rate and a different storage policy.

• 1
  Start with 20 to 40 tagsEnough for OEE and alarm history, small enough to keep the mapping honest.
• 2
  Keep raw and derived separatePublish the raw register and the interpreted value, so you can re-derive later.
• 3
  Timestamp at the sourceGateway timestamps survive clock drift better than server-side ones.

The gateway is a read-and-forward device. It is not a safety system, not a real-time controller and not a substitute for the machine's own interlocks. If a signal needs a response inside one scan cycle, it belongs in the PLC logic, not in an external gateway. Putting a network hop into anything that stops an axis is a design error you will regret at the worst moment.

Older machines are the other boundary. A control from the 1990s may only expose a serial port with a proprietary frame format, or nothing at all. In that case the honest answer is often a hardware retrofit: read the I/O directly, or add a signal tower sensor and count light states. That gives you less data but it is reliable, and it does not require reverse-engineering a protocol the builder never documented.

Network segmentation matters more than people expect. Machine networks on flat plant VLANs are common, and a gateway with a misconfigured IP can knock a machine offline. Put gateways on their own VLAN, allow only the outbound flows they need, and keep a documented rollback. A gateway that takes production down is worse than no gateway.

Finally, there is the maintenance question. Firmware updates, certificate renewals and tag changes all need an owner. Gateways that nobody owns silently stop publishing after a network change, and you find out three weeks later when the OEE report looks suspiciously flat.

• 1
  Not for closed loopIf the response must beat one scan cycle, keep it inside the PLC.
• 2
  Retrofit beats guessworkFor undocumented legacy controls, sensors are often cheaper than protocol archaeology.
• 3
  Assign an ownerEvery gateway needs a named person for firmware, certificates and tag changes.

Poll interval is a budget you spend. Two hundred milliseconds is a good default for state, counters and alarms. One second is fine for temperatures and pressures. Anything below 50 ms should justify itself with a specific engineering question. Increasing poll rate multiplies network traffic, gateway CPU and database writes at the same time, so the cost is not linear in usefulness.

Change-of-value reporting is the single biggest saving. If a tag has not moved, do not send it. Keep a heartbeat so the consumer knows the gateway is alive, and send a full snapshot on reconnect. This alone can cut traffic by more than 90 percent on a typical machining cell, where most tags sit still for minutes at a time.

Buffering is what keeps data intact through network drops. A store-and-forward queue on local storage lets the gateway keep collecting during a switch reboot or a server restart, then replay in order. Size the buffer for the longest outage you are willing to lose, and monitor queue depth as a health metric. A queue that only ever grows means your consumer is falling behind.

Quality flags belong on every record. Mark values as good, stale or bad at the gateway. A stale value that looks good will quietly poison weeks of analysis, and you will not notice until someone questions a number in a meeting.

• 1
  200 ms defaultFast enough for OEE and counters, cheap enough to run across a whole shop.
• 2
  Send on changeHeartbeat plus change-of-value cuts traffic far more than compressing payloads.
• 3
  Flag stale dataA timestamp older than two poll intervals should be marked stale, not good.

For a contract machining supplier, gateway data answers customer questions that used to be guesswork. Which machine ran a given part number, at what cycle time, and did it alarm mid-run. If a dimensional issue appears on a batch, the timeline of program number, tool change and spindle load is far more useful than a paper traveler.

At GreatLight we run 127 high-precision CNC machines across 3 wholly-owned plants, including 16 simultaneous 5-axis machining centers and 16 mill-turn centers, with a maximum processing size of 4,000 mm. On work like aerospace brackets, medical instrument housings and EV drivetrain parts, the useful data is usually narrow: which program revision ran, how long the cycle took, and whether an alarm interrupted it.

The traceability requirement drives tag choice more than the analytics do. If a customer asks for process evidence on a lot, you need program number, machine ID and timestamp bound to the inspection record. That is a small tag set, but it has to be reliable and it has to be retained. Everything else is optional.

The same logic applies to inspection data. We inspect 100 percent of parts before shipment and can supply reports on request, and tying those reports back to a machine timeline is where gateway data earns its keep. It turns a shipment record into a process record.

• 1
  Traceability firstProgram number, machine ID and timestamp bound to the lot are the core requirement.
• 2
  Analytics secondOEE and utilization are useful, but they come after the traceability chain works.