MTConnect Graphr: Intern Project

A few months ago I blogged about my first problem statement at my intern. Though I failed to keep up my promise of keeping you updated about it, the app got ready soon enough. It now rests at github. Harnessing the power of HTML5, jQuery and PHP, it delivers just what the problem statement dictated. Meanwhile, I took the liberty of christening it MTConnect Graphr and blogged about its technical aspects at the company blog.

So do check out the post and the app in your leisure time, and of course I’d love to have some feedback. 🙂


Setting up a MTConnect Agent on a UNIX(Ubuntu) machine

While working on one of my short term projects at System Insights Inc., I got a chance to test out MTConnect agent built in C++ over linux(ubuntu). I was surprised to find that absolutely no documentation existed for setting up the Agent in Unix environment. (Yes,  though we all love open source, the majority of manufacturing industries are big enough to afford windows for their systems.) Although it didn’t turn out to be a big hassle in the end, I thought (credits to Athulan for the inception) that it would be a good idea to list down the process of setting up a MTConnect agent on Linux. So, here you go:

Step 1: Download the zip archive of the latest version of MTConnect C++ Agent SDK from MTConnect Github and extract its contents onto your local disk.

Step 2: Download & Install libxml-2.0 and libxml-dev packages from the apt repository.

apt-get install libxml2
apt-get install libxml2-dev

Step 3: Now you need to prepare a Makefile in order to compile the agent. This can be done using the Cmake package.

  • Download & install cmake if you don’t already have it.
apt-get install cmake
  • Open the ‘agent’ folder in the terminal and run cmake and make.
cmake .

Step 4: If everything went right, your agent would be ready to be deployed. You can now start it off as a service.

./agent daemonize

If you are unsure whether the process is running, you can check out the process status:

ps aux | grep agent

The agent service should be up & running. You may change the agent.cfg file in any text editor based on the instructions here.

Have fun 🙂

MTConnect – The Problem Statement

As promised in my last post, I am back to vent out my experiences with MTConnect. Reading up more about MTConnect, I found that it has a pretty easy architecture. There is an Agent which provides XML data representation over HTTP. The data to the agent is fed by either a MTConnect compliant machine tool, or by an Adapter which converts data from legacy machine tools into a format which the Agent can read.

MTConnect Architecture

The MTConnect architecture, and the fact that it sends data in XML stream were reasons good enough for me to test its capabilities out. As per my experience, the best way to learn an API or a language is to assign a goal for yourself. It is always nice to get your hands dirty and learn something new, but before you give shape to clay, you must have an idea of what you wanna shape it into. I had previously done a few projects in HTML, PHP and Javascript. So naturally the first idea I got was to make a cross-browser cross-platform WebApp. Yep. It sounded clean and promised good fun. But it seemed dangerous being so open-ended with something as strong as MTConnect. Hence, I decided to define to myself the limitations of what I actually wanted to do. The PS I came up with was finally something like this:

A cross-browser cross-platform WebApp with ability to

  • Connect to any MTConnect Stream specified by the user
  • Recognize all the devices within the stream
  • Continuously read & display multiple parameters for each of the device
  • Display condition of all components
  • Plot a curve of the variation of a parameter over time
  • Allow user to monitor a parameter and alarm if it moves outside the range of values entered

So much so for the saying – “Well Planned is Half Done.”  In the next few posts, I’ll brief you over the way the things transpired in my tryst with MTConnect.

MTConnect – the beginning

Manufacturing Industries are the unacclaimed giants supporting our present world built on the pillars of consumerism. They use up a great amount of our natural and human resources to produce sell-able products. Most of these industries use huge energy sapping machines which run for most parts of the day an night. Once considered hen with golden eggs, the manufacturing sector is not considered profitable anymore. Reason: the rising cost of raw materials, energy and man power. Hence, it has become imminent that the industry adapts itself to the changing times.

The best method of survival in any field is optimization of resources. We all have the same numbers of hours each day but still some people seem to be able to make much more of the same time. How ?.. The answer lies in optimization. But how do we optimize resources in a manufacturing industry. There are so many factors which hamper such attempts:

  • Lack of Data: there exists very little data on the actual run time of machine.
  • Lack of Standards: with thousands of manufacturers, any attempt of data acquisition gets right down into the bin.
  • Lack of Awareness: manufacturers really don’t know if there is any way out apart from the age old method of operations management

A closer look at the problem reveals the fact that the second factor is the biggest setback the industry faces. If standardized, the act of data collection would be pretty simple and might lead to path breaking innovations in the manufacturing factor. Now this is what MTConnect tries to achieve.

MTConnect is an upcoming manufacturing industry standard to facilitate the organized retrieval of process information from numerically controlled machine tools. It is a lightweight, open, and extensible protocol designed for the exchange of data between shop floor equipment and software applications. Defined as a read-only standard, it presents data from shop floor devices in XML format. The advent and widespread acceptance of such a standard can open many new avenues in the field of manufacturing management. Apart from monitoring the machines, for the first time ever, it might be possible to make advancements in the not so well developed field of predictive quality and predictive maintenance.

During the course of my internship at System Insights Inc, I am getting vis-a-vis with MTConnect. It seems pretty exciting on the outside. Let me see what all will I be able to accomplish with it. More about this in the next post.