Alarms and warnings
What they are
They serves to inform DAQ processes about problems detected by DAQ itself
or by user control or monitoring programs. By definition they are not foreseen
to inform an user in every detail, but as a problem report from rather
large systems. Then detailed analysis must be done by dedicated monitoring
programs. The current state of alarms and warning are transferred in a
run status segment for on-line monitoring and in BOB
data block of Begin of Burst events for off-line needs.
-
Warnings serves only to inform a user that something goes wrong
but DAQ continues to accept and write data.
-
Alarms serves to inhibit the data recording if it is set.
By RC_gui
at start of run a user can allow to write data of bursts with
detected alarms.
There are two kinds of alarms and warnings:
-
Hardware alarms are foreseen mainly for systems which are
not programmable or for computers which are running under non UNIX
style systems. The name reflects the fact that a signal must be put in
VME NIM input register to be recognized as an alarm and distributed for
other processes.
-
Software alarms and warnings are generated by DAQ, control or monitoring
processes running on computers with installed slow control libraries.
The automon
process displays alarms and warnings messages on a screen. It did not affect
on a set or reset alarms issued by other programs like HV monitoring
ones. Reset of an alarm may be done only by program which set it.
IMPORTANT! Program authors must provide the alarm reset at
exit of their monitoring program.
Implementation of software
alarm.
Any implementation of new alarms and warnings are not allowed
without expert (V.Olcshevskii, S.Trusov) permission.
To implement a new software alarm:
-
Inform experts (V.Olcshevskii, S.Trusov) about your needs and get
a number of alarm which your code will generate.
-
Add call of
initclient(3,0,0);
in main() function of your program.
-
Add function calls
set_soft_alarms(int how,
int alarm_number) ,
where how determines set (1) or reset (0) the alarm. The function
returns 0 if the execution failed and 1 in case of success. The header
file user_alarm.h should be added also.
-
Recompile your code and link it with Slow Control libraries ~daq/lib/libscclient.a
and ~daq/lib/libscutil.a
-
Set environment SC_HOST = pcdirac06
-
Use RC_gui to select: write or not write burst data at this alarm.
-
Start your code.
The function
int get_soft_alarms(int *alarm_bit_pattern_word)
serves to get software alarm bit pattern word. A set bit means
that there is an alarm with number equal to bit number. The function returns
0 if failed and 1 in case of success. You don't need to call this function
immediately after set_soft_alarms(() one, as the last one checks itself
that request was done properly.
IMPORTANT! Processes RD
and automon
must be restarted after implementation of new alarm or warning
What to do
You see an alarm messages, know the reason and decided to collect
and write data nevertheless.
-
Using RD you can check is data
recording allowed or not. If the lines informing about data file name and
its size are red, there is no data recording. If it is so, you must stop
run and using RC_gui
allows the data recording at the alarm.
-
Then if you decided on your responsibility to ignore the alarm, you have
two choices:
-
Nothing to do anymore and hear and see messages from the user program generating
this alarm.
-
Exit from an user program which generates this alarm. In last case, it
must reset alarm and so, it will not be distributed anymore. It will look
like it is absent at all. Please, write corresponding message in run logbook
in order the next shift could know that.