Closed ZLLentz closed 6 years ago
I think this PR is where I want it to fix the rapid cycle bug. Some of the odd stuff in here is due to odd behavior in pydaq
, but feel free to call me out on it.
The tests pass locally, but are getting stalled out on the same matplotlib
problem that was plaguing transfocator
. This time the culprit is bluesky
, which is doing the innocuous import matplotlib
.
Merging #44 into master will not change coverage. The diff coverage is
100%
.
@@ Coverage Diff @@
## master #44 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 5 5
Lines 763 770 +7
=====================================
+ Hits 763 770 +7
Impacted Files | Coverage Δ | |
---|---|---|
pcdsdaq/daq.py | 100% <100%> (ø) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update efbd6be...0820ac9. Read the comment docs.
I'm going to merge this as-is and use it as a starting point for the changes I discussed with @ddamiani
Description
Force the
Daq
class to wait at least1s
betweenstop
andbegin
. The timer starts onstop
, and the sleep is skipped if enough other things have happened.closes #40
Also fix an unrelated bug where the
Daq
class wasn't correctly reset after adisconnect
, and finally kill the deprecated argument.I also redid some of the
ami
tests because they stopped working and the old tests didn't make sense to me any more.Motivation and Context
Doing scans where there is very little going on between steps (e.g. no moves or really fast moves) AND there is enough during the step (
>0.05s
of action) results inpydaq.Control.stop
routines that exit quickly but don't actually stop the daq in that time. Callingpydaq.Control.begin
in this approx0.45s
window when theDAQ
claims to be ready to run causes the command to hang forever.How Has This Been Tested?
Test added