The trigger manager class will in general have exactly one instance: the trigger manager process. The trigger manager accepts registration requests followed optionally by trigger reports from registered monitor processes. The triggers are routed to the meta-Database, used to generate EPICS alarms or ignored, depending on the trigger disposition field, annd on the Trigger manager configuration. The trigger manager also produces html status reports that summarize the state of the trigger manager and recent trigger activity.

The trigger monitor process is run with the following command line:

   TrigMgr [-ofile <trig-direc>] [-notify <e-mail>] [-ntrig <in-file>]
           [-debug <level>] [-noDB] [-noEpics] [-timeout <nsec>]

Where the meanings of the flags are summarized in the following table:

-access <a-file>	Specify an access (configuration) file
-debug <level>	Specify a debug printout level. No debug messages are produced at the default level [0]. The message volume increases with the level.
-idletime <t-idle>	Number of seconds to wait for next trigger.
-maxtime <t-max>	Max seconds before forced file write.
-noDB	Disable database logging. Storage of xml trigger files will continue.
-noEpics	Disable Epics alarm generation.
-notify <e-mail>	Specify the e-mail address to which messages will be sent by LDAS each time a trigger ingestion job finishes.
-ntrig <in-file>	Specifies the number of triggers to write per XML file (barring timeout).
-ofile <trig-direc>	Specify the directory to which the XML trigger tables are to be written. By default HOME/triggers is used.
-timeout <nsec>	Watchdog timer - If no trigger arrive in the specified time, any saved triggers will be written out.

TrigMgr Inputs:

Configuration File
The TrigMgr configuration file specifies which triggers are accepted by the trigger manager and optionally places limits on the disposition of the trigger. The trigger configuration file contains one or more lines, each of which specifies the disposition of a group of triggers. If a trigger matches more than one trigger group, the first group specified will take precedence. Each line contains the following fields separated by spaces:

Process Name	Name of the monitor generating the specified trigger
Process Version	Version number of the monitor.
Trigger ID	The trigger ID string
Trigger sub-ID	The trigger sub-ID string.
-dmask <mask>	Mask of allowed dispositions for the trigger group.
-maxprty <max>	Maximum allowed priority for the trigger group.

The first four fields must be specified in the order listed. An asterisk (*) may be used to allow any value for the positional fields.

Messages:
The trigger manager accepts monitor messages as defined in TrigMsg.hh. The following message types are handled:

TMM_REGISTER	The specified process is registered with the trigger manager. The message carries a TrigProc object identifying the registering process. If the registration succedes, the trigger manager replies with a TMM_ProcID message with a unique process ID determined by the trigger manager. If an identical process is already registered, the Trigger manager returns the existing process ID. Otherwise, if the ProcessID field of the message has a valid process ID, the process ID is used. In all other cases the trigger manager assigns the process a new ID.
TMM_TRIGGER	Defines a trigger to be processed. The trigger may be forwarded to either the EPICS alarm system or the meta-database or both depending on the trigger disposition field and the trigger control database. The trigger manager will reply with either a TMM_Ack or TMM_NAck message depending on whether the trigger and triggering process were recognised.
TMM_Close	Causes the specified process to be unregistered.
<other>	Other message types are ignored and no reply is returned.

Signals:
Signals are used to terminate the trigger manager or to cause it to reread its configuration file.

SIGHUP	Reread the configuration file. Counts from continuing trigger classes are left intact
SIGINT	write out pending triggers and terminate.
SIGTERM	write out pending triggers and terminate.

TrigMgr Outputs:

Trigger meta-Data Tables: TrigMgr writes the summarized trigger data to XML table files. The table files are given a unique name of the form TrigMgr<unique-id>.xml, where <unique-id> is a unique numeric identified composed of the date and time and a sequence number. XML tables are written whenever a fixed number of triggers (see -ntrig command line argument) have been accumulated, a HUP signal is caught or the watchdog timer expires without any new triggers having been received. After writing a trigger table file, TrigMgr submits a job to the LDAS Manager API with the ldas_submit script (which must be available in the process path) to copy the trigger to the LDAS meta-Database.

Trigger Manager Status: TrigMgr writes the current status to html files. This is stored in $DMTHTMLOUT/TrigMgr.html making it accessible via the CDS Web server (e.g. http://blue/gds/monitor_reports/TrigMgr/TrigMgr.html). The status page contains a list of all currently registered processes and a summary of all configured triggers.

Author:

J. Zweizig

Version:

1.0; Modified April 24, 2003