Fast PID control hampered by minimum teleperiod 10 sec

[Terje Moseid Bryhni]

Hi,

I have set up Tasmota with PID control and Timeprop on an ESP32.

Now that I am testing and setting up parameters, I find that the minimum teleperiod of 10 seconds is too high. Apparently, this minimum value is a hardcoded somewhere and probably has to do with computing time and MQTT communication. 

In my case, where I am using an inline 9 kW spargewater heater for brewing, it would create problems not to visit the PID algorithm every 1-5 seconds or so.

I am using a local sensor on MAX6675, and I can see the temperature updating fast on the web server. 

Is there any way to reduce teleperiod below 10 seconds or run the PID algorithm faster than the teleperiod?

[Philip Knowles]

Teleperiod is the MQTT update period. The PID loop runs faster

 

The ESP8266 will run the PID algorithm at 1 cycle per second, which is much faster than is needed for the sort of processes Sonoff devices are usually associated with.

 

Regards

 

Phil K

Sent from Mail for Windows

--
You received this message because you are subscribed to the Google Groups "TasmotaUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/bb4fada0-94df-4047-971f-295ad64320f1n%40googlegroups.com.

 

[Philip Knowles]

Forgot to add, if you don’t change PID_UPDATE_SECS from 0 the algorithm runs every time it gets a temperature update.

 

Regards

 

Phil K

Sent from Mail for Windows

 

From: Terje Moseid Bryhni
Sent: 19 January 2022 10:56
To: TasmotaUsers
Subject: Fast PID control hampered by minimum teleperiod 10 sec

 

Hi,

[Terje Moseid Bryhni]

OK, so I change the PID_UPDATE_SECS to 1 or 2, but still, I want to update the PID present value at the same pace. 

If I leave the PID_UPDATE_SECS at 0, the PID algorithm will run every time PID present value receives a new value. But now, that happens every TELEPERIOD. Can I deselect PID_USE_LOCAL_SENSOR and update the value with a script or change the code? Documentation says: "If not using the sensor then you can supply process values via MQTT using cmnd PidPv"

I can see on the webserver that "MAX667 Temperature" updates at an ok pace. The best option could be to average 3-4 values and feed that to PIDpv.
Best regards,

Terje

[Philip Knowles]

I think you are confusing 2 issues - the PID update and MQTT updates.

 

With PID_UPDATE_SECS at 0 the PID algorithm runs every time the sensor reading is updated. So the PID is doing the job of controlling reacting to the sensor input.

 

The state of the PID is reported at TelePeriod – it does not affect the PID - it is just reporting – reducing the TelePeriod will not make the PID react to the temperature change any faster as it reacts to every sensor reading. Sending MQTT messages more frequently just clogs the system.

 

Having said that, if you have a heating system with a time constant at under 5 seconds you most likely have an over sized heating element. In the days when I used to do PID for a living we would be working with (heating) time constants of several minutes and sensor updates every 10 seconds or so. Mind you, one of the advantages of using 4-20mA was ignoring ‘least significant digit’ over control – as soon as digital instruments came in control room staff started to want to control to the nearest 0.1C despite that being lower than the accuracy/repeatability of the sensor.

 

PID is a ‘black art’. With heating we often just used PD as Integral ’wind up’ could be a big problem (particularly at start up). We’d also often have 2 elements and 1 controller. One would be used at system start up to get the temperature up quickly then we’d switch over to a smaller element and the controller for process control

--

You received this message because you are subscribed to the Google Groups "TasmotaUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/bb4fada0-94df-4047-971f-295ad64320f1n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "TasmotaUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/8c6f3525-a87f-4f8d-a5a4-24fc72d67a9fn%40googlegroups.com.

 

[Terje Moseid Bryhni]

Thanks for your valuable feedback. It is possible that we will fail, having 0-9kW input to 1 litre water volume and a delayed temperature measurement on the discharge. We have for now used manual power setting on the pwm, but that isn't 100% stable either. We have a 100degC electro-mechanical thermostat and a big safety switch. And we have used it.... Potentially dangerous gadget.

I am trying now to assemble a berry script to make a number of samples, do a weighted average and feed to the PIDpv (present value). However, I am facing difficulties with the timer function inside the for loop. The structure is roughly:

def pause....print("pause") ...end pause

def SetPIDpv

  (initialize variables)

    for i: 1:10 (get sensor reading)

        tasmota.set_timer(500,pause)

    end

(calculate weighted average and tasmota.cmd() to set pidpv) 

end

What happens, is that all the pauses/timers come after the sensor readings are finished in a rush (acquiring identical temperature values). The same sort of behavior with tasmota.delay(500) (which is a terrible idea, anyway). You probably guessed I'm not a programmer.... help? 

Cheers, Terje

[Philip Knowles]

You have a steam generator. 9kW will raise 1l of water by 45C in 20 seconds. The temperature will be rising so fast that the PID won’t be able to cope. The residual heat in the element means that switching the element off at, say, 10 seconds may still result in an overshoot. I’m presuming that there is a water flow and you are trying to maintain a constant output temperature. Depending on what you are trying to achieve it may be that a 4.5kW pre-heater followed by a PID controlled 4.5kW final heater may give you better control. Alternatively controlling the water flow may also be stable (like a power shower).

 

Good luck

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/5226a455-b7e0-4af4-9f34-e6fcb4863e3bn%40googlegroups.com.

 

[Terje Moseid Bryhni]

Definitely not an easy task. But now I got tangled up in functions and loops, trying to implement a timer to my FOR loop.

Is it possible to just implement a delay (doesn't need to be accurately timed), that doesn't occupy the processor (like the tasmota.delay(ms) would)?

Cheers, Terje

[Terje Moseid Bryhni]

Nope, I think PID is not going to do the trick here, at least not with Tasmota. I have managed to feed new present values into the PID engine, and it does calculate: However, the actual output does not update. I tried to set PID_CYCLETIMES to one second, but I don't see that happening. The result being that a delayed adjustment of power gives an overshoot of 40 degC (!). I'm not sure if this is due to a bug in the pid code, that it somehow defaults to 60 second cycle time or whatever. So there are a couple of workarounds: 1) Just plain, manual power adjustment like before, 2) Construct a slower working algorithm to deal with small changes 3) Go for an Arduino and a different PID code. Is it difficult to connect a 16x2 display and a rotary encoder and make a menu to operate the heater?

[Philip Knowles]

I would erase and reflash and try it without changing any of the defaults (and possibly with a smaller heating element so that it’s less critical). PID is difficult at the best of times and once it goes wrong it’s virtually impossible to resolve. Having said that I think the issue isn’t with the PID put the Time Proportional part. The cycle time of that defaults to 60 seconds and needs to be set at build time. You have a system that has a cycle time of 20 seconds. If you set the cycle time to 5 seconds (and the dead time to 1 second – you’ll have to experiment with this (and the cycle time) – too short and the element won’t heat up – too long and you’ll lose control) you’ll get 5 seconds of full power. The PID would then send a reduced value of say 0.5 so you’d get 2.5 seconds of heat in that 5 seconds. The next cycle might be 1 second in 5 seconds etc.

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/d24c8ec6-c5e5-401f-be39-52b10741da2dn%40googlegroups.com.

 

[Terje Moseid Bryhni]

The Time Proportional part could be the problem. But I'm sure I set the cycletimes to 1 and dead time to 0 in my last flash. It doesn't help.

The heater is already built, so changing the element is not an option. And it's quite fit for the purpose. We've usually set it manually to around 50-60% during sparging to 70-78 °C, with a low flowrate. Ideally, we should be at 78 +/- 2°C.

I could design a control loop based on physical knowledge of the process. I could try with a cycle period of 1 second and adjust every 10 seconds

- manual power setting to approx. right temperature

- Set Tset, measure Tact

- Loop

   - Measure Tact, calculate dT (deviation)

   - When cycle period ends: adjust power dP = k*dT

   - Wait 10 sec

- End loop

So k would depend on flow rate. We have a flowmeter available, but it's a 5 dollar crappy one from Ali Express and can't be trusted. If it turns out that we can use that signal, it can be used as feed forward to adjust k and perhaps shorten the adjustment period.

[Philip Knowles]

1 second is too short. It needs to be long enough to heat the water otherwise everything will wind itself up. The dwell time should also be long enough to make a difference or, again, it will wind everything up. The normal dwell is the time taken to cycle a valve. In your case it should be long enough for the element to make a reasonable change in temperature.

A good place to start is half the time taken for the element to heat from cold to the required temperature. That's your cycle time. The dwell should be about half the time to reach the temperature again after it moves of the set point.

At the start of the process the output will be on for 100% of the cycle time. After it reaches halfway the output should start to pulse and as it nears the set point the output should start to cycle at the dwell time once a cycle to maintain the temperature. If the temperature oscillate you may need to reduce the dwell.

Get Outlook for Android

---

From: sonof...@googlegroups.com <sonof...@googlegroups.com> on behalf of Terje Moseid Bryhni <mrt...@gmail.com>
Sent: Saturday, January 29, 2022 3:35:09 PM
To: TasmotaUsers <sonof...@googlegroups.com>

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/d61784d1-5f41-4953-8465-c20cfe6dabd8n%40googlegroups.com.

[Terje Moseid Bryhni]

Hi,

I appreciate your input! I take it that there is still some hope in trying to implement this with the tasmota PID and time proportional function. I put the project aside for a few days, but today I made a simulation model in Unisim - as realistic as I am able to.

I fiddled with the PID constants and observed that there was not much room for aggressive control before it oscillated. I decided to try the autotune function and Unisim suggested Kc=0.407, Ti=2.02 and Td=0.448. Here is a plot of some responses to changes in setpoint, and an upset with a 5% reduction in flowrate at the end. Slow - takes 20 minutes from 8 to 78 degC, but possibly acceptable in use. I will try to flash the ESP32 with the new values, and a dead time of 12 seconds (which I assume is the same as you call "dwell time"). Cheers!

[Terje Moseid Bryhni]

Not so successful test last night. Tried with deadtimes=12 and cycletimes = 12 and 1. I can't see any difference, so I am wondering if I have my platformio setup right. Time proportional module does not seem to work, so you can all imagine when the controller kicks in with 100%= 9 kW for 10-12 seconds and possibly even another round.... Still seeing overshoots of 30-40 deg C....

Maybe I should try to load tasmota from a fresh start and try to do just a minimum of changes. Keep changes of user configs to the user_config_override part? That file will be read after my-user-configs and override it, right?

Terje

[Philip Knowles]

Dead time MUST be significantly lower than cycle time. The cycle time is the time for the element to heat the water from cold  the dead time is the time for a change to appear in the temperature. The controller will not attempt to control until the dead time has elapsed.

You need to find both by experimenting. Switch the element on from cold and firstly time for the temperature to start to rise then the time it takes to reach the temperature. That's the cycle time. Switch the element off and see how long it takes for the water temperature to drop. That, along with the first time you took, is a good approximation of the dead time. 

Regards

Phil K

Get Outlook for Android

---

From: sonof...@googlegroups.com <sonof...@googlegroups.com> on behalf of Terje Moseid Bryhni <mrt...@gmail.com>

Sent: Tuesday, February 8, 2022 10:46:15 AM

To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/73e0b3cd-4c5f-47ec-97b4-cd9e599d2d68n%40googlegroups.com.

[Philip Knowles]

The cycle time shown is the process cycle time and is the maximum that the cycle time could be set to but, in practice, you would set the cycle time  (time between scans of the inputs) to about 25% of the process cycle time but it MUST be longer than the dead time.

 

Sent from Mail for Windows

 

From: Philip Knowles
Sent: 08 February 2022 11:01
To: Terje Moseid Bryhni; TasmotaUsers
Subject: Re: Fast PID control hampered by minimum teleperiod 10 sec

 

Dead time MUST be significantly lower than cycle time. The cycle time is the time for the element to heat the water from cold  the dead time is the time for a change to appear in the temperature. The controller will not attempt to control until the dead time has elapsed.

You need to find both by experimenting. Switch the element on from cold and firstly time for the temperature to start to rise then the time it takes to reach the temperature. That's the cycle time. Switch the element off and see how long it takes for the water temperature to drop. That, along with the first time you took, is a good approximation of the dead time. 

 

Regards

 

Phil K

 

Get Outlook for Android

From: sonof...@googlegroups.com <sonof...@googlegroups.com> on behalf of Terje Moseid Bryhni <mrt...@gmail.com>
Sent: Tuesday, February 8, 2022 10:46:15 AM
To: TasmotaUsers <sonof...@googlegroups.com>
Subject: Re: Fast PID control hampered by minimum teleperiod 10 sec

 

Not so successful test last night. Tried with deadtimes=12 and cycletimes = 12 and 1. I can't see any difference, so I am wondering if I have my platformio setup right. Time proportional module does not seem to work, so you can all imagine when the controller kicks in with 100%= 9 kW for 10-12 seconds and possibly even another round.... Still seeing overshoots of 30-40 deg C....

Maybe I should try to load tasmota from a fresh start and try to do just a minimum of changes. Keep changes of user configs to the user_config_override part? That file will be read after my-user-configs and override it, right?

 

Terje

søndag 6. februar 2022 kl. 11:34:22 UTC+1 skrev Terje Moseid Bryhni:

Hi,

I appreciate your input! I take it that there is still some hope in trying to implement this with the tasmota PID and time proportional function. I put the project aside for a few days, but today I made a simulation model in Unisim - as realistic as I am able to.

I fiddled with the PID constants and observed that there was not much room for aggressive control before it oscillated. I decided to try the autotune function and Unisim suggested Kc=0.407, Ti=2.02 and Td=0.448. Here is a plot of some responses to changes in setpoint, and an upset with a 5% reduction in flowrate at the end. Slow - takes 20 minutes from 8 to 78 degC, but possibly acceptable in use. I will try to flash the ESP32 with the new values, and a dead time of 12 seconds (which I assume is the same as you call "dwell time"). Cheers!

lørdag 29. januar 2022 kl. 17:54:33 UTC+1 skrev knowles...@gmail.com:

1 second is too short. It needs to be long enough to heat the water otherwise everything will wind itself up. The dwell time should also be long enough to make a difference or, again, it will wind everything up. The normal dwell is the time taken to cycle a valve. In your case it should be long enough for the element to make a reasonable change in temperature.

A good place to start is half the time taken for the element to heat from cold to the required temperature. That's your cycle time. The dwell should be about half the time to reach the temperature again after it moves of the set point.

At the start of the process the output will be on for 100% of the cycle time. After it reaches halfway the output should start to pulse and as it nears the set point the output should start to cycle at the dwell time once a cycle to maintain the temperature. If the temperature oscillate you may need to reduce the dwell.

 

Get Outlook for Android

What happens, is that all the pauses/timers come after the sensor readings are finished in a rush (acquiring identical temperature values). The same sort of behavior with tasmota.delay(500) (which is a terrible idea, anyway). You probably guessed I'm not a programmer... help?