If another alarm server cannot be found, the alarm server will open the save file and restore the data from there. If there are two save files, one from the Primary server and one from the Standby server, Citect will use the one with the latest date. If no save file is configured, the alarm server cannot get the initial state of the alarms and there will be no summary information. In this case, the server will start processing the alarms, and then acknowledge all the new alarms. You can tell the Alarm server not to acknowledge the alarms on startup by setting the [ALARM] Ack=0 parameter.

While both alarm servers are active, they will both read data from the I/O Server and process the alarms. The on/off status of each alarm is not passed between the two servers. This limits the data transfer between the two servers. It also assumes that both servers must be reading the same data from the I/O Servers and so both will see the same alarms become active. When operators perform functions on alarms, for example, acknowledge, disable, enable, add comments, etc, this information is passed between the two alarm servers. (If an operator acknowledges an alarm on one server, that server will tell the other server to acknowledge the same alarm.) Note that there are some low level Cicode functions that only operate on the alarm server on which they are called - see the online help for full details.

You can only configure two Alarm servers in a Citect project, the Primary server and Standby server. Citect Clients either talk to the Primary or Standby Alarm server. On startup, they will try to talk to the Primary. If the Primary is not running, they will try the Standby. If the Primary comes back online, any Clients talking to the Standby will stay talking to the Standby server. (It does not matter which alarm server the clients talk to as they both contain the same data.) Allowing Clients to attach to either server will help balance the load generated by each client on the server.