Looking through the lockloss site, I was able to find some examples of locklosses where ISC_LOCK_STATE_N transitions to LOCKLOSS a long time after the refined lockloss times we derive from our indicator channels. These may indicate states where the Guardian code needs to be changed to keep up with the state of the IFO.
https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/events/1263/651643/indicators_WIDE.png
https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/events/1264/540297/indicators_WIDE.png
https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/events/1264/153709/indicators_WIDE.png
https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/events/1264/440335/indicators_WIDE.png
This is good info to see. My biggest concern is with OFFLOAD_DRMI_ASC (index = 111), has a sleep in the main() method that reads whatever the MICH TRAMP used to be and then sets the sleep to that. It will set the sleep timer to 20seconds because of the ENGAGE_DRMI_ASC state in ISC_DRMI. I have removed this odd referencing to an old TRAMP time and changed it to just wait for the ramping to be done.
The other ones could use some time to look at as well, but it iwll have to wait for now.