Glorious1
Guru
- Joined
- Nov 23, 2014
- Messages
- 1,211
This discussion slipped by me (major stuff going on) but it is interesting and I would like to learn more about how it might be implemented. I'm not sure bias or 'default' duty cycle at idle can be fixed since for many of us ambient temperature may vary widely. Even if it didn't, wouldn't you essentially have to run a script like this to determine what the ideal duty cycle is for steady-state at idle? Or is its actual value not really that important? Maybe just set it to the minimum duty cycle setting?Just a heads up... this controller can only be used in PD mode because the implementation isn't quite right. The code hasKi
set to 0, and I'm guessing no one has it set to non-zero since it wouldn't work right. The code is essentially doing this:
Code:curr_dc = curr_dc + Kp * err + Ki * integ + Kd * deriv
And sinceKi
is always 0, it's really only doing this:
Code:curr_dc = curr_dc + Kp * err + Kd * deriv
What it should be doing is this:
Code:curr_dc = bias_dc + Kp * err + Ki * integ + Kd * deriv
Wherebias_dc
is your "default" fan duty cycle, i.e. the duty cycle at idle that keeps your disks close to your desired set point. In other words, the current duty cycle should not be part of the computation. The integral is what ends up offsetting you to the correct place. An extreme example would be if you set your bias to 50, but it should really be 20. After running for a while, the integral will end up around -30 to get you to 20.
Secondly, I guess I'm having difficulty figuring how the system can work if you don't apply the PID output to the previous duty cycle. It's an adjustment right? Often a fine one. I can't imagine the system coming up with an accurate, absolute duty cycle out of thin air without knowing what it's set at now. Honestly I'm not enough of a mathematician to see how that prevents using I, but if it does, I'm OK with calling it a PD controller. It works great as is.
That said, it would be fun to try this approach some time and see if it works.