-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Information on Parameters #6
Comments
Thanks for testing out my library: I haven't had a chance yet to really stress test it, so I'm glad someone is! The bias is a constant that's simply added to whatever the normal PID controller outputs. For example, when controlling the shaft angle of a DC motor via PWM, you want to add a bias of 127.5 (255.0 / 2.0 = 127.5) so that negative PID outputs (to reverse the motor direction) correspond to positive PWM duty cycles (negative duty cycle doesn't make sense and analogWrite() only accepts positive values AFAIK). That is why I have the bias of 127.5 in the example. This might not be what you want since your project is quite different. Are you using the library's built-in debug statement generator? Are you using the serial plotter vs serial monitor? The plotter should show you what the PID controller's really doing and help you figure out what to change. You might want to set the bias to 0 (depending on your "actuator" interface), set reasonable windup limits, set P to some really small value, then zero out I and D. Increase P until you get a marginally stable oscillation around the setpoint, then increase D until the oscillation is minimized (note that optimal D might be super small, e.g. 0.001), and then increase I until you have zero steady state error. |
Also, there's usually a connection between the output limits and bias. Often times, the bias is the median value between the output limits |
Thanks for the quick response. I was using the debug with a serial monitor and also Putty (because the new Arduino IDE doesn't let you copy any more than about 20 rows of data. I am actually packing the time, actual temp, set point and output into an MQTT message that a Perl program monitors when I am running a test. Eventually the Perl code will move this into a MySQL DB to store each kiln run. But currently it is one step at a time. I will try setting bias to 0 tomorrow and then maybe a couple runs with tighter windup limits. I did read about the PID tuning technique of starting with P and raising until it oscillates, then cutting in half and going to I next, etc. -- but each run needs time and has to let the glue gun cool down. That tip about a very low D is a good one -- examples out there are all over the map. And I know that I will need to do this again when I (eventually) hook it up to a real kiln. Thanks. |
Here is some info. on further testing for a heater type application. Google Cohen-Coon tuning method. It got things in much better shape. |
Hello - Thanks for this library. I am working on a PID controller for glass kiln(s) -- annealing, fusing, etc. I have a rig set up with a TC and hot glue gun to test. I am down the rabbit hole of figuring out the Kp,Ki,Kd values. I got it pretty close, but notice all tests are oscillating above the set point. Best so far is a set with Kd = 0. I used your code example and notice the setBias is at 255.0 / 2.0 -- is this making the "landing point" always wind up high? Or maybe setWindUpLimits (also used your code example). As I watch it loop it never seems to range below the set point -- which would keep things closer to where I want them if it went there before starting to fire the heat. I have a PDF with examples if you are interested (but don't know how to share). Thanks.
The text was updated successfully, but these errors were encountered: