Google Earth KML Generator for Radio Networks
One thing that really bothers me sometimes is having the same data in multiple places, and having to manually update the same data more than once. So I was bothered when a colleague recently spent a few days creating a google earth file for our communications network (>150 nodes), even though we had a spreadsheet of all the locations of each node already. So, in a couple of hours I came up with this program which converts a spreadsheet or csv file into a kml file which can be imported into google earth.
Take the following data (this is not a real network, I just picked a bunch of random points):
Drop the spreadsheet onto the CsvToKml program, and it spits out a kml file, which looks like this in Google Earth:
Now every time we update the spreadsheet all we need to do is feed it to CsvToKml and we get a new google earth file.
Loopback interfaces on RX1500
Recently we decided to convert a bunch of layer 3 radio links into layer 2 links in order to simplify our OSPF routing database, work around a couple of nasty OSPF bugs in the radios and achieve better balancing when there are equal cost paths. However this took me down a bit of a rabbit hole that I wasn't expecting - consider the topology change below:
On the left, all of the central routers interfaces are in one vlan/subnet. On the right the interfaces all have their own IP addresses. This creates a problem - what IP address does one use when wanting to ssh into the device? We can use any of the IP addresses of course, but what about monitoring via SNMP? What about terminating VPN endpoints? Which IP do we choose, when any of the radio links might be down for whatever reason, and therefore the associated IP address will be unavailable?
Read the rest of this entry »
Crosswire Webclient
Crosswire is a dispatch platform that is compatible with SIP, analog and digital radio. It comes with a Java client which you pay for per instance, but there are occasions where you may want additional people to be able to listen in. To this end I have developed a web client that watches the crosswire mysql database and plays out the audio in semi real time. By this, I mean that you have to wait for each call to be persisted to disk before you can listen to it which creates a delay of at least the length of the call before you can listen to it. It is written in ASP (C# Razor), source is here.
Adapting ospf-visualiser for use with RuggedCom RX1500
A handy thing to see in an OSPF network is a visual view of the active paths and costs. There are a couple of expensive tools around that can do this very well, but there isn't much around that can do it for free. One such free tool is ospf-visualiser which can take output from quagga and print out a pretty picture of the network. If you have telnet enabled on a machine with quagga then you can telnet to it and everything is supposed to work, but it isn't compatible with RuggedCom devices out of the box.
Therefore I have extended ospf-visualiser so that it can SSH to a RuggedCom ROXII device, log in using the given credentials and extract the required data to build the model. Rather than write a new parser for the RuggedCom ospf command output, I have opted to log in to the maintenance shell and run the quagga commands directly so the existing data parser can be used, which means that the total amount of code changed is actually quite small.
New SSH options for source data
Output for example RuggedCom network
The next step will be to enable live listening to LSA packets so that the visualisation is truly live, but for now the source and binaries are on Github
02.1.18The ArchestrA Attribute Wrangler
One frustration that I often have with ArchestrA is wanting to do bulk updates to attributes on one or more objects. Things such as,
- Updating a the description on an attribute that has a typo for all objects descending from a template
- Change all the alarm priorities on objects hosted in a particular area
- Changing the IO references for all objects using a particular topic name
Repairing 'corrupt' ASE 1.x capture files
Recently I captured a whole bunch of data using an ASE V1 RTU test set to trouble shoot a comms issue, with the intention of analyzing the data once I got back to the office. Well when I did get back to the office and tried to open my files, ASE just sat there, blank, looking at me as if I were stupid. I only had one capture file out of a dozen that actually opened and it happened to be the smallest one. I figured that ASE had an issue opening large capture files, so I fired off an email to support asking for haaaaalp.
I was told that there was no issues viewing large files, but that I had likely following the incorrect procedure for capturing files which must be closed properly. There was no hope of recovering my data.
Intouch Multimonitor - version two
Following on from my last post on the subject, I have now made my multimonitor application work for arbitrary screen layouts (but still limited to only two monitors). Additionally, a number of subtle bug fixes have been implemented, such as the windows correctly showing following a NAD update. Grab the updated package (for InTouch 2017) here. To set the screen layout, simply select the picture that fits your situation on the settings page:
Multimonitor selection
Multipath routing with MimoMax and RX1500
Recently I have been working on a project that involved adding redundant paths to a couple of existing comms links, using RuggedCom RX1500 routers at the end of each link, deploying OSPF to manage the routing. The links themselves are RF, using Mimomax NDL radios which are also routers running OSPF. The paths are equal cost so I was expecting the RX1500 to load balance the paths more or less equally. This was indeed the case, but when we plugged it all in, our DNP communications to all of the RTUs on those links appeared to get worse, with lots of failed polls occurring. Upon further inspection it was mostly class 0 polls that failed, and the reason was that the packets were arriving out of order. It is important to note here that were using DNP over UDP at the time. Below is an approximate diagram of the network (subnets are represented by the circles).
Network diagram
Using the InTouch Script Toolkit to get design time window offsets
Well that title is quite a mouth full, so perhaps I should explain what is going on here. During the course of a previous post I created an InTouch application that worked on multiple monitors. An improvement on that application was to create a Quick Function MMPopup(WindowName as Message) such that it shows a popup window using the offsets specified at design time, but on the correct monitor. 
This seems like a trivial problem at first glance, but on closer inspection it is not so straightforward. There is no way to get the design time window offset, without showing the window and getting it from GetWindowPosition(). This is a truly abominable approach, and I found it worked poorly at best. I decided that this information could surely be obtained from the *.win file, and so set about reverse engineering the file format to a point where I could get this data. It proved to be a fairly straightforward task, but as it involves reading and converting binary data it can't be done inside a simple QF. Hence I set about obtaining the script toolkit (part of the FSK2000 toolkit) which my local Wonderware distributor kindly supplied.
Read the rest of this entry »
Creating a multimonitor application in InTouch
For a long time our operators have been asking for multi-monitor support in our InTouch application, they want to be able to have alarms showing on one monitor and a substation on another for example. InTouch does support multiple monitors, but it makes you do a lot of work to get things the way you want. In our case we wanted to have two independent monitors, each showing a different window in the application. Additionally we wanted to have a history of windows for each screen that you could scroll back through like a web browser, and for the application to work when scaled for monitors on different resolutions.
These are some of the things that you need to be aware of when developing a multi monitor application:
- Each window can only be shown on one monitor at a time (InTouch limitation)
- If you try to show a window that is already open on a different monitor, it will close the window on the monitor it was originally on, leaving you with a blank screen.
- $ObjHor and $ObjVer are given in pixels, offset from the top left corner of the view window client area. This is important as when you are viewing the application on a monitor with a different resolution to the design resolution this must be taken into account.
- When using the Show* functions on a monitor of different resolution to the design resolution, same applies as above.
- Calling windowstate() on a window right after (ie in the same script) showing or closing the same window will not return the result you are expecting!
This is a rough guide as to how I went about achieving these goals.
Modify win.ini (twice!)
You need to configure InTouch to use multiple monitors, you do this in the win.ini file, but here's the trick - there are two win.ini files! The one in C:\Users\<user>\AppData\Wonderware\win.ini is used by view and window maker, but the wwtechsp.dll library uses the system win.ini file, the location of which varies by operating system and other settings. The correct file to use is which ever one has been modified by the InTouch installer.
- C:\Users\<user>\WINDOWS\win.ini
- C:\Windows\win.ini
Append/add a configuration section such as the below to these files, using the appropriate figures for your monitors, NOT your application design resolution (although on the machine you develop the application, these will be the same).
[InTouch] MultiScreen=1 MultiScreenWidth=1920 MultiScreenHeight=1080