...
Should your detector not configure, it is either not turned on, needs power cycling or some cable is not patched correctly. Please let CDS folks know which detectors you would like to use so we can test them beforehand.
Some detectors have a stand-alone version of the DAQ process that can be run on the server the detector is connected to. This is the case for the Jungfrau, the Alvium and the Zyla for example. This is very helpful to decouple DAQ problem from detector setup issues.
The binaries can be found in /cds/group/pcds/dist/pds/current/build/pdsapp/bin/x86_64-rhel7-opt/
. The detectors can be tested in free-run and triggered mode (the DAQ must be running for that). The stand-alone processes take similar argument as the DAQ process. It is a good idea to check the cnf and pass the same arguments.
Example:
Warning |
---|
These processes should be run as <hutch>opr. It would run as yourself, but sometimes the process creates files and this lead to permission issues when running the DAQ with the opr account. |
Code Block | ||||
---|---|---|---|---|
| ||||
./vimbaStandAlone -n 10 -t |
Troubleshooting ipimbs is described on this page:Troubleshooting for Controls IPIMB and Wave8s
The possible problems are that there is an issue with the EVR, the RCX boxes (data coming back from the camera) or the EDT card.
If no other physically triggered devices on the same EVR work either (other OPALs, Alviums, Zylas or Jungfraus), the problem is likely the EVR: as an expert, I would run evrsnoop. The second step is to power cycle the master (using serverStat or another method).
Should other triggered devices run, you can choose to look at the LEDs on the camera: if the are solid green, the boxes are not the issue. Should a camera have just run recently, it is likely NOT the RCX box.
...
Troubleshooting ipimbs is described on this page:Troubleshooting for Controls IPIMB and Wave8s
The possible problems are that there is an issue with the EVR, the RCX boxes (data coming back from the camera) or the EDT card.
If no other physically triggered devices on the same EVR work either (other OPALs, Alviums, Zylas or Jungfraus), the problem is likely the EVR: as an expert, I would run evrsnoop. The second step is to power cycle the master (using serverStat or another method).
Should other triggered devices run, you can choose to look at the LEDs on the camera: if they are solid green, the boxes/fibers connecting them are not the issue. Should a camera have just run recently, it is likely NOT the RCX box.
The third suspect is the EDT card. Try to power-cycle the server: with luck, this will reset the card and make things work again. serverStat will take the DAQ alias as argument, no need to peruse the cnf-file.
One of the things to check here is the EVR: first, run 'evrsnoop' on the EVR host machine (typically dad-<instrument>-master).
The command is
/cds/group/pcds/dist/pds/current/build/pdsapp/bin/x86_64-rhel7-opt/evrsnoop -h
-h will list all options, you will need to specify which EVR with the '-r a/b/c' option and which event codes you want to check with the -o <code> option. I would usually use event code 40 as that should always come and you can check if the fiducial differ by 3. The output should look something like this:
After confirming that the EVR receives the event codes, check that the cable at the back of the card is properly seated and that the correct channel is running to your detector.
Received Fiducial 010353 Event code 40 Timestamp 11828
Received Fiducial 010356 Event code 40 Timestamp 11828
Received Fiducial 010359 Event code 40 Timestamp 11828
Received Fiducial 01035c Event code 40 Timestamp 11828
After confirming that the EVR receives the event codes, check that the cable at the back of the card is properly seated and that the correct channel is running to your detector.
My BLD misses a source:
You will have to fix this with the mask used in the bld-process in the cnf file.
...
[ Take out the nodes with the issue, assuming your problem is limited to a single node. If it's wider spread, it might warrant a call.]
Most likely, the recorder process cannot connect to the node that you are trying to run the recording process on. This node depends on the source and is listed in your .iocrc file. You can use serverStat to check on the server health and power cycle if appropriate.
This means your recording process is up and you can connect to the PVs. If this PV does not have well-formed timestamps when you request this (necessary for cameras!), the data the process would want to record cannot be found as the timestamp us used to determine what should be recorded.
First, please make sure the image in the camViewer updates. This means the IOC is up and running. The recorder process uses a special interface on a special machine, so in addition this this, that machine needs to be up (see recorder source and DAQ won't start). More details can be found here:
Most likely, the recorder process cannot connect to the node that you are trying to run the recording process on. This node depends on the source and is listed in your .iocrc file. You can use serverStat to check on the server health and power cycle if appropriate.
This means your recording process is up and you can connect to the PVs. If this PV does not have well-formed timestamps when you request this (necessary for cameras!), the data the process would want to record cannot be found as the timestamp us used to determine what should be recorded.
First, please make sure the image in the camViewer updates. This means the IOC is up and running. The recorder process uses a special interface on a special machine, so in addition this this, that machine needs to be up (see recorder source and DAQ won't start). More details can be found here:
LCLS1 XTCAV Controls Recorder Troubleshooting
Assuming your timetool camera (either an OPAL or now an Alvium works), some details that need to be set are descirbed at Timetool Troubleshooting
Keep in mind that too large an ROI can lead to problems for 120Hz running (at least w/ an OPAL). We need to test if unpacking&processing the Alvium causes issues & when.XTCAV Controls Recorder Troubleshooting
Some things to check if the Acqiris is causing problems:
...