I think the 33ohm resistor combined with the fast pid frequency never allowed the gate to fully saturate.
It makes sense. I’ll swap it back to the 10 ohm resistor and see what difference that makes. Sometimes I forget that these newer boards do everything faster than the old 8 bit. Didn’t realize it was 250 times as fast.
Oh yeah, 2khz is totally audible range. And I can imagine the MOSTFET not saturating fast enough. If that’s the case, the MOSFET will run much hotter at the higher switching frequency.
You know what is funny, looking at their config page, their default readings per second is 20, so any pid frequency above 20 is completely wasteful as there is nothing new it can do in the feedback loop, all it’s doing is wasting energy.
Exactly. I’m glad it was an easy fix like that. Kept scratching my head trying to figure out why a simple mosfet circuit could have such issues.
@Stephanie_A The effective reading rate is actually way lower than 20Hz because there’s so much filtering applied to the reads. The Smoothie MCU ADC is seriously awful, and too noisy to use without massive smoothing. That smoothing adds sensing lag.
But, the PID output switching definitely SHOULD be much faster than the reading. If your PID frequency equals your read sensitivity, it’s always outputting 100% or 0% power on every temp read. That’s silly. You need the PWM to be fast enough that you have a meaningful resolution to output between reads. I would want the PID PWM to be >10x higher frequency than the read speed. Also, the faster it goes, the less it creams the PSU – 10Hz switching is practically bang-bang as far as the PSU rail voltage is concerned, unless you’ve got an absurd amount of capacitance.
What’s pointless is reading a first-order physical system with a ~1 minute time constant at 20Hz. Adds zero value. Wastes clock cycles. Reading every second is perfectly adequate.
2k is just excessive though. I’ll mess with the values to see where I can get the steadiest voltage without an audible range as well.
@Griffin_Paquette Agree that 2KHz is excessive. Very little thought went into the original Smoothie heater code. It was basically a straight port of krufty old Marlin code, but with a “faster is better” mindset on the sampling etc. It’s been improved a lot in the last few years to solve the LPC176x ADC noise issues, but some stuff just never had any real logic behind it, and worked well enough to not get changed.
If your heater can heat up so fast that there is a significant difference within 50ms of heating, then it would be a problem if the pid freq matched the read freq. Since it’s reading temp of the heater medium and not the power of the heater, I don’t think it’s an issue.
The faster it goes, the more load it places on the psu caps, they never have time to recover.
@Stephanie_A I think it might be more accurate for us to say something like:
- the PID switching needs to be much faster than the physical process change, so the response to PWM duty cycle appears as a smooth power curve and not a bang-bang response.
- the PID switching needs to be slow enough for the MOSFET to be saturated most of the time.
- There needs to be enough capacitance for the high-current switching to not play hell with the PSU voltage. (This is deliberately vague – I think there are multiple valid approaches here related to PWM frequency and capacitor sizing.)
- the temp reads don’t need to be any faster than something like half the time constant of the actual temp sensor (…I think this is not an exactly valid application of the nyquist limit but you get the idea…) and doesn’t necessarily need to be related to the PID switching rate at all.
- Temp sensing noise screws everything up. In particular, sensing noise combined with a high PID refresh rate causes the PID derivative to blow up and saturate the PID output with junk 0%/100% values.
I was thinking about pwm rate, not pid rate, you’d think pid rate is tied to the sensor read frequency and not the pwm frequency, because if the pid adjusts the pwm based on zero change in feedback from the sensor then things will never work right.
On something that reacts so slowly a pwm frequency that is significantly faster than the sensor rate would yeild no better results and lower efficiency through switching losses, because the total on and off time is still the same in between sensor reads whether the pwm frequency is 10 times the sensor rate, or two times. If pwm was less than sensor rate, then there is going to be a problem.
If the sensor rate is very slow and the pwm is slow then you can have problems with reading only while heating or cooling in the pwm cycle.
A good way to fix that is to have an averaging at the Nyquist frequency of the pwm, then that average is fed as the sensor reading. Single measurements are noisy anyways.
Personally I take sensor readings as fast as possible (at the most accurate adc settings) then feed them into an averaged median at 50% of the values.
Oh, good clarification on the terminology… PID loop refresh rate should definitely equal the output rate of the filtered temp reads. For example, you can oversample the ADC at 20Hz (or whatever), run that through a filter, and then output a smoothed temp and refresh PID every second or half second. I believe Smoothie currently samples the ADC at 20Hz in the background to build a moving average and then inputs that filtered value to the PID loop at 20Hz as well. The first part is fine (although not how I’d solve the noise problem) but updating the PID that fast is pointless. In effect the PID is working off a full second or so of sensor data, but it’s updating target power output 20 times per second.
The PWM chopping frequency should be fast enough that the electrical load on the PSU and thermal load on the heater element looks more or less analog, not like a bang-bang loop. If the PWM switching is fairly slow, the load will act to the PSU and heater just like it’s being switched on 100% and off 0% over and over, which is 1) hard on the PSU to regulate without major voltage oscillation, and 2) puts a lot of thermal stress on the heating element, wiring, PCB, connectors, etc. For example, you’d be more likely to prematurely fail an extruder heater cartridge (made of a wire coil potted in brittle ceramic) if it’s PWM switched at 1Hz rather than something faster OR slower. And those cartridge failures tend to cause shorts from coil to casing (electrifying the entire hot end and possibly gantry – has happened to me!) or cause the coil to internally short, dropping its resistance and increasing its power output (has also happened to me!).
For another example, a series of FlashForge printers were built a couple years ago with off-spec heatbed PCBs that had resistance too low, and FlashForge opted to compile a PWM duty cycle cap into the firmware to ensure the heater power draw didn’t exceed 12A or thereabouts. Problem was, the heatbed PWM was pretty slow so the circuit basically got slammed with excessive current for part of a second, alternating with zero current for part of a second. It didn’t affect measured heatbed temps (too much thermal mass) but it DOES cause wire connector thermal cycling, which accelerates oxidation, and causes an increased rate of connector/wiring melt-down failures we often see in Chinese printers.
I see what you mean, though for that to work (seen as an analog load) the mosfet would need to be able to switch fast enough and the caps would need to be able to filter fast enough. An inductor after the mosfet would reduce the ripple and present more of an analog load, but adds in new issues.
But the faster switching would save the heater wires, you’re right. Again, didn’t think about that. Make sure to add it to your book.