Friday, June 8, 2018

The Arnold Classic 2018: Enter Raspberry PI

The Arnold Classic 2018: A place for those with a passion for sport, fitness, and an overall desire to challenge themselves, compete, and to ultimately be blessed with the eternal spoils of victory after an arduous two and half days of pushing their bodies and minds to their absolute limits.

Enter IDX, what challenge faces the mighty IDX you ask? Will we dead lift four hundred kilograms worth of ice cold steel, and prove ourselves stronger than a ‘mountain’? Will we sprint that one-hundred-meter sprint faster than a ‘bolt’ of lightning? Will we outplay the E-Sport community to be crowned the ultimate gamers in the land?

Well… not quite, but we did create an awesome solution for managing the chess timers in the Big Chess School tournament, using some cutting-edge technology, including but not limited to:
  •           Raspberry PI Model B as our hardware platform running Raspbian Stretch
  •       Node as our underlying server
  •           Node-Red to handle the Raspberry PI’s GPIO
  •           MQTT to handle message transmission to and from the web server and its clients
  •           Javascript/ReactJs for the user interface.

The Raspberry PI plugged into the impressive “PI, Modbus PSU & IO Interface” developed by our friends over at danntech, this was placed inside of a giant chess queen supplied by bigchess. Which housed and powered the PI as well as some sparkly lights and buttons that the school kids would be smashing to start and stop their timers:

The requirement was to have three of these rigs all running in parallel so that multiple games could proceed at once, we had a web server running on a laptop mounted to the bottom of one of the screens, this laptop also hosted the MQTT broker. Each Raspberry Pi had a Node-Red setup which would interpret the GPIO values and publish them to any subscribers, the subscribers were defined in ReactJs using the ID’s of the TV’s or a special admin ID used by a sperate device for sending the team logos to each screen, when a message was received by a subscriber the Raspberry Pi would know what it needed to do: start, pause, resume, reset, or change team logos.

Our overall setup looked like this:

The little Raspberry Pi devices held true and strong for their full two and a half days of competing, without a single report of delays or crashes. with that in mind, I think it's fair to say that Raspberry PI Model B with Node, Node-Red, MQTT, Javascript and ReactJs as your support, you are the true champion of this event.

For more information about custom IDX solutions, contact
For more information on the above solution contact

Wednesday, May 16, 2018

Remotely Monitor Tank Levels Part 2/2 - Online configuration

So, now that we have successfully installed our tank sensor in our last blog: Remotely Monitor Tank Levels Part 1/2  We can move onto the configuration of the Netbiter Argos server (User Interface and logging server for the Netbiter system.

Step 1: Create an account on the Netbiter Argos server

Go to and press "create account". From here you will need to add the particulars supplied with your newly purchased Netbiter Controller including the System ID and the Activation code, this will enable the Argos server to link to your Netbiter and fetch the required information from your devices. You will also need to supply a unique account name and password (these will form your login details to the server). Lastly the account creation process will require some personal particulars such as your name and contact details.

Account will be created once you follow the activation prompts emailed through to you, once you login to your Argos account for the first time, you will see that the Netbiter controller whose details you provided in the previous step is already added to your account and is ready for configuration and parametisation.

Step 2: Uploading or creating a template for your tank sensor

The Netbiter Argos portal uses "templates" to effectively map the communication information required from your devices, this information could for example be: Modbus Registers, J1939 engine parameters. Fortunately there are quite a few pre-built templates readily available for a multitude of generator controllers, UPS systems, Ultrasonic tank sensors and more, you can view  and download these templates from the Netbiter website.

Uploading a template:
You can upload a template to your account through the following steps:
1) Download the relevant template for your device (this is in a .xml format)
2) Click on the Management tab, then templates, and then press "upload" at the bottom of the page
3) navigate to your .xml template file and press upload
The template is now available for you assign to your Netbiter device

In this case however, the tank sensor is an integral part of the Netbiter range, and the template should already be available within your Argos account, therefore it is not required that you upload it.

Creating a template:
There may be a case where there is no template available for the device which you are connected to, In this scenario you will need to create your own template. This is a very simple process which can be executed with in a couple of steps.

1) Ensure that you have the device user manual on hand, which will outlay the devices communication settings and provide a mapping for the communication registers.
2) Whilst logged into your Argos account, Click on the "Management" tab, then "Templates tab"  and press the "create" button at the bottom of the page
3) Choose the type of template you wish to create (Modbus, SNMP, Ethernet/IP or J1939), this will indicate the communication protocol of the device with which you have connected your Netbiter controller
4) Choose a name for your template. For example: Ultrasonic Tank Sensor V1.1
5) Either use "Default group" to add in your first parameter, alternatively you can create your own set of groups by pressing "Add group".
6) Create a parameter by pressing "Add parameter". you will be faced with multiple options in the next screen per parameter, the most important required data is as follows:
   6.1) Name - refers to the description of the tag you wish to add within your template. For example a tag we could name in our fuel sensor configuration could be "Fuel level %"
   6.2) Unit - not required however very useful when it comes to displaying values and reading tags for simplified reading and understanding, in the case with our previously mentioned tag, the unit of interest would be "%"
   6.3) Type -  Refers to the register specific information that will be read by the Netbiter and defines the 'area' that the Netbiter controller will read from, as well as how to handle the data received. The data type will be defined within your device user manual and may differ from parameter to parameter. there are four options available (Coil, Discrete input, Holding and input registers).
   6.4) Address - Modbus address can be considered similar to that of post boxes, each piece of information requires a unique address where the data can be written to and read from. you will need to take into consideration of the address will need to be offset by 1 or not (ie. addressing starts from 0 or 1).
   6.5) Datatype - Within digital communication, there are various data types to convey different pieces of information, this could vary in data size and format (8, 16, 32 bit, floating point, string). Choose the data type declared within the user specifications of your device for the relevant register.
   6.6) Scaling - Scaling is to be utilised when the piece of information being read from the device does not represent the true readable value required for the user interface. for example a temperature sensor may not feedback a Modbus register with the exact temperature read (25.6 DegC), but may only provide the Netbiter with an Analog signal (4-20mA) which is a variation of a small current to represent a value i.e. 4mA represents the lowest temperature value and 20mA the max , any value in between can provide infinite accuracy on a corresponding temperature between the lowest and highest limits.
   6.7) Offset -  Adds a value to the (scaled) parameter value. For example a scaled parameter value of  23.6 DegC plus an offset of 5.0 means that the resulting value will be 23.6 + 5.0 = 28.6 DegC
***The balance of the required fields can be found in Argos user manual for advanced action.
7) Save Press save - the template will now be available to add into your systems configuration. Remember that any time you make changes to the Netbiters configuration (Modbus, logging, alarm settings etc.) you will need to download the new configuration. this is done within the 'Management" tab, press 'Synchronize configuration' when completing necessary adjustments.

Step 3: Setting up logging parameters, Alarms and communication gateway settings

Setting log points:
The Netbiter has the ability to log parameters of interest at varying resolution. Logging can be useful for trending data point of interest, exporting the data for ERP systems or analyzing system usage and potential abuse.

1) Within the 'Management' tab, open 'Configuration' then 'Logging (0)'
2) Press 'add log parameter'
3) Select the required Group and Parameter  for the data point to be logged
4) Select the required Log interval, this is how often the chosen data points value will be stored, or the resolution of the logged data (ranging from 30 seconds up to 60 minutes).
5) Finally select the Log type:
   5.1) Value = the data value will be logged every time at the chosen interval as per point 4
   5.2) Delta = the data point will be logged every time it changes from the previously logged value
   5.3)  Hysteres = the data point will be logged every time it changes by a specified amount (Hysteres) from the previously logged value
6) Press save, dont forget to press Synchronize configuration for your logging configuration to take effect

Setting alarms:
The Netbiter has in depth alarming capability. This allows you to receive notifications and acknowledge alarms. Alarms are based on a value reaching or exceeding a configured point, on an action e.g. a digital input registering as true. you can assign severity to a certain alarm in order to determine how that alarm will be handled.

1) Within the 'Management' tab, open 'Configuration' then 'Alarms (0)'
2) Press 'add alarm parameter'
3) Select the required Group and Parameter for the alarm to reference
4) Choose necessary alarm variables:
   4.1) Trigger =
   4.2) Value =
   4.3) Severity =

Gateway settings:

Within this tab you can set up the communication specific settings (network type, speed, timing and error checking).
The relevant communication settings can be sourced from the device user manual, each device
connected to the Netbiter needs to conform and support the configured settings. once settings have been entered, press 'save settings'

Finally press Synchronize configuration and test your required inputs to confirm they are being received in good order.

For more information on Argos Netbiter RMS systems contact Industrial Data Xchange now   +27 11 548 9960

Friday, April 27, 2018

Insights from the PROFIBUS wire (understanding equipment behaviour)

This blog is a by-product of a recent project to investigate and validate the sequence of events on some electrical Switch-gear where the SCADA and Switch-gear communicate over PROFIBUS DP. This was done by examining what was happening "on the PROFIBUS wire" (Actually PROFIBUS DP has two wires, a red one and a green one!).

It also brought into focus the idea that analysis of process data as it appears “on the wire” could have many operational and maintenance benefits – achieved without additional loading or complication for the  associated SCADA. While it is true that modern field-bus and industrial Ethernet systems support the use of intelligent field devices which can provide access to configuration and diagnostic information via FDT and similar engineering tools there is a an effortless simplicity to gaining insight on the wire through independent means. This is especially true when comparing events from different sensors or items of equipment to determine cause-and-effect relationships and accurate time sequencing.

Now we go back to the actual investigation. An intermittent logic fault reported by the SCADA suggested that the feedbacks from  Switch-gear contactors were sometimes reported in the wrong sequence causing incorrect operation. By recording data change at the wire level we were to monitor the behaviour of  ten pumps which all shared a common IO template and test this hypothesis.

The pumps all had an IO template as shown below:

Signal Description
Signal Name
Signal Type
(XB01) Feedback Signal – Contactor is Open
(XB02) Feedback Signal – Contactor is Closed
(XB08) Ready (Start)
(XB20) Some Fault condition that will prevent normal operation
(XB04) Remote Operation of Pump is enabled
(XQ01) Current that flows when pump is operated (0 to 100%)
(YB01) Open Command (pulse of width of 2.0seconds)
(YB02) Close Command (pulse of width of 2.0seconds)

If we view what happens on the PROFIBUS wire over a period when a pump is started and then stopped we expect to find initially (an idle pump in the "off" state):
FBOPN = 1           This implies that the pump is stopped (not energised)
FBCLS = 0            This implies that the pump is stopped (not energised)
READY  = 1         This indicates that the pump is available to be started
FLT  = 0                This indicates that there is no local fault that might prevent operation
REMOTE   = 1     This indicates that the SCADA is enabled to operate the pump
CURRENT  = 0    As the pump is stopped there is no current
CMD OPN = 0     There is no active command to stop
CMD CLS  = 0     There is no active command to start

When a pump is requested to start we expect to see a 2-second duration pulse, ⸥⸺⸤ (0 to 1 and then 1 to 0 transition) on CMD CLS which will cause:
FBOPN = 0           This implies that the pump is now started (energised)
FBCLS = 1            This implies that the pump is now started (energised)
READY = 0          This implies that the pump is started (energised) or is not able to start
REMOTE  = 1      This indicates that the SCADA is enabled to operate the pump (does not change)
CURRENT > 0     For a few hundred milliseconds there will be a high start-up current before the                                      current drops back into normal operating range ( 0 > CURRENT <= 100)
CMD OPN = 0     There is no active command to stop
CMD CLS  = 0     After the 2-second-wide pulse there will be no active command present.

During normal pump operation the value for CURRENT changes while all other signals remain in the same state (as above).

When a pump is requested to stop we expect to see a 2-second duration pulse, ⸥⸺⸤ (0 to 1 and then 1 to 0 transition) on CMD OPN which will cause:
FBOPN = 1       This implies that the pump is stopped (not energised) was previously 0
FBCLS = 0        This implies that the pump is stopped (not energised) was previously 1
READY = 1       This indicates that the pump is again available to be started – was previously 0
FLT = 0              This indicates that there is no local fault that might prevent operation (unchanged)
REMOTE = 1    This indicates that the SCADA is enabled to operate the pump (unchanged)
CURRENT = 0  Within one or two scans, there is no current as the pump is stopped.
CMD OPN = 0   After the 2-second active pulse has completed the signal return to zero
CMD CLS = 0   There is no active command to start

This expected sequence is described below.
The expected sequence for pump starting, running and stopping

By comparing the sequence of events occurring on the wire with the event log produced by the SCADA system we expected to correlate and explain (where possible) the behaviour that was observed.

Our approach was to passively listen on the PROFIBUS network and capture the traffic between the SCADA and the Switch-gear, knowing that the commands would be contained in the CYCLIC DATA EXCHANGE OUPUT issued by the SCADA to the Switch-gear and that all the feedbacks would be contained in the CYCLIC DATA EXCHANGE INPUT received by the SCADA from the Switch-gear. Also by creating filters to watch for specific data changing we could limit the amount of data that we needed to record.

As the intermittent error conditions could be days apart we choose to install a monitor at the remote site and then upload the recorded data to our office where we developed an offline tool for analysis and reporting – a tool that created a simple-text-log of when signals changed and the duration of time that had elapsed before the change occurred. It also created an excel spreadsheet that showed the state of all related signals for every DATA EXCHANGE message that contained any data that had changed. 
PROFIBUS Monitoring Tool with Remote Monitoring
The PROFIBUS monitoring tool made use of PROCENTEC PROFITRACE to connect passively onto the PROFIBUS network and to log the data to disk.

The above screen shows a filtered view of recorded PROFIBUS messages that contain the I/O data exchanged between the PLC Master (Station Address:1) and the LV Switch-gear PROFIBUS Slave (Station Address:30).
All outputs from PLC are exchanged in a single message (SRD HIGH) while the inputs from the LV Switch-gear are exchanged in a single message (DL). From the I/O Schedule it is possible to extract the I/O for each pump and analyse when values change and to measure the duration of time before a change occurs.
The next picture (an extract from an Excel spreadsheet report for one of the pumps highlights normal expected behaviour from just before a START and until just after a STOP. 

An example of Excel Spreadsheet produced for a pump operation : start, high-current, normal current, and stop


This blog will not go into any detail on the project finding but will rather indicate what the author saw as a general-purpose tool and benefit from passive listening on the wire (in this case PROFIBUS but it could be MODBUS or some industrial Ethernet) independent of the host SCADA system.
  • Listening on the wire, independently, provides a single accurate version of what information was shared between the SCADA and Switchgear Station – with timing and detail at the same resolution of raw information transfer. When high-level systems log and report events there is no guarantee that they have the same accuracy as they may be subject to slower cycle times and asynchronous task execution and reporting.
  •  Determination of the exact sequence of events is made possible. Changes in feedbacks can only be reported with the INP message while commands are only transferred in OUT messages. This makes sequence of event analysis straight forward.
  • What was very insightful was the high-speed-capture of the start-up current which could be as much as ten times the normal operating current. As these start-up currents are very short in duration, a few hundred milliseconds, it is possible that they are typically not seen in any SCADA logs. This suggests that very useful statistics and profiles of start and stop operation could be captured in this way and be provided to asset optimisation and equipment maintenance applications for analysis and operational intervention. This can be achieved without any load on the SCADA and by not requiring the SCADA to have to have much faster scans to capture these transients.
  • Hence there is the real sense that this type of non-intrusive data recording and analysis may have many valid use cases – suggesting that there is more to PROFIBUS diagnostic monitoring than just the statistics of physical network faults and configuration issues – what the data is doing on the wire may provide useful insights not easily acquired from SCADA or the PlantData Historian that typically receives its data from the SCADA.

If you have any questions or comments you are invited to contact the author