PLC Virtual Shared Memory using SQLBridge

How can you accomplish virtual shared memory between PLCs of different models or even different brands? For example, how can you share memory between Rockwell and

Siemens processors? And what problems would this solve?

The first thing I want to point out is that the solution is not complicated or expensive and very few people even know about it. Yet it's the simplest solution in the world and can be setup to work in just a few minutes. The solution, by use of SQL Bridge, simply involves mapping two transaction groups in the bidirectional update mode to the same table. That's all. Each transaction group maps to a single PLC. And did you know you can create additional transaction groups for many more PLCs configured in the same way and have all of them share the same memory? There's no limit in the number of PLCs that can partake.

All this can be configured from only the Ignition Gateway and Designer. You can even launch several Gateway clients and using the Quick Client monitor and manipulate address values in each of the PLCs simultaneously. Everything for configuration and testing in one program and at arms length. How simple is that?

Think of the problems solved. Some gnarliest problems I ever encountered as an integrator had to the with inter-processor communications and handshaking, particularly between different brands or models of PLCs. It usually got complicated. Just documenting all the communication paths and getting my head around them, especially when there were many different brands/ models of processors involved, was onerous. Usually hardware protocol converters were required and talk about a pain, ouch! Handshaking was unreliable and it seemed like communication would always stop at 2am in the morning...always. And none of this was really "shared memory" anyway. Not really.

What do I mean by shared memory? Simple... you change a value of an address in PLC "A" to 99 and a corresponding address in PLC "B" gets the same value of 99. Now if you change the same address in PLC "B" to 33, then the original address in PLC "A" now sees 33. This is the magic of the bidirectional mode. I call it bidirectional mirroring. It's the most useful thing ever for an integrator. A thousand uses. No one else would ever understand the value of this.

But it gets better than that. Transaction Groups are configured just by dragging and dropping browsed tags into them. There are just a few fields to fill out to make it all work and half of those are just dropdown or checkbox selections.

Experienced integrators know that shutting down any system during production is no good. That's why online programming was invented for PLCs. Well, it's the same with SQL Bridge. Need to make an online change? No problem - no need to shut anything down.

You only need the SQL Bridge module and the zero-cost platform all at a price which is ridiculously low. You might want some OPC drivers too but they are equally low cost. I think the pricing committee lost their minds!

Virtual Shared Memory is just one thing out of 1000 things you can do with SQL Bridge. SQL Bridge was my secret weapon when I was an integrator. Now it's yours. Enjoy!

IIoT that Just Works

This is the wildest technology wave I've ever seen. No one wants to be left behind. But as I look over the IIoT landscape it looks mostly like a solution in

search of a problem. The Cirrus Link solution for Ignition is just the opposite.

The Cirrus Link MQTTEngine and MQTTDistributor modules for Ignition provide an out of the box, end-to-end solution which can be setup and running in a matter of minutes. What does it accomplish? It can publish (with MQTTEngine) industrial edge-of-network data to an on-premise or off-premise cloud (MQTTDistributor) and then subscribe to that data (MQTTEngine again) from any number of Ignition servers (for analysis and distribution to end-users). Other enterprise software can subscribe to this cloud data as well with access being determined by role and authentication level.

What's so special about this? Imagine tens of thousands of datapoints (from thousands of edge-of-network devices) all being delivered to any number of Ignition servers with second or sub-second response times even from low bandwidth and unreliable links. Imagine that the tags representing these tens of thousands of datapoints were created automatically in just a few seconds (not a few months) just by subscribing to the cloud and imagine that each tag can be configured with advanced alarms, with history, event scripts, etc. Now imagine that every datapoint is a bidirectional and stateful connection. That's the magical 40,000 foot view.

A third Ignition module by Cirrus Link (MQTTInjector) facilitates the simulation and modeling of an entire IIoT network with thousands of edge-of-network nodes in a snap. So you can setup and test an entire end-to-end system within the Ignition ecosystem and all within arms length on a sunny afternoon.

But it gets even better than that. MQTT is an open standard (see MQTT.org) and compatible edge-of-network hardware devices which can talk practically any industrial protocol on the field side (Director Series) are available from Elecsys Corp.

Arlen Nipper of Cirrus Link is co-inventor of MQTT (in collaboration with IBM). Arlen has a long history with major Oil and Gas companies in data acquisition and control. The major problem has been how to communicate reliably to remote assets over low-bandwidth and unreliable links. The technology behind the Cirrus Link MQTT for Ignition solution has been in constant field use for many years. It is the successful response to problems well known in industry.