[FR] Heaters PWM is too coarse

[Theoristos]

In Marlin 1.1.x software PWM resolution is artificially coarsed down to 7 bits (looks like an attempt to improve PWM frequency). So, a unit PWM rise corresponds to +2 C temperature increase, or even to +3 C for hi-power heaters. This coarseness lays down on PID, which needs constantly "play" with output an integrator value in attempts to dither this mismatch. So, in fact there is a little gain in such PWM freq increase. Besides, it leads to higher temperature noise or even PID loop unstability.

It looks highly preferable to change heaters PWM algorithm to hi-freq sigma-delta PWM with 9-11 bits resolution. It would significantly decrease temp noise and increase PWM stability.

The funny part of story is that current PWM realization already contains some dither algorithm, but it is low-freq and have only 7-bit precision.

[oysteinkrog]

Is it the same for 2.0?

[Theoristos]

Sorry, I do not examined 2.0 at all yet. One said that 2.0 oriented on 32-bit controllers, maybe on stuffed full with fast 12-bit hardware PWMs and such case is not a problem... But if algorithm is stays unchanged it looks like good idea to tune 2.0 too. I simple got some weird heater PID problems on my Makerbase with M1.1.8 and try to dig a little deeper down the rabbit hole.

[boelle]

Bugfix 2.0 is both 8 bit and 32 bit

[Theoristos]

Have checked 2.0, there is completely same chain: (float 0...PID_MAX=255. ) get_pid_output -> (uint8 shifted down to 0...127) soft_pwm_amount ->[optional 0...63 - 0...3 with low-freq dithering to 0...127 scale]

[thinkyhead]

This code is ancient. Someone with ancient wisdom will be required to debug and fix it.

[AnHardt]

ancient wisdom

Do you talk about me? :-)

Indeed the heater PWM-resolution is a compromise between heater-switch-frequency and the heater-interrupt frequency. When this compromise was made we had bad, uncooled MOSFETS, like we still have on the RAMPS. Increasing the heater-switch-frequency would make the FETs even hotter. For increasing the interrupt frequency we don't have enough power with the 8-bit AVRs. Switching from normal PWM to sigma-delta PWM at the same interrupt frequency would mean instead of switching (normally) the heaters with ~4Hz to 500Hz at 50% duty cycle. Higher switching frequencies will also complicate the use of 110-220V AC beds switching off at the zero crossings of the current. Now the periods are long enough to allow about up to 25-30 half waves and a random partial when switching on. When switching faster than 100-120 HZ they get eiter no or a random part of a half wave. The switching has to be synchronized with the net frequency then. And the 4Hz have the big advantage of being usually not audible( - if you don't suffer from Prusa-PSU-clicking).

For the fans sigma-delta PWM may be a acceptable idea, but may cause audible sounds.

[thinkyhead]

Do you talk about me?

Not specifically. But you fulfilled the role.

[Theoristos]

Indeed the heater PWM-resolution is a compromise between heater-switch-frequency and the heater-interrupt frequency.

And what issue you see with interrupt freq? ~976 looks as a quite high freq, but we downgrade it down to 15 Hz or even less.

Increasing the heater-switch-frequency would make the FETs even hotter.

Yes, it may be issue. But, for example, for my on-board heater mosfet 1kHz switching losses gives negligible increase in comparison to 100% current forward losses. Less than 2% or even less. Yes it will give an issue on switching relay schematics (I wonder, does anybody use it?). It is not really needed for highly inert heaters like bed heaters. I can think up a pair of issues with fans, so I', not sure that is best for them. But for head heaters... I get some telemetry from board, it constantly swinging the 'I' value. As me, this is not the way that PID should work,

Maybe we will turn to enhanced Sigma-Delta with 2-byte or even 4-byte accumulator and switching time control? It will give us increased accuracy and tunable maximum switching frequency. Plus, universal code for any peripherals. The drawback is only some increase of execution time.

Аnd in the end. Why current PWM precision is so rude coarsened down to 7 bits?

[AnHardt]

Аnd in the end. Why current PWM precision is so rude coarsened down to 7 bits?

I don't really know. I did not write that code. But i have a guess.

In the early days we had 4 temperature sensors. When read with the ADC in the temperature interrupt we used one cycle to configure the ADC for the pin and start the conversion and a second to pick up the value. We needed for 4 sensors * 2 cycles * 16 (oversampling) = 128 cycles to get a new temperature. When we have a new temperature it makes sense to calculate new PID values for the PWM. And only when we have a new PWM value if makes sense to update that. If we set our priority to: apply that new value as soon as possible, it makes perfect sense to use a 7-bit PWM when that is done in the same ISR. With the ~1 KHz interrupt we can have a PWM with: 1024 different states wit a update frequency of ~1 second or 512 states in ~1/2 second or 255 states in ~1/4 second or 128 states in ~1/8 second ...

I have no clue, If setting the priority to the update frequency is better than to the number of states. Just a guess for the reasoning.

If you want to add Sigma-Delta-Modulation for the heaters - do it. But not as a replacement but as a additional option. Than well see what happens with the RAMPS MOSFETs.

With the much faster ARMs the temperature code could look completely different. For the AVRs Marlin used to avoid as much slow pointer arithmetic as possible - especially in the interrupts. For that even arrays and loops have been avoided. That resulted in (on the ARMs) unnecessary splitting about every routine existing twice or more, to handle extruder-heaters, bed, chamber, ... . A limitation to 1KHz temp-ISR frequency is meaningless. ADC could be read by DMA. Having more timers (on the F4s) could allow much more hardware PWMs. We can stop to think about divisions an an the F4s about floats. (If we learn to avoid busy waits in all places where we now tend to burn down all the additional speed of the ARMs).

[boelle]

@AnHardt would it be fair to call this a feature request instead?

[boelle]

i have made this a FR instead, since there is an ask for change in the way marlin works

[tombrazier]

Quick back of an envelope calculation based on my E3D V6 clone's physical parameters:

Heater power = 36W Heatblock heat capacity = 15 J / K PWM frequency = 1kHz

A 1/128 change in PWM output will result in a delta temperature of 36 W / (15 J / K) * 0.001 s = 0.0024K.

Does it matter at all if PID dithering the PWM output results in short term fluctuations of this order? Who has a temperature probe that can even come close to a noise threshold at this level?

I think the question about 7 bit resolution is not really the issue. High frequency delta sigma, on the other hand, may have a case if the hardware can handle it. The entire 7 bit PWM cycle repeats abut 8 times a second and in that time you can get a temperature fluctuation of up to 128 * 0.0024K = 0.3K.

Note delta sigma is essentially a dithered 1 bit PWM.

[tombrazier]

Following up from my last comment, I think the OP did not actually want higher resolution PWM, but high frequency delta sigma DAC. This is already provided by setting a higher value for SOFT_PWM_SCALE and enabling SOFT_PWM_DITHER. As long as the fans can handle the PWM frequency if FAN_SOFT_PWM is enabled, there is nothing to do here.

e.g. 1kHz delta sigma DAC is realised with

#define SOFT_PWM_SCALE 7
#define SOFT_PWM_DITHER

@MarlinFirmware I think this FR can be closed.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.