MTConnect Saves from the Fires of Adapter Hell

Mtconnect fireThose of us in the world of discrete and process automation think that everyone is part of the discrete world (individual parts) or the process world (continuous processes). The belief is that everyone uses PLCs and DCSs to control their systems and that their network architectures are composed of the technologies that are most familiar to us: Modbus, Profibus, DeviceNet, EtherNet/IP, and ProfiNet IO.

That’s a very limited view. There’s a whole other world of automation devices – a pretty big one at that – that uses very sophisticated automation systems to generate product. That world is the machining or automated tooling domain. That’s a world with sophisticated cutting and machining tools, specialized processes, and its own terminology and methodologies.

It’s similar to the traditional automation world that we’ve known for the last 30 years – a world before sophisticated information technologies like OPC UA. Like general automation, the automated tooling industry uses sophisticated controllers that don’t interoperate well, legacy machines that have limited or no ability to provide data, and applications that can’t pull all the data they need without very cumbersome and complex interface equipment.

‘Adapter hell’

Just like the process and discrete automation domains, machine tooling facilities were faced with the prospect of creating or acquiring unique, sometimes custom, adapters or interfaces for every machine tool on the network and every machining center software application. The lack of any common machining communication standard created a situation that Dave Edstrom, president of the MTConnect Institute, described as “adapter hell.” Shop floor integration was complex, laborious, inefficient and expensive.

MTConnect, started in 2006, is the solution to that problem in the machine tool industry. MTConnect has become the universal interface that connects machine tools to the rest of the digital world. Prior to MTConnect, shop floor machine monitoring of a series of disparate tools from different vendors was impractical for all but the largest, most profitable, and most technologically adept machine shops. MTConnect democratizes the machine shop floor and brings the ability to provide sophisticated analysis in the machining realm – live monitoring, fault notification, fault prediction and trending, efficiency reporting, and so on – to even the smallest machine shops.

In Contrast to OPC UA, MTConnect is a pretty simple technology built on two very well-known standards: XML and HTTP. Very simply, MTConnect can be thought of as a well-defined standard for sending machine shop floor data as XML files. MTConnect uses simple HTTP Get instructions, the same instructions used for web servers to deliver web pages, to request machining data from a controller.

Simple technology for small industry

This works very well in the tooling industry as the industry is small enough to define a common vocabulary and information model semantics to serve most, if not all, information transfer requirements of the industry. Items like power on/off, spindle speed, axis position, axis speed, feed, block number, status, CNC mode, work number, alarm, spindle load, axis load, spindle override, and the rest are common to most of the equipment in the industry.

MTConnect defines two devices that comprise the software functionality needed to transfer data from a machine controller to an application: Adapters and Agents. Adapters are software components that interact with the machine controller. An Adapter translates the machine controller data from its often proprietary values and format into the common terminology of MTConnect. For example, an Adapter would translate a speed value in feet/minute to the Spindle Speed (a standard term) value in mm/sec (the standard units).

Software devices that interrogate Adapters are known as Agents. Agents have two functions. One, collect data from one or more Adapters, and two, provide that data to applications. Agents communicate with Adapters in whatever communication mechanism is available from that particular Adapter. The MTConnect standard does not define how data moves from Adapter to Agent.

Agents are the software components that respond to HTTP Get requests from applications with XML files. Those requests can include Probe requests which are requests for the XML Schema for a machine controller or Stream requests which are data requests. The XPATH language is supported which provides the capability to limit requests to specific values.

So someday, while you are wandering around the plant trying to avoid that late afternoon meeting with your boss, and you make a wrong turn and find yourself in the tooling area of the plant, you’ll know something about the protocol that makes all that tooling work: MTConnect.