Edge Computing Gateway Achieves Data From Mitsubishi Tool-Tool Machines in MES

• 1
  Key takeaways
• 2
  What an edge computing gateway actually does on the floor
• 3
  Protocol choices and what each one costs you
• 4
  Why Mitsubishi tool-tool data is harder than machine status
• 5
  How the gateway fits into the MES job and OEE model
• 6
  When a gateway is the wrong answer
• 7
  Step by step: proving the data path on two machines
• 8
  Gateway versus direct PLC connection versus manual entry

An edge computing gateway achieves data from a Mitsubishi tool-tool machine by sitting between the machine control and the network. It speaks the controller's native language on one side, usually Ethernet with SLMP or MC protocol, sometimes RS-232 or RS-485, and speaks MES-friendly protocols on the other side, typically OPC UA, MQTT, or a REST payload. The gateway is not a historian. It polls, maps, filters, and forwards. That distinction matters when you size it.

The Mitsubishi controller exposes registers, relays, and data registers organized by device type. A gateway reads D registers for part counts and cycle values, M relays for machine status, and X or Y devices for input and output states. Each tag in MES maps to one address. If MES expects a part count and the gateway reads the wrong D register, you get a plausible number that is simply wrong. Address mapping is the step where most pilot projects fail.

Timing is the second mechanism. The gateway runs a scan loop. Every cycle it reads the tag list, compares values, and only publishes what changed. That change-of-value logic is what keeps MES load flat as you add machines. A raw stream from 20 machines will saturate a modest MES endpoint. A filtered event stream will not.

The gateway also does light computation. It can convert raw register values into engineering units, group a start and end signal into a cycle time, and stamp records with a local timestamp before they leave the cabinet. This is the part that earns the word edge. If your gateway only forwards bytes, you have built a network bridge, not an edge layer.

• 1
  Poll, do not listenMost Mitsubishi CNCs do not push data unsolicited. The gateway drives the conversation.
• 2
  Map every tag to one addressA tag without a documented address is a future data error.
• 3
  Filter at the edgeChange-of-value publishing keeps MES ingest predictable.

Mitsubishi controllers in the field span several generations. Newer M800 and M700 series controls often expose Ethernet and support SLMP, which is a clean binary or ASCII conversation over TCP. Older M500 and M300 controls may only offer serial, or offer an optional Ethernet card that is not installed. A gateway purchase should start with a controller inventory, not a software shortlist.

OPC UA is the common northbound choice because MES platforms and historians accept it without custom code. It also carries data types and timestamps, which MQTT alone does not define. MQTT is lighter and travels better across segmented networks, but the payload schema is your responsibility. Whichever you pick, the gateway must own the schema. If MES defines the schema, every new machine becomes a software change.

Serial adds latency and cabling constraints. At 9,600 baud, a tag list of 40 registers can take a noticeable fraction of a second to read. If you need sub-second machine status on a serial link, split the tag list. Read status registers every scan and read slower diagnostic data every fifth scan. This is normal practice, not a workaround.

Network segmentation is not optional. Put the gateway on a machine VLAN, terminate it at a firewall, and allow only the outbound session it needs. A gateway with two network interfaces can bridge segments, but bridging is a security decision, not a default. Most plants route the northbound traffic through a single controlled path.

• 1
  SLMP over EthernetBest fit for M700 and M800 controls with the network option enabled.
• 2
  Serial MC protocolWorks on older controls; budget for slower scan rates.
• 3
  OPC UA northboundTyped and timestamped; accepted by most MES platforms.
• 4
  MQTT northboundLight payloads; you own the schema and the broker.

Machine status is simple. A spindle running signal, a cycle start, and a part counter are all accessible from standard PLC devices. Tool data is not. Tool life, tool ID, wear offset, and remaining life often live in the NC side of the control, in areas that PLC register reads do not reach. On Mitsubishi controls, some of this data is available through specific system variables or through the controller's own data window, and some is only visible in the NC program and tool offset tables.

This is where a naive gateway project stalls. The team proves that running and stopped states work, then discovers that tool life numbers are not on the same address map. The fix is usually one of three things: read the tool offset table through the same protocol if the controller supports it, read it from a separate NC data path, or accept that tool life is managed in the machine and only the tool change event is sent to MES.

The third option is often correct. If MES needs to know when a tool changed and which program was running, a tool change event plus a program number is enough. If MES needs to predict tool wear across a fleet, you need the actual offset values, and that requires a documented NC data path. Decide which problem you are solving before you specify the gateway.

One more boundary: tool data sampled at the wrong moment is misleading. Reading a wear offset while the operator is editing the offset table produces a transient value. A gateway should read tool data at tool change, or at cycle end, not continuously. Sampling discipline is part of the data model.

• 1
  Status is easy, tool life is notPLC devices cover status. NC-side data needs its own path.
• 2
  Sample at tool changeContinuous reads catch operator edits and transient values.
• 3
  Event plus program numberOften enough for MES job tracking without offset values.

MES does not want raw machine signals. It wants a job context. A good gateway feeds three record types: machine state changes with a timestamp, cycle completions with a part count and cycle time, and tool change events with the tool and program identifiers. Everything else is diagnostic and belongs in a separate log.

The gateway should carry a machine identifier and, where possible, a work order or program number. Without a work order link, MES can report machine utilization but cannot report job progress. The work order number usually comes from the MES side, pushed down to the gateway and matched to the running program. If the operator loads a program manually, the gateway can still send the program number and let MES map it.

OEE calculation needs three inputs: availability, performance, and quality. A gateway can supply availability and cycle time. Quality usually comes from a separate inspection or first-pass-yield record. Do not ask the gateway to invent quality data. Scope it to what the controller actually knows.

Time synchronization matters more than most teams expect. If the gateway clock drifts from the MES clock, cycle events land in the wrong order and OEE reports show impossible overlaps. Point the gateway at the same NTP source as the MES servers. This is a five-minute configuration that prevents weeks of argument.

• 1
  Three record typesState change, cycle complete, tool change. Keep it small.
• 2
  Carry a work order linkWithout it, MES reports utilization but not job progress.
• 3
  Share one NTP sourceClock drift breaks event ordering and OEE math.

A gateway is not a fix for an unstable network. If the machine network drops packets during shift changes, adding a gateway will make the data loss visible, not solve it. Fix the physical layer first. Industrial Ethernet in a machining cell sees chips, coolant mist, and vibration. Shielded cable, proper grounding, and a managed switch are prerequisites.

A gateway is also the wrong answer when the controller has no accessible data path and no retrofit option. Some very old controls expose only a serial port used by a tape reader or a proprietary bus. In that case, the honest options are a machine retrofit, a sensor-based approach using current transformers or vibration sensors, or manual entry. A sensor-based layer can give you run state and cycle counting without touching the control, but it cannot give you program numbers or tool data.

Do not use a gateway as a control path. Reading from a machine is safe. Writing to a machine through a gateway means MES or a cloud service can change offsets or start cycles. Keep the gateway read-only unless there is a specific, audited reason to write, and if you do write, put the logic in the controller, not in the gateway.

Finally, budget the engineering time. Hardware is a small fraction of the project. Tag mapping, schema definition, MES configuration, and acceptance testing are the real cost. A pilot on two machines is the right first scope.

• 1
  Fix the network firstA gateway exposes data loss, it does not repair it.
• 2
  Sensor retrofit is a valid fallbackGives run state and counts, not program or tool data.
• 3
  Keep the gateway read-onlyWriting to a control is a separate safety decision.