Sheila, Patrick, Jenne, Eric Thrane on the phone.
Eric wanted to do an injection, and since his code requires the intent bit to be set, Patrick attempted to set it. This however proved impossible. This is probably related to the work described in 20870. According to the CDS overview, there are no excitations on except those from calibration, which will need to be on while the intent bit is set. (screenshots attached of the CDS overview and some ODC screens).
Side note (sheila's opinion only):
I found the ODC screens confusing to navigate, and it is very unclear to me which bits go into calculating other bits to find out what the problem is. It seems to me like it is a bad idea for us to make ourselves dependent on ODC to set the intent bit, since people on site don't have control over it.
Evan deciphered the ODC screen that was apparently telling us that TCS was not observation ready. We put a 0 in the H1:ODC-MASTER_TCS_2_MASK, and this made the observation bit ready, so Ed has set the intent bit.
I think this has uncovered a bug/issue: There may be a problem with the connection between the TCS ODC and the ODC-MASTER models at LHO. I'm debugging it now and will reply with what needs to be fixed. On a separate note: I believe site leads (at least Fred) said that operators would be trained on how to read and use the ODC with the changes made in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20870 and Duncan M. and Stefan B. are the experts on site to teach people how to read this screen, but I'll walk through the way to read it for this example: Evan correctly read off the bit that was preventing obs-ready from being green from the ODC MASTER overview screen. To do this, you just trace across the row that you care about (OBS-READY) and find the red bit, then count across the top list of subsystems to find which subsystem that is coming from (I would appreciate it if anyone can show us how to turn those text boxes so we can align them with the columns better). The next step would be to look down one step further by clicking on the TCS button to see that the 30th bit of the TCS ODC is the only bit that can affect the OBS-READY bit. From the comment, this was done correctly as well, and you can read off the bitmask for the relevant row in the matrix on the right. You can also see this by looking at the large black/green matrix to find the green bits that affect each row, which tell you which bits of the subsystem ODC are mapped to which row in ODC MASTER. At this point, you will see that the whole TCS ODC at the top of that screen is red, however, which I believe is a bug somewhere in the FE code. If it were behaving normally and you wanted to learn what the bits meant in the vector at the top: The last step would be to click on the relevant subsystem from the ODC-SITE-OVERVIEW screen, and in this case you would learn that bit 30 is the Excitation bit, as expected.
I have found the issue: The h1odcmaster.mdl was locally edited and then committed to SVN on Aug. 18, as recorded in alog: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20622 This occured after we had circulated the new h1odcmaster.mdl that was used for alog: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20870. Duncan M. is going to ensure that everything is up to date with the SVN, then re-implement the changes he made on Aug. 18 in a copy of h1odcmaster.mdl and then generate the ECR to fix the bug. For the time being, I have set all the bitmasks of form H1:ODC-MASTER_TCS_XX_MASK to 0x0 so the bad connection cannot affect ODC-MASTER.
Ryan, this does not adequately explain the situation. Why does the bit mask in TCS affect READY? We were told that READY was just GRD-IFO_OK and NO EXC. How was it that TCS was somehow wired into that logic?