PLC Shift apps are tag-based and can run on most Debian-based Linux systems. They can also publish and subscribe to tags using MQTT transport with Sparkplug B payload. This raises some interesting possibilities, like running PLC Shift apps in a data center, instead of at the edge.
Reasons to do this include:
Less hardware at the edge, reducing power consumption and complexity.
Increased cyber security, as a data center is easier to secure than computers in the field, which are susceptible to attacks based on physical access.
Of course, this requires robust and reliable communications, but communications reliability is increasing every year, and end users continue to make investments in communications infrastructure.
This demo requires PLC Shift version 1.5 or later
PLC to Gas Flow Computer
In this system, we use a Rockwell Automation Compact Logix PLC to generate the differential pressure (dp), static pressure (sp), and temperature (temp) inputs that are needed by the gas flow computer. We use the PLC Shift Datalogger app to pull data from the PLC once per second using the EtherNET/IP protocol.
The data logger then publishes the values to the MQTT Broker whenever the values change. We use Node-RED to subscribe to the values that are generated by the data logger and republish them to a topic that the gas flow app expects. This is required because Sparkplug B publishes data to a topic on the #DDATA# channel, but the gas flow computer is required to subscribe on the #DCMD# channel. The gas flow app calculates corrected flow and exports all of the flow history to the cloud.
Node-RED must have the node-red-contrib-mqtt-sparkplug-plus package installed. This makes it easy to work with SparkPlug B payloads.
We start by subscribing to the topic spBv1.0/plc-shift/DDATA/edge/dl-test-mqtt/ in Node-RED. In this case, the Sparkplug B group ID is "plc-shift", the device name of the PLC Shift device is "edge" and the app name is "dl-test-mqtt". All of these values are configurable in PLC Shift Manager. The datalogger app publishes Sparkplug B metrics to this topic. Metrics are serialized into the message's payload using the Sparkplug B binary format.
Each value that is published via SparkPlug B has a 64-bit unsigned integer alias. We use this alias to determine whether each published metric is the dp, sp, or temp, and then apply the tag name that the gas flow computer expects and also zero out the alias. We zero out the alias so that the subscribing application can match the tag by name, instead of using the alias. When the alias is not zero, the PLC Shift runtime will try to match by alias instead.
Each parameter in the PLC Shift app has a unique parameter ID, which is where the alias comes from. The parameter ID isn't shown anywhere, but we can tell you what it is, so contact us at support@reverity.io if you need help. We'll fix this oversight in a future release.
We then publish the updated metrics to the spBv1.0/plc-shift/DCMD/edge/gf-test-mqtt topic. The gas flow application is subscribed to this topic. The gas flow app sees the updated values.
The code in the Node Red function is shown below, and the entire flow as well as app configurations can be downloaded here.
This demo requires PLC shift version 1.5 or later
if(msg.payload.metrics === undefined)
{
// return the original message
return(msg);
}
var metrics = msg.payload.metrics;
//console.log(metrics)
//console.log(msg.payload.metrics[0])
//console.log(msg.payload.metrics[1])
//console.log(msg.payload.metrics[2])
var count = 0;
for (var i = 0; i < metrics.length; i++) {
//console.log(metrics[i]);
//metrics.push(msg.payload.metrics[i]);
if (metrics[i].alias.low == 1116468)
{
metrics[i].alias = 0;
metrics[i].name = "Inputs/temp";
//console.log("temp " + i);
}
else if (metrics[i].alias.low == 1116268)
{
metrics[i].alias = 0;
metrics[i].name = "Inputs/dp";
//console.log("dp " + i);
}
else if (metrics[i].alias.low == 1116368)
{
metrics[i].alias = 0;
metrics[i].name = "Inputs/sp";
//console.log("sp " + i);
}
count++
}
//console.log(metrics)
//console.log("end");
var newMsg = { payload: msg.payload };
return (newMsg);We're using the PLC Shift Datalogger app to read the tag values from the PLC using EtherNET/IP and to publish them via MQTT, but this app can only move data from the PLC to MQTT. It cannot move data from MQTT to the PLC. If bidirectional data flow is required, then another piece of software, like Ignition Edge, should be used at the edge, instead of the PLC Shift DataLogger.
The animation below shows tag values from the data logger at the top and tag values in the gas flow app below. Values are polled from the PLC by the data logger and published to the broker using MQTT. The gas flow app has subscribed to tag values via MQTT.
The values change in the data logger app, and then shortly thereafter appear in the gas flow app as inputs. Everything is kept in sync, and API requirements for one-second update times are met. The PLC program that is generating the tag values includes some noise, so that tag values are always changing and are realistic.
Conclusion
PLC Shift applications are quite flexible, and many different deployment architectures are possible, including deployment to the datacenter. Note that using MQTT is only one option. We could also poll the PLC directly using EtherNET/IP from the data center, assuming that latency and communications reliability requirements are met.
We didn't show containerized deployment, but preliminary testing shows that it's possible. We still need to do some work here to create a polished solution.
PLC Shift adapts to your requirements, instead of the other way around. Let us know what you're trying to do, and we'll do our best to make it work.