Versions Compared

Key

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

...

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.

Run a detector without the DAQ

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. 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

Run these processes as <hutch>opr. It would run as yourself, but sometimes the process creates files and this lead to permission issues when running the DAQ as opr.

Code Block
languagebash
titleRun an alvium in triggered mode
./vimbaStandAlone -n 10 -t

My ipimb has an issue:

Troubleshooting ipimbs is described on this page:Troubleshooting for Controls IPIMB and Wave8s

My OPAL damages on every shot (but configures):

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.

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.

My BLD misses a source:

You will have to fix this with the mask used in the bld-process in the cnf file.

The address of the sources is here.

My ipimb has an issue:

Troubleshooting ipimbs is described on this page:Troubleshooting for Controls IPIMB and Wave8s

My OPAL damages on every shot (but configures):

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.

My <detector> damages often (but configures):

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.

The address of the sources is here.

My BLD has an My BLD has an issue:

For LCLS-I, we use the last server in the list of used dss-nodes to run the BLD process. Check out of the data comes in, you can ssh to that node and call:

...

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: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

Timetool

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

Acqiris

Some things to check if the Acqiris is causing problems:

...