-<h3>Number of busy boards</h3>
+<h3>Busy Times / Busy Boards</h3>
<p>
-This button gives you the number of busy front-end boards, that have stopped working and are blocking the trigger.
+This field gives you the address of a busy front-end board, that has stopped working and is blocking the trigger.
During normal operation, the full message gives the busy times for all sub-systems.
-<h4>Error Handling if the button is not <font color="gree">Green</font></h4>
+<h4>Error Handling</h4>
<ul>
-<li>If there is "readout waiting" reported at the same time, the real problem is to be found there.
-<li>If there is a "sync" error reported at the same time, the real problem is to be found there.
-<li>Check the list of board addresses, which board is busy.
-<ul><li>If all addresses start with '2' (from MDC), try to resync missing OEPs
-<li>If all addresses start with '7' (from RICH), a 'Resync DiRich' should help
-<li>If not, a DAQ restart should solve the problem.
+<li>If there is a "sync" error reported at the same time, look there.
+
+<li>If there is "readout waiting" reported at the same time, look there.
+
+<li>Do a DAQ Restart
</ul>
+
+
+<h4>Additional notes</h4>
+<ul>
<li>If the misbehaving board is from MDC and the error happens several times for the same board,
do a MDC power-cycle of the corresponding chamber.
<li>If the board is from MDC, and there is a "FEE Error" at the same time, an MDC LV power-cycle is needed.
e.g. if the data transport to EB failed, the board with the smallest
buffer and the most data gets busy first.
-<p>*The list of addresses can be found at the wall next to the door to the server room.
+<p>*The list of addresses can be found on the main monitoring web page.
<p>
Checks which boards are out of sync with the rest of the boards
-<h4>Error Handling if the button is not <font color="gree">Green</font></h4>
+<h4>Error Handling</h4>
<ul>
<li>Check the list of board addresses, which board is busy.
-<li>If the address starts with '7' (from RICH), try to resync DiRich
-<li>If not, a DAQ restart should solve the problem.
+<ul><li>If all addresses start with '2' (from MDC), try "Resync missing OEPs"
+<li>If all addresses start with '7' (from RICH), try "Resync DiRich"
</ul>
+<li>Do a DAQ restart
+<li>If the problem came from RICH and the DAQ restart didn't help, try a "Reboot DiRich" and "Reboot RICH Combiner" (takes 1 second only) followed by a DAQ restart
+<li>If it happens several times for the same board, consider a reboot of the corresponding board / subsystem
+</ul>
+
+
+<h3>Read-out</h3>
+<p>Usually shows the amount of data send to event builders, or the possible cause of a problem when readout has stopped.
+
+<h4>Error Handling</h4>
<ul>
<li>If there is a "Sync" error reported at the same time, look there.
-<li>If the boards listed are from RICH (address starting with 7), do a Resync DiRich.
-<ul><li>If DAQ doesn't start again, make a DAQ Restart
-<li>If this didn't help, try a "Reboot DiRich" and "Reboot RICH Combiner" (takes 1 second only) followed by a DAQ restart
-</ul>
-<li>If the board is not from RICH, do a DAQ restart
-<li>If it happens several times for the same board, consider a reboot of the corresponding system (see the list on the wall next to the door to the server room for a list of addresses)
+<li>If the boards listed are from RICH (address starting with 7), do a "Resync DiRich".
+<ul><li>If this didn't help, try a "Reboot DiRich" and "Reboot RICH Combiner" (takes 1 second only) followed by a DAQ restart</ul>
+
+<li>Do a DAQ restart
+<li>If it happens several times for the same board, consider a reboot of the corresponding board (see the list on the web server)
</ul>
<p>
This button gives information about not responding front-ends.
</p>
-<h4>Error Handling if the button is not <font color="gree">Green</font></h4>
+<h4>Error Handling</h4>
<ul>
-<li>This time-out detection is only available for MDC. Try to ReSync missing OEPs (takes 15 seconds).
-<li>If the same board shows errors repeatingly, try a power cycle of this chamber.
+<li>If all addresses start with '2' (from MDC), try "Resync missing OEPs"
+<li>If all addresses start with '7' (from RICH), try "Resync DiRich"
+<li>Do a DAQ restart
+<li>If the same board shows errors repeatingly, try a reboot or power cycle of this subsystem.
</ul>
+
+
+<h4>Additional Notes</h4>
+<ul>
+<li>If the board is from MDC, and there is a "FEE Error" at the same time, an MDC LV power-cycle is needed.
<h3>Data Rate</h3>
<p>
-The data rate gives the amount of data per second transfered by all Eventbuilders. <br><br>
-<b>Also displayed are:</b> <br>
-the amount of data transfered per event,
-the total amount of data per second and
-the number of special calibration triggers recorded.
-</p>
-
-<h4>Error Handling if the button is not <font color="gree">Green</font></h4>
+The data rate gives the amount of data per second written to disk by all Eventbuilders and the average size of one event.
+
+<h4>Error Handling</h4>
<ul><li>No files are written - both rate numbers are 0. Check whether actually no data is to be taken. Switch EB to the correct file type or restart EB if this doesn't help.
<li>The rate of MDC calibration events and status events is not 1 Hz (check the long text on mouse over). Check in the CTS monitor if they are switched off (upper right corner)
<h3>Error bits</h3>
<p>
-This buttons shows the number of accepted events (written to disk) with errors reported by the front-ends.
-<br>Try to do a DAQ restart
-<br>In some cases a power-cycle of the corresponding system / chamber is necessary.
-<br>Please note that the error will not be reset on a DAQ restart! To reset it, restart EB.
+The number of accepted events (written to disk) with errors reported by the front-ends.
+<h4>Error handling</h4>
+<br>Try to do a DAQ restart
+<br>In some cases a reload or power-cycle of the corresponding system / chamber is necessary.
This button gives you the number of discarded events in the Eventbuilders. Few discarded events (<1%) are fine.
</p>
-<h4>Error Handling if the button is not <font color="gree">Green</font></h4>
+<h4>Error Handling</h4>
<dl>
<dt>Check the datarate that is delivered by DAQ</dt>
<dd> If many events are lost, the EB might be overloaded. Check that the trigger rate is about the expected value.</dd>
-<dd> Check that the number of eventbuilders can handle the intended datarate. Beam runs require at least 4 builder nodes, 8 is usual. Try to increase the number of event builders using the buttons "Set x EB" in the operator GUI</dd>
+<dd>Check that the number of eventbuilders can handle the intended datarate. Beam runs require at least 4 builder nodes, 8 is usual. Try to increase the number of event builders using the buttons "Set x EB" in the operator GUI</dd>
<dd> Check in the EB summary that writing data to local disk and TSM/lustre is working. There might be backpressure if too much data is written to tape. Try reducing the trigger rate.</dd>
<dt>Restart the Eventbuilders</dt>
-<dd>Only if datarate from DAQ is ok and many events are discarded. See details on restarting eventbuilders at <a href="doc.cgi?eb-run">#EB running</a></dd>
+<dd>Only if datarate from DAQ is ok and many events are discarded.
<dt>Try reboot of a failing DAQ system.</dt>
-<dd>If the data sent by some system should be corrupted, try to reboot it using
-the "Reboot XY" buttons in the DAQ section of the operator GUI. <b>Only if there is a hint (not green light in tactical overview) that something is wrong!</b> </dd>
+<dd>If the data sent by some system should be corrupted, try to reboot it. <b>Only if there is a hint (not green light in tactical overview) that something is wrong!</b> </dd>
<dt>DAQ restart</dt>
-<dd>Use "Start DAQ" button in operator GUI. If eventbuilders still discard events or do not work properly, restart them as described in <a href="doc.cgi?eb-run">#EB running</a></dd>
+<dd>Use "Start DAQ" button in operator GUI. If eventbuilders still discard events or do not work properly, restart them
</dl>
<p>
The left number shows the average event rate (Ev/s) accepted by the central trigger system (CTS) in previous 120 seconds. <br>
The right number shows the average event rate collected by the event builders (BNET). <br>
-<b>Both values should be approximately the same.</b>
+Both values should be approximately the same, but differences are to be expected due to different counting methods.
+<b>Note that this currently has a bug: Even when there is an error, the field flashes red only every few seconds and is green in between!</b>
</p>
-<h4>Error Handling if the button is not <font color="gree">Green</font> for more than 10 seconds: </h4>
+<h4>Error Handling </h4>
<dl>
<dt>In case of a negative deviation</dt>
<h4>Error Handling</h4>
-<ul><li>First thing to try: "Resync OEP".
+<ul><li>First thing to try: "Resync OEP" (not if >4 boards are missing).
<li>If this doesn't help, do a DAQ restart.
-<li>If this doesn't help, do a power cycle of the MDC sector and Reboot OEP.
+<li>If a board shows an error directly after DAQ restart several times, do a power-cycle of the corresponding sector
<li>If this doesn't help, use "Reboot MdcHub" plus 2 DAQ restarts.
-<li>If 1-3 boards show an error, do a power-cycle of the corresponding sector
-<li>If 7-9 boards show an error, do a DAQ restart
<li>If 14/16 boards show an error after a power-cycle, click "MDC LV Turn On ALL Relais". You can
check the status of relais <a href="/mon/monitor.cgi?1-window-MDCLV">here</a>.
</ul>
<h4>Error Handling</h4>
<p> Restart DAQ. If this doesn't help, do a power-cycle of the corresponding system.
- - see the list of addresses on the wall next to the door to the server room.
<h4>Error Handling</h4>
<ul>
-<li>Do a DAQ restart
-<li>If the same board (with 7xxx address) misses again afterwards, use "Resync DiRich" and another DAQ restart
+<li>Try a Resync DiRich
+<li>Do a DAQ restart
+<li>Do another DAQ restart
<li>If this doesn't help, use "Reboot DiRich", "Reboot Rich Combiner" and a DAQ restart
<li>If many boards are missing (>100), check RICH power supplies
<li>If a hub board (with 8xxx address) is missing as well and a DAQ restart does not help, consider a RICH power cycle
<h3>ECal Endpoints</h3>
-This button shows if all ECal front-end modules are active. The button is red if at least one module
+This button shows if all ECal / STS / fRPC front-end modules are active. The button is red if at least one module
is missing.
<h4>Error Handling</h4>
<p> Restart DAQ.
-<p>If this doesn't help after the third try, do a power-cycle of the ECalRpc 48V supply. Afterward,
-do a Reprogram FPGA and Restart DAQ.
+<p>If this doesn't help after the third try, do a power-cycle of the 48V supply of the corresponding system.
module is missing.
<h4>Error Handling</h4>
-<p> Restart DAQ. If this doesn't help, do a power-cycle of the corresponding system - see the list
-of addresses on the wall next to the door to the server room.
-
+<p> Restart DAQ. If this doesn't help, do a power-cycle of the corresponding system
This button shows the number of boards that have not been initialised in the last few seconds.
This might appear from time to time because a front-end had an error bus recovered automatically.
-<h4>Error Handling in case it is not <font color="gree">Green</font> for more than 30 seconds.</h4>
-<ul><li>If there is a busy at the same time:
-<ul><li>If the board belongs to MDC: Do a LV power-cycle of the chamber
-<li>Else: Do a DAQ restart.
-</ul>
-<li>Else: Do a DAQ restart.
+<h4>Error Handling </h4>
+<ul>
+<li>Do a DAQ restart
+<li>If the board belongs to MDC: Do a LV power-cycle of the corresponding chamber
</ul>
--- /dev/null
+<h3>RPC Thresholds</h3>
+Monitors the noise level in RPC. Sometimes noise in a part of the detector gets too high because of problems with the thresholds. Problems should also be visible in the rate plots for the detector (in one of the main operator windows).
+<h4>Error Handling</h4>
+Use "Thresholds RPC" to reload the proper settings. A DAQ restart is not needed.
+<br>If the situation doesn't change, inform the RPC operator.
This button shows the trigger input errors. This could indicate a problem with a trigger / reference time / common stop signal.
</p>
<h4>Error Handling</h4>
-Restarting DAQ should help, but could also be a mechanical issue.
-
+This usually points to an electrical error in the trigger cabling in the cave. Nevertheless, try a DAQ restart.
+<h3>Beam Abort</h3>
+The beam abort is used to shut down the accelerator in emergency cases. The long message contains the current status of all possible sources of the beam abort.
+<ul><li>If red blinking, the error condition is active, no beam to Hades should be possible
+<li>If red, the error was active at some earlier point in time. Needs to be reset manually
+<li>If yellow, the logic is not active and not beam abort will happen.
+</ul>
+
+<h4>Error Handling</h4>
+<p>Errors have to be handled by the shift leader and the accelerator control room.
<h3>CTS Current Rate</h3>
-The current rate at which triggers are sent by the CTS. The rate should always be in the expected region! If it is not, first take a look at the CTS monitor for the TOF and RPC rates to find out where the problem is located.
+The current rate at which triggers are sent by the CTS. The rate should be constant, depending on the beam intensity and spill shape!
<h4>Error Handling</h4>
-<dl><dt><strike>Shown trigger rate is low, but DAQ is running faster<dd>The counter has a bug if the trigger rate is above 130kHz (only reachable with pulser) due to a counter overflow. Ignore the warning message in this case.</strike>
+<dl>
+<dt>Rate is 0<dd>
+<ul><li>If a red 'sync' error is shown (second row, right), the problem can be found there.
+<li>If a red 'readout' error is shown (second row, right half), the problem can be found there.
+<li>Check the "Busy Boards" to see if a front-end has stopped working and is blocking the trigger.
+</ul>
+Follow the usual <a href="doc/restartdaqguideline.htm">restart DAQ guidelines</a> to get the DAQ running again.
<dt>Rate is 2-5 Hz<dd>Typically this happens when only calibration triggers are sent and no additional triggers are generated. Make sure this is desired and trigger settings are right.
-<dt>The rate is 0<dd><ul><li>Check the "<a href="doc.cgi?daq-busy">Busy Boards</a>" monitor to see if a front-end has stopped working and is blocking the trigger. Follow the usual <a href="doc/restartdaqguideline.htm">restart-DAQ guidelines</a> to get the DAQ running again.
-<li>Check the CTS settings if the right trigger source is selected.
+
+<dt>Unusual Value<dd>Check the CTS settings if the right trigger source is selected. Check the beam detectors to see if there is an accelerator problem.
+</dl>
+<h3>Uptime</h3>
+The time since the last restart of the DAQ. Might be reset in case the monitoring is restarted manually.
+For information only.
-<h3>MDC Blocked</h3>
+<h3>MDC w/o data</h3>
<p>
-This button gives the number of MDC-MBO that do not deliver data (updated only if rate per motherboard is above 1000, and trigger is running at
+This button shows the number of MDC-MBO that do not deliver data (updated only if rate per motherboard is above 1000, and trigger is running at
more than 1000 Hz).
</p>
<h3>MDC Token</h3>
<p>
-This button shows the number of automatically corrected motherboard errors. The number shouldn't be too high since any re-initialisation needs time. For very high rates, consider a power cycle of the corresponding chamber.
+This button shows the number of automatically corrected motherboard errors. The number shouldn't be too high since any re-initialisation needs time. For very high rates, consider a power cycle of the corresponding chamber. Ask the MDC expert.
</p>
<br>
<h4>Error Handling if the button is not <font color="gree">Green</font></h4>
-Please run a new TDC calibration. Possible reasons are:
+Please talk to the DAQ expert if a new TDC calibration is needed. Possible reasons are:
<ul>
-<li>The temperatur has shifted to far from last calibration.
+<li>The temperatur has shifted too far from last calibration.
+<ul><li>This can happen after some boards have been shut off for some time and haven't reached their normal working temperature yet. </ul>
<li>There are front-ends in the system whose calibration file has not been updated
<li>The time since the last calibration is too long
<li>Eventbuilders return a bad quality of the last calibration run
+<h3>Environment</h3>
+A monitor for the environment in the cave. The sensor is located below the RICH, next to the DAQ crates mounted there.
<h3>EPICS HV Sequencer</h3>
+Sequencers are a part of our high voltage control and monitoring system. All should be active for a safe operation.
-<p>Some high voltage control is not working any more. Please inform the MDC operator before taking any action.
<h4>Error Handling</h4>
-<p>Click the 'Restart Sequencer' button in the control window or run on lxhadeb06:
-<br><pre>ssh scs@lxhadeb06 'echo -en "\x18" | netcat -w 1 localhost 4813</pre>
+<p>Some high voltage control is not working any more. Please inform the respective detector expert before taking any action.
+<p>Click the 'Restart Sequencer' button in the control window
<br>Restarting might take a minute until the button is green again.
+<h3>Padiwa ECal</h3>
+Shows the status and temperature of all Padiwa front-end boards in ECAL.
+
+<h4> Error Handling</h4>
+If the error persists for more than a minute, do a DAQ restart.
+If this doesn't help, a powercycle of the ECAL front-ends might be needed.
+
+<h3>Padiwa Hodoscope</h3>
+Shows the status and temperature of all Padiwa front-end boards in the Hodoscope.
+
+<h4> Error Handling</h4>
+If the error persists for more than a minute, do a DAQ restart.
+If this doesn't help, a powercycle of the Hodoscope front-ends might be needed.
+
+<h3>Padiwa iTOF</h3>
+Shows the status and temperature of all Padiwa front-end boards in iTOF.
+
+<h4> Error Handling</h4>
+If the error persists for more than a minute, do a DAQ restart.
+If this doesn't help, a powercycle of the iTOF front-ends might be needed.
+
+<h3>Padiwa Start</h3>
+Shows the status and temperature of all Padiwa front-end boards in Start.
+
+<h4> Error Handling</h4>
+If the error persists for more than a minute, do a DAQ restart.
+If this doesn't help, a powercycle of the Start front-ends might be needed.
+
--- /dev/null
+<h3>STS</h3>
+Shows the current consumption of the STS-2 FEE
+
+<h4> Error Handling</h4>
+An error is shown if the power consumption is lower than nominal.
+Ask the STS operator to check if all frontends are operational or if a fuse is broken.
-The actual rate on the PT1 (M2) trigger input. The left number is the raw count, the right number is after subtraction of the off-spill count rate to reduce noise.
+<h3>Rate on trigger inputs</h3>
+The actual rate on the PT1 trigger input. The left number is the raw count, the right number is after subtraction of the off-spill count rate to reduce noise.
-The actual rate on the PT1 (M2) trigger input. The left number is the raw count, the right number is after subtraction of the off-spill count rate to reduce noise.
+<h3>Rate on trigger inputs</h3>
+The actual rate on the PT2 trigger input. The left number is the raw count, the right number is after subtraction of the off-spill count rate to reduce noise.
-The actual rate on the PT1 (M2) trigger input. The left number is the raw count, the right number is after subtraction of the off-spill count rate to reduce noise.
+<h3>Rate on trigger inputs</h3>
+The actual rate on the PT3 trigger input. The left number is the raw count, the right number is after subtraction of the off-spill count rate to reduce noise.
-The actual rate on the PT1 (M2) trigger input. The left number is the raw count, the right number is after subtraction of the off-spill count rate to reduce noise.
+<h3>Rate on trigger inputs</h3>
+The actual rate on the PT7 trigger input. The left number is the raw count, the right number is after subtraction of the off-spill count rate to reduce noise.
-The actual rate on the PT1 (M2) trigger input. The left number is the raw count, the right number is after subtraction of the off-spill count rate to reduce noise.
+<h3>Rate on trigger inputs</h3>
+The actual rate on the PT8 trigger input. The left number is the raw count, the right number is after subtraction of the off-spill count rate to reduce noise.
<h3>DiRICH Voltage</h3>
<p>
-This button gives you the minimum and maximum voltage of the FEE of the RICH detector.
+This displaces you the minimum and maximum voltage of the FEE of the RICH detector.
<h4>Error Handling if the button is not <font color="gree">Green</font></h4>
<ul>
<li>Check if a backplane has significant different voltage values in <a href="rich_drawing_2.htm#rich1V">DiRICH 1.1V</a> and <a href="rich_drawing_2.htm#rich2V5">DiRICH 2.5V</a>. Higher values on 4x4 backplanes are
normal!
-<li>If a single backplane is on low power and makes problems, the LV connector has to be pressed in. An expert is needed!
-<li>If Backplanes are white, possibly a LV Powersupply failed. An expert is needed!
+<li>If a single backplane is on low power and makes problems, the LV connector at the detector has to be pressed on. This should only be done by an expert!
+<li>If backplanes are white, possibly a LV powersupply failed. An expert is needed!
</ul>
<h3>DiRICH Temperature on Backplane</h3>
<p>
-This button gives you the minimum and maximum temperature between the Backplane and the MAPMTs (as well as at the inner spokes) in the RICH detector. <br/>
-This temperatur is critical for the RICH! The backplane temperature is connected to a interlock that shuts down the RICH after a certain temperature is reached (See Tactical Overview).
+This button gives you the minimum and maximum temperature between the backplane and the MAPMTs (as well as at the inner spokes) in the RICH detector. <br/>
+This temperature is critical for the RICH! The backplane temperature is connected to an interlock that shuts down the RICH if a certain temperature is reached as indicated above.
<h4>Error Handling if the button is not <font color="gree">Green</font> or <font color="orange">Orange</font></h4>
<ul>
<li>Temperature of DiRICH is too high.
-<li>Check temperature of the <a href="rich_drawing_bkpl.htm#richTemperatureBackplane">Backplane</a> and the <a href="monitor.cgi?10-RichInnerTemp">Gas </a>. Is update time up to date?
-<li>If temperature is realy to high and it stays to high (ca. 2 min), call the operator.
-<li>If Interlock has fired and RICH is down, call the operator.
+<li>Check temperature of the <a href="rich_drawing_bkpl.htm#richTemperatureBackplane">backplane</a> and the <a href="monitor.cgi?10-RichInnerTemp">gas </a>. Check if "update time" is up to date.
+<li>If temperature stays too high (ca. 2 min), call the RICH operator.
+<li>If interlock has fired and RICH is down, call the operator.
</ul>
-<h3>Isobutan Gaspipe (RICH radiator)</h3>
+<h3>Iso-butane gas pipe (RICH radiator)</h3>
<p>
-This values indicate the status of the isobutan gas system.</br>
-<b>Isobutan pressure:</b> Pressure of the inlet.</br>
-<b>O<sub>2</sub> concentration:</b> value should be below 400ppm. Oherwise a warning/error is shown.</br>
-<b>Isobutan Ratio:</b> Should be below 50. Oherwise a warning/error is shown.</br>
-<b>Scales:</b> weight of the two bottles next to of the target hall. Weight is an indication for an exchange of the bottles.</br>
+This values indicate the status of the iso-butane gas system.</br>
+<b>Iso-butane pressure:</b> Pressure of the inlet.</br>
+<b>O<sub>2</sub> concentration:</b> value should be below 400ppm. Otherwise a warning/error is shown.</br>
+<b>Iso-butane ratio:</b> Should be above 50. Otherwise a warning/error is shown.</br>
+<b>Scales:</b> Weight of the two bottles next to the target hall door. Weight is an indication for an exchange of the bottles.</br>
+<h3>RICH Thresholds</h3>
+Checks if the thresholds for all RICH frontends are loaded properly.
+
+<h4>Error Handling</h4>
+A small number of problems (<100) is usually no problem and can be ignored.
+If a larger number is shown, reload thresholds for RICH (might take a while).
+If this doesn't help, talk to the RICH operator.
<h3>DiRICH Temperature</h3>
<p>
This button gives you the minimum and maximum temperature of the DiRICH boards of the RICH detector.
-This temperature is not directly criticly for the RICH operation, but it influences the inner temperature.
+This temperature is not directly critical for the RICH operation, but it influences the inner temperature.
<h4>Error Handling if the button is not <font color="gree">Green</font></h4>
<ul>
<li>Temperature of DiRICH is too high.
-<li>Check temperature of <a href="rich_drawing_2.htm#richTemperature">all DiRICHs</a>. Is update time up to date.
-<li>If temperature is realy to high and it stays to high (ca. 2 min), call the operator.
+<li>Check temperature of <a href="rich_drawing_2.htm#richTemperature">all DiRICHs</a>. Check if "update time" is up to date.
+<li>If temperature stays too high (ca. 2 min), call the RICH operator.
</ul>
a high server cpu may lead to discarded events. <br>
See a list of the CPU loads <a href="/mon/monitor.cgi?10-window-EBCPU">here</a>.
</p>
-<h4>Error Handling if the button is not <font color="gree">Green</font></h4>
+<h4>Error Handling</h4>
<dl>
<dt>You should have a look if there is some error in the status of the Eventbuilder-buttons.</dt> If not, ignore the error.
-<dd>If there is a problem, restart Eventbuilders as described in <a href="doc.cgi?eb-run">#EB running</a></dd>
+<dd>If there is a problem, restart Eventbuilders</dd>
</dd>
</dl>
</dl>
<p>
This button gives the disk fill level.
</p>
-<h4>Error Handling if the button is not <font color="gree">Green</font></h4>
+<h4>Error Handling </h4>
<dl>
-A detailled view of the fill level of every single disk can be seen <a href="http://hadesdaq02/mon/monitor.cgi?30-EBDisks">here</a>. The DAQ expert (!) should delete
-files, that have already been copied to lustre or on tape.
+A detailled view of the fill level of every single disk can be seen <a href="mon/monitor.cgi?30-EBDisks">here</a>. The DAQ expert (!) can delete files that have already been copied to lustre or on tape.
</dl>
<h3>Trigger accepted</h3>
<p>
This button shows in percentage of available triggers accepted by the CTS to read out the front-end boards.
-Typical value should be around 50% in total.
+<strike>Typical value should be around 50% in total, depending on the beam intensity.</strike>
The first value shows the percentage of accepted triggers in the last second, the second value is the integral number for the last spill.
</p>
<h4>Error Handling if the button is not <font color="gree">Green</font></h4>
<h3>PT3 Rate</h3>
-<p>
+<strike>
This button shows the triggered high multiplicity events per second compared to the countrate in the Start-detector.
<!--The second number should be around 0.7% during beam time since the interaction rate is around
1%. The first value is the rate
If something goes wrong, ask your shift leader.
+</strike>
<h3>Trigger sources</h3>
<p>
-This button displays the used Trigger source. It is <font color="yellow">yellow</font> if there is a trigger input error to CTS.
-</p>
-If the button is <font color="#AC0">olive</font>, the pulser is switched on.
+This button displays the used Trigger source.
+<ul>
+<li>It is yellow if there is a trigger input error to CTS.
+<li>If the button is olive, the pulser is switched on.
+<li>If orange, the trigger is stopped (e.g. via the Control GUI)
+</ul>
-<h4>How to deal with problems:</h4>
+<h4>Error Handling</h4>
<ul>
-<li>If the port that is displayed above is not a selected trigger source or not corresponding to Start/Veto, the error
-can be ignored.</li>
<li>Restart DAQ to make sure all settings are loaded correctly
</ul>
<p>
This button gives you the number of counts per second in the start-detector of the last spill (second value). The first one is the trigger count for the last second.
<br>
-In case of problems, ask your shift leader.
-
+Note that this number saturates quite early, at a couple MHz beam ion rate.
jspc29 / hadesdaq.git / commitdiff