Page History
...
UNSOLVED (1MHz): with both the fake cam and hsd Matt saw that if he ran at 1MHz then disabled for a few seconds then reenabled that all the buffers were stuck in software and system would hang. Reproducible 1 out of 3 attempts.
UNSOLVED (1MHz): when we record 10 hsd's to disk disable times out for several segment levels
UNSOLVED: hsd configure times out the first time, but works second time. Matt says that he seen the transition not received at all by the hsd. Phase 1 completes in Digitizer.cc but phase2 maybe doesn't start, consistent with Matt's observation? log file in /reg/neh/home/cpo/2020/06/12_17:41:55_drp-tst-dev010:tmohsd_0.log. What I observed: both tmohsd_0/1 completed phase 1 but failed to receive phase 2. How I think it's supposed to work: tmohsd_0/1 each write some kcu registers (resetting tx/rx/user/qpll). both tmohsd_0/1 set config epics vars in its own pva server ("hsdpvs" process). both of these servers communicate with one "hsdioc" (running hsd134PVs c++ executable on dev07). hsdioc programs both channels of the hsd ("fmc" in the code) and sets READY (e.g. DAQ:LAB2:HSD:DEV07_1A:B:READY). tmohsd_0/1 both watch for their own A:READY and B:READY for each channel. maybe resets take a while to recover? maybe a "reentrancy" problem in hsdioc?Could it be the clear readout? But we have a 1s delay in control.py after clear readout (sent on both configure/beginrun).
...