Reverse engineering the innards of System Platform #1 - Packages, Templates, Objects, Primitives and Attributes

In order to try and understand various aspects of System Platform a little better, I have been poking around the inner workings of the software and discovering many interesting things, which I intend to share in a series of posts on the subject.  So here goes with the first one about Packages, Templates, Primitives and Attributes - settle in because it's a long one.

Firstly, we must must realise that the templates, primitives and attributes that we are going to talk about here are not the same as the templates and attributes that we are used to dealing with in the IDE which I will call IDE templates and IDE attributes from now on.

Templates are a base object type, such as $UserDefined, $Symbol, $DiscreteDevice and so on.  This list of templates is in the database in table template_definition, and for example mine looks like this:
Read the rest of this entry »


The 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

Read the rest of this entry »

| Posted in SCADA, Software | 12 Comments »

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

Multimonitor selection

| Posted in SCADA | 6 Comments »

I like ArchestrA, but...

There are just so many bugs, and annoyances that it makes me want to tear my hair out on a continual basis.  I'm not a full time software engineer, but I code enough to know that so many of these things could be fixed with relatively little effort.  Here is a list of things that really get my goat, and if some Schneider code monkey ever sees this then please feel free to sort them out.  Or, just send me a link to the repo and I'll send you back some pull requests (as if that would ever happen!).

  1.  Opening objects in the IDE is painfully slow, and can only be done one at a time.  If you open objects too quickly one after another then the frame sizes (attribute list and attribute settings) get all messed up.
  2. Buffered attributes are a great concept but they have so many subtle bugs associated with them that they are unusable.  They cause alarms that can't be acknowledged following subsecond value changes, the times in the alarm database for these attributes are all in UTC and not local time like the rest, and they don't always initialize correctly when they also have the inverted flag set.
  3. Plain weird shit happening/object corruption.  Like this:aabugs1The attributes in the above image are all boolean tags, have nothing to do with voltage, but somehow I am getting random events from other attributes mixed in with these ones.  In this case the problem was solved by un-logging the attribute in the template, redeploying, and enabling the logging again and redeploying but there is no way that this sort of stuff should ever happen, and I could see it leading to some very expensive mistakes by operators.
  4. Failovers barely ever work well.  The only times I have ever seen a AppEngine failover work properly is when it was graceful, ie I asked the engine to failover via the SMC.  If I simply restart the machine, all hell breaks loose.  Objects only half work, alarms going off that were never configured, some objects get corrupted and need to be recreated from a galaxy dump.
  5. There is no where to report bugs.  There is nowhere to make suggestions.  The forum is great, but I sometimes my question can only be answered by someone that writes the code or at least has access to it.
  6. Deploying objects takes over the IDE.  In fact lots of basic operations (think import/export objects) do this.It would be nice to be able to deploy objects in the background and continue working on other objects, then show the outcome in the status bar or something so I can get on with other things in the mean time.
  7. When deploying half the time it appears the deployment has failed, when it has actually completed successfully.
  8. Multiple monitor support in InTouch is about as useful as the tits on a bull.  I mean I got it to work quite well, but holy balls it took a quite a bit of custom code, testing, and more testing.  I am very much looking forward to the next release which I understand has proper multimonitor support. (UPDATE: have beta build, and it has mult-monitor support by way of a new view container, intouch remains the same.)
  9. Renaming attributes in both graphics and in objects will break in either animations (for graphics), or will reset your IO references (in objects).  This creates an aversion to creating good naming conventions, because if you try to correct an error after you have created many instances you are in for a crap time.

Lets hope the System Platform 2017/Omni addresses some of these.

| Posted in SCADA | 2 Comments »

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. itstk6This 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 »

| Posted in SCADA | 3 Comments »

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).


Read the rest of this entry »

| Posted in SCADA | 35 Comments »

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 »