Introduction

The primary tool for monitoring the state of the LGD is lgdmond. This program checks the BOS and EOS events, and logs any problems it finds. In addition, in the case of major failures, it will send alarms to the alarm server.

Getting Data

In order to be assured of getting data, lgdmond runs off of DAQ shared memory. This guarantees that it will see enough data, regardless of what analyzers are running, etc. This also means that it must run on mpsdaq. It is normally started as part of the standard DAQ startup.

Entire spills are grabbed from shared memory (queue = BUF_EB_LGD3), and the BOS and EOS events are examined. An area of shared memory is also set up that holds data so other programs can access it (this is not fully implemented), and also for commands to be sent to lgdmond.

So as not to take up too much CPU, lgdmond is configured to skip some spills, and not process them. Normally, it only processes every third spill.

Processing Data

When lgdmond gets a spill, it does the following:

• Extract the BOS and EOS events from the record.
• If it is a new run, it dumps a list of problems (see below) and then zeros counters, etc. Also saves pedestal info to map.
• Checks the status of the MPS magnet. If this is the first event of a new run, it stores the status (on or off). If it is not the first event of a run, it makes sure the status has not changed. If it it has, it sends an alarm, and ignores the rest of the spill.
• Extracts the ADC data from the event.
• Checks for pedestals at or below threshold (0) and accumulates pedestal everages.
• Checks the the normalization tube fired on the EOS event. If not, it sends an alarm and ignores the data. If it did :
  • Accumulate averages.
  • Check for channels below threshold (25). Check for dead columns (20 or more channels below threshold) and dead splitters (all columns for a splitter dead).

Reporting Problems

At the end of each run, a list of problems is created, and saved to $E852_LOGDIR/LGD/RunXXXX.log. This uses the averages that have been accumulated during the run. This data will only be dumped if at least 50 spills have been seen by lgdmond. The list contains:

• LOW MONITORING : The channels average monitoring signal was below 30 counts.
• WIDE MONITORING : The width of the average was greater than 25%. Note that a channel that is both low and wide will only be reported as low.
• LOW PEDESTAL : The channels average pedestal was below 3 counts.
• WIDE PEDESTAL : The width of the average was greater than 6 counts. Note that a channel that is both low and wide will only be reported as low.

Controlling lgdmond

The primary means of controlling lgdmond is through a perl script, ctl.lgdmond. This takes one of three arguments :

• start : Start lgdmond with it's respawn script, start.lgdmond. The respawn script sends an alarm and restarts the program every time it crashes or quits.
• stop : Stop lgdmond and it's respawn script. This will cause lgdmond to exit gracefully and not restart when it gets it's next spill!. This is because of how communication is handled with lgdmond.
• kill : Kill lgdmond and it's respawn script NOW!. Not very gracefull, but it works all the time.

You can also send two commands directly to lgdmond with the program mondCommand. It communicates with lgdmond through shared memory, and thus must also be run on mpsdaq. After every spill, lgdmond checks to see if there is a command for it. AT this time, mondCommand takes on of two arguments :

• EXIT : This causes lgdmond to exit. This is how the ctl.lgdmond script does a stop. Thus, since lgdmond only checks for commands after it looks at a spill, if there are no spills coming, it never looks, and a ctl.lgdmond kill may be needed
• DUMP : This forces lgdmond to dump a report of it's problems now, dumping to the normal place. At the end of the run, the end of run dump will be appended to this forced dump, unless the file is removed.

** 1/18/94 R.L.