How MTConnect Works

MTConnect is the open standard that lets CNC machines from different builders share what they are doing in one common language. Here is how it works, in plain terms, from the control to your monitoring screen.

By Ryan Lenhart · Updated Oct 5, 2026

Before MTConnect, getting data out of a CNC machine meant learning a different interface for every brand — and often paying for custom software for each one. A shop with three builders on the floor needed three integrations.

MTConnect fixed that by defining one common language for machine data. A Haas, a Mazak, and an Okuma that each support MTConnect describe their state the same way, so one piece of software can read all three.

The four pieces of an MTConnect setup

Some modern controls include the adapter and agent internally, so the machine itself answers MTConnect requests. Older machines usually need an external adapter. One agent can serve many machines, each as a separate device.

How a client gets data from an agent

MTConnect agents speak plain HTTP. Clients make four main kinds of request:

Responses are XML (newer agents can also return JSON). Every observation carries a timestamp and a sequence number, so a client can request "everything since sequence 18,240" and reconstruct exactly what happened, even after a network blip — as long as the agent's buffer still holds those changes.

FEAI Machine Monitor uses exactly these requests — /probe, /current, and /sample — with HTTP GET only.

What MTConnect data looks like

Data items fall into three categories:

• Samples — continuously varying numbers, like spindle speed, feed rate, load, or position
• Events — discrete states and values, like execution state, controller mode, program name, or part count
• Conditions — health status: NORMAL, WARNING, or FAULT, with alarm codes and messages

For monitoring, the most important events are Execution (ACTIVE, READY, STOPPED, INTERRUPTED, FEED_HOLD, and others), PartCount, Program, ControllerMode, and Availability. What Data Does MTConnect Provide? covers each one.

A real request, step by step

Here is what happens when monitoring software connects to a machine:

1. The client requests http://192.168.1.50:5000/probe and learns the machine has a controller with a path, an execution data item, a part count, and a program.
2. It requests /current to get the latest values: execution ACTIVE, program O1234, part count 87.
3. It repeatedly requests /sample?from=<next sequence> to receive every change since the last request.
4. It stores each change with its timestamp, building a minute-by-minute timeline.
5. From that timeline it calculates running time, stops, utilization, OEE, and production.

MTConnect versions

The standard has evolved through 1.x versions to the 2.x series, adding richer device models, more data types, and JSON support. For basic monitoring — state, part counts, programs, alarms — almost any version provides what you need. The version that matters is whatever your agent runs, and good client software handles the differences.

Security and network considerations

• Read-only. Clients cannot change programs, offsets, or settings through MTConnect.
• Local. Agents run on your network. Nothing leaves the building unless your client software sends it out.
• Plain HTTP. Most agents use unencrypted HTTP on the shop network, so keep agents on a protected machine network or VLAN rather than exposing them to the internet.
• Firewalls. The monitoring PC needs to reach the agent's port. That is usually the only rule required.

FEAI Machine Monitor is local-first: it reads agents on your network and stores data on your own PC.

What MTConnect means for shop owners

If your machines support it, monitoring becomes a software decision, not a hardware project. You can try monitoring tools on your own machines without buying gateways.

It is multi-brand. Mixed fleets can be seen side by side in one view.

Support varies. Some controls include MTConnect as standard, others as a paid option, and some need a third-party adapter. Two machines from the same builder can differ by control version and options. Check machine by machine — our Haas, Mazak, Okuma, and Fanuc pages cover the common cases.

How to get started

1. Inventory your machines — control model, options, and whether MTConnect is available.
2. Look for existing agents — previous projects or dealers may have set them up. See Already Have MTConnect?
3. Test one machine in a browser: http://<ip>:<port>/current. How to Test an MTConnect Connection has the full checklist.
4. Connect a client and watch a week of data.

Ready to see your MTConnect data as a live timeline? Start free — 2 machines.