Making my own PID library

[ajevticc]

Hello everyone, I am trying to make a simple PID controller for a heater using MicroPython, Pi Pico and a MCP9600 Thermocouple Reader.
I have based it around the standard PID Arduino Library(http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/), which is also used for MicroPython simple-pid library (https://micropython-simple-pid.readthedocs.io/en/latest/#), (https://github.com/gastmaier/micropython-simple-pid/blob/master/simple_pid/PID.py#:~:text=%23%20Compute%20integral%20and%20derivative%20terms,output%2C%20self.output_limits)).

Now, the main problem that I have is quite interesting.

Until the circuit reaches the desired Setpoint (100 C), the program and the I2C bus work just fine. The moment that the Setpoint is overshoot, the readings of the temperature go all over the place (random values all of a sudden). I have tried multithreading, longer delays, lowering the I2C clock but nothing helps to make the problem go away. At the end I am printing the data via UART and using a FTDI chip just for an easier display on the Arduino Ploter (you can see on the screen shoot the behaviour of the input (red), output (green) and setpoint (blue)).

Here is the code:

from machine import Pin, I2C, PWM, UART 
import time
pwm0 = PWM(Pin(16))      # create PWM object from a pin
pwm0.freq(30000)         # set frequency

i2c1 = machine.I2C(1, sda=Pin(14), scl=Pin(15), freq=50000) #Error 5 change CLK speed
                                                            #or wrog value CLK

Setpoint = 100.0
Kp = 100.10
Ki = 600.0
Kd = 1.50
outMin = 0.0
outMax = 65535.0
dt =0.1
Iout = 0.0

uart = UART(0, baudrate=230400, tx=Pin(0), rx=Pin(1))

i2c1.writeto_mem(0b01100110, 0x06, bytearray(0x20))
i2c1.writeto_mem(0b01100110, 0x05, bytearray(0x04))
valueK = [0x00,0x00]

temperatureK = []

while True:
    valueK = i2c1.readfrom_mem(0b01100110, 0x00, 2)

    temperatureK = (valueK[0] * 16.0 + valueK[1] /16.0)
        
    Input = temperatureK
    lastinput = Input
    error = Setpoint - Input
    Pout = Kp * error
    Iout = Iout + (Ki * error * dt)
    if (Iout > outMax):
        Iout = outMax
    if (Iout <= outMin):
        Iout = outMin
    Dout = Kd * ((Input - lastinput ) /dt)

    Output = Pout + Iout + Dout
    if (Output > outMax): 
        Output = outMax
    if (Output <= outMin):
        Output = outMin

       
    PWMOUT = int(Output)
    pwm0.duty_u16(PWMOUT)
    roundPWMOUT = Output / 1000  #just to fit on the graph
    strPWMOUT = str(roundPWMOUT)
    strSETPOINT = str(Setpoint)
    strINPUT = str(Input)
    uart.write(strSETPOINT+' '+strINPUT+' '+ strPWMOUT +'\n')
    time.sleep(0.1)

All ideas are welcome, my only guess is that somehow the math of the program is interfering with the I2C bus (input)?

Thank you so much for your time reading this!

[rolandvs]

Maybe I2C clock stretching causing problems?

[ajevticc]

Thank you for the reply, I'll have to check with an oscilloscope that but still, if that was the problem, shouldn't it go away after I lowered the clock rate to the bare minimum of 10 kHz? More over, the problem is constantly at the same spot.

[ajevticc]

Good day, I just checked the SCK signal, everything is the same for both cases (46.8 kHz). Lowered the setpoint to 50 C and the problem is exactly after setpoint. The funny thing is I don"t understand how is the program affecting the input signal (I2C).

[mattytrentini]

I wonder if it's related to #10067?

[ajevticc]

Thank you for this link, well the problem is quite interesting. It's not the value of the width of the pulse signal that's the problem. The frequency is.

pwm0.freq(30000)

By lowering this to let's say 500 Hz the problem goes away. (still present to some degree but not a problem)

[peterhinch]

My guess is that this is electrical. Thermocouples are sensitive beasts. On the left hand side of the plot, presumably the PWM is fully on, and at the RHS it is fully off. Only in the transition region around the setpoint is there a pulse waveform. If that can be confirmed with a scope, then the cause is very likely electrical interference between the PWM output and the thermocouple input.

[ajevticc]

Thank you for this response. You where on the right track, the reason why I did not find the problem is because its not about the PWM value but rather the carrier frequency value that making the problem.

pwm0.freq(30000)

By lowering this to let's say 500 Hz the problem goes away. (still present to some degree but not a problem)

I was trying to lower the pwm value and it would not show any changes.

Any recommendation on an article about filtering the PWM signal in a circuit so that it doesn't affect everything else?

Thank you once more this helped a lot!

[2dof]

edit:
I have done "stupid" simulation of Your PID code to check signals, and I conclude that Your PID controller is not tuned, sampling is to fast ( edit: i find out that You set sampling time time.sleep(0.1) so it is ok ) and there are main reason of Your problem (not I2C or PWM ) .

To make conclusions easier You should plot control output not as pwm clock value as (roundPWMOUT = Output / 1000) but
best in % of control value -> roundPWMOUT = 100 * Output / outMax # ( 100 * Output / 65535.0 -> 0 - to 100 % range ),
then You will see that:

1. from start of control the control signal is on 100 % ( outMax = 65535 ) so Your PID "push" max value - it is saturated .
   in point when error change from to "+" to "-" value PID is trying to control but his control value goes to 0 ( 0 % PWM ) so it is unable to control , rest of changing output temperature comes from process dynamic ( I gues that Your actuator is a heater so we have a thermal process)

2. You have to Tune Your control parameters ( Kp, Ki, Kd) for example with Ziegler–Nichols Tuning Rule Based on Step Response of Plant (First Method) , for example see: https://faculty.mercer.edu/jenkins_he/documents/TuningforPIDControllers.pdf,

edit: in any problem with performing tuning - let as know, we will help, better explanation of step response tuning method : https://yilinmo.github.io/EE3011/Lec9.html

3.What Do You control ?
Thermal process is type of first-order-plus-deadtime response type process so it is not usually "fast"
so it is not need sampling at "max" speed determined by -while- loop and code inside, You should set sampling time according to
Time_constants_of Your process ( for example Tsamilning = Tprocess/( 10 to100) should be ok, and after that tune PID)
( edit: i find out that You set time.sleep(0.1) so sampling time = 0.1 s is ok )

[peterhinch]

I would suggest an electrical solution if it turns out to be an electrical problem. I can make specific recommendations if it is actually electrical.

Using code in an attempt to make a silk purse out of a sow's ear seldom turns out well.

[2dof]

You are righ, my sugestion that there is no problem betwen i2c and pwm is false, ( for heater element as actuator i used to use on-off with sub zero hz and there waz no peoblem), but when khz is used in PWM it can cause some issue.

[ajevticc]

First and foremost, thank you for this much response! I'll start with 2dof. I am interested how did you do a simulation?
I am guessing that you made some sort of a function to generate a value of temp?
For the kp, ki, kd values I have amplified the by a factor of 100 just for the sake of the speed to see what is happening. Even then I have a nice ramp output. (see the picture below).

Thank you for the very useful links. Yes, the parameters where made using Ziegler-Nichols step response method using a RPi 4.

As for the heater, I am controlling a small DC heating PTC element in aluminum case. I think that would make it a second order process because the heater has where to store energy?

This is something that I wanted to ask somebody about sampling time. Is it mentioned somewhere in the lings the calculation that you gave? I have come across this formula also Tsample = Tprocess/( 5 to 10) ???

I will be posting more pictures about the project here.

Thank you so much for your time!

[ajevticc]

Here is a quick hand drawn schematic.

As peterhinch mentioned above, yes the problem is electrical. The PWM signal is affecting the K-type thermocouple. What would be easiest way to resolve this? I would still like to have a higher frequency than 500 Hz for the sake of resolution in control.
Once again thank you for your time!

[2dof]

to answer Your question in some ordered manner due to more important issues:
Electrical problems:

1. as peterhinch noticed there is electrical problem ( noise in reading temp during change PWM :

• does a PWM wires are shielded?
• how physically a switich block ( TC427 +IRF are realised ? -> on separeted board from PICO with common ground connection?
• and how termocouple is mouted ?( does a PWM wires and thermocouple wires ( + I2C wires) ale close to each other.

-> because You use PWM on 30000 (or 10K or just in some kHz ) so wires of pwm can act like Radio and wires of Termo can act like recewier ( but ussualy sensor with cables is shilded) so maby interference is with sda-scl communication .... issue to investgate for You, but before that:

I would still like to have a higher frequency than 500 Hz for the sake of resolution in control. Once again thank you for your time!

Now You have "resolution in control set by -> time.sleep(0.1) because You update control value every 0.1 sec (10 Hz) ( in real: 0.1s + time of code execution time (which we can ignore ) not 500 Hz or not PWM freq like 10kHz or 30kHz . The 0.1 sec is a Sampling (Ts) time here.
You are cocntrolling temperature by on-of heater and for example: when PWM is configured on 10kHz and PWM is set on 50% Duty cycle
then: during Ts=0.1 sek (control value update) a heater (in total) is ON in 0.05 sec (current flow-> heating) and off 0.05 sec (current stop - not heating) , so mean value of current is on 50 % of max value ( the current (Ampests) is the real physical "controling signal "
It will be the same when you set PWM clock on 30kHz, (or 1kHz: lowest PWM Hz for esp32). - Do You see what I mean ?

Now: "SAMPLNG" Time " : I give Tsample = Tprocess/( 5 to 10) i.e sampling frequency should be at lest 5 to 10 faster than process time ( sugested by control process book therory based on Nyquist theory from signal processing. You can sample signal for Your 500 Hz it will still good but when Your process reaction takes seconds it is beter consider if is is worth (from CPU, other task in your code point of view). of corse the higher Fs (1/Ts) then we consider our controler more as "analog" and less as digital controller and we do not have to play in discretization of PID.
From Yours first chart on x-axis You have samples ploted every 0.1 sek and from curve shape changes i estimate Your Time proces (Tp) takes seconds ( a refer to First-Order Process with Dead Time as simple model of Your process)

HOW to solve electrical issue? first try some experiments ( to analyse of nature of noise source) .
perform step responce of our process, i.e set PWM foe example on 10 % fixed (or 20,% 30% ..50 % ,try couple settings) and plot results
-> do this for couple settings of Your PWM ( see Esp32 minimum PWM frequency - maybe it will be solution)
-> before that , change time.sleep(0.1) to time.sleep(0.05) or if serial port allow to 0.01 ( 100 Hz Ts) : noise in Temperature reading has more higher freq.
-> if Your PWM wires are not shielded - fix it.

edit: thy also some PWM ramp ( generate for example from 0 to 20% in 5 sec ) to analyse of temp error propagation )

[2dof]

As for the heater, I am controlling a small DC heating PTC element in aluminum case. I think that would make it a second order process because the heater has where to store energy?

Bye default i consider your process as first order with delay , it also be considered as higer order it depends of physical construction, by default first order for Your is good ( see https://www.electricalengineeringinfo.com/2017/05/transfer-function-mathematical-model-thermal-system.html )

about my "stupid" simulation: I just done a step response of Your PID controller - Your code but with: Setpoint and Input fixed values (no sensor reading), (at first I was supriced that control signal is saturated also "donky blinded" by "lack of" sampling time and just not even noticed a transient behavior ( electric issue noticed by pererhinch) which is most importnant issue.

In typical numerical simulation i usually use from odeint (from scipy.integrate python ) with digital controllers implementation ), when numerical proces identification is needed then I use mentioned z Ziegler–Nichols for first order or scipy.optimize lib for more advanced.
Since i finishing my own API for digital PID for esp32 (micopython) and PRI (Python) and do some in chip tests and simulations I will try prepare example of simulation in python with Your PID code and process and give some ww links if interested.

[2dof]

@ajevticc i have coded simple process simpulation for Your PID implementation (with some changes according do anti-windup section),
in :
https://github.com/2dof/esp_control/tree/main/python_simulation
You will find read_me.txt and python script with simulation)

as example I added tutning based of IMC rules (for Your pid code) and ziegler step method ( standard pid implementation),
see read_me.txt and see comments in *py file in simple_pid() function ( section for standard PID are commented and your pid and tuning
are active (comment/uncomment section to test difference in pid action)

[ajevticc]

@2dof thank you so much for the response. For the last two weeks I have been unwell and therefore unable to respond at all. I want you to know that I really appreciate your help.

I hope to get back tomorrow to the laboratory and start testing the code, and finally to show the improved setup. Likewise, I am reading for now...

[ajevticc]

Hello @2dof, tried to running your simple_pid_FOPDT.py, but it just shows three windows and then reports a crash? I am using Thonny and Python 3.10.6.

[ajevticc]

Time to show the setup. I solved the problem by putting an optocoupler in between the Pi Pico PWM output and the input of the TC 427. By doing this, I have separated the noisy switching GND entirely from the Pi Pico and the thermocouple. Also, shortening the PWM line and by that lowering the inductance of the trace (no ringing on the PWM line).

As for the integral windup, one of the ways to solve it was also to make the Ki constant small in retrospect to the Kp component of the PID. My initial parameters were Kp = 0.1, Ki = 6.0 and Kd = 1.5. When I made the Kp much larger, like Kp = 1000 and Ki = 1.6, the system started behaving as expected with no overshoot.

Here are some pictures at 100 C.

[ajevticc]

[peterhinch]

Good work. My control system theory is decidedly rusty and I'm happy to be told that the following is nonsense but I'll stick my neck out anyway...

As has been mentioned above, heating a thermal mass approximates to a single pole system. Say your control system has a large proportional (P) term, and zero integral (I) and derivative (D) terms. On power up it will approach the setpoint on an exponential curve, stabilising at the setpoint with no overshoot. It sounds to me as if this is very nearly what you have, although you haven't mentioned D.

Clearly this behaviour can be improved, but the question arises as to what needs to be bettered? The time from power up to getting within a given tolerance of the setpoint or the response to external disruption when the setpoint is reached?

If the former you can use a nonlinear approach: turn the PWM to 100% until within tolerance, then switch to P==1000. That achieves the fastest possible outcome.

It's really only in the case where you need a rapid response to external disturbances that you need optimised PID control.

[2dof]

Good job with solving problems.
about Your PID implementation: U= P+I+D where You use D action = Kd * dpv/dt = Kd*(pv_actual-pv_last)/dt Your controller act as PI for setpoint change, and as PID for proces value innerrupted by noise ( sp = const, and any change (noise) act in process will be "activate " D " action for change in pv (also You avoiding derivative kick from change in sp)
In standard PID controller D = Kd * de/dt You will get typical configuration for setpoint tracking/ disturbance rejection (depends on tuning parameters) ( https://paginas.fe.up.pt/~lepabe/publicacoes_restritas/papers/Ijee1673.pdf).

To test setup (one or both PID architecture You can put some ice/ cold air) check difference).
also You can test Your PID with real time sampling: compute Ts (time sampling) from time lib ( when Your code is not call by timer interrupts or tasks and You have to do other computing (lcd/ uart etc).
There is a lot of PID implementation but as peterhinch Everything depends on your goal ( Heat Plate for electronic repair, heat gun etc)

I recommend the books as additional lecture:

1. PID controllers: theory, design, and tuning/Karl Johan Astrom and Tore Hagglund, -
2. "Digital Control" by Kannan M. Moudgalya (2007 John Wiley & Sons, Ltd) -> typical Digital theory implementation of controllers
3. Practical PID Control, Antonio Visioli (2006 ) Springer-Verlag

[ajevticc]

@peterhinch yes, I have forgot to mention the D parameter. To avoid the derivative kick I have kept the Kd = 1.0 also very small compared to Kp and Ki. You are completely right, everything is a trade-off. For me personally, two things were important:
Tolerance to the set point to be below 2 C and that there is no or minimal overshoot. So I am very happy and learned a lot about this process control.

[ajevticc]

@2dof yes that is also one of the problems that I had to solve early on. Tho avoid the derivative kick due to noise but still to retain the computational speed I did not implement a software filter directly into the code loop but at the hardware, MCP9600 has a filter that you can set on. And it works very nicely. Also keeping the Kd very small in comparison to the Kp and Ki.

For the testing to outside interference I use compressed air and the system is behaving very good.

Just to check with you, you want me to test if the time for processing the PID values is stable (not including uart and etc.)?

Yes as I mentioned above, everything is a trade off.

Thank you so much for the literature, that is something that I also wanted to ask about but forgot. Will be reading it.

Wanted also just to ask you again about the your simple_pid_FOPDT.py, it just shows three windows and then reports a crash when i try to run it. I am using Thonny and Python 3.10.6.

[2dof]

about simulation simple_pid_FOPDT.py:
Do not use Thonny ide ( even if You switch interpreter (Tools-> Options -> Interpreter on alternative Python 3 interpreter .... ) it sometimes do crash (ussualy lack of some libs ( need matplotlib for plot, numpy, and scipy modules), I reccomend install Conda environtment and use Spyder IDE (build In), ussualy using >= Python 3.8.5 and python 3.9, python 3.10 shoud be ok.

About noise filtering, if needed use MCP biuld in filtering, if You want use software filter directly then micropython is not to fast ( usually for dsp filters arrays are used, arrays object in micropython are slow. But usually as noise filters in control a lag function is added ( just first order transfer function ( F(s)=1/(1+T_lag *s) where (...) higher frequency fluctuations in the process variable
signal can be damped so that they are excluded from the processing in the control algorithm in particular to avoid affecting the derivative ( action (based on Simens Simatic Standard PID Control Manual).

Alternative for noise filtering You can use a control u = P+I+D + alpha* du(t)/dt , where <alpha* du(t)/dt> is optional derivative filter , but all depends of Your goal - I usually use "the simpler, the better" rule.

About sampling Time/ processing Time: Your Code (reading sensors, pid value calculation and sending to uart) is much faster than sampling time ( defined by time.sleep(0.1)) so You do not have take account processing time. But when You do a lot of calculation in while loop (other stuff than PID calculation) You can take exact time using utime module ( also, You can use to measure time execution of Your code) . In Your case it is not need be implemented, but always good to know:

 import utime
....
t = utime.ticks_ms()
....
while loop:   
   valueK = i2c1.readfrom_mem(0b01100110, 0x00, 2)

   # dt  exact time calculation 
   delta = utime.ticks_diff(utime.ticks_ms(), t) /1000   # ms to sec
   dt= max( 0.1 , delta) 
  .........
  ........

   time.sleep(0.1)
   t = utime.ticks_ms()

About control tolerance: In some process You need go as fast as possible to the setpoint but avoid overshoot then "penalty" cab be added ( when we have overshoot then u=u- beta*error) , do You add non-linear element in Your control. But usually a some optimal control design is enough.

[ajevticc]

This is the fully functional version of code.

from machine import Pin, I2C, PWM, UART 
import time
pwm0 = PWM(Pin(8))      # create PWM object from a pin
pwm0.freq(200)         # set frequency

i2c1 = machine.I2C(1, sda=Pin(14), scl=Pin(15), freq=50000) #Error 5 change CLK speed
                                                            #or wrog value CLK

Setpoint = 180.0

#Original param
# Kp = 0.10
# Ki = 6.0
# Kd = 1.50

Kp = 1000.0
Ki = 10.60
Kd = 1.0

outMin = 0.0
outMax = 65000.0
IoutMin = -65000.0
IoutMax = 65000.0
dt =0.1
Iout = 0.0
Input = 0.0
lastinput = 0.0 

uart = UART(0, baudrate=230400, tx=Pin(0), rx=Pin(1))

i2c1.writeto_mem(0b01100110, 0x06, bytearray(0x20))
i2c1.writeto_mem(0b01100110, 0x05, bytearray(0x04))
valueK = [0x00,0x00]

temperatureK = []

while True:
    valueK = i2c1.readfrom_mem(0b01100110, 0x00, 2)
    temperatureK = (valueK[0] * 16.0 + valueK[1] /16.0)

    Input = temperatureK
    error = Setpoint - Input
    Pout = Kp * error
    Iout = Iout + (Ki * error * dt)
    if (Iout > IoutMax):
        Iout = IoutMax
    if (Iout <= IoutMin):
        Iout = IoutMin
    Dout = ((Input - lastinput ) /dt)
    Dout = Kd * Dout

    Output = Pout + Iout + Dout
    if (Output > outMax): 
        Output = outMax
        Iout = Iout - (Ki * error * dt) #  anti-reset windup 
    if (Output <= outMin):
        Output = outMin
        Iout = Iout - (Ki * error * dt) #  anti-reset windup 

       
    PWMOUT = int(Output)
    pwm0.duty_u16(PWMOUT)
    roundPWMOUT = Output / 1000
    strPWMOUT = str(roundPWMOUT)
    strSETPOINT = str(Setpoint)
    strINPUT = str(Input)
    uart.write(strSETPOINT+' '+strINPUT+' '+ strPWMOUT +'\n')
    lastinput = Input
    print(Input)
    time.sleep(0.1)

[2dof]

Yo do not ned use:

    if (Iout > IoutMax):
        Iout = IoutMax
    if (Iout <= IoutMin):
        Iout = IoutMin

since You have saturation checking in output calculation (and add antiwindup component to Iout part.

[peterhinch]

Note that saturation checks can be a one-liner:

value = max(min_val, min(max_val, value))

[TamaMcGlinn]

I hope you don't mind my asking a probably silly question; I am new to micropython.

I see you use 'from machine import uart', but following this guide from AdaFruit, there is no such library called 'machine' either built in to MicroPython or in the MicroPython library bundle, and anyway the name seems to suggest the implementation is interchangeable so that you have a different one per board. So how did you get the uart library installed for use in MicroPython?

[robert-hh]

This forum is about MicroPython, not Adafruit CircuitPython. There are quite a few differences between them, even if both use the same Python core engine maintained my MicroPython. MicroPython usually has a built-in machine module with several classes. One of the is teh UART class. See https://docs.micropython.org/en/latest/library/machine.html#module-machine

[ajevticc]

Hello everyone, long time no see!
Here is the hardware design of the project. Everything is DIY. And also the output of the system where the blue line is the temperature set point, red line is the measured temperature and the green line is the PWM output.