Java Tops the Charts of Programming Language Popularity

There are two indexes I'm aware of which measure the popularity of programming languages.  The most referenced one is the TIOBE index.  I've watched it for a number of years with Java being in the #1 position usually.  The latest rating for March 2016 shows Java has advanced far out into the #1 position by a long shot. Python comes in at position #5.

The TIOBE index is apparently calculated by an algorithm applied to data found on the web by a web crawler.

Another index is the PYPL index (PopularitY of  Programming Language) which is calculated based on Google Trends and how often language tutorials are searched by language.  According to this index Java is #1 by a massive margin and Python is #2.

There are other corroborating sources.  Inc. Magazine ranks Java as #1 with Python coming in #2.  C comes in at #3.  Another interesting approach is based on job listings for programming jobs such as is reported by CodingDojo and which lists SQL as #1 (though not really a development language as you would normally think of one), Java as #2, and Python as #5.

CodeEval claims to be more of a language predictor based on the languages that over 2000 tech industry employers are testing for.  According to this index, Python has held the #1 position for four years in a row with Java coming in at  #2 and with a huge margin over C++ which is in position #3.

It's interesting to note that Java is the clear leader no matter which approach is used.  Python's rating is more varied, but it is always at or near the top of the list.

For me, it's reassuring to know the language choices we made ten years ago are still top of the list in popularity.

Open Source Publish-Clients for IIoT

Cirrus Link will release open-source MQTT publish-client libraries through the Eclipse Foundation in the second quarter of 2016. Libraries will be available in C, C#, Java, Python and JavaScript. Java will be available as a standalone library, as well as a module for Kura. Kura is a Java/OSGi-based framework for IoT gateways.

These libraries leverage the open and popular Google Protobuffers standard, as well as the Kura definition for data which just happens to align nicely with common PLC datatypes. They will be released concurrently with the open Sparkplug standard which tracks "state" though the use of birth and death certificates.

What is little understood by the larger IoT audience is that in the IIoT setting, "state" is required. SCADA is useless without state. The Sparkplug standard wraps up the MQTT definition, Protobuffers for data representation, Kura specifications for datatype definition, birth and death certificates to provide "state" and other simple mechanisms to make MQTT useful in SCADA applications.

Any publish-client compatible with the Sparkplug specification will also be a proper Ignition citizen through the use of the MQTT Distributor module. This makes me want to build some sort of edge of network device using Raspberry Pi or BeagleBone. I've got a few ideas. Now I just need some time.

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.