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

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

...

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.

...

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

I have included a recorder source and the DAQ won't start:

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.

The IOC recording seems to work fine, but my output file is of size 0:

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.

The XTCAV recording does not work:

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:

included a recorder source and the DAQ won't start:

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.

The IOC recording seems to work fine, but my output file is of size 0:

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.

The XTCAV recording does not work:

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

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:

...