Page History
...
Should other triggered devices run, you can choose to look at the LEDs on the camera: if the 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
...
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 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:
...
<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 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:
/reg/g/pcds/dist/pds/current/build/pdsapp/bin/x86_64-rhel7-opt/bldServerTest -i <Interface name> -a 239.255.24.<address>
To find the address of choice, look at "My BLD misses a source".
If you do not see any damage reported, but cannot see data in ami: make sure that see event code 140 - this (or a subset) produces the BLD (depending on the source).
To figure out what the interface name is, call "/sbin/ifconfig -a". You want the name for the CDS interface. Recently we have seen cases where the BLD came over the FEZ interface only.
In 120 Hz operation, a difference in fiducials of 3 is expected. Some more detail can be found at the BLD DAQ page.
If data are not coming through, first check that the BLD source is properly selected in the DAQ partition.
A common problem with ebeam BLD is that the L3Energy calculation will not update if the accelerator has changed its beam energy configuration and not yet updated alarm limits on data that goes into the calculation. This should be evident in the "damageMask" of ebeam BLD. If so, call ACR.
For LCLS-II DAQ, see L2SI DAQ BLD reception
My detector runs without errors, but I can't see any beam:
Trusting that there actually are photons on the detector that could be seen, the second point are the timing settings. Find the values you should use here:
Go to the EVR configuration (with the exception of pgp triggered devices as the EPIX), if you are using aliases in your DAQ, it should be straightforward to find the right trigger channel. Look at all available EVR cards. For the run trigger setting for e.g. CsPad detectors, it might be best to contact your POC.
My data does not seem to be moving well:
The Files-in-WAIT-state table in the PSDM-Mover-Tape Grafana dashboard shows all files that are waiting for the movers to be transferred including files that are being transferred.
For any issues and question email and/or call the data-management group, depending on time-of-day and urgency
[ 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:
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.
To find the address of choice, look at "My BLD misses a source".
If you do not see any damage reported, but cannot see data in ami: make sure that see event code 140 - this (or a subset) produces the BLD (depending on the source).
To figure out what the interface name is, call "/sbin/ifconfig -a". You want the name for the CDS interface. Recently we have seen cases where the BLD came over the FEZ interface only.
In 120 Hz operation, a difference in fiducials of 3 is expected. Some more detail can be found at the BLD DAQ page.
If data are not coming through, first check that the BLD source is properly selected in the DAQ partition.
A common problem with ebeam BLD is that the L3Energy calculation will not update if the accelerator has changed its beam energy configuration and not yet updated alarm limits on data that goes into the calculation. This should be evident in the "damageMask" of ebeam BLD. If so, call ACR.
For LCLS-II DAQ, see L2SI DAQ BLD reception
My detector runs without errors, but I can't see any beam:
Trusting that there actually are photons on the detector that could be seen, the second point are the timing settings. Find the values you should use here:
Go to the EVR configuration (with the exception of pgp triggered devices as the EPIX), if you are using aliases in your DAQ, it should be straightforward to find the right trigger channel. Look at all available EVR cards. For the run trigger setting for e.g. CsPad detectors, it might be best to contact your POC.
My data does not seem to be moving well:
The Files-in-WAIT-state table in the PSDM-Mover-Tape Grafana dashboard shows all files that are waiting for the movers to be transferred including files that are being transferred.
For any issues and question email and/or call the data-management group, depending on time-of-day and urgency
[ 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:
XTCAV Controls Recorder Troubleshooting
Acqiris
Some things to check if the Acqiris is causing problems:
...
Remember that you must run the DAQ with recording enabled in order to update the Logbook.
Technical note:
"serverStat" at this moment works in all hutches when using the machine name or IP, but the "DAQ alias" interpretation feature might not quite work. We hope to improve on this soon.
...
Overview
Content Tools