Eight years ago when I first encountered MTConnect, I felt the technology would transform the machine shop. Today, support for MTConnect is commonplace in new machine tools, and often available for older tools through various upgrade options. Software packages exist to collect and analyze data on a server or on the cloud. However, I thought the technology could become a lightweight option not only for data analytics, but also for basic machine shop automation.
What is Automation?
A simplified definition of automation might be “when something happens, do some other thing automatically.” By making machine tool status accessible remotely using open web technologies, MTConnect solves half or problem. It tells us “when something happens” on the machine tool. Yet though there are many MTConnect data analytics tools, I have not seen any generic automation systems based on the standard.
Maybe You Haven’t Looked Hard Enough?
Possible. If you’re aware of an MTConnect-based automation platform, please let me know. But I have run a few quick Google searches. I’ve turned up a ten-year old article on using XML in automation, with a focus on OPC-UA. I’ve found a whitepaper on uses for MTConnect, but aside from a mention of alerts, it hardly touches on automation. I even found an article from the International Society of Automation entitled The Next Generation of MTConnect Applications, but with little mention of automation.
Maybe It’s So Easy Everyone Is Already Doing It?
The concept is pretty simple: monitor an MTConnect stream for changes, and when something interesting happens, act on it. Even if using MTConnect to automate machine shop activities is trivial, it seems there would still be mention of it: in articles, on the MTConnect forums or user wiki, or elsewhere.
If everyone is already automating with MTConnect, they don’t seem to be writing much about it. And if that’s the case… someone should, so now someone has.
Maybe It’s a Dumb Idea?
Most of my ideas are. Perhaps MTConnect is not suitable for machine shop automation. After all, many tasks in a machine shop require realtime guarantees, or relate to safety-critical operations. For those, an application-layer software protocol is not the way to go. The answer is dedicated safety-rated PLC hardware.
It’s also possible that no one us automating with MTConnect because the older, existing tools are more familiar: if you’ve already taken the time to connect your devices over DeviceNet, ModBus, OPC-UA, or any of the many other industrial protocols, redoing it with MTConnect is reinventing the square wheel.
Or Maybe It’s Just Hard?
Also possible. MTConnect solves the problem of knowing “when something happens” on the machine tool, but the other half of the problem is harder. If you want to “do some other thing automatically,” and that thing involves controlling a machine tool, then it seems we’re still stuck with using some other protocol or manufacturer library to interface with the tool.
This is not a show-stopper problem. Plenty of possible automation tasks, such as notifications, could still be handled in a generic manner. Even tasks that do require interacting with a machine tool could be handled through plug-in actions or scripts.
So What Might We Automate?
Anything that we want, within the limits of what MTConnect reports.
- Condition notifications. When a “warning” or a “fault” condition occur, send an email / text message / Twitter DM / Bat signal.
- Any kind of notifications, really. Open a trouble ticket with maintenance based on temperature, alarm message, or after every 1000th part.
- Closed-loop feedback. If a measured value (temperature, hydraulic level, etc.) strays out of bounds, activate a corrective action until it returns to normal.
- Simple integration. Fred still insists on tracking inventory in Excel? When the part count changes, look up the program name and increment the appropriate spreadsheet cell.
How Might We Automate?
Earlier I documented my attempt to build the TrakHound MTConnect.NET library on Linux. My intent in doing so was to use it as a basis for something similar to what I’ve been talking about. From there, it’s simple to stream MTConnect data. Once the data is streaming, we’ll need to check the data items against a configurable set of criteria. Then, when we find a match, we’ll need to be able to do something useful, in an extensible manner.
If anyone is interested, let me know and I’ll continue.