HTML5/JavaScript MT Connect Viewer

In my last few posts, I've talked about what MT Connect is, how it works, and why CCAT is excited about it. Now I want to talk about a proof-of-concept web-based viewer I've created for viewing the real time status of our machine lab.

As I said before, an MT Connect agent provides the current status of the devices talking to it, by returning an XML string with all the details in it. Since the advent of AJAX it's been very common for developers to create web-based applications that hit a server for XML data, and on loading it, modify what's being shown on a web page (using DOM manipulation). This is basically the strategy I wanted to take, with the added feature of using the HTML canvas element included in modern HTML5-compliant web browsers. The canvas basically allows you to draw in 2D on a portion of a web page. The great thing about using HTML and JavaScript is, it works on any platform that supports HTML5 features (including iPad/iPhone/Android browsers).

One reason I chose the canvas element was because we had built a flash-based viewer a few years ago for a single machine, which just listed out some of the MT Connect data we were getting in real time (spindle speed, etc...). But now we have three machines (and maybe more in the future) that we'll want to be able to view at the same time, so I thought having an overhead view of our layout would be a cool way to get heads-up info on what's happening in our lab.

Luckily I had built a basic JavaScript library for creating and drawing 2D shapes on a canvas when learning JavaScript. So all I really had to do was write some code to interrogate the Agent, extract data on the machines I wanted to know about, update the 2D shape objects with the right information, and let my graphics library handle the graphics.

So to start, I used a VBA macro in Visio to export my 2D layout to JavaScript code that would create 2D shape objects in my graphics library format. So at this point I had a canvas element that would draw our machine lab layout, which was a great start.

I then added a JavaScript function that uses JQuery to get an XML string from my MT Connect Agent detailing the current status of my machines. I also used JQuery to convert the XML output into the JSON format, which converts the XML data into native JavaScript objects, and step through the XML tree to find what I need.

All that was required now was a function that would get the current status information as JSON data, and map that data to my 2D shape objects, and then call itself after some interval (using setTimeout). So I wrote that function, and it works pretty well, just turning machines different colors depending on their current state. You can click on a machine, and see some more detailed information pop up on the side.

I've also played with storing the last 150 spindle locations and drawing that on top of the machine, but the problem there is converting the spindle locations into relative locations within the bounds of its machine, otherwise the toolpath usually leaves the bounds of the machine. But if you watch long enough you see it follows the shape I set in my MT Connect machine simulator.

I've also started playing with pulling in other information, like temperature, and displaying that. Right now my simulator doesn't modify the temperature but that should be easy enough. I can see it working where there's a little thermometer shape next to the machine that changes color with increasing temperature. Or even a spindle shape that moves around drawing the toolpath line and changing color with temperature. There's also a power consumption aspect to this all, where maybe I draw bar gadgets next to the machines so you can see at a glance which machines are using the most electricity.

Regardless, MT Connect can provide some very interesting data, but there's a lot of it. At some point the really hard part will be in gleaning out what a user wants to see and only showing them that.

One issue I ran into while building this tool had to do with cross site request issues. An MT Connect agent is basically a webserver, except that it only serves XML strings based on what URL you go to. You can't serve arbitrary files (like JavaScript/HTML files). This isn't an issue if you're writing an application in VB/A, for instance, because the XMLHTTPRequest object provided by Microsoft doesn't care where the request is going to. However, the XMLHTTPRequest does care when it's being called in a web browser. Basically, any AJAX request you send has to be served by the same server that gave you the HTML document your JavaScript is running in.

So to get past this issue (which is a showstopper, if you can't actually get anything out of the agent) I used a PHP script that when called, retrieves /current from the agent, and returns that to the caller, keeping the request on the same domain, as far as the browser knows. So that works well enough, it seems, but it now means anyone who wants to do something similar in the browser has to also have php running (or some server side scripting that can do the same thing).

One other issue I'd like to mention is that I have to use a JQuery library for converting the XML output string of the agent into the JSON format, for creating native JavaScript objects. It'd be very cool if JSON was an option for output on the agent. Maybe that should be something I work on building, and if successful, contribute it to the project and try to get it included in a release.

For now, you can see the veiwer at ccat.us/mtconnect. At some point, I hope the simulated data goes away, and we can start showing the real status of our machines. I'd also like to work at automating the creation of these HTML pages so that other MT Connect users can view their shops using the same code I've written. We'll see where this all goes. In the meantime, I cobbled together another version of the viewer that shows the status of the simulated machine at agent.mtconnect.org as well as the toolpath the spindle is following (right now it only keeps about 20 points, and kinda looks like the game "snake", but I might up that value to show more points.

Contact me at jfournier@ccat.us if you have any questions about this.

Machine Simulator for MT Connect

In my last post, I talked about how MT Connect works, and how our machine lab isn't yet hooked up to an MT Connect agent (though we're working on it). While I'm waiting for the machines to be connected (and to provide some more lively data) I've created a very basic machine simulator with a fake MT Connect adapter built into the simulation, to provide some action to an agent, ultimately letting me view that action in a web-based tool.

I built the simulator using Microsoft Visio. Basically, I created a fake tool path for a spindle to follow, by just drawing a bunch of node shapes, and connecting them using splines. Then, I created a circle representing the spindle of a machine. The device/spindle shape also holds custom shapesheet attributes mapping device attributes to the device/data item ID's for the machines defined on my agent.

The spindle shape just follows the path of the lines (using a Visio animation routine I built a while back), and at each animation update (set to 2 seconds) it sends our MT Connect agent the current location of the spindle, as well as the current status of the virtual machine (working or broken down). You can see a screen shot of the simulator in action below:

To handle reporting the state of the machine, I just hold a "Next State Change" time on each device object, and on every update see if that time has elapsed. If it has, I flip states (from working to broken or vice versa) and then schedule the next state change event for that machine. Very basic stuff.

I mentioned in my last post that the two agents I've used (available at https://github.com/mtconnect) both allow you to use an HTTP "PUT" request to store information about a machine. So, every time I want to update my MT Connect agent, I just create an XMLHTTPRequest object in VBA (from the Microsoft XML library reference) and open a URL that basically looks like this: http://mtagent/storeSample?timeStamp=(current time)&dataItemID=(data item id for x location, or whatever)&value=(whatever value to store)

With the simulator created, I just set up three device shapes in Visio; one for our Haas machine, one for our Hurco, and one for our Yasda. These machines were already defined in our Devices.xml file on our MTAgent server, which is where our MT Connect Agent gets run from.

By using the simulator to populate data for our real machines, I was able to build a viewer that would dynamically update and show the latest status of all our machines (even though the status was fake). Now, when we get the machines hooked up for real, the same viewer will be able to show the actual status of our machines, which will include a lot more than just spindle X/Y location and if the machine is running or not.

In my next and final post on MT Connect (for the next few weeks at least) I will talk about the HTML/JavaScript viewer I wrote for viewing the current state of our machine lab.

MT Connect Basics

So CCAT has been tracking this standard/protocol called MT Connect for a while. I've been very interested in it, especially from the standpoint of consuming all this great data that machine shops with MT Connect can generate. I think we're still a long way from having this tool be as ubiquitous as general CNC machining, but I'm hoping CCAT is there with some incredible tools when that does happen (and I think it's inevitable).

So in this post I'd like to talk about how I constructed a web-based viewer for MT Connect data. But first, I'd like to talk briefly about how MT Connect works, as well as how I'm generating data for this proof-of-concept.

MT Connect has been created as a data protocol, and really nothing else. My understanding is that it exists to standardize/define things like: for a milling machine the spindle is where the tool is, and the spindle turns at a rate called SpindleSpeed, and there are certain units that can be measured in, etc... The protocol also defines several key terms: agents, adapters, and devices.

A device is just a discrete unit that can be connected to MT Connect. The most important devices typically are the machines/controllers themselves, but I know the standard involves more than that, including bar stock feeders, tool holders, all kinds of stuff.

An agent is basically a software executable that sits somewhere and listens to things that devices want to tell it. The agent also is able to be interrogated by client software that wants to know things about devices. The agents I've dealt with so far (both are open source and free to use: https://github.com/mtconnect) are implemented using TCP/IP, meaning they work over the internet/web.

The two agents implement HTTP web servers, which allow you to interrogate them using regular web technologies (i.e. the "GET" XMLHTTPRequest). When you interrogate an agent, it spits back your data in an XML file, which is very easy to program for. The two agents I've used also allow you to use HTTP "PUT" requests to store information about devices, meaning you can update an agent even by visiting a URL in your web browser. Very cool, and easy to do.

So, probably the most difficult item here is the adapter. The adapter is what allows a device to talk to the agent. Machine tools typically use their own proprietary protocols and data formats and terminologies within their controllers. A Fanuc controller can put out completely different data streams than a Haas controller, even if they're saying basically the same things.

So an adapter has to be made for converting from one controller "language" (proprietary format/protocol) into the standard MT Connect protocol, and then sent to the agent. So that's the adapter's job. The adapter can live on the controller as a separate piece of software (if the controller allows that) or it can live on a computer that sits near the machine and communicates with it over a parallel or serial cable. Either way, the adapter provides a stream of data about its machine in a standard format.

So CCAT has this Advanced Manufacturing Center where we have a few machines on consignment from Yasda and Hurco, as well as housing our Laser Applications Lab. We want to have these machines hooked up through MT Connect, but we're still working to install the correct adapters for these machines. In the next post, I'll talk about how I built a machine simulator that also acts as an adapter, sending the status of a simulated machine to an MT Connect agent.

MT Connect and CCAT

MT Connect is a protocol/standard developed for the purpose of allowing machine tools to communicate information about themselves to other computer systems. For instance, this allows a machine to report its current status - whether it's broken down, working, or idle. It can also report its current spindle speed, feed rate, location, and even the current line of g-code that it's running.

All in all, it's a pretty great way to be able to collect activation/utilization data on any machine, regardless of the brand or make or model of controller running it. The obvious upside for simulation users is that you can process the data from a machine and get a list of state-change events and what times they happened at. This data can be run through a distribution-fitting tool, and spit out mean time between failure and mean time to repair distributions. There's a very good paper on this topic here.

The standard is still evolving. Right now it really only covers the machine resources on a shop floor, but at some point I hope it will include labor resources, and part/process tracking. This would allow us to get accurate cycle time/setup time observations on a part-process-machine level, and get us to the point where simulation models can be initialized to the current state of the system being modeled, and then run to predict the next few hours or days or weeks worth of production.

MT Connect can help turn simulation users into basically a weather man, though instead of predicting the weather they're predicting when jobs will be completed and planning contingencies in case a machine goes down. Powerful stuff.

And CCAT is hoping to help make this a reality. We have been attending the MT Connect standards meetings, and I just finished developing a proof-of-concept JavaScript/HTML-based viewer for MT Connect, which I'll detail more in a post to come.