[BUG] SKR V1.3 BLTouch + FAST_PWM_FAN problem

[DrNeis]

Description

If I activate "#define FAST_PWM_FAN" in the most recent Version of Marlin 2.0 my BL Touch Probe stops working connected to my Board " BIGTREETECH SKR V1.3". The Probe shows blue LED always on and doesn't react to GCODE. If i uncomment that line everything works fine again.

Steps to Reproduce

1. Activate "#define FAST_PWM_FAN"
2. Use the hardware mentioned above

Expected behavior: Fan should be silent if running on reduced Speed AND BL Touch should still work

Actual behavior: Fans are silent, but BL Touch stops working.

[Bob-the-Kuhn]

I'm seeing similar behavior on my Re-ARM. On mine the blue LED is also out. The logic analyzer shows no activity on the servo pin.

The FAST_PWM_FAN functionality for the LPC176x family was added by PR #13491 on 26 Mar 2019.

Time to do more digging. So far all I know for sure is that I don't understand the servo includes nor what timer is used by the servo code.

[Bob-the-Kuhn]

The problem might be that FAST_PWM_FAN_FREQUENCY either isn't set or is set too high.

Try setting it to 50.

At 300 the BLTouch deploys and stows but the blue LED is off when stowed.

[ManuelMcLure]

It would be nice to be able to set different PWM frequencies for different pins. 50Hz is great for servos, but is pretty flickery for RGB LEDs.

[Roxy-3D]

It would be nice to be able to set different PWM frequencies for different pins. 50Hz is great for servos, but is pretty flickery for RGB LEDs.

My vote would be we need a PWM class that can be instantiated for any pin. It needs to be carefully coded so it doesn't burn a lot of CPU cycles regardless of how many pins are using it. It can't use much more program space than the current code uses.

[DrNeis]

Thank you for your answers. I found the "#define FAST_PWM_FAN_FREQUENCY" in the Configuration_adv.h file and tried different frequencies. At first I tried to set ist to 31400 - because that seems to be the standard frequency on the ATMEGA2560 i used before without problems. But still no reaction from BLTouch. Next try was 5000 - without sucess.

Then I tried 50 as you Bob-the-Kuhn suggested - an the BLTouch worked again - BUT with 50Hz my radial fans are quite noisy if throttled down (they are running around 15-20% most of the time).

So at the moment it seems not to be possible to use the "FAST_PWM_FAN" on BIGTREETECH SKR V1.3.

(I noticed that the blue led on the BLTouch seems to light up brighter when FAST_PWM_FAN is activated at high frequencies.)

[DrNeis]

Did some more experiments. For my configuration FAST_PWM_FAN_FREQUENCY 600 still works. With 650 the BLTouch is able to deploy and restore the pin from the menu but "self testing" doesn't work. With 700 BLTouch doesn't react any more. I also tried to set BLTOUCH_DELAY to diffent values but without success.

Now I use FAN_SOFT_PWM instead of FAST_PWM_FAN. Still an annoying sound from the fan but a lot better than without.

Would be great if some could find the problem and FAST_PWM_FAN can be used as it was possible with the ATMEGA2560.

[Bob-the-Kuhn]

The "problem" is the LPC176x only has four timers which forces sharing of one timer for the servos and the FAST_PWM_FAN.

I take it the 600 setting had a noise worse than the FAN_SOFT_PWM.

[p3p]

Servos and FAST_PWM_FAN are incompatible on LPC176x because all hardware pwm channels have to run at the same frequency, the software fallback PWM needs all of its channels to run at the same frequency as well, although each system (hardware and software fallback) don't need to be the same you can not ask for a software channel it is just provided if the pin doesn't natively support PWM (or the shared hardware channel is already in use).

I had a feeling adding that support would be more trouble than it was worth, but not everyone uses servos so I though allowing it for lights may be useful.

[Bob-the-Kuhn]

My explanation was totally wrong.

The LPC1768 family already has PWM on any pin. If the pin is hardare PWM capable then a hardware PWM channel is used. If not then timer 3 is used to provide a software PWM.

Try the following file. It forces the fan pins onto the software PWM if FAST_PWM_FAN is enabled. That way the hardware PWMs and the software PWMs can have a difference base frequency.

temperature.zip

[Bob-the-Kuhn]

@p3p - as I understand/remember we have three basic types of PWMs:

• traditional 50Hz servos
• FAST_PWM_FAN that wants to be above the upper human hearing frequency
• LED brightness which should be 60Hz or more

Maybe the LEDs should also be forced onto the software PWM and the default should set to 60Hz or maybe even 120Hz. If FAST_PWM_FAN is enabled then they'd run at the faster rate.

[DrNeis]

Thank you for your comment p3p. I think the BLTouch Probe is used by many marlin users as a reliable Z-Axis Probe. So we need PWM because the probe is controlled like a servo - without beeing a servo. On the other hand FAST_PWM_FAN is great to keep throttled fans quiet - especially if running a TMC2208 driven "Silent Printer".

Is there any possibility to solve this issue?

[p3p]

@DrNeis We try to fix everything in software around these parts because it helps the most people without requiring hardware modification, but the hardware solution to this is a capacitor across the fans power leads with a current limiting resistor, smoothing the PWM signal into a DC voltage the fans are happy with, although at low frequency it may not reduce the ripple enough.

@Bob-the-Kuhn Although I tried very hard to optimise the fallback Software PWM code it is really not fast enough to run at 32Khz (5 us per Hz), it would be fine for a LED at 400Hz needed to be above every ones (probably) threshold for flicker, I'm not sure what the right solution would be, but disabling support for FAST_PWM_FAN again may be the best solution.

As a side not the Hardware channels can run at upto 25Mhz (although that only gives 1 bit of resolution ;) ) with no overhead.

[Bob-the-Kuhn]

The old software PWM (PR #9004) did all the next interrupt calculations when the pin was attached which kept the ISR as a strictly table lookup routine. The comments indicate a 5uS minimum ISR execution time which means an absolute top limit of 10kHz. The more software PWM pins the slower it gets.

10KHz is still in the audible range so that approach probably isn't an improvement. It's also much more complicated.

---

~Another possibility is to not chain the hardware PWM modules and set the frequency for each independently. There's no reason to have the PWMs synchronized. I'm thinking the pseudo code would go something like this:~

Never mind - I forgot that there is only one timer/counter for all the hardware PWM modules on the LPC1768. DUE has a timer/counter for each module.

[DrNeis]

@p3p I really appreciate your hard work! A hardware solution with something like a resistor would be no problem to implement, but I would like to use FAST_PWM_FAN to throttle down my radial part cooler fans variable as needed for different parts. For big parts with wide overhangs they need to run at about 80%. For smaler parts or slow prints i throttle them down to around 20%. Therefore it would be great to have FAST_PWM_FAN

[ManuelMcLure]

Interestingly enough my part cooling fan is perfectly happy with the 50Hz hardware PWM (as long as I set FAN_MIN_PWM to 35 and uncomment the FAN_KICKSTART_TIME line) but fails to start with the faster PWM rate I get if I set FAST_PWM_FAN.

[Bob-the-Kuhn]

Here's some proof of concept code (ugly and not fully functional) on using the Motor Control PWMs if FAST_PWM_FAN is enabled.

The biggest drawback is it can handle only 3 fan pins.

It does generate 31.4kHz PWMs. Theoretically it has 256 settings but … The ISR execution time is 1.375uS. Since the period is 31.94uS in reality it's more like 10-20. The max setting has to be limited to about 90% or else ISR jitter will result in missed pulses.

@p3p - if this is of interest I'll work on it some more.

[gloomyandy]

@Bob-the-Kuhn did you mean to post a link to the code?

[Bob-the-Kuhn]

Yes I did. Here's the code.

MCPWM.zip

[hhoweson]

Just had this issue myself: was tinkering with various settings and went for a print and my hotend went straight through my new (today) bed material ): After a half hour of being confused as hell I narrowed it down to FAST_PWM_FAN with the same hardware as the OP. If this isn't going to be (or can't be) fixed there should at least be warnings to prevent costly repairs for other users.

[Roxy-3D]

If this isn't going to be (or can't be) fixed there should at least be warnings to prevent costly repairs for other users.

Yeah... I'm waiting for a Pull Request from you to fix the issue.

[ptyork]

Does it look like there will be any "fix" action on this? If not, though I'm not qualified to try to actually fix it like @Bob-the-Kuhn, I can do a pull request for a SanityCheck.h for this to at least prevent enabling both. Does this affect anything that uses a servo? If so, what other devices require a servo and thus should not be enabled if FAST_PWM_FAN is enabled? If not, it's just as simple as:

#if ENABLED(FAST_PWM_FAN) && HAS_Z_SERVO_PROBE
  #error "FAST_PWM_FAN is not supported when using a servo probe."
#endif

EDIT: if so, then:

#if ENABLED(FAST_PWM_FAN) && NUM_SERVOS > 0
  #error "FAST_PWM_FAN is not supported when using a servo probe."
#endif

right?

[gruvin]

@boelle I see this as a bug BUT it's caused by hardware limitations (ironically) and therefore not going to be resolved in that context. However ...

Software PWM for servos will work if interrupt driven, to avoid gitter. (I'm guessing it's already interrupt based?) This would leave HW PWM for fans, LEDs and the like, where the frequency is not mission critical, as it certainly is for servos, where there's a definite and slow maximum allowable freq.

SOFT_PWM_SCALE > 0 would reduce servo resolution, which is bad. So, some kind of convoluted exception would have to made there for the 32-bit MCUs. One approach would be to keep SW PWM interrupt always at some, "highest" frequency and switch to implementing the slower speeds in the ISR routine — skip if down counter > 0, sort of thing. This would be a terrible idea on a slow 8-bit MCUs but shouldn't be an issue on a 100 MHz 32-bit chip.

Obviously, all the (presumably) ISR code's pulse width timing would need to be aware of this, in different ways than it likely is today.

Doable but oh what a PITA and on what should have been an allround higher performance MCU. 🤷‍♂

FWIW, in my case the only issue is flickering case light LEDs! sigh

[Coffee0297]

i can confim this bug as of 22/08/2019. skr v1.3 bltouch v3.1 tmc5160 spi 24v

[thisiskeithb]

Should a check/warning be added if BLTOUCH & FAST_PWM_FAN are enabled for LPC176*?

[boelle]

@DrNeis is the issue still there?

[boelle]

Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.

[opiswahn]

@boelle I also have the same problem mentioned above. As soon as i deactivate FAST_PWM_FAN it works again. I belive there should be some kind of fix in the firmware for this?

[boelle]

someone needs to make the fix and send it in as a PR to 2.0.x

marlin dev people are just like you and me, they dont get any money

everyone can help, my code skills are not good enough, simple stuff i can do and if people tell me what file to edit and what needs to be changed

[eun-ice]

I suggest a comment on FAST_PWM_FAN option to hint for this would be welcome, I had to backtrack a boatload of config changes until I found this was the reason why my bltouch stopped working.

[thisiskeithb]

I suggest a comment on FAST_PWM_FAN option to hint for this would be welcome, I had to backtrack a boatload of config changes until I found this was the reason why my bltouch stopped working.

See https://github.com/MarlinFirmware/Marlin/pull/16038

[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.