Sigma controller regularly warmstarts or resets

[Product_Support]

Issue

Controller regularly warmstarts or resets every 5 minutes. The site was upgraded from a BAS system

Product Line

Satchwell Sigma

Environment

• Sigma
• Controller 1 warm start
• BAS
• Wireshark

Cause

In Sigma each device (server, controller and DNN) must be unique, in BAS this was not the case as terminal and outstations could share the same number.

The resetting controller is receiving requests for files or alarm data that was previously routed to a BAS terminal, the Sigma controller does not handle the data and resets/warmstarts. 

The previous BAS terminal number would have been the same as the controller number, typically T1 and OSN1.  When upgraded to Sigma the BAS terminal number would have been changed to a new designation but some of the system configuration has not been updated correctly.

Resolution

1. Alarm routing:  Check that all the alarm routing in the object files (R1, R2, R3, and R4) are set correctly.  Some systems use single destinations such as T1, if this is found and the destination number matches a controller number then this must be changed. (See Node reset messages are received at regular time intervals after a BAS 2800+ to Sigma upgrade)
   To search for possible incorrect routing destinations use the latest Sigview utility and search for any alarm routing that matches a controller number.
   Note: Typically device number 1 is the issue, but this may not be the case in all situations and another device number may have been duplicated.
2. Operlist.txt Files: Check that all the operlist.txt files have been modified to the latest version and none contain the older BAS format. For example the wrong entries are;
   1 C:\Bas\Data\OSN2\ROUTESET.REC    ROUTESET.REC
   1 C:\Bas\Data\OSN2\LOOKOSN.REC     LOOKOSN.REC
   1 C:\Bas\Data\OSN2\PNTFLE.REC      PNTFLE.REC
   With Sigma can be;
   ;This is a dummy OPERLIST.TXT
    
   (Note: CRLF (Carriage Return & Line Feed) after the line)
   The dummy operlist.txt file will be created automatically by Sigma if the existing operlist.txt file is deleted from the server and then a download to the controller is performed.
3. Default/Backup server number: Using the Diagnostics - View Comms Stats, check that all the controllers on the system do not have the default or backup server number configured the same as a controller number.
4. Logging Servers: Using the Diagnostics - View Logging Servers, check that no logging data sets have been created with a server number matching an existing controller number.
5. Wireshark Trace: If neither of the above help then it may be possible to look at the Ethernet data packets being received by the controller (obviously will not work if the controller is on an ARCnet LAN).   
   1. Set up a laptop with Wireshark (see Using WireShark to analyse communications on an Ethernet network) with an Ethernet hub at the controller.
   2. Run the trace until a reset/warmstart is observed at the controller
   3. Save the trace and email to Product Support or add and apply the following filter to show only those data packets being sent to the controller:
      ip.dst==192.168.2.1   (Change the IP Address to match that used by the controller)
      Look for packets that appear to come from another controller (source IP address).  For example below shows a request for the Lookosn.rec file on controller 1 (fault with operlist.txt file).