Page History

...

 hsd "89" was on the slave XPM:1.  another hsd "88" was on the same XPM:1 but worked.  all links looked locked on the xpm side.   saw this again in /reg/neh/home/cpo/2020/06/16_18:19:24_daq-tst-dev07:hsdioc_89.log (same digitizer!, but also saw 88 fail below).  Note that this is after I commented out all the configure-resets in Digitizer.cc (that happened on Jun 16 at 14:54).  The various digitizers look similar:

...

UNSOLVED: Running at 10Hz with no recording phase2 of disable not be seen by any hsds: /reg/neh/home/cpo/2020/06/16_15:26:24_drp-tst-acc06:control.log.  can see control.py try to write xpm pv's for disable phase 2.  Saw this again here when recording at 100Hz:  /reg/neh/home/cpo/2020/06/18_15:37:36_drp-tst-acc06:control.log.  Seemed not so reproducible at 10Hz, but reproducible at 100Hz.  Saw it without recording, and with slow update disabled ?here: /reg/neh/home/cpo/2020/06/18_18:33:51_daq-tst-dev03.pcdsn:control_gui.log

PROPOSED SOLUTION: running 1 hsd (datadev_0) and after a while the deadtime goes to 100% from that hsd, but timepausecnt is zero for both hsd’s.  I think it's caused by ben's headercntof latching to 1 on the “A” hsd, even though msgdelay is set to 99.   Do we need to increase msgdelay?  Matt says msgdelay is max 100 (corresponding to 1us).  This could be caused by slow updates ignoring dead time if we get long dead time due to the soft-lockup issue above (now solved by Matt, we believe).  So could be the same issue.  Matt will have SlowUpdates pay attention to dead time to avoid this.

...