Bug Report: ultraLatency.py does not place the AMC13 into an idle state when it finishes

[AndrewLevin]

I have just successfully completed a latency scan using ultraLatency.py and noticed that the AMC13 continues to increment its L1A counter.

Brief summary of issue

Types of issue

• Bug report (report an issue with the code)
• Feature request (request for change which adds functionality)

Expected Behavior

I would expect that, after I complete a latency scan successfully, and then check the AMC13 registers using st command in the AMC13 tool, that I do not see the L1A counter increasing.

Steps to Reproduce (for bugs)

1. [gemuser@gem904qc8daq ~]$ python /opt/cmsgemos/bin/ultraLatency.py -s2 -g0 --shelf=3 --nevts=1 --vfatmask=0x0 --filename=/data/bigdisk/GEM-Data-Taking/GE11_QC8//GE11-VII-S-CERN-0002/latency/trk/2018.07.17.15.27/LatencyScanData.root --scanmin=20 --scanmax=40 --throttle=0 --stepSize=1 --mspl=4 --amc13local --t3trig
2. [gemuser@gem904qc8daq ~]$ AMC13Tool2.exe -i gem.shelf03.amc13 -c $GEM_ADDRESS_TABLE_PATH/connections.xml
3. issue st
4. issue st again after the AMC13 receives another signal

Context (for feature requests)

I am taking latency scans using both xdaq and python scripts. I assumed that if the python latency scan finishes normally, it will reset the AMC13 to an idle state.

Your Environment

I am working as gemuser on gem904qc8daq.cern.ch