---
title: "MTConnect, OPC UA and Modbus compared"
description: "MTConnect reads machine tools, OPC UA models and secures plant data, and Modbus moves bare registers. See how each one works and when your machines need it."
category: "Machines and connectivity"
author: "Mahmoud Parto"
published: "2023-04-11"
updated: "2026-10-20"
source_url: "https://www.iotflows.com/blog/machine-communication-protocols/"
---
> Question: What are MTConnect, OPC UA and Modbus, and when do you need each?

## Key takeaways

- MTConnect gives machine tools a shared, read-only vocabulary that an agent serves over HTTP, so a client cannot change the machine.
- OPC UA models, reads and writes industrial data, with certificates, signing and encryption built into the protocol.
- Modbus moves bare 16-bit registers, so every device needs its maker’s register map before the numbers mean anything.
- Plain Modbus TCP carries no authentication; the Modbus/TCP Security variant wraps the same messages in TLS on port 802.
- Run state, uptime and part counts need no protocol at all, because a sensor can read them from outside the machine.

MTConnect, OPC UA and Modbus are three standards for reading data from a machine’s control, and each one does a different job. MTConnect gives machine tools a shared, read-only vocabulary; OPC UA models, reads, writes and secures data from almost any industrial device; Modbus moves bare 16-bit registers whose meaning lives in the device’s manual. You need one only when the data you want lives inside the control.

This guide is for engineers and plant managers deciding how to get data off a mixed fleet. It explains how each protocol works, where machine connections stall, and how to choose.

## What a machine protocol defines

A protocol for machine data answers three questions: how bytes move between two devices, what each value means, and who may read or change it. The three standards in this guide answer them differently, which is why one can’t stand in for another.

| Layer | Question it answers | Example |
|---|---|---|
| Transport | How do the bytes move? | TCP port 502, HTTP, RS-485 serial |
| Data model | What does a value mean? | “Spindle speed in rpm” or register 201 |
| Access | Who can read or write? | Read-only agent, or permissions per user |

For example, a spindle turning at 1,200 rpm reaches your software as the number 1200 in all three. Modbus sends only the number. MTConnect and OPC UA send the number with its name and unit, so the software knows what it is looking at.

Figure: The same 1200 rpm spindle speed read three ways: Modbus returns register 201 as hex 04 B0 with no name or unit, MTConnect returns RotaryVelocity in REVOLUTION/MINUTE, and OPC UA returns a typed Spindle.Speed node in rpm.

*Modbus sends a bare number; MTConnect and OPC UA send the number with its name and unit. Sample data.*

Each protocol talks to the machine’s controller: the [PLC](/docs/get-started/glossary/#plc) or CNC control that runs it. That makes it the right tool for data only the control holds, and more than you need for data a sensor can see from outside.

## How MTConnect works

> **Definition.** **MTConnect** is an open, royalty-free standard from the MTConnect Institute that defines a shared vocabulary for machine tool and other manufacturing equipment data, such as execution state, spindle speed and part count, and serves that data read-only over HTTP from software called an agent.

The specification describes MTConnect as a data and information exchange standard built on a dictionary of terms for manufacturing operations, open and royalty-free for anyone to implement.[1] The dictionary is the point.

A measured spindle speed is a `RotaryVelocity` sample with the subtype `ACTUAL`, in `REVOLUTION/MINUTE`.[2] Software written against the standard reads that item the same way on any builder’s control that implements it.

### Adapter, agent and client

Three pieces of software sit between the machine and your dashboard:

- An *adapter* is optional hardware or software that turns what the equipment provides into a form the agent can receive.[1] A control that doesn’t speak MTConnect natively needs one.
- An *agent* collects data from one or more machines, organizes it, and answers requests from client software.[1]
- A *client* is your monitoring or analytics software, which asks the agent for data.

An agent must answer four requests: `probe` for the machine’s structure, `current` for the latest value of every data item, `sample` for buffered history, and `asset` for the assets the agent tracks.[1] The Institute’s reference agent also takes input over [MQTT](/docs/get-started/glossary/#mqtt) and can publish to an MQTT broker.[3]

### Read-only by design

The MTConnect REST API is read-only and produces no side effects on the agent or the equipment.[1] A client can’t start a program, change an offset or clear an alarm through MTConnect. If you need to write back to a machine tool, MTConnect isn’t the path.

### Security in MTConnect

MTConnect defines what the data means and how to request it. Protecting the connection falls to the transport and the network. The reference agent supports TLS, so it can serve its data over HTTPS with certificates.[3]

The OPC UA companion specification for MTConnect, released in September 2019, expresses the MTConnect model in OPC UA and brings OPC UA’s end-to-end security to it.[4] The two standards cooperate rather than compete.

## How OPC UA works

> **Definition.** **OPC UA (Open Platform Communications Unified Architecture)** is a platform-independent framework from the OPC Foundation, released in 2008, for modeling industrial data and exchanging it securely between clients and servers, with reads and writes governed by access permissions.

OPC UA runs on anything from a microcontroller to a cloud server, PLCs included.[5] A device or gateway runs an OPC UA server. Your software connects as a client, browses what the server offers, and reads, writes or subscribes to values based on the permissions it holds.[5]

### Information models

Where Modbus has registers, OPC UA has a typed model that a client can browse. For example, a press might expose a node for its main motor, a variable for motor current with a data type and an engineering unit, and a method that resets a counter.

The modeling framework is extensible, so industry groups publish companion specifications that fix the model for one kind of machine.[5] The MTConnect companion specification is one of them.[4]

### Transports

OPC UA is often described as an HTTP or MQTT protocol, but that isn’t accurate. Its main client and server transport is OPC UA TCP, which runs directly on TCP/IP and whose endpoints use the `opc.tcp` URL scheme.[6] IANA registers port 4840 for it, and port 4843 for OPC UA over TLS.[8]

HTTPS, WebSockets and SOAP over HTTP are alternative mappings in the same specification.[6] The separate publish-subscribe model, PubSub, defines mappings for UDP, raw Ethernet and MQTT.[7]

PubSub is built for many-to-many traffic.[5] Choose it when one device feeds many consumers, and choose client and server when your software asks for data on demand.

### Security in OPC UA

Security is part of the OPC UA protocol. Each client and server is identified by an X.509 certificate, messages can be signed and encrypted, users authenticate, and activity is logged as an audit trail.[5]

Because OPC UA can write as well as read, the permissions a client receives are a decision for the plant. Connecting software to a controller is a security concern for many plants, and IT usually reviews it first.

## How Modbus works

> **Definition.** **Modbus** is a request-and-reply messaging protocol, published by the Modbus Organization, in which a client reads or writes numbered bits and 16-bit registers on a server device over Ethernet or a serial line.

The specification calls it an application layer messaging protocol for client and server communication across different buses and networks, run over TCP/IP on Ethernet or over serial links such as EIA/TIA-485.[9] Older documents call the client a master and the server a slave.

### Four tables of numbers

Modbus organizes a device’s data in four primary tables.[9]

| Table | Size of each item | Access |
|---|---|---|
| Discrete inputs | 1 bit | Read-only |
| Coils | 1 bit | Read and write |
| Input registers | 16-bit word | Read-only |
| Holding registers | 16-bit word | Read and write |

Each table addresses up to 65,536 items, and function code 03 reads 1 to 125 holding registers in one request.[9] Nothing in Modbus says what register 108 holds. The device maker’s register map does, so every new device model means a new map to load and check.

> **Register numbers start at 1, addresses at 0**
>
> The specification addresses registers from zero, so registers numbered 1 to 16 are sent as addresses 0 to 15.[9] When a value reads as its neighbor’s, check for this offset before you suspect the device.

### Read a temperature and a counter

#### Worked example: Reading a barrel temperature and a cycle counter over Modbus TCP

A hypothetical injection molding machine publishes this register map in its manual:

- Register 108: barrel zone 1 temperature, in tenths of a degree Celsius.
- Register 109: active alarm code, 0 for none.
- Registers 110 and 111: cycle counter as one 32-bit value, high word first.

Your client sends function 03, starting address 107 (hex 006B), quantity 4. The device answers `03 08 08 FC 00 00 00 01 86 A0`: the function code, a byte count of 8, then four registers of two bytes each, high byte first.

- Register 108 is hex 08FC = 2,300, so the barrel reads 230.0 °C.
- Register 109 is 0, so no alarm is active.
- Registers 110 and 111 are 1 and hex 86A0 = 34,464, so the counter is 1 × 65,536 + 34,464.

**Result:** Cycle counter = 100,000 cycles at 230.0 °C, with no alarm

The specification defines only 16-bit registers, so how two registers combine into a 32-bit value is the device maker’s choice. Read the same counter with the words swapped and you get 34,464 × 65,536 + 1 = 2,258,632,705 cycles. The register map, not the protocol, tells you which word comes first.

### Security and current use

Plain Modbus TCP, on port 502, has no authentication or encryption.[10] The Modbus/TCP Security protocol carries the same messages inside TLS on port 802, adding encryption, integrity checks, certificate-based authentication and roles for authorization.[10] Where a device supports only plain Modbus, protect it with the network: keep it on a segment that only the systems that need it can reach.

Modbus is old, but it isn’t retired. HMS Networks’ 2026 analysis of newly installed nodes in factory automation puts Modbus TCP at 5% and Modbus RTU at 3%.[11]

The Modbus Organization describes Modbus/TCP as widely deployed in industrial control systems.[10] Meters, drives, temperature controllers and older PLCs are where you meet it most.

## Compare MTConnect, OPC UA and Modbus

The biggest practical difference is direction. MTConnect only reads, while OPC UA and Modbus clients can also write to the device.

Figure: Three data paths. MTConnect flows one way from machine control to adapter to agent to client. OPC UA and Modbus clients send reads and writes to a server in the device and get values back, over port 4840 and port 502.

*MTConnect only reads; OPC UA and Modbus clients can also write, so access needs a decision.*

| | MTConnect | OPC UA | Modbus |
|---|---|---|---|
| Maintained by | MTConnect Institute | OPC Foundation | Modbus Organization |
| Built for | Machine tools and other shop equipment | Any industrial device | Any device with registers |
| What a value carries | Name, unit and timestamp | Name, data type and unit | A bare bit or 16-bit number |
| Read or write | Read-only | Read and write | Read and write |
| Security in the protocol | None; relies on the transport | Certificates, signing, encryption | None; TLS variant on port 802 |
| Main transport | HTTP from the agent | OPC UA TCP, port 4840 | TCP port 502, or serial |

Each row comes from the standard’s own specification. Your device’s documentation says which of them it supports.

## Why machine connections stall

A protocol on the spec sheet doesn’t mean the data reaches your dashboard. Connection projects stall at five points, and each one has a fix you can plan for.

- **A mixed fleet.** A 2005 lathe, a 2019 machining center and a hydraulic press can speak three different protocols, or none. Each protocol is a separate connector to build, test and keep running, so list every machine’s protocol before you budget the project.
- **No data path.** A control with no network port, or with no MTConnect support, needs an adapter before an agent can read it. Budget the adapter per machine, not per plant.
- **No meaning.** Modbus values arrive without names. For example, 40 meters and drives across six models means six register maps to load and verify against a hand reading.
- **The security review.** A controller connection puts a new device on the machine and on the plant network. That is a security concern for many plants, so IT usually reviews it first. Bring IT in before the project starts, not after the hardware arrives.
- **More data than you need.** Reading 30 values a second from each of 20 machines is 600 values a second, or 51.8 million a day. Decide which values answer a question before you poll them all, and use a [data collection plan](/blog/manufacturing-data-collection/) to rank them.

## Get machine data with or without a protocol

IoTFlows reads machines both ways. [SenseAi](/docs/get-started/glossary/#senseai) mounts on the outside of any machine and reads vibration and sound, so it reports running, stopped, part counts and cycle times with no connection to the control. The sensors [never connect to your PLC](/docs/get-started/faq/#plc).

On Enterprise, the IoTFlows [edge device](/docs/get-started/glossary/#edge-device) reads PLCs and controls over MTConnect, OPC UA, Modbus TCP, EtherNet/IP, Profinet and MQTT, and it reads only the controls you choose to connect. Its signals feed the same dashboards and alerts as the sensors, so a controller alarm can open a Maintain work order.

IoTFlows engineers scope, build and validate each [custom integration](/platform/custom-integrations/), and it goes live in one week to a month, depending on the machines. [Stanley Black & Decker](/customers/stanley-black-decker/) used the edge device to pull every welding data point from the robotic welding machines on a major automotive customer’s production lines.

## Which protocol do you need?

Start from the data you need, not from the protocol. The first two rows need no connection to the control at all.

| Data you need | What reads it |
|---|---|
| Running or stopped, uptime, downtime | A sensor on the machine |
| Part counts and cycle times | A sensor, or the control’s counter |
| Program name, alarms, feed override | The control, over MTConnect or OPC UA |
| Process values from a PLC | OPC UA, or Modbus TCP if that’s all it has |
| Meters, drives, temperature controllers | Modbus TCP or Modbus RTU |
| Setpoints written back to a machine | OPC UA, with write permissions agreed |

Use that table with these rules:

- **Choose MTConnect when** your machines are CNC machine tools whose controls support it and you only need to read. It gives every builder’s control the same names, which suits [CNC machine monitoring](/solutions/cnc-machine-monitoring/) across brands.
- **Choose OPC UA when** you connect PLCs, robots or mixed equipment, need a typed model, need security in the protocol, or need to write back.
- **Use Modbus when** a device offers nothing else. Load and verify its register map, and keep it on a protected network segment.
- **You don’t need any of them if** your questions are about run time, stops and counts. A sensor answers those from outside the machine, and the [sensor vs PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) sets out what each path sees. For a whole line, see [production line monitoring without PLCs](/blog/production-line-monitoring-without-plcs/).

> **Specifying a new machine?**
>
> Ask the builder three questions before the order: which protocols the control supports, whether each one is a paid option on the control, and for the data item list or register map. The answers decide whether the machine connects on delivery or needs an adapter project.

## Questions

### Is MTConnect the same as OPC UA?

No. MTConnect is a vocabulary for machine tool data with a read-only HTTP interface. OPC UA is a general framework that models, reads and writes data from any industrial device and secures the connection itself. The two organizations released a companion specification in 2019 that carries the MTConnect model over OPC UA, so one machine can offer both.

### Can MTConnect change settings on a machine?

No. The MTConnect specification defines a read-only interface with no side effects on the agent or the equipment. A client can request the machine’s structure, its current values and buffered history, but it cannot start a program, change an offset or clear an alarm through MTConnect.

### Which ports do MTConnect, OPC UA and Modbus use?

Modbus TCP uses port 502, and its TLS variant uses port 802. OPC UA TCP uses port 4840, and IANA also registers 4843 for OPC UA over TLS. An MTConnect agent serves HTTP on the port set in its own configuration, so read the agent’s settings before a firewall review.

### What is the difference between Modbus RTU and Modbus TCP?

Both carry the same function codes and the same four data tables. Modbus RTU runs over serial lines such as RS-485, and Modbus TCP runs over Ethernet on port 502 with an extra header in front of each message. A gateway can translate between the two, so a serial device can still answer a TCP client.

### Do I need a protocol to monitor machine uptime?

No. Uptime, downtime, part counts and cycle times can be read from outside the machine with a vibration or current sensor, with no connection to the control. A protocol adds what only the control knows, such as program names, alarm codes and feed overrides, so connect one when you need that data.

## Sources

1. [MTConnect Standard Part 1.0: Fundamentals, Version 2.5.0](https://docs.mtconnect.org/MBSD_MTConnect_Part_1_2-5-0.pdf), MTConnect Institute, accessed Oct 16, 2026
2. [RotaryVelocity.Actual, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/ObservationInformationModel/ObservationTypes/SampleTypes/RotaryVelocityActual), MTConnect Institute, accessed Oct 16, 2026
3. [MTConnect C++ Agent (cppagent) README](https://github.com/mtconnect/cppagent), MTConnect Institute, accessed Oct 16, 2026
4. [OPC Foundation and MTConnect Institute announce release of the OPC UA Companion Specification for MTConnect](https://opcfoundation.org/news/press-releases/opc-foundation-and-mtconnect-institute-announce-release-of-the-opc-ua-companion-specification-for-mtconnect/), OPC Foundation, accessed Oct 16, 2026
5. [Unified Architecture](https://opcfoundation.org/about/opc-technologies/opc-ua/), OPC Foundation, accessed Oct 16, 2026
6. [OPC 10000-6 UA Part 6: Mappings, section 7 TransportProtocols](https://reference.opcfoundation.org/Core/Part6/v105/docs/7), OPC Foundation, accessed Oct 16, 2026
7. [OPC 10000-14 UA Part 14: PubSub, section 7 PubSub mappings](https://reference.opcfoundation.org/Core/Part14/v105/docs/7), OPC Foundation, accessed Oct 16, 2026
8. [Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.csv), Internet Assigned Numbers Authority (IANA), accessed Oct 16, 2026
9. [MODBUS Application Protocol Specification V1.1b3](https://www.modbus.org/file/secure/modbusprotocolspecification.pdf), Modbus Organization, accessed Oct 16, 2026
10. [MODBUS/TCP Security Protocol Specification](https://www.modbus.org/file/secure/modbussecurityprotocol.pdf), Modbus Organization, accessed Oct 16, 2026
11. [Annual HMS report 2026: Industrial network market shares](https://www.hms-networks.com/news/news-details/15-06-2026-annual-hms-report-2026), HMS Networks, accessed Oct 16, 2026