A (slightly) better MTConnect monitor

Awhile back I created a simple MTConnect monitoring application in HTML5 and Javascript. In doing so, I also looked at a few methods of accessing MTConnect data from a web application, and a few problems I ran into along the way.

Since then, I’ve fiddled with the code a bit. No big changes, just a minor update.


The newly renamed Agent class (formerly MTConnect.js) now triggers three types of events:

  1. A devices event whenever an MTConnectDevices document is received.
  2. A streams event whenever an MTConnectStreams document is received.
  3. An errors event whenever an MTConnectErrors document is received, or when some other error occurs.

This allows an application to receive notifications whenever the Agent retrieves an MTConnect document, by using jQuery.bind() to provide an event handler.

Slightly better streaming

In the previous article, the MTConnect monitoring application simply polled the MTConnect agent for the current state every five seconds. At the time, I said that was fine for a basic application that just displays a snapshot of the device state, but would miss any transitions shorter than the polling interval.

I also mentioned that the MTConnect standard includes support for streaming using x-mixed-replace, but lack of consistent cross-browser support makes it unusable in a Javascript application. (If anyone has gotten this working, please let me know. It would greatly simplify things.)

So to make sure that the application receives all DataItem changes the Agent class first requests /current from the MTConnect agent. It then, in a loop, requests /sample from the MTConnect agent, each time using the nextSequence attribute from the Header tag of the previous request.

This ensures that the Agent class will not miss any DataItem changes, except in two exceptional cases. First, if the instanceId attribute of the Header changes, this indicates that the MTConnect agent has restarted. Data may have been lost. Second, if the MTConnect agent returns an MTConnectErrors document, an error occurred. In either case, we have to restart the process, because we cannot assume that no changes occurred.

A monitor() function

For convenience, all of the above is wrapped up in a convenient Agent.monitor() function. All an application has to do is create an instance of the Agent class, bind event handlers for any events it wants to process, and then call monitor(). It does all of this asynchronously, so it won’t block the rest of the page code.

var agent = new Agent(options);
var $agent = $(agent);
$agent.bind('devices', function(e, doc){
//...code to handle devices document
.bind('streams', function(e, doc){
//...code to handle each dataitem
.bind('errors', function(e, doc){
//...code to handle errors

It would be more convenient if I didn’t have to maintain a separate agent and $agent variable, to store the actual Agent object and the jQuery wrapper for it, respectively. Then I could simply chain the requests to have something like:

// This doesn't work, but would be nicer.
var agent = new Agent(options)
.bind('devices', function(){})
.bind('streams', function(){})
.bind('errors', function(){})

That would allow the creation of a complete monitoring app in what is essentially a one-liner. I’ll keep working on it.

Demo user interface

Not much to write about for UI changes. I just recently got a new laptop running Windows 8, and I sort of like the metro tiles, so I’ve modified the CSS to mimic that style slightly.


I’ve also added an “interval” input, that uses a jQuery UI spinner widget to allow the user to enter a numeric value for the polling interval.


Next steps

Well… most of the “next steps” items from the last article are still to be done. I’m trying to decide whether it would be beneficial to anyone to wrap this Agent class into a jQuery plugin and continue to develop it.

Beyond that, I’m also planning on putting together some basic widgets to display data at a higher level than just individual DataItems. I have a work-in-progress “device” widget working that displays the device name and color-codes the background based on device Execution mode and Availability.

So that’s about it. Not much new to talk about. As always, I’ll continue to work on it as free time and interest allow. See the GitHub repository for the most up-to-date version.


2 thoughts on “A (slightly) better MTConnect monitor

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s