I have been developing an IR temperature controller for induction heating, with two operating modes as On/Off and PID. The On/Off mode works pretty good, however since some of the induction heating projects deal with high overshoots, we need to add the PID feature.
I have used the Sous Vide Controller code from Adafruit as the base of my code and am trying to modify it into what suits our kinds of projects. The main issue comes from the natural differences between the Adafruit project and ours. In the Adafruit project, the heating occurs pretty slow and they have developed the autotuning in a way compatible with very slow temperature changes (in the order of several minutes). However, in induction heating we sometimes deal with very high heating rates (several tens of degrees in seconds). This has been caused issues with the autotuning of the PID controller that I am using.
The other issue is that in the Adafruit code, the autotuning is activated when the system is in a steady state condition. However I need to change the code in a way that the autotuning starts from the beginning and considers the time to temperature too.
I think there are some parameters from the PID Autotune library that are not introduced in the Adafruit code and need to be modified in order to get a smooth response considering the time to temperature, but I am not sure which ones.
The code below (On/Off mode is deleted for abstracting) currently takes the inputs (Temperature Setpoint, Kp, Ki, Kd) and then runs the PID control. When the object reaches close to the temperature setpoint, the autotune mode can be activated. I have attached the connections diagram to this message.
Any help on how to modify this code to run the PID Autotune mode in the correct way is highly appreciated.
There are many who swear by the use of canned software, a.k.a. libraries. While these are convenient, they are hardly ever the best solution. In the commercial world we are not permitted to use libraries that were not developed 'in-house' and as such need to deal with many of these issues from first principles. PID is one such function and not a very difficult one to implement. I would suggest that you look at it a bit closer and decide if maybe you'd be better off writing your own.
Regardless of your path, PID is still used (in spite of better/faster algorithms) primarily because it is 100% guaranteed to converge. This does not translate into a guarantee that it will 100% converge in your lifetime. The algorithm is very sensitive to the constants you use (Kp, Ki and Kd), with a strong emphasis on Kp. How quickly your out put settles and how well it deals with overshoot are going to depend on the (initial) settings. In your code you show Kp = 850, Ki = 0.5 and Kd = 0.1. The values for Ki and Kd are reasonable, but Kp seems a bit out of sorts. Generally when we test for new settings, we start with Kp = 1.0, Ki = 0.1 and Kd = 0.1 and move around from there. You might want to have a second look at lines 625-635. These values will work, but it might be your grandchildren that see the results.
DKWatson:
There are many who swear by the use of canned software, a.k.a. libraries. While these are convenient, they are hardly ever the best solution. In the commercial world we are not permitted to use libraries that were not developed 'in-house' and as such need to deal with many of these issues from first principles. PID is one such function and not a very difficult one to implement. I would suggest that you look at it a bit closer and decide if maybe you'd be better off writing your own.
Regardless of your path, PID is still used (in spite of better/faster algorithms) primarily because it is 100% guaranteed to converge. This does not translate into a guarantee that it will 100% converge in your lifetime. The algorithm is very sensitive to the constants you use (Kp, Ki and Kd), with a strong emphasis on Kp. How quickly your out put settles and how well it deals with overshoot are going to depend on the (initial) settings. In your code you show Kp = 850, Ki = 0.5 and Kd = 0.1. The values for Ki and Kd are reasonable, but Kp seems a bit out of sorts. Generally when we test for new settings, we start with Kp = 1.0, Ki = 0.1 and Kd = 0.1 and move around from there. You might want to have a second look at lines 625-635. These values will work, but it might be your grandchildren that see the results.
Thank you very much for your reply.
I took your advice and tried to run the system with lower Kp values (Kp=1.0 to 10.0), however it did not help much. The output still fluctuates +/-20 degC around the setpoint.
The autotune mode does not converge in a reasonable time (I did not observe it converging at all, so I stopped it after 5 min). many different autotune settings tested, no success.
I think that I need to take your advice and try to develop my own autotune code, which will not be easy considering that I am a NB in coding.
If you know any autotune code that I can use as the base for my code, it will be highly appreciated.
I’d have a look at how to tune PID loops - a fast responding loop may well need some derivative if the rate of heating is very fast .
Give some thought to your system too - if there is a lot of thermal mass for example after tuning heat off the measured temperature may continue to rise. Where and how you measure temperature has an effect too .
A fast system with a lot of lag may be inherently unstable anyway and controlling may not be the fault of the PID . But while you are playing move the P term over a very wide range .1 to 100 ? and note it’s effect - when it’s better when it’s worse - optimally tuned , if it’s a fast system you are likely to get over shoot, without it you are likely to heat up slowly . Try a bit of derivative next , integral deals with offsets .
Your code looks pretty complex , I think someone has already suggested writing your own PID loop, well worth a go . All the autotuners I’ve seen are rubbish by the way .