Mitsubishi PLC and CNC Data Acquisition: How the Data Actually Moves

• 1
  Where Mitsubishi PLC and CNC data acquisition data comes from
• 2
  Protocol choices and what they cost you
• 3
  Sampling rate, resolution, and the events you will miss
• 4
  What data acquisition cannot tell you
• 5
  Matching the collection method to the machine and the question
• 6
  Collection method compared by requirement

Every data point on a machine starts as a memory address. In a Mitsubishi PLC that address is a device such as D100, M50, or X0. In a CNC controller the useful values live in parameters such as spindle load, feed override, tool number, and alarm history. Data acquisition is simply the job of copying those addresses on a schedule and putting them somewhere a database can read.

That copy is not free. Each read costs bus time and CPU time, and the controller is busy running the machine. If you poll too fast, you slow the machine. If you poll too slow, you miss short events such as a 200 ms torque spike that explains a scrapped part. Most of the engineering work is choosing the right middle ground.

There are three practical read paths. Direct polling over Ethernet or serial, where the collector asks for values. Cyclic broadcast, where the controller publishes a block of values on a fixed cycle. And event-driven reporting, where the controller sends a message only when a condition changes. Each has a different cost and a different failure mode.

• 1
  Direct pollingSimple to build, but read rate is capped by bus latency and controller load.
• 2
  Cyclic broadcastPredictable timing, larger bandwidth use, harder to map to part-level traceability.
• 3
  Event-drivenCheapest on network load, but you must define the trigger conditions carefully.

Mitsubishi controllers speak several protocols, and the choice usually decides the rest of the architecture. MC Protocol over Ethernet is the common one for PLCs: it reads and writes devices by address, and it is well documented. For newer controllers, an OPC UA server or an MTConnect agent gives you a named data model instead of raw addresses.

The trade-off is naming versus speed. MC Protocol gives you raw addresses, so your collector must know that D100 is spindle load and D102 is cycle count. OPC UA gives you readable tags, which is easier to maintain, but the server layer adds latency and one more thing that can restart after a power event.

Serial protocols still exist on older machines, and they are the ones that cause trouble. RS-232 or RS-485 at 9,600 baud can carry roughly 960 bytes per second. A 40-word payload at 2 Hz will fill that link. Plan the data set before you plan the cable.

One more constraint: vendor protocol libraries are licensed per connection or per node. A plant with 30 machines can turn a small project into a recurring cost. Confirm licensing before you commit to a topology.

• 1
  MC Protocol over EthernetGood for device-level reads. You own the address map and its documentation.
• 2
  OPC UASelf-describing tags, better for mixed-vendor plants, more moving parts.
• 3
  MTConnectRead-only and machine-tool oriented. Useful when you only need status and counts.
• 4
  Serial Modbus or proprietaryStill common on legacy cells. Bandwidth is the hard limit, not the software.

A 1 Hz sample tells you the machine was running. It does not tell you why a bore came out 0.02 mm oversize. Servo torque, spindle load, and axis following error change on a much shorter timescale, often in the 10 to 100 ms range. If those signals matter, you need a faster path than a plant-wide poll.

The usual fix is buffering at the edge. A small industrial PC or gateway sits next to the machine, reads fast, stores locally, and forwards a compressed or aggregated stream upstream. The machine network stays isolated, and a dropped plant link does not lose data. The gateway holds a few hours of samples and replays them when the link returns.

Resolution matters as much as rate. If a PLC register stores spindle load as an integer from 0 to 4,000 counts, one count is 0.025 percent. That is fine for trend charts. It is not fine for detecting a worn tool by a 0.5 percent load shift. Check the raw register scaling before you trust the trend.

Timestamping is the third piece. PLC scan time, gateway clock, and server clock all drift. Use one time source, typically NTP on the gateway, and record the scan timestamp at the source. Without it, two signals from the same cycle can appear seconds apart in the database.

• 1
  1 HzEnough for uptime, part counts, and shift reporting.
• 2
  10 HzEnough for cycle-time analysis and most alarm correlation.
• 3
  100 Hz and aboveNeeded for torque, vibration, and tool-wear signatures. Requires edge capture.

Controller data describes the machine, not the part. A stable spindle load curve means the cut was consistent. It does not prove the finished bore is within 0.005 mm. If the tool was set wrong or the fixture moved, the load curve can look perfect while the part is out of tolerance. Pair controller data with metrology, not instead of it.

There are also signals the controller never sees. Coolant concentration, ambient temperature, and raw material hardness all affect the result and usually sit outside the PLC. A common mistake is to build a large dashboard and then discover the strongest predictor of scrap was never wired into the system.

Safety and control networks should stay separate. Tapping a network that carries safety I/O to add a data collector is a real risk. Read from a separate port or a mirror, and keep the collector on a segment that cannot write to the controller.

Finally, a data acquisition project without a defined decision is just storage cost. Before wiring anything, write down the question the data answers: which tool change interval, which alarm, which cycle. If no one can name the decision, the project will stall after the pilot.

Start with the age of the controller. A recent Mitsubishi CNC with an Ethernet port and an OPC UA or MTConnect option is straightforward. A 15-year-old PLC with only a serial port needs a gateway that speaks the old protocol and converts it. The hardware cost is similar; the engineering time is not.

Then look at what you are measuring. Status and counts tolerate slow polling and simple storage. Process signatures need edge capture and time alignment. Traceability needs a part identifier tied to every record, which usually means a barcode read at load and a write to a local database at cycle end.

For a plant with mixed vendors, a gateway per machine plus one upstream broker is easier to maintain than point-to-point links into a single server. It also limits the blast radius when one collector fails. Keep the address maps in version control. They will change, and undocumented maps are the main reason a working pilot cannot be rolled out.

• 1
  Simple status and countsPoll at 1 Hz, store in a time-series table, no edge device needed.
• 2
  Cycle and alarm analysisGateway per cell, 10 Hz buffer, NTP timestamp, event triggers on alarm bits.
• 3
  Process and tool-wear signaturesHigh-rate edge capture, local ring buffer, upload on cycle end.