My last post looked back on some of my unfinished projects. At the time of its writing, I was in a retrospective mood, and not just because it was the end of the year.
After five years with the same company, I left my position at the end of the year. Three weeks into the new year, it’s too early to say how things will work out, but I know it was the right move. Still, I look back to see a lot of unfinished business: proofs-of-concept, prototypes for products that never materialized, pet projects perpetually on the back-burner, and so forth.
Sadly, I won’t get to see them finished.
I enjoyed working both in the THINC realm and in the growing MTConnect realm. Most of my posts in this blog were about one or the other. Since my new job is in a different field, unfortunately it seems unlikely that I’ll be able to continue working with either.
To the folks who visited this blog either for THINC or for MTConnect, thank you for visiting. I’m always open to answering questions or providing quick code examples for either technology. (My ability to answer questions about THINC may be limited, as all of my documentation and libraries now reside with my former company.)
As for this blog, time will tell what direction it moves from here.
(As the year 2013 comes to an end, I’m looking back at some of my unfinished projects from the past year. This article is about projects related to MTConnect.)
In the past year, I have written about MTConnect quite a few times. And I’m not a paid shill or anything. After so many years in the machine tool industry, dealing with islands of isolated proprietary data, the openness of the MTConnect standard is very exciting, particularly since it has the backing of so many industry giants.
Not all of my projects are what I would consider finished, though.
Awhile back, I wrote a Frequently Unasked Questions post, in which I answered questions based on popular search results for this blog.
Since then, the search terms leading to this blog have changed a bit, so here are some more answers to questions that nobody actually asked me…
For anyone else out there developing an MTConnect Adapter in .NET:
I’ve forked the AdapterLab project from this year’s [MC]2 Conference, and am working on wrapping it into a proper toolkit for developing MTConnect adapters in .NET. The forked version is located here.
Since the time I created this blog (a little less than a year ago), I’ve checked the site statistics quite a few times. Of particular interest are the search keywords that lead new visitors here: knowing the terms that people search for when they visit this blog helps me understand what type of information visitors expect.
Predictably, many of the terms have to do with machine tools: “MTConnect”, “Okuma”, and “THINC” turn up quite often in the search terms. Others are a little more surprising.
I think of each search term as a question that was never asked. So in this post, I thought I’d take some time and answer a few visitors’ unasked questions.
In my earlier post, Set up an MTConnect Agent in three or so steps, I mentioned that pre-compiled Windows binaries for the MTConnect Agent would be more convenient.
Since then, their GitHub repository has been changed to include link for a pre-built MTConnect Agent for Windows. Convenient, neh?
Hi! This article is very old and outdated. You might consider checking out this newer article on installing the MTConnect Agent.
In the past few months, I’ve written about MTConnect on several occasions. I’ve even posted a walkthrough for installing the MTConnect agent on a Debian system.
Lately I’ve seen a few visitors searching for information on MTConnect agent setup. I don’t really have a walkthrough for completely setting up the MTConnect agent, but I thought I’d post a very brief overview.
“I know exactly what is happening on my plant floor.” At the [MC]2 2013 conference last week I was introduced to what were called Turner’s Five Laws of Manufacturing. One of those laws: whenever someone tells you that, don’t believe them.
Better yet, try the following. Ask them to pull out their smartphone. They do have one, right?
- Ask them how the S&P is doing. (As I write this, it’s -26.33 for the day to 1,548.24.)
- Now ask them for this evening’s weather forecast. (Low 60°F, 30% chance of rain.)
- Now ask them for the part count, hourly efficiency, and downtimes of their machines since 8am today.
Dave Edstrom and John Turner made this point in the conference lectures. We live in an age when Siri can give us directions to the nearest Applebee’s. How many machine operators receive a notification when one of their machines goes down? The penetration of machine monitoring packages on the shop floor is still surprisingly low.
The repeated MTConnect mantra has been “different devices, common connection”. As evidenced last week at [MC]2, multiple companies are working to provide solutions to all sorts of problems in the machining realm: live monitoring, fault notification, fault prediction and trending, efficiency reporting, and so on. With so many solutions available, any shop ought to benefit from at least one of them.
But all of this work on the software side comes down to one question: does your CNC speak MTConnect?
Since then, I’ve fiddled with the code a bit. No big changes, just a minor update.
NOTE: For improvements to this simple monitor, see the post A (slightly) better MTConnect monitor. Source code available on the GitHub repository.
The story so far: we have several possible methods of retrieving data from an MTConnect agent into a web application, although none are entirely client-side. Knowing that, let’s create a simple MTConnect monitoring application.