PID_improvements #45
Loading…
Reference in New Issue
No description provided.
Delete Branch "PID_improvements"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Changes:
Rescale integral when ki is changed to prevent kick when tuning ki.
Use safer default PID parameters.
When reporting, tec v measurement shows voltage across tec, not voltage at adc pin
Added methods to retrieve TEC voltage and current
Integral anti windup when actual TEC current deviates from TEC current setpoint (compliance voltage reached)
@ -3,6 +3,7 @@ use uom::si::{
f64::{
ElectricPotential,
ElectricalResistance,
testing if error 500 is fixed
seems ok
still ok
@ -364,6 +364,16 @@ impl Channels {
(duty * max, max)
}
// Get actual current passing through TEC
Actual?
There are quite a few variables describing currents, like current setpoint, dac voltage setpoint controlling output current, dac voltage readback for current control.
This returns the thermostat measured current that is passing through the TEC, hence "actual".
I'll rephrase the comment for clarity.
@ -5,2 +6,4 @@
};
/// Allowable current error for integral accumulation
const CURRENT_ERROR_MAX: f64 = 0.1;
Shouldn't this be configurable as well? The situation here doesn't seem very different than the configurable integral clipping.
There isn't really a lot of reason for this to be user configurable I think. It mostly has to do with the inherrent noise of the current reading, which will be pretty consistent between other thermostat devices.
TBH I don't really think the integral clipping makes a lot of sense as well, as it heavily depends on the ki value and ambient temperature, thermal load, and usually I just set it so large so that it doesn't get into the way.
Should the clipping be hardcoded as well then (and perhaps be scaled by ki)?
I'll see if it makes sense to calculate integral limit based on parameters during the code review.