How to Connect CNC and Legacy Machines to ERP

A shop-floor reference guide for connecting CNC and legacy machines to an ERP. Its tables cover the data each machine type can share and the usual collection path, compare MTConnect with OPC UA, and separate ERP events from signals that stay local. It explains how a machine count becomes an ERP quantity, with quality confirmation, work-order matching, resets and network outages accounted for, then closes with basic CISA-aligned security checks and a machine inventory template for a small pilot.

Connecting a machine to your ERP (enterprise resource planning system) does not mean streaming its signals into the ERP. It means sending a small set of events and counts: a cycle completed, the part count, when the machine ran or stopped, and which alarm stopped it. Spindle load, axis positions and temperatures stay on the shop floor.

That makes the work mostly a survey: what each machine can share, how that data is usually collected, and which part of it the ERP needs. Keep these tables open while you walk the floor. The last one is a blank inventory sheet.

For CNC (computer numerical control) machine data collection, start at the machine, not in a software catalog. Read the control model and software version on the control’s screen. Look on the cabinet for an Ethernet port or a 9- or 25-pin serial port. Then ask the dealer which data options are installed, since some interfaces must be ordered or switched on.

What you find on the machine	What you can usually read	How it is usually collected
Newer CNC control with MTConnect, built in or installed as an option	Run state (MTConnect calls it Execution), mode, active program, part count, spindle speed and load, alarms	A client sends web (HTTP) requests to the machine’s MTConnect agent; usually no extra hardware
Newer CNC control or PLC (programmable logic controller) with an OPC UA (OPC Unified Architecture) server	Whatever the server exposes. Machine tools that follow OPC 40501 share a common set: identity, state, jobs, tools, errors and warnings.¹	An OPC UA client with a read-only account
CNC with Ethernet but only the control maker’s own protocol, such as FANUC FOCAS	Axis and spindle data, alarms and operator messages, program files, tool life, diagnostics²	An adapter: software that reads the vendor protocol and passes the values on as MTConnect or OPC UA³
PLC-run equipment: presses, ovens, washers, robot cells	PLC tags or registers, such as cycle done, counts, faults and temperatures	The PLC’s own protocol (Modbus TCP, serial Modbus RTU or EtherNet/IP⁴) or its OPC UA server. Get the tag list or register map first.
Older CNC with only an RS-232 serial port, used for DNC (direct numerical control) program transfer	Programs only, unless the program prints data: a macro print command (DPRNT on FANUC controls) can send a line such as a part count at each cycle end	A serial-to-Ethernet converter or the DNC computer captures those lines
No usable port: manual machines, relay logic, very old controls	Running, idle or off; stack-light color; cycle or part counts	Discrete I/O (input/output) and add-on sensors: a digital input wired to a cycle-end relay or the stack-light lamps, a current clamp on the main motor cable, a vibration sensor, a proximity switch on a chute

What a control shares depends on its model, software version and options, so treat the middle column as a starting list. The quickest test for MTConnect is a browser: if the machine runs an agent, its /current page shows the latest values.⁵

The last two rows are where legacy machine integration needs extra hardware. Add-on sensors work from outside the control, so they fit any machine. They give states, run time and counts, but never program names or alarm text. Add a stop reason the operator picks on a tablet, and you also get downtime by reason.

A camera aimed at the stack light or the door can classify state too; Video Analytics vs Machine Vision explains which camera setup fits which job. Anything mounted inside an electrical cabinet is work for a qualified electrician.

MTConnect vs OPC UA

A newer control may offer one of these standards or both. MTConnect, from the MTConnect Institute, is a data dictionary and a read-only interface for manufacturing equipment. Its latest released edition is Version 2.7, adopted on 16 February 2026.⁶ OPC UA, from the OPC Foundation, is a general industrial protocol that reads, writes and secures the connection itself.⁷

	MTConnect	OPC UA
Built for	Manufacturing equipment: machine tools, ovens, sensor units, bar feeders³	Industrial devices of all kinds, from microcontrollers and PLCs to cloud servers⁷
Direction	Read-only: a request has no side effects on the agent or the machine³	Reads and writes current and historical data⁷
How a client gets data	Web requests to an agent: /probe lists what the machine has, /current returns the latest values, /sample returns a time series. Answers come as XML; the Institute’s open-source C++ agent can also return JSON.³⁵	A client-server session, or publish-subscribe⁷
Data model	One dictionary for all equipment, with names such as Execution, PartCount and Program, and alarms reported as Conditions	Any model. Companion specifications fix one per industry, such as OPC 40501 for machine tools.¹
Security	Read-only, so a client cannot change the machine. HTTPS is allowed.³ Keep the agent on the machine network.	X.509 certificates for each client and server, signed and encrypted messages, an access audit trail⁷

The two also overlap. In 2019 a joint working group of the OPC Foundation and the MTConnect Institute released a companion specification that applies the MTConnect data model to OPC UA.⁸

The practical rule: use whichever your control offers with the least setup, and ask software vendors which of the two they read for your control. On a CNC whose agent already answers in a browser, MTConnect is the quicker start. On a robot cell whose PLC already serves OPC UA to a SCADA (supervisory control and data acquisition) system, stay with OPC UA.

What goes to the ERP and what stays local

The ERP plans and costs work orders. It needs to know when an operation ran, how many good and scrap parts it made, and why the machine stopped. Anything faster than that belongs in a local database next to the machines.

Data	How often it changes	What the ERP receives
Cycle complete and part count	Once per cycle	Counts per operation, summed per job or shift; good quantity once it is confirmed (see the next section)
Job start and end, tied to a work order operation	A few events per job	Actual start, end and run time on the production confirmation
Run and stop changes, alarms	Each time they change	Stop records (start, end, alarm or operator reason), summed as downtime minutes by reason
Scrap and its reason	When an operator records it	Scrap quantity with a reason code
Polled state, spindle load, feed override, temperatures, axis positions	Every second or faster	Nothing: these stay in the local database and dashboards

One value logged once a second makes 86,400 rows a day, per signal, per machine.

A small stack sits between the machines and the ERP. An edge gateway, a small industrial PC at the cell, reads each machine in its own protocol. It adds time stamps and can buffer readings already collected from the machines while the connection to the ERP is down. Gaps on the machine-to-gateway link still need reconciliation. Some setups also publish the values to an MQTT broker, a lightweight publish-subscribe hub, so several programs can use them.⁹

A local database keeps the raw values and the stop records. A small service then posts summaries to the ERP through its API (application programming interface), an import table or a scheduled file. If you run an MES (manufacturing execution system), stop records may go there first.

None of these parts has to come from the machine builder, which keeps a machine-to-ERP integration vendor-neutral. Once the ERP holds job times, counts and stops, reports can come straight from its exports, as How to Automate Production Reports from ERP Exports describes.

From a machine count to an ERP confirmation

A count on a control is not a production confirmation. Four things have to be settled before the ERP books a quantity against a work order.

What the control actually counts. MTConnect defines part counts and cycle counts as separate observation types, each with its own subtypes, among them ALL, GOOD and BAD; a count published without a subtype means ALL.¹⁰ A cycle is not a part, since one cycle may yield several parts or several cycles one part, and a count that means ALL is production, not good production. Read the agent’s /probe response, or the PLC tag list, to see which counts your control publishes, and ask the builder what each one increments. Where a control does publish a GOOD count, find out which rule sets it before you treat it as good quantity.

Who confirms quality. Good quantity comes from whoever judges the parts: the operator at the station, a gauge, or a downstream inspection step. Decide where that judgement is recorded, and let the machine supply only what it measures. Scrap keeps its own entry with a reason code, as in the table above.

Which order the count belongs to. The control usually does not know the work order. Something has to make the link: the operator picks the job on a terminal or tablet, an MES assigns it, or a table you maintain maps the active program to an operation. The program name alone is not enough, because the same program can run for several orders. It identifies the operation only where that mapping is written down and kept current, and someone has to own it when programs change.

What happens around resets and outages. Counters are usually cumulative and reset on a program change, a shift or a power cycle, so the gateway stores the last reading and sends the difference. A value lower than the last one means a reset, not negative output. It does not tell you what the machine made while the link was down: that interval has to be reconciled against the operator’s tally or the next booking, and marked as uncertain rather than filled in by arithmetic. Give each confirmation a permanent identifier when it is created, repeat that identifier on every retry, and have the ERP ignore a confirmation it has already posted. Then a dropped connection costs a retry, not a double booking.

Security basics

Every data connection is a new path into the shop floor. In May 2025, CISA (the US Cybersecurity and Infrastructure Security Agency), the FBI, the EPA and the Department of Energy published five primary mitigations for operational technology (OT).¹¹ Four apply directly to machine connections; the last two rows add protocol points. NIST SP 800-82 Revision 3 covers the same ground in depth.¹²

Basic	What it means for machine connections
Keep OT off the public internet	No port forwarding to a control, PLC or HMI (operator panel).
Secure remote access	Remote support goes through a VPN (virtual private network) with phishing-resistant multi-factor sign-in that your IT team controls.¹¹
Change default passwords	On gateways, switches, HMIs and controls. CISA notes that recently targeted systems used default or easily guessable passwords.¹¹
Segment IT and OT networks	Machines and gateways sit on their own network or VLAN (virtual LAN) behind a firewall. CISA suggests a demilitarized zone (DMZ) for passing control data to enterprise systems.¹¹
Read only	Give OPC UA and vendor-protocol clients read access only. Write nothing to a control or PLC.
Know which protocols have no login	Plain Modbus TCP (port 502) has no encryption or authentication. The Modbus/TCP Security protocol adds both through TLS (Transport Layer Security), on port 802.¹³

Machine inventory template

Copy this table into a spreadsheet and fill one row per machine, even those you expect to have nothing to share. The columns also cover several high-priority fields in the 2025 OT asset inventory guidance from CISA and partner agencies: manufacturer, model, IP address, communication protocols and physical location.¹⁴

Machine ID	Location	Make and model	Control and software version	Year	Ports and data options	Network and IP address	Data wanted	Used by
VMC-03 (illustrative)	Bay 2	Vertical machining center; model from the nameplate	FANUC; version from the system screen	2016	Ethernet; FOCAS available; MTConnect option not installed	Office network, 10.0.20.43	Run state, part count, alarms	Cell lead, planner

The sample row is illustrative: every value is an assumption.

Fill “Data wanted” with the numbers you need, such as run state, part count and alarms. Fill “Used by” with the people who will use them, such as the shift lead and the planner, and mark the bottleneck machine.

Then start small: connect one or two machines read-only, ideally a newer control and the bottleneck. Compare their counts with paper travelers or ERP bookings for a couple of weeks. Once the counts agree, send data to the ERP and add machines by control type, since machines with the same control share one connector setup.