How Mitsubishi CNC collects and connects to the ERP system
This guide is for manufacturing engineers and IT staff who need to pull real production data off Mitsubishi CNC controls and push it into an ERP without stopping the shop. It covers the data layer, the connection layer, and the write-back that closes the loop.

In this article
- 1
- 2
- 3
- 4
- 5
- 6
- 7
What you need to know first
What Mitsubishi CNC collects and connects from the control
Every integration starts with the same question: what can the control actually give you? On Mitsubishi CNC, that depends on the series (M70, M80, M800, M8 series, or older M50/M60) and on which communication options were ordered. The control exposes data in three layers, and you need to know which layer each signal lives in before you write any code.
The first layer is machine status. Run, stop, alarm, feed hold, door open, and cycle-complete flags come straight from the PLC. These are cheap to read and cheap to store. The second layer is production counters, such as part count, cycle time, spindle run time, and tool change count. The third layer is process data: spindle load, axis position, override values, active program number, and offset tables. Process data is where the value is, and also where the polling cost is.
Which signals matter for ERP? In practice, four groups feed almost every work order: start and end timestamps, good versus scrap quantity, active program or work order number, and alarm codes. Everything else is nice to have for dashboards but does not change a production schedule.
A common mistake is trying to collect everything on day one. Engineers wire up 40 tags, the poll cycle slows down, and the ERP starts rejecting records. Start with the four groups above. Add process data later once the pipeline is stable.
- 1Control series mattersM70/M80 expose more open interfaces than older M50/M60 controls.
- 2PLC tags are not freeEach tag has a read cost. Count them before you set the poll rate.
- 3Program number is the keyWithout it, you cannot tie a cycle to a work order.
Three connection paths and when each one fits
There is no single correct way for Mitsubishi CNC collects and connects to an ERP. There are three practical paths, and the right one depends on how many machines you have and how much control you have over the control side.
Ethernet with a native protocol is the cleanest path. Modern Mitsubishi controls support MTConnect or OPC UA through an option card or a gateway. MTConnect is read-only and gives you a standard XML schema, which makes the ERP side simple. OPC UA supports subscriptions, so you stop polling and let the server push changes. If your machines are M80 or newer, this is the path to choose.
File and macro output is the low-cost path. The CNC program writes a small text file or CSV to a shared folder at the end of each cycle using macro variables. A service on the network watches the folder and inserts rows into the ERP. This works on almost any control, needs no option card, and is easy to debug. The downside is latency: you get data at cycle end, not during the cut.
Digital I/O and PLC relay is the fallback. A stack light or relay board gives you run, stop, and alarm as dry contacts. You get binary state only, no counters and no program number. Use it when the control is locked down or very old, and accept that the ERP will only know that a machine is running, not what it is making.
- 1MTConnect or OPC UABest for M80 and newer, read-only or subscription-based.
- 2Macro file dropWorks on nearly any control. Cycle-end latency only.
- 3Digital I/OFallback for locked or legacy controls. State only.
Network and security setup before the first tag
Integration projects usually fail on the network, not on the protocol. Put the machine network on its own VLAN. Do not let the CNC controls share a broadcast domain with office traffic, and do not route them to the internet. A gateway or edge device with two network interfaces is the normal pattern: one side talks to the machines, the other side talks to the ERP middleware.
Set static IP addresses on every control. DHCP leases that change after a power outage will silently break your tag addresses. Record the IP, the port, and the protocol version for each machine in a spreadsheet before configuration starts.
Firewall rules should be explicit. The gateway needs to reach the ERP on one port, and the ERP needs to reach the gateway on one port. Nothing else. If your IT team wants deep packet inspection on the machine side, expect timing jitter and plan for a larger buffer.
Time synchronization matters more than most people expect. If machine clocks drift by 30 seconds, cycle records will not line up with ERP shift boundaries, and reports will disagree by a full shift. Point every control and the gateway at the same NTP source.
- 1Separate VLANKeep machine traffic off the office network.
- 2Static IPsRecord IP, port and protocol per machine.
- 3One NTP sourceClock drift breaks shift-level reporting.
Common errors and how to avoid them
The first error is polling too fast. Engineers set a 100 ms poll because it feels more accurate, then the gateway CPU saturates and records arrive late. Match the poll rate to the decision it supports. A production schedule does not need 100 ms data. Tool breakage detection might.
The second error is mapping inside the ladder. When the part number lives in the PLC program, every new job needs a program edit and a download. Put the mapping in a table outside the control and read it by key.
The third error is no buffering. A five-minute network drop during a 90-second cycle wipes out a shift of counts. Local storage and a retry queue cost almost nothing and prevent the argument about whose numbers are right.
The fourth error is writing to the control too early. If you push offsets before the read path is trustworthy, you will chase phantom problems. Run read-only for two weeks, compare counts against the operator's tally, then enable write-back one machine at a time.
- 1Pull count reconciliationCompare gateway counts with the operator tally daily for the first two weeks.
- 2Alarm code mappingMap control alarm codes to ERP reason codes before go-live, not after.
- 3Change logRecord every tag, mapping and firewall change with a date.
How to build the pipeline in six steps
Follow these in order. Skipping step 2 is the most common reason projects stall in commissioning.
- 1Inventory the controlsList every machine: model, control series, software version, installed communication options, and network port. Note which machines are M70/M80 and which are older. This list decides your protocol per machine.
- 2Pick the protocol per machineAssign MTConnect or OPC UA to M80 and newer controls. Assign macro file output to older or locked controls. Assign digital I/O only where nothing else is possible. Do not mix protocols on one gateway without testing.
- 3Define the tag list and poll rateStart with 8 to 12 tags per machine: status, program number, part count, cycle time, alarm code, spindle load, feed override, and timestamp. Poll at 1 s for status and counters. Poll process data at 5 s or slower. Sub-100 ms sampling needs a dedicated edge device per machine.
- 4Normalize and buffer at the edgeConvert every value to a common unit and timestamp format at the gateway, not in the ERP. Buffer at least 8 hours of data on local storage so a network outage does not create gaps. Use a store-and-forward queue with retry.
- 5Map tags to ERP objectsCreate one mapping table: machine ID to work center, program number to item number, alarm code to reason code, and part count to operation quantity. Keep the table in the ERP or in a database, not in the ladder logic. Engineers can then change a mapping without touching the control.
- 6Close the loop with write-backPush work orders, tool offsets and tool life limits from the ERP to the control. Use the same protocol in reverse where the control supports it. Write back only after the read path has run clean for two weeks. Log every write with the operator ID and the previous value.
Which connection path fits your shop
Pick the row that matches your control population and your latency needs.
| Path | Best fit | Latency | Effort |
|---|---|---|---|
| MTConnect over Ethernet | M80 and newer controls | 1 s or less | Medium: needs option card |
| OPC UA subscription | Mixed fleet with a gateway | Under 1 s on change | Medium to high |
| Macro file drop | Any control, low budget | Cycle end only | Low: shared folder plus service |
| Digital I/O relay | Locked or pre-M70 controls | Instant state change | Low, but state only |
| Manual barcode scan | Very low volume cells | Shift end | Very low, operator dependent |
Start read-only, then close the loop
Get the read path stable and reconciled for two weeks before you write anything back to the control. If you need parts machined while the integration is still being designed, send us the drawings and we will quote within 12 hours.
Questions engineers ask before go-live
Do we need an option card for Mitsubishi CNC collects and connects to work?
Not always. MTConnect and OPC UA usually need a communication option or a gateway device on M70 and M80 controls. Macro file output needs no option card at all, which is why it is common on older machines.
Check the option list on each control before ordering hardware. A missing Ethernet option is cheaper to add at commissioning than to discover on go-live day.
How many tags per machine is reasonable?
Start with 8 to 12. That covers status, program number, part count, cycle time, alarm code, and a few process values.
More tags raise the poll cost and the mapping work. Add them only when a specific decision needs the data.
What happens when the network goes down mid-cycle?
If the edge device buffers locally, nothing is lost. The queue holds the records and forwards them when the link returns.
Without buffering, you lose the cycle. The ERP will show a gap that no one can explain three weeks later.
Can we push tool offsets from the ERP to the control?
Yes, on controls that support remote write. Keep it behind a confirmation step and log the previous value.
Enable write-back only after the read path has been stable for two weeks and the counts reconcile.
Does this work with mixed machine brands?
Yes, but normalize at the gateway. One tag model for all machines makes the ERP side far simpler.
Brand-specific quirks belong in the gateway driver, not in the ERP schema.
How long does commissioning usually take?
A single machine with an existing network and a clear tag list can be running in a day or two. A mixed fleet of 20 machines with mapping work takes several weeks.
Most of the time goes into the mapping table and the count reconciliation, not the protocol.
Need parts while the integration project runs?
Upload your drawings and get a quotation with free DFM analysis within 12 hours. Tolerances held to ±0.005 mm, 100% inspection before shipment.
12-hour quote100% inspectionNo minimum order quantity