Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Use the "startami" command. This will start a second client if you are not on the main DAQ machine and it will restart the DAQ AMI client if run on the main DAQ machine (after asking for confirmation, so you will need to use a terminal). Should the server side by unhappy, you will need to restart the DAQ.

Troubleshooting the DAQ

Ami does not work: the DAQ is fine after a restart, but I see no updates/detectors in ami

Make sure that all dss nodes are selected. If you needed to take a node out due to problems, you need to edit the <hutch>.cnf file. You can use "serverStat <ip>" to get the name for the node that causes a problem and then edit the list of dss_nodes to exclude this node. If the problematic node is the last one, you might see that you have to reselect the Bld upon a restart. This means that the DAQ will make you allocate twice (the first time it'll fail with a complaint about a Bld change).

A second cause for this problem can be that the calib-dir is not mounted on the non-nodes anymore. ami will look for the pedestal files here, so it will take a long time until int times out and will start, but w/o the detectors. You can check if that is the case by looking at an ami log file (e.g. for ami0-0) or ssh to a moo-node in use and  check if you can see the pedestals files in /reg/d/psdm/<hutch>/<expname>/calib/<dettype>/.... At this point, please call your on-call ECS person who will escalate it or work around it.

The DAQ shows "NO CONNECT" in procStat: 

...