Node-RED and MTConnect

Node-RED and MTConnect

Stock photo that turns up in a search for “Node Red”

Recently I noticed a few visitors to this site were searching for information on MTConnect support in Node-RED.

I’ve never used Node-RED before, but thought this would be a good reason to take a first look at it.

What’s Node-RED?

Originally developed by IBM, and released as open source software in 2016, Node-RED is (to quote its website) “a programming tool for wiring together hardware devices, APIs and online services in new and interesting ways.”

Node-RED allows you to describe IoT hardware, online services, databases, and other APIs as nodes, which can be connected and laid out into a “flow” that performs useful actions.

Installation is easy — a one-liner on the command line if you already have NodeJS and NPM.

Its browser interface is a drag-and-drop “visual” paradigm that, depending on your background, might vaguely remind you of VSCode, ladder logic coding, Scratch programming language, flowcharts, or even HyperCard.

Once deployed to the Node-RED server, each “flow” will perform whatever actions were visually laid out in the browser.

Flows can easily be exported to JSON, making them easy to share and move from server to server.

How does it work with MTConnect?

Node-RED is meant to automate flows that include online services, and hey, MTConnect is an online service.

After walking through two tutorials on the Node-RED website, I tried to create a basic flow: when triggered, send a request to an MTConnect agent for current data, then process the resulting XML.

Putting together a simple flow to retrieve data from an MTConnect agent.

The trigger was an “inject” node. The HTTP request was an “http request” node, configured to request https://smstestbed.nist.gov/vds/current. Next came an “xml” node, which processes boring old XML into more easily consumable JSON.

MTConnect data, in JSON form, in the Node-RED debug window.

From there, getting header data (such as timestamp and next sequence number) and the device streams data was a matter of processing the JSON using Javascript. Easy.

What Next?

This is the most basic example possible. A real solution for MTConnect would include handling error messages from the server, and of course, doing something useful with the MTConnect data.

Since MTConnect is HTTP-based, processing errors would mean adding “switch” nodes to handle HTTP error codes, and to handle cases when the MTConnectAgent returns an error document.

Doing something useful with the MTConnect data would mean some sort of output. This might happen through websockets, TCP, HTTP, or by linking to another flow that handles the hard work of doing something.

Although Node-RED “inject” nodes can be set up to periodically fire a trigger, I have not yet found a method to handle MTConnect’s multipart/x-mixed-replace-style streaming.

This is not a deal-breaker — a periodic trigger can be combined with nextSequence to periodically retrieve any new data — but it looks like Node-RED could more easily handle streaming if the MTConnect spec included a websockets interface.

Regardless of this, it seems that Node-RED could be used to automate actions based on MTConnect, which could make it the basis of a notification flow or a machine monitoring system.

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: