The configurations files with the correct GBT phases used for the configuration of the detector are `$DATA_PATH/config/gbt/gem-shelfXX-amcYY-phases.txt`. Update the files with the newest values of the phases, tracking the differences between the previous version and the new one, if needed (relevant changes are if the phase is/was set to 15 or if it is shifted by 3/4 units). If VFAT and GBT communication statuses are different, they should be traked in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-online-support/-/issues).
The configurations files with the correct GBT phases used for the configuration of the detector are `$DATA_PATH/config/gbt/gem-shelfXX-amcYY-phases.txt`. Update the files with the newest values of the phases, tracking the differences between the previous version and the new one, if needed (relevant changes are if the phase is/was set to 15 or if it is shifted by 3/4 units). If VFAT and GBT communication statuses are different, they should be traked in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-ops/gem-issue-tracker/-/issues).
#### Taking the DAC scans
#### Taking the DAC scans
...
@@ -123,7 +123,7 @@ for i in {0..11}; do getCalInfoFromDB.py XX YY $i --write2File --write2CTP7; don
...
@@ -123,7 +123,7 @@ for i in {0..11}; do getCalInfoFromDB.py XX YY $i --write2File --write2CTP7; don
~/scripts/testConnectivity.py --gemType ge11 --detType=short XX YY 0xfff -a --skipGBTPhaseScan --acceptBadDACFits --skipScurve -i -f5
~/scripts/testConnectivity.py --gemType ge11 --detType=short XX YY 0xfff -a --skipGBTPhaseScan --acceptBadDACFits --skipScurve -i -f5
```
```
The output files should be inspected and any result that could indicate a broken DAC circuit should be reported in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-online-support/-/issues).
The output files should be inspected and any result that could indicate a broken DAC circuit should be reported in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-ops/gem-issue-tracker/-/issues).
### Data-taking procedures
### Data-taking procedures
...
@@ -175,7 +175,8 @@ for l in 1 2; do for i in {01..36}; do cp $DATA_PATH/GE11-M-${i}L${l}*/scurve/<s
...
@@ -175,7 +175,8 @@ for l in 1 2; do for i in {01..36}; do cp $DATA_PATH/GE11-M-${i}L${l}*/scurve/<s
for l in 1 2; do for i in {01..36}; do cp $DATA_PATH/GE11-M-${i}L${l}*/scurve/<symlink>/SCurveData/h2ScurveSigmaDist_All.png /nfshome0/gempro/elog/<my_name>/h2ScurveSigmaDist_All_GE11-M-${i}L${l}.png; done; done
for l in 1 2; do for i in {01..36}; do cp $DATA_PATH/GE11-M-${i}L${l}*/scurve/<symlink>/SCurveData/h2ScurveSigmaDist_All.png /nfshome0/gempro/elog/<my_name>/h2ScurveSigmaDist_All_GE11-M-${i}L${l}.png; done; done
```
```
Any discrepancy between the results and what expected from the configuration, i.e. the scans or the analysis failing for a part of the detector, should be investigated and tracked in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-online-support/-/issues).
Any discrepancy between the results and what expected from the configuration, i.e. the scans or the analysis failing for a part of the detector, should be investigated and tracked in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-ops/gem-issue-tracker/-/issues).
#### Checking the HV mapping
#### Checking the HV mapping
Checking the HV mapping is one of the last checks to be performed once the front-end communication has been established and the frontend status confirmed. The HV training must be completed as well since signal amplification is required in the chambers.
Checking the HV mapping is one of the last checks to be performed once the front-end communication has been established and the frontend status confirmed. The HV training must be completed as well since signal amplification is required in the chambers.
@@ -183,26 +183,3 @@ But the setup should *always* be left in a usable state for the next user.
...
@@ -183,26 +183,3 @@ But the setup should *always* be left in a usable state for the next user.
Moreover, if you are not on the list of approved individuals who can modify the hardware/stand infrastructure you should not (if you are wondering if you are on this list it probably means you are *not*).
Moreover, if you are not on the list of approved individuals who can modify the hardware/stand infrastructure you should not (if you are wondering if you are on this list it probably means you are *not*).
Failure to follow these rules makes more work for the DAQ expert team, setup responsible/sysadmin.
Failure to follow these rules makes more work for the DAQ expert team, setup responsible/sysadmin.
### Requesting time on GEM setups
Each setup has its own requisition page on SuperSaaS to manage testing and ensure we do not collide with other users.
To see the available setups and to request time on navigate to:
Before trying to modify the above schedules you'll need to first ask for the GEM Infrastructure shared password on SuperSaaS to use the scheduling tools.
To do this ask one of the DAQ expert, setup responsible/sysadmin.
When scheduling you need to provide:
- Your name
- Your email
- Estimated time your test will take (starting & ending time)
- Description of your test
Your request will be submitted and then approved.
!!! note
Any non-overlaping request is considered as immediately approved and you can start using the stand.
In case of long or overlaping requests, please contact the setup responsible.
