SCADA Deep Dive

I wanted to take an in depth look at the SCADA system.

One problem with SCADA is that it works well for small amounts of data (read a pin or a sensor for example) - but less well for devices requiring a large amount of data or with 'critical' timing.

For example - to connect a OLED display to an Arduino UNO isn't really practical - although it should work (although currently some issues here) - it will be very slow. Each byte written to the display requires a minimum of 8 bytes to be sent to the Arduino (so to clear a 128 x 64 display requires 1024 * 8 bytes to be sent - and the Arduino also replies to each command) - this is slow at 115200 baud and means other control methods (Bluetooth or LORA radio for example) will be unusable.

To counter this - I decided to move some processing back to the Arduino. I rewrote the SCADA firmware to make it easy (easier) to extend - for example to add a 'Print' command to send text to an attached OLED display.

The command format is:

0x3a, command, optional data, 0x3b, 0x0a

So, for example, to set a pin to 'state' (1 = on, 0 = off) send:

0x3a, 0x80, pin, state, 0x3b, 0x0a

The Arduino (or other SCADA slaves) reply with

Cmd (0x80 here), optional data.

To read a pin -

0x3a, 0x81, pin, 0x3b, 0x0a

The Arduino replies with:

0x81, state (1 pin is high, 0 low)

My firmware uses a different approach to the Flowcode firmware - commands are 'vectored' to a macro by using a lookup table. This means new commands can be added simply by creating a new macro and by adding a line to the lookup table. Unused commands can also be easily 'removed' simply by commenting out the lookup table initialisation - the linker then doesn't include the associated macro.

This technique 'might' be slightly faster than using a switch statement - however the 'overhead' of macro calls (the AVR compiler doesn't generate optimal code) balances this out. This is largely irrelevant - the main limiter on speed is the UART communications (here 115200 baud or 11520 bytes per second (allowing 1 start and 1 stop bit)) - when each 'byte' requires a command sequence of several bytes it will be seen that communications will be much slower than this.

As a test - I wrote a simple FC SCADA script to toggle a pin (pin 12) on the Arduino as fast as possible - this produced a slightly irregular trace at about 50Hz. (Note that FC Is interpreting the code here) After exporting the App - the output became more irregular and slower (at about 16Hz)

A simple Python script gives a more regular waveform. Note that the duty cycle is slightly greater than 50% because the 'loop' code occurs whilst the pin is off.

Here I used the RegisterWrite (which takes a 16 bit address) command. Using SetPin gave ~125Hz

In my next post we'll look at creating 'custom' commands to control an OLED display.