Camilla, Vicky

Screenshot of how we found the SQZ_FC and SQZ_OPO this AM. Two separate issues.

Only to-do might be fixing the SQZ_FC issue in FIND_IR. I hope the SQZ_OPO_LR issue is solved, but we will watch out for it.

More description of the issues from this morning/last night and how to fix it:

• SQZ_FC -  same stuck in FIND_IR issue as yesterday 76862. See the execution time over-run circled in today's guardian screenshot. 
   
  • To fix: brought SQZ_FC to "DOWN". That was it, SQZ_MANAGER took over the rest.
     
  • To-do: Unsure why we have gotten multiple timeouts in the past 2 days, try to resolve this. 
    • Maybe in SQZ_FC, on Line 112, we need to wrap the cdu.getdata() function call in TJ's timeout checker function. 
    • In the meantime, I have added a log statement to Line 111 just before cdu.getata() is called, and reloaded SQZ_FC. So if FIND_IR gets stuck again, we can confirm whether it is really this function call that times out the guardian.
       
• SQZ_OPO_LR - did not scan to high enough PZT voltage to find co-resonance. Hopefully we have now increased the scan range enough to fix this for O4b. Steps taken today:

  1. From it being STALLED and MANAGED, I took SQZ_OPO_LR to AUTO. This worked to un-stall it, and let it continue locking. If the scan is fixed, this should be enough to solve the problem.
      --> Not sure why OPO guardian was "STALLED" when it jumped to "IDLE" state, but I think this is related to the guardian "jump" to IDLE. I'm not sure if we even want to fix this -- leaving the SQZ_OPO_LR guardian in STALLED was probably the correct move, otherwise it would have spent hours scanning the PZT without finding co-resonance. Better to fix issues with not finding co-resonance, maybe not much to do here.

  2. OPO couldn't lock on co-resonance b/c that was at 104V, but PZT1 was only scanning up until 100V -- I changed the scan offset.

     • OPO did not find co-resonance within its scan range, then it timed out, jumped into IDLE, and the guardian STALLED. See sqz locking screenshot -- increasing the scan range let it find co-resonance at 104V, and then SQZ_MANAGER easily went back up to FDS.

     • I increased H1:SQZ-OPO_PZT_1_OFFSET from 0V to 15V, and saved this 15V offset in SDF. We cannot increase H1:SQZ-OPO_PZT_1_SCAN_STOP above 100V in slowcontrols, so we have to increase the scan offset to get the PZT there.

       • Note, back when OPO_PZT2 was at 0V (before 76688), I think the OPO would often find co-resonance between 100-110 V during O4a. 

     • Based on a previous opo co-resonance issue, 76642 seemed to want to the scan starting around ~50V. Today's issue shows we want to scan beyond 105V, probably up to 110V or even 115V (the max). Based on OPO cavity scans (e.g. screenshot from LHO:75285), I think OPO PZT1 is not super effective (in terms of um/V scanning) below 50V or so.

     • Let's try scanning from 55V - 115V to guarentee we find co-resonance. This is how it's currently set. This corresponds to the first screenshot, where H1:SQZ-OPO_PZT_1_OFFSET = 15V (saved in SDF), H1:SQZ-OPO_PZT_1_SCAN_START = 40, H1:SQZ-OPO_PZT_1_SCAN_START = 100V.