07.27.18

update on compiling sall calcs with gcc for SCD6000

It's been a while since I last worked on this, and today I made my first (unsuccessful) attempt to load a gcc compiled elf onto a SCD6000. In the previous post, I outlined how a sall file can be turned into an elf outside of the RTU Station environment.  The progress made in this post is the small step of using the gcc toolchain from within the RTU Station environment.  This is required, because any points used by the calc need to be parsed and included for the rest of the RTU configuration (these points are stored in the defs.h file, which gets renamed to <calcname>.h).  The details are in on github.

Unfortunately, the first attempt to load an actual file didn't work (the calc shows up in the error state in the RTU).  This is not at all unexpected, and now begins the tedious process of trying to understand why.  This may prove to be quite a challenge, given that we can't really observe the internals of the RTU, but I'll keep chipping away at it.

 

10.20.17

Running RTV and RTU Station on Windows 10

The SY-1101211D release of RTV and RTU Station does not support Windows 10,  which is no surprise since it took several years for Schneider to add support windows 7.   There are a couple of reasons that the standard installation doesn't work -

  • The included version of Java doesn't support Windows 10
  • Internal windows compatibility settings cause the RTU Station precheck process to elevate, which causes bash to crash for reasons I haven't bothered to investigate

To fix the first problem:

  1. Download the latest version of Java (8u151 at the time of writing) and install it - make sure you download the 32 bit version even if you are on a 64 bit system!
  2. Change the launcher.ini file in C:\Program Files (x86)\Foxboro\Remote Terminal Viewer, and edit the JRE line to JRE=C:\Program Files (x86)\Java\jre1.8.0_151\bin\javaw
  3. Open up the permissions for the C:\Program Files (x86)\Foxboro\Remote Terminal Viewer folder.  On my system the installer messed all the folder permissions up - we need the Users group to have Modify and Write permissions, so add those in if they don't exist.  If the splash screen never goes away after you open RTV, then these permissions are not correct.
  4. Done!  This is enough if you just have RTV installed.

If you have RTU station installed as well:

  1. In C:\Program Files (x86)\Foxboro\RTU Station\launcher.ini, change the JRE as above.
  2. Check the permissions for C:\Program Files (x86)\Foxboro\RTU Station\ as above.
  3. If after doing step 1 RTU Station always fails the precheck, try changing the PROGRAM line to
    PROGRAM=cmd /c "set __COMPAT_LAYER= & ..\cygwin\bin\bash.exe -c "cd scripts && ./precheck.sh > ../startup.log 2>&1" "
    

    This wraps up bash in a cmd instance, where we disable the compatibility environment variable that causes it to auto-elevate.

  4. If RTU Station still fails quietly (getting stuck on the splash screen), then change the line ARG3=-Xmx1024m to ARG3=-Xmx512m (credit to the chap from the 2017 user group conference for coming up with this one!)

A special note - the backup\restore utility seems to not support the compressed backup format so if your old data backups don't restore then try to unzip them manually first.

| Posted in Foxboro | No Comments »
10.20.17

compiling SALL calcs for SCD6000 without WindRiver

Schneider released the SCD6000 RTU a while ago now, and while it has come with some good improvements, it has also come with a couple of shitty regressions. One of these shitty regressions is the use of the propriety Wind River C compiler for the compilation of SALL files. I'm guessing that this decision was made because Wind River makes VxWorks, which I believe is the operating system that runs on the SCD RTUs.  However because Wind River is based on GCC, and I don't want to pay many thousands of dollars for a compiler I only use a handful of times a year, I wondered if it was possible to use instead the very free GNU ARM embedded toolchain?

Now I don't actually have any SCD6000 hardware to test on, so this is just what I have come up with so far, and hopefully one day I'll get a chance to test it. On the other hand, if anyone out there wants to test this for me then please do so and let me know the results!

First, lets examine the process of how a SALL file is transformed into an elf binary.

  1. SALL file is converted into a C file.
    For SCD5200 RTUs this is done using the sall.exe file, located in C:\Program Files (x86)\Foxboro\RTU Station\utils\CalcsRTU_SALL\<firmware version>\buildsal\. You can run the program from the command line by using the following syntax: sall.exe infile.sal outfile.c errorfile.
    For SCD6000 RTUs this functionality is built into a dll file that is called directly from RTU Station.
  2. Compile and link the files into an elf file.
    For SCD5200 RTUs this is done with the Watcom compiler, and for SCD6000 RTUs this is done with the Wind River compiler. In both cases a make file is used to invoke the compiler and linker.

Read the rest of this entry »

01.25.17

InTouch/Archestra/SCD5200 Tag Checker

I have recently been working on a project to upgrade our InTouch SCADA to ArchestrA.  This has a number of challenges, but a big one is how to be sure that you got all the right tag names going to the correct IO.  We use DNP and SCD5200 RTUs almost exclusively for large sites, so I have started writing a tool that parses all of our SCD5200 RTU configurations, our InTouch tag database, and the ArchestrA database and produces a spreadsheet with a comparison of all tags and addresses.  It can take also take a map file that maps RTU names to ArchestrA areas to InTouch topic names.  You can then review this report to compare any glaring differences - still a time consuming process but damn site quicker than doing it manually.  The tool is fairly functional at present and parses all my data correctly, but I've no doubt that there are a lot of edge cases not taken care of yet.

Source is on Github.

| Posted in Foxboro, SCADA | 4 Comments »
08.16.15

Changing a DNP Master from UDP to TCP in System Configurator

A frustrating situation that may occur from time to time when programming SCD5200's is creating a DNP master and adding it to a UDP Master Group, only to discover that the device doesn't support UDP, only TCP. Normally one would have to detach the device, reattach it to a TCP Master Group, and remap any points to slaves. This can be a monumental time waster, so I will share how we can cut some corners and move it with a bit of database back door banter.

  1. Navigate to your cygwin directory and start bash. (set your window width buffer to 2000 to make things look nice)syscfgtcpudp1
  2. Login to the SYSFG database
    psql -d SYSCFG
  3. Enumerate your dnp protocol masters
    select * from protocol_master_dnp;

    Note the protocol_type_oid column. For me, tcp devices show up as 115, and udp masters are 552 (for dnp slaves udp is 553 and tcp 99). Your version of System Configurator may have different numbers here.

  4. Enumerate your dnp protocol master groups
    select * from protocol_master_grp_dnp;

    Note the prot_grp_type_oid column. Mine shows 551 for UDP, and 64 for TCP.

  5. Change the DNP Master type, and change its protocol group. Write down the oid for the UDP Master Group and the oid for the UDP Master that you want to change to TCP. For me those numbers are 201506300351335920 and 201505120209572450. Now:
     update protocol_master_dnp set protocol_type_oid = 115, protocol_grp_oid = 201506300351335920 where oid = 201505120209572450;

And that's it!

| Posted in Foxboro, SCADA | No Comments »
05.11.13

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 »
05.11.13

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 »
05.5.13

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 »
04.29.12

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 »
02.27.12

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 »