Winter SImulation Conference 2011

Had another good year at the Winter Simulaton Conference last year in Tempe, AZ. I didn't get to play golf (which is lucky for everyone else on the course), and there was more rain than I'd like, but the conference itself was probably the best I've been too (out of 6). It didn't hurt that they had the conference mere miles from an in-n-out burger. But I felt that manufacturing is starting to get a little more popular at the conference, which I like.

I also was blown away by Simio for the 4th year in a row, with their announcement of the Risk-based Planning & Scheduling tool they've released. I also took their practitioners training course, which showed me even more how powerful, and great their product is becoming.

Forio was there again and was very interesting as always, as they now have support for running discrete event simulations in "the cloud." Very cool technology, which I think has a lot of potential for helping make simulation more of an every-day tool, on top of the education arena they seem to be popular in.

For the first time, I chaired a session of presentations, and was very impressed with the papers presented on auto-generated simulation models. I also presented in the Sustainability track on manufacturing sustainability (I think...it's been a couple months, and I guess I should have posted this sooner). Anyway, it was probably nothing terribly new for anyone who reads this blog, but I feel it was probably the last I'll talk about my work on CMSD, at least for a while:

If anyone has any comments or questions I'm always happy to respond. Though, the "contact me" link on the top right seems to get to me much faster than the comments. At least until I find a way to automatically subscribe to all comments...

Interactive MT Connect Simulator

In the series of posts I made on MT Connect and a viewer I created for consuming some of this data, I also put up a post on a simulator for feeding data into MT Connect without having an actual machine. The simulator was based in Visio, where I could draw a "toolpath" to follow and a little shape would follow the path spitting out coordinates and breaking down intermittently, all the while pushing data to an MT Connect agent.

This simulator didn't work well for use in developing an MT Connect client I've been working on, because it was just a bit too random. I could never really demonstrate the software the way I wanted, having to wait an indeterminate amount of time for something I wanted to have happen, happen.

So I decided to mess around with building an interactive tool I could use to give a more predictable feel to the demo. I wanted to be able to, for instance, put a machine into a broken-down state and take it out of that state at will. I wanted to preempt a process if it was taking too long, or needed to get another part on the machine.

So the premise for how this simulator works is, I have a bank of machines, as well as some number of part types (3 for now). Each part type has its own processing sequence, and takes a different path through the machines. Each process also has a processing time distribution assigned to it, so they're somewhat randomly distributed (I think just normal).

To use the simulator, then, you grab a part from one of the in queues, and drop it onto a machine. The machine takes over, and runs for a time, and spits the part to the right of the machine. You then have to pick up the part and drop it in the out queue, and it travels to the next queue in its sequence.

Behind the scenes, I have javascript that uses an HTTP PUT to an MT Connect agent (has to go through a PHP script because of cross site scripting issues) whenever some event occurs (part on machine, part off, machine state change, etc...). Double clicking on the left arrow for a machine will make the machine "break down." The right arrow will restart the machine when double clicked. Double clicking the machine with a part on it will preempt the process and kick the part off the machine. It'll have to finish on the machine later. Double clicking the out queue will also preempt the process, but the part is considered "finished" and moves on to its next process.

You can play with it below, and muck around in the source code if you want. It's all made using HTML and javascript, utilizing the Raphael scalable vector graphics library to make the graphics easy. Cool thing is, this more or less works on any browser (thanks to Raphael's support of VML for older versions of IE). At some point I hope to start this as an open-source project so others can add new data items. It'd be good, too, to be able to point this thing at other agents, so anyone can use it. Right now it's hooked to the .NET agent running on our network, so you need a secret code to start submitting to it.

Any comments or suggestions would be more than welcome.

Here is a link to the simulator on the CCAT website.

Process Summary Read/Write

QUEST does not provide a BCL command to give you a process cycle time. Instead, there's an SCL routine called sample_cycle_time that does just that, gives you a sample. If your time is constant then fine, that will return the cycle time for the process. However, if you want to get the distribution name as well as any parameters, you're on your own.

Years ago I put together an SCL script that reads the mdl file for the current model and parses out any process definitions it finds. You could pretty easily modify this routine to use an arbitrary mdl file, if you want.

The script can be found here. the script saves out the definitions to a tab-delimited text file, and tries to open in Excel. I have a constant defined as EXCEL_LOCATION that points to the Excel.exe file, and allows the launch_excel procedure to open an Excel file for you. So you'd have to provide that constant as well.

I have another script that allows me to read the tab-delimited file back in, assuming you've made some modifications to the cycle times you want to apply to the model. At some point I'll post that up.

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.