Alarms handling algorithm is shown in figure at the right. Each analog signal is read by the CPU, averaged by certain samples, and compared with the threshold with an appropriate sign of comparison ("<" or ">"). If an alarm occurred at this signal (analog value exceeds the threshold), the program lights correct LED. Then it takes into account the blocking status of the current alarm. If alarm is not blocked, software takes appropriate action by changing the default state of the digital outputs. In case of the blocked alarm, program just lights both LED for this alarm (ALARM LED and BLOCK LED) and tries to return digital outputs to default state, if it’s allowed by other channels. If alarmed analog signal returns to it’s normal range, system tries to return digital outputs to non-alarm state, again considering other alarmed channels.
The DEFAULT state is a special digital outputs pattern, which allows full control of the gas system by a computer. In this state, if computer doesn’t switch on any device, no devices are switched on; but computer is able to turn on any of them. In other words, Alarm System doesn’t lock any device. This means that in case of total blocking (code 79) gas system becomes fully controllable by a PC.
The idea was as follows. If alarm is not blocked and there is an alarm situation in some channel (some parameter exceeds the threshold) the code changes the default state of the digital outputs only in the memory, and stores in the memory which outputs it changed. If there is no alarm, the code changes only those outputs, which were not alarmed by the previous channels, making use of the stored list of the changed outputs. So the outputs which changed their states because of the alarm are not affected by the alarm recovery procedure, if we consider a single processing (handling) cycle. Only after processing of all the channels the result of their influence upon the digital outputs really comes out of the memory. This eliminates wrong digital output states and "flashing" of these signals.