40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  PSL  Not logged in ELOG logo
Entry  Tue Jan 22 20:26:18 2019, awade, DailyProgress, TempCtrl, Running relay controller overnight on refcavs 
    Reply  Wed Jan 23 11:28:53 2019, awade, DailyProgress, TempCtrl, Correcting BN after running relay controller overnight on refcavs 
       Reply  Thu Jan 24 14:24:10 2019, awade, DailyProgress, TempCtrl, Custom implementation of PIDLocker script for finer control of intergration on cav heaters PIDLocker_cavcontrol.py.zip
          Reply  Fri Jan 25 10:46:24 2019, awade, DailyProgress, TempCtrl, PID locking of cavity heaters to BN PID_locking_GlitchAndRunAway_2019-01-25_at_10.50.19_AM.png
             Reply  Fri Jan 25 15:45:48 2019, anchal, DailyProgress, TempCtrl, PID locking of cavity heaters to BN 
Message ID: 2295     Entry time: Fri Jan 25 10:46:24 2019     In reply to: 2294     Reply to this: 2296
Author: awade 
Type: DailyProgress 
Category: TempCtrl 
Subject: PID locking of cavity heaters to BN 

Testing of this seems to confirm that lower intergrator values are the way to go.  We had excellent locking with <1.2 kHz/min for a period of about 12 hours.  This is almost good enought to move down to 500 Hz/V VCO slope with some averaging. yes

Settings were P=0.0015, I=0.000050, D=0.0.  The heater diff value hovers around 0.68 W for a setpoint of 69.2 MHz.

Glitches and BN sign

Bad news is we had a glitch that spiked the pre-cavity BN detector frequency at about 5:07 am this morning.  This spiked the intergrator value and drove the heater value up for about 30 min before the BN crossed the 0 Hz point.  There wasn't enough time for the intergrator to wind back down the sign change of the BN frequency ment that the loop then just drove away from the setpoint eventually railing at 1.1 W diff heating. no

This will be more a problem down at the 27 MHz point that we want to lock to. As the set point is so close to the BN flip across 0 Hz any disturbance can drive our loop into this runaway state. Its not clear how we reject these glitches or reliably sense the flip across 0 Hz.  Filtering pre-cav BN for glitches seems bad as it will introduce poles that then affect the loop.  Trying to sense a change in BN slope (I think anchal implemented this?) will be hard if the slope is very shallow as it crosses, this will give confusion about the sign if the noise dominates over the derivative value. 

Machine learning would be helpful here maybe.  If you include information about the laser slow frequency controls (for both lasers) its really obvious when the direction of the BN evolution is inconsistent with frequency direction of the laser evolution for both cavities.

For now I am going to narrow the hard stops on the PID script.  This should prevent the loop from railing hard and taking hours to recover.  It seems that without a drastic change in the environment temperature we will never need more than 0.1 W of movement either side for the actuator center point.  I'll set the limits to [0.65, 0.75] W for now, this should be enough to gently hold the BN in the 0- 100 MHz range and will prevent hard railing way out of range.

Attachment 1: PID_locking_GlitchAndRunAway_2019-01-25_at_10.50.19_AM.png  48 kB  | Hide | Hide all
PID_locking_GlitchAndRunAway_2019-01-25_at_10.50.19_AM.png
ELOG V3.1.3-