MTConnect (ANSI/MTC1.4) is a read-only standard for getting data out of manufacturing equipment, and it is the only protocol in common use that ships an opinion about what a machine tool means. It is HTTP and XML — no special client library required — and it is deliberately one-way: MTConnect cannot write to a machine, which is a large part of why plants allow it.
The architecture is two pieces. An adapter sits next to the machine and speaks whatever the controller speaks — FOCAS, a serial protocol, a vendor API — and emits a simple key-value stream. An agent consumes that, holds a buffer of recent data, and serves it over HTTP. You then have four endpoints: /probe returns the device model, /current returns the latest value of everything, /sample returns a range by sequence number, and long-polling /sample gives you a stream.
The semantic part is the DataItem dictionary. Every value is classified as a Sample (a continuous measurement like spindle speed), an Event (a discrete change like program name), or a Condition (normal / warning / fault), and has a defined type and units. That is genuinely more than Modbus or raw OPC UA gives you.
The limit is that the dictionary is a floor, not a ceiling. Vendors add their own DataItem names freely, and the corpus reflects it: Haas alone emits spindle speed as SRPM, S Speed, S SPEED_RPM, s_speed_RPM and SRPM (1/min). Standardised categories, unstandardised names — which is exactly the gap normalization fills.
Yes, by design. It has no mechanism to write to a machine, which is why it is frequently the only protocol a plant will permit off the machine network.
The adapter talks to the machine in the machine's own protocol and emits a simple stream. The agent buffers that stream and serves it as MTConnect XML over HTTP. One agent can serve several adapters.
It can carry the data, but its vocabulary is metalcutting — DataItem types assume spindles, axes, paths and tools. For a robot or a chiller the semantics stop being helpful.