Etch a Sketch Charting

Every metrics board on every shop floor needs one of these.  Don't like the latest metric?  Shake it until you forget...

Someone should hook one of these up to MT Connect.

Lifehacker Link

eVSM User Group

There is a user group for eVSM on LinkedIn where I and the other developers of the software are members.  We actively read the activity on the group, and it's a great place to reach us for help with mapping problems, as well as submitting feature requests.  We also form feature review groups, which help drive improvement in the software.

Even though it's on LinkedIn, it's an open group, meaning anyone can at least view the contents, without having to have a LinkedIn membership.

eVSM User Group on LinkedIn

As an aside, if you have any suggestions for eVSM you can also submit them by using the Contact Me link on the side of this page...

Player Piano and MT Connect

I recently read Player Piano, by Kurt Vonnegut. The book is about a society that has had almost all manufacturing automated away, and the skilled labor relegated to fixing potholes, essentially being paid to do nothing.

The beginning of the book goes over how things are made. So at one point bright young engineers devised a way to record the movements of master machinists and play them back over again, obviating the need for machinists. Aside from the issue of how you'd go about making a new product or process change without a machinist to record, the idea had to be intriguing in 1952 when the book came out.

The really interesting part, though, is Vonnegut's description of the status display in the office in a factory (which had about 3 people working, total). The display simply shows a brass plaque for each machine, with a status lamp that would flash red if there was a problem.

The point of the book has little to do with how the factories worked, instead dealing with the resentment between the few people who still had meaningful jobs, and those that didn't. It did, however, get me to think a bit about what the point of MT Connect is. If you think you need MT Connect in order to keep all your machines working all the time, then that is completely misguided.

I suggest instead you read The Goal and put some thought into which machines need to be fully utilized. Spoiler: it's only a few of the many.

Which leads me to an encouraging thought: you don't need to connect all your machines in order to get value from MT Connect. You don't need a massive investment in Adapter installation and IT infrastructure. You could instead find your bottleneck resource(s) and monitor those to start correlating downtime with its root causes. Then you can fix the root causes and increase throughput without worrying about the 97% (made up statistic) of machines where it doesn't matter if they're working 100% of the time.

So the question I have now is what would you use to monitor bottleneck machines with MT Connect? Would it be as simple as a lamp for each machine that matters? Really, it could just be a smartphone app that shows a list of machines and flashes red for problems. Ideally it would route alerts to the right people automatically and keep some statistics on performance over time.

If no one beats me to it, maybe I'll build the app. As an aside, it would probably be easy to build using Firebase, which is excellent.

In conclusion, read The Goal and Player Piano and you'll be better off than you were.

Now For Something Not Entirely Different

I've quit my job at the CT Center for Advanced Technology (CCAT), after over six years.  CCAT was the first real job I had out of college, and I learned an incredible amount of skills and worked on incredible projects with incredible people.

I couldn't help it.

I've been given the opportunity to join the folks at eVSM as a consulting developer, helping them add new features to their product, which, if you've read much of this blog, I'm a pretty big fan of.  We'll also get into some new areas which I can't discuss, but it's very exciting for me.

The reason I couldn't help but leave CCAT was, the eVSM gig allows me to be my own boss, and take on contract work with anyone I want to work with.  The upsho is that I'm already contracting with CCAT on some MT Connect work, and look forward to helping them on interesting projects in the future.  I'll post a link when this first contract is done.

At the moment I'm pretty tied up with CCAT and eVSM work, but over time as I get acclimated to working in this manner (read: when I want, where I want, and what I want) I hope to create some great software products that will help people in manufacturing (and healthcare, services, etc...) be great at their jobs.  I also hope some of the five people who read this blog might consider taking on my services at some point.

This probably means I'm not going to be doing much of anything with QUEST, though I expect to be doing something with simulation very soon (probably with Simio though).  I also plan on continuing my participation in the MT Connect standardization process, because I truly think it will be a game changer in the field of Industrial Engineering.

MT Connecting to Twitter

Google Apps Script is awesome.  I've been using Google Apps for years, but until recently (when adding a snooze function to gmail) I had never used or really noticed Google Apps Script.  I'm going to abbreviate it to GAS, which isn't great, but I didn't pick the name.

So, GAS is basically the VBA of Google Docs, in that it's designed to help you integrate many of their services together.  I think GAS is even better than VBA because, for one, you get to write JavaScript, which, outside the browser context, is a joy to use.  It's great that you can just add new methods/properties all willy nilly, which, for someone who's been stuck with VBA for going on 9 years, is pretty great.

Another reason to love GAS (sorry) is that your scripts live "in the cloud", and can be run at periodic intervals.  Combine that with Google Docs' spreadsheet module, and you can do some interesting data collection without having to run software on your own computer.

And now I'll start getting to the point.  Because MT Connect is built on the same technologies as the web, we can use many of GAS's built-in XML tools to pretty easily parse out an Agent's data stream.  Also, remember how I said JavaScript lets you add new properties to objects willy nilly?  Well, the XML library adds XML attributes and nodes to objects, rather than making you have to call routines to check for them and get their values (I'm looking at you, VBA).

So, to show how cool this is, I put together a GAS App in a Google Docs spreadsheet that runs a function every minute, to grab the current power status of our Yasda H40i milling machine, and store the latest value in a spreadsheet cell.  Any time that value changes, the script calls a function to send a tweet on the Yasda machine's Twitter account (@CCATYasda5) denoting the new power status.  Ridiculous?  Absolutely.

At some point I may dig deeper into this tutorial and see if I can set up a UI where you can simply enter a few items (agent URL, device UUID, and data item(s) to monitor) and have it authenticate into your own Twitter account.  But the fact of the matter is, Google App Script made it very easy for me to pull in XML data over the web, pull up the previous status information, and handle authentication into Twitter with very little effort on my part, all for free, running on the web 24x7, which is why Google Apps Script is awesome.

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.