Virtual Serial Ports, com0com, RFC2217, and Radio

Tunneling com ports over tcp, and in particular over low bandwidth radio links can be a tricky business. Even more so if you are on windows and want to use free or preferably open source software. Recent work I've been involved in has required that many devices with different and proprietary protocols (all serial in nature) be tunneled over a udp radio connection from a Windows server to the client device.  The image below demonstrates the conecpt.

Read the rest of this entry »


Creating a complete test environment in ArchestrA

I've been playing around a lot in ArchestrA lately, but have had the problem where my system is completely virtual and has no real connections to real devices.  So I decided to simulate real world devices by creating model objects, which attempts to mimic the behaviour of the real device.  The regular object has no idea that its talking to a simulated device instead of an actual device, so we can do a large amount of testing in the lab without ever having to connect a real device!

The following diagram gives an overview of how this works.

Read the rest of this entry »

| Posted in SCADA | No Comments »

IDF Beta Compiler ready

A beta version of the IDF Compiler for x64 is now ready, as usual the source is on GitHub.  It will happily compile correctly formed IDF Calcs, if anyone notices any oddities please open an issue on GitHub or send a pull request.

Still to implement:

  • Syntax checking
  • Function parameter checking
  • Unary +/- operators (maybe?)

The windows upgrade script has been updated to include the IDF compiler for the two latest firmware revisions (C and E), if you use a firmware different to this your IDF calcs will not compile yet.  Note you can run the upgrade script on an existing installation and it should copy over all the new binaries (note that your syscfg database will be hosed).

| Posted in Foxboro, SCADA | 1 Comment »

Reverse Engineering the IDF Compiler

So as mentioned in previous posts, the IDF Compiler is a 16 bit application, and consequently does not run on 64bit windows operating systems. Therefore, we must write a new IDF Compiler for 64bit windows!

I originally started out analysing the decompiled assembly, but as those of you who have written application in the old segmented architecture will know, it doesn't make for pleasant reading. I did however work out the basic structure of the compiler, and there wasn't anything in there that looked too difficult. So to write a new compiler, instead of doing in depth analysis of the assembly it will be faster so simply learn by observation. An IDF Calc is made up of one statement in infix notation. The compiler then converts this to reverse polish notation (RPN), and presents it in a text form, where the operators and functions are mapped to opcodes. Thus the code:

a = b + c

is converted to RPN

a b c + =

which is then mapped into a custom representation

0, "b"
0, "c"
2, "0"
1, "a"

Note that the order of the RPN tokens and the custom representation is the same, except that the assignment operator is treated slightly differently.

Therefore, all we need is the map of all the function codes to op codes (this can be generated by observation of the 16 bit compiler), and we are set!

| Posted in Foxboro, SCADA | No Comments »

InTouch database corrector

I finally got sick of manually fixing our InTouch Tagnamse Database, so work has begun on a tool to automatically correct errors in a database dump.  Currently the tool deals to the following issues:

  • Initial Values that are larger or smaller than the engineering limits
  • Alarms (LoLo, Lo, Hi, HiHi) that overlap, or are outside engineering limits
  • Initial Values and Minor Alarm Deviations that are very small
  • Removal of tags with bad AccessNames

More features will be added as required/requested. Check it out on GitHub

UPDATE 24/1/17:  There is a fairly fundamental bug with this tool - it doesn't parse quotes or commas in the csv file, so if your description fields use quote or commas won't work.  A fix is in the pipeline.

Incidentally, if anyone else has had problems with "dde.cfg - out of disk space" errors which result in losing the access names I'd be interested to hear about it.  Our application doesn't appear to be corrupt  (it reimports fine), yet it still breaks every now and then.

| Posted in Foxboro, SCADA | 2 Comments »

Moving a mater/slave group from one port to another in system configurator

 This post describes a procedure for moving a master or slave protocol group from one comms port to another.  The comms port can be on the same or different cards in the RTU File.

Note:  This procedure is not (to my knowledge) an approved or recognised procedure (by Foxboro) for accomplishing this task! Proceed at your own peril and backup first.


  1. It is assumed that the port that the protocol group is to be moved to has already created in System Configurator.  System Configurator may or may not be running whilst making changes to the database, depending on your installation.  If errors are encountered connecting to the database withpsql then close System Configurator.
  2. In this example the DNP3 Master group will be moved to the second port on the 8 Channel Serial Card on slot 5.
  3. Open Bash
    Read the rest of this entry »

| Posted in Foxboro, SCADA | No Comments »

Upgrading a C50 configuration to a SCD5200 configuration in System Configurator

NOTE:  This method is not supported by Foxboro, and has not been extensively tested.  Proceed with caution!

 How System Configurator stores data

System Confiogurator uses the PostgreSQL database as its data store.  In particular, the SYSCFG database stores data related to the current rtu configuration, and the ROOTDB database stores data such as rtu types, IO modules, menu options etc.

There are a number of tables (which are in turn split into subtables) that contain items in the configurations.  The main tables of interest are:

  • unit_rtu – Contains all the RTUs
  • card – Contains all the IO cards, CPU cards, comms cards
  • card_file – Contains all the RTU IO files, such as 5 slot or 10 slot.  Usually has the same number of entries as unit_rtu
  • comms_port – Contains all the comm ports
  • calc_task_rtu_idf – Contains all the IDF calcs
  • calc_task_rtu_sall – Contains all the SALL calcs
  • point_unit – Contains all the points that are available to consume for a slave device

Read the rest of this entry »

| Posted in Foxboro, SCADA | 4 Comments »

Running Foxboro's System Configurator on Windows 7

The latest edition of System Configurator is fine on Windows 7/8/10 so this information is now redundant.

This post is related to Foxboro's System Configurator program for configuring SCD5200 and RTU50/C50 RTUs. Now, SysCfg only runs on windows XP at the moment (Jan 2012), which is a PITA because everyone in the real world now uses Windows 7. So I have endevoured to do Foxboro's job for them, and make SysCfg work on W7.  Note: I have removed the upgrade files and scripts as they are not required with the latest versions of RTU Station, I'll leave the rest of the post for history.

How System Configurator Works

SysCfg is made up of a number of different components. The GUI is made of a java program (obvious from the non standard windows look and feel, but more obvious when you look at the program files). However the java program is little more than a GUI, because a large portion of the work is done by this thing called Cygwin.

What is cygwin?

Cygwin is like having a copy of linux on windows. Its basically a unix like environment that you can install, and then you can open up a bash shell and use a whole bunch of typicall GNU/linux utilities.

SysCfg uses cygwin extensively because all the data stored in you configurations etc is stored in a PostgreSql database, which for some reason they have chosen to access via cygwin rather than use the native windows version of postgresql. My guesses for this design choice is that either:

a) There is also a linux version of SysCfg and they are trying to keep the same code base.
b) The original/current dev is a linux dev, and this is the best they could come up with for windows
c) Some other extremely weird reason

But whatever the reason that is how they've done it, so that's what we've got to deal with.

So what's the problem with W7?

The short answer is I don't know 100%. I suspect the problem lies in that there are some fundamental ways in which memory is managed in windows 7, along with many of the system dlls being changed has probably upset the apple cart a wee bit with the very old version of cygwin that syscfg comes with by default. The postmaster service just simply does not work on windows 7, crashing with an error about not being able to allocate memory on the heap (or something similar, I forget). It was suggested by some people that the problem could be fixed by rebasing all the *.dlls in the cygwin distribution, but the problem was that I could not get a binary copy of the rebase program for that version of cygwin, nor could I compile it because I didn't have the compilers installed.

So what then?

The solution I came up with was to simply replace the entire cygwin distribution with the latest version and use that. This gives us a newer version of postgresql and all the other tools (usually a good thing), but unfortunately changed a couple of things as well. This meant that we have to have another service running on the target machine (Cygwin Server), and have to make a few minor changes to the registry and one of the SysCfg maintenance scripts.

And thats it?

Well not quite. Because the of the newer postgresql version, SysCfg backup files are no longer backwards compatible with the older version. SysCfg backup files are simply a zip file with a SQL script in them which contains all the data. The problem was that there are some minor changes to the script that didnt quite work with the older version, but fortunately these changes are minor enough to be able to automatically correct.

The short version is, the W7 SysCfg can restore new and old backup types, but the XP SysCfg can not restore W7 backups.

So, I made the SysCfgBackupDeversioner tool, which makes a few changes to the backup file so that it works with the XP SysCfg. Its operation is failry simple, all it does is add 'WITHOUT OIDS' the the end of every CREATE TABLE statement, and makes a few modifications to the initial db setup stuff at the start of the file (Basically removes the new stuff and replaces it with the old stuff).

And, because where I work we store all the backups on the network, I created another tool which backs up and restores across the network (which doesn't work with the regular program).  It can also deversion the backup file as part of the same process, so if you use this you will notice almost no difference from your normal configuring experience.

| Posted in Foxboro, SCADA | 9 Comments »

Testing the Perle IOLAN SDS1M for use in a DNP3 radio network


For a master station upgrade, a device/terminal server is required to interface a number of radios and RTUs to the master station.  The handshaking with the radios requires precise timing of RTS/CTS lines, and so a Perle IOLAN SDS1M was obtained for testing, with the intention to purchase a SDS-16C provided that the testing demonstrated that it would be suitable.

Testing Setup

The master station software installed on a laptop is connected to a radio in one of two ways:

  1. Directly via a serial cable
  2. Via an Ethernet cable to the SDS1M which is in turn connected to the radio.

A second radio is connected to a Foxboro SCD5200 RTU.  The master station can be configured to poll the RTU via one of three communication channels:

  1. Via a hardware serial port on the laptop
  2. Via a TruePort virtual serial port and through the SDS1M (uses Ethernet)
  3. Via Ethernet, and then through the SDS1M

Read the rest of this entry »

| Posted in SCADA | No Comments »