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
Message ID: 2257     Entry time: Thu Nov 22 12:49:35 2018
Author: anchal 
Type: DailyProgress 
Category: TempCtrl 

The configuration run:

I ran overnight PIDAutoTune with following parameters:
RelayAmplitude = 0.75 W
Offset = 0.25 W (So Differential Heater switches between -0.5W to 1W)
Setpoint = 34 MHz
Initial Differential Heater (Actuator) = 0 W
Common Heater = 0.5 W
Runtime = 15 hrs
This gave the following results:
Critical Gain, Kc = -12.27416
Critical Time Period = 84.3s (Note the reduction in time from the last measurement)
PID constants: Kp = -2.4548, Ki = -0.05824, Kd = -68.98078

Conclusions and next steps over the long weekend:

Today, I manually brought the frequency to near 27.3 MHz and switched on the PID with the estimated parameters. It looked like it was doing a good job except for momentary jumps in the actuation. This might be readout error or simply that we need some sort of LPF on the actuation calculation. Even 0.1s actuation on South heater causes a big problem because of huge change in current and because the south heater is a much more effective heater than north.

Just to check my hypothesis, I modified the PIDLocker_beta.py code to create a condition that actuation will be changed only if it is changing by less than 0.5 or if it has been asked to change in last two timesteps. I see that this successful in avoiding the harsh jumps. Now I'm running it to see how it works with an initial error of about 5 MHz. It is much more than I would like to start this PID (for reasons stated below) but I need to go for the weekend now.


  • In my opinion, since the PID parameters turned out to be so huge, they will properly work in small deviation from setpoint only. Definitely within ~50 MHz of setpoint which was maximum amplitude during Relay tuning.
  • This also suggests that we probably cannot create an all regime working PID with our actuators. We simply need more ability to actuate if current cooling times are going to be constant for a faster convergence to the desired setpoint from far off place.
  • I and Awade were discussing this yesterday. If we ant convergence to 27.34 MHz from initial points as far away as ~500-900 MHz, we need some artificially intelligent code.
  • Not too intelligent though. In awade's words "we need something dumber than neural networks (because of the time involved in making and training them) and smarter than a PID".
  • I'm thinking of a code which looks at higher derivatives than first, maybe up to the third derivative.
  • If we get a code like this, which we can train during night times it might be a good thing to have to save about (6hrs to a day) while bringing the frequency to the desired point. I'll keep this at a lower priority for now though as we have other pressing issues to work on.
ELOG V3.1.3-