Welcome! Log In Create A New Profile

Advanced

Anyone trying to implement deadzone PID compensation in Marlin

Posted by jzatopa 
Anyone trying to implement deadzone PID compensation in Marlin
March 30, 2014 08:25PM
I see that Repetier firmware has added a dead zone compensation feature to help stabilize temps while printing. Is anyone trying to port this over to marlin?


WWW.ZATOPA.COM - Your Place for high quality 3D Printing Filament and accessories
Re: Anyone trying to implement deadzone PID compensation in Marlin
March 31, 2014 04:35AM
You mean [www.repetier.com] or [forums.reprap.org] ?

I've looked into the deadtime control a bit, but I think that it might be a workaround to problems and defects that don't need to be in RepRap's PID implementations. Deadtime is a common feature in lots of processes successfully managed by PID controllers, but Marlin's M303 Ziegler-Nichols autotune method doesn't recognise or handle large deadtime well. See [controls.engin.umich.edu] with Cohen Coon or Zeigler-Nichols open-loop tuning.

You might be able to simulate the deadtime control scheme with Marlin's current PID by increasing PID_FUNCTIONAL_RANGE so its PID algorithm can kick in further from the setpoint, increasing K1 so you get more smoothing on the timescale of the deadtime for a good derivative estimate; and decreasing kI to minimize the integral-windup-caused overshoot, and then tuning kD appropriately. If kD is big enough, its contribution will be clipped to on/off behavior

Many RepRap firmwares use a fixed limit on the Integral accumulator, implemented in a way which guarantees overshoot if you start from far enough away from the setpoint. One Marlin workaround for this that limits this effect is the #define PID_FUNCTIONAL_RANGE 10 which makes it work like BANG-BANG outside of setpoint+/-PID_FUNCTIONAL_RANGE. But the way the algorithm resets the integral accumulator to zero at +/- 10C can cause weird behavior ( [forums.reprap.org] or [forums.reprap.org] ) if the heater is strong enough to overshoot more than the functional range--If it overshoots high, it will turn off the heater, set the integrator to zero, and start driving it negative until it undershoots below the setpoint significantly. When entering the functional range form the high side, it would be better to set the integrator at the high limit and begin reducing i.

Enlarging PID_FUNCTIONAL_RANGE would help with the jagged transition wiggle seen in these graphs: [numbersixreprap.blogspot.com] but that would enable the I term to produce more overshoot.

I've been fiddling with Conditional Integration to keep the integral term from winding up excessively: [github.com] and [github.com]

Edited 1 time(s). Last edit at 03/31/2014 04:43AM by DaveX.
Sorry, only registered users may post in this forum.

Click here to login