search

terjeio / grblHAL

This repo has moved to a new home https://github.com/grblHAL
232 stars 90 forks source link

STM32F411: Spindle PWM output at 100% is glitchy #196

Closed phil-barrett closed 3 years ago

phil-barrett commented 3 years ago

When running spindle at 100% (i.e. full speed), the Spindle PWM output shows random glitches on the output pin. These glitches are less than 62.5 nS (the limit of my logic analyzer's resolution). I have not hooked up my O'scope - will do it if you want to see the glitches in more detail. They appear to be random - see the 3rd LA screen shot posted below. This does not prevent the spindle from running at 100%.since PWM usually gets filtered to a voltage and there really are only a handful of them. This does not seem to happen at 50% or 99.9% duty cycle. See the screenshots below.

[edit] pwm pin is on PA8

Note, this does not happen on the T4.1 version of grblHAL.

$I:

[VER:1.1f(STM32F411).20201103:] [OPT:VNMSL,35,1024,5,0] [NEWOPT:*FLASH,TC,SS] [DRIVER VERSION:201103]

Main branch of grblHAL.

Hardware: Nucleo-F411RE

$30 = 1000 $31 = 0 $33 = 5000

RPM for 100% was 1000 RPM for 99.9% was 999 RPM for 50% was 500

LA Screen Shots: First is 50%, Second is 99.9% and third is 100% spwm 50% spwm 99 9% spwm 100%

avizienis commented 3 years ago

I noticed the same on a blue pill.

langwadt commented 3 years ago

sure that 100% is really 100% ?

phil-barrett commented 3 years ago

sure that 100% is really 100% ?

Perhaps it isn't. In which case the problem is worse because the PWM pulses are pretty random.

But, I am quite confident that when grblHAL sees a max speed ($30) of 1000 and ioSender has requested a speed of 1000, that is 100%. [edit] terje has explained this and it isn't!

A bit more info. I played with different PWM frequencies and max spindle speeds. The PWM frequency seems to have no effect on the behavior. Setting max speed to 10000 rpm, requested speeds of 9999 and 10000 resulted in similar behavior (random glitches). Requesting 9998 resulted in correct behavior.

terjeio commented 3 years ago

sure that 100% is really 100% ?

It is not, I have checked F303/F4xx. It is 100% minus one PWM bit resolution. I have to check the behaviour of the other supported processors before commiting a fix.

phil-barrett commented 3 years ago

Hmmm, that means I'm having sampling issues with my LA. Not sure why they appear randomly - should be a "beat frequency" to them.

langwadt commented 3 years ago

unless the LA and MCU is running on the same clock they will not be synchronous and also drift so it'll look random

terjeio commented 3 years ago

Hmmm, that means I'm having sampling issues with my LA. Not sure why they appear randomly - should be a "beat frequency" to them.

Nyquist? Sampling rate has to be pretty high to catch the pulses reliably. Checking MSP432, same issue. There is a 200ns pulse there. To avoid aliasing the sample rate should be at least the double (100ns/10Mhz).

I do not think this is an issue in any practical sense as the PWM frequency will always be in discrete steps. The PWM bit resolution is dependent on the counter prescaler, period (frequency) and available bits for adjusting the duty cycle. For most processors I have adjusted the prescaler to get low enough frequency and good duty cycle resolution for servos. In addition to fixing this minor glitch some work should be put into optimizing for the prescaler value?

phil-barrett commented 3 years ago

I have a 16 MHz sample rate on my LA. Kind of low. Might have to buy a better, faster one though it works fine for most of my needs.

terjeio commented 3 years ago

Teensy 4.1 glitch - 100MHz sampling rate:

t4

Will it be possible to measure a significant RPM discrepancy at the spindle? Anyway, I'll fix this after checking all drivers, including PWM inversion mode that some supports. It is, IMO, a very minor bug so not a top priority.

phil-barrett commented 3 years ago

Ok. Looks like it is on all platforms. Too short on the iMXRT1062 to capture on my LA. If nothing else, it is good to remember that sampling rate has measurement implications.

Will it be possible to measure a significant RPM discrepancy at the spindle? Anyway, I'll fix this after checking all drivers, including PWM inversion mode that some supports. It is, IMO, a very minor bug so not a top priority.

Yes. I said as much in the original post.

terjeio commented 3 years ago

Ok. Looks like it is on all platforms.

Nope, it is not. I went back to the first MCU I started coding grblHAL for, Tiva C or TM4C123, and with the fix PWM output drops to 0 at 100%. Without the fix there is a tiny glitch... So at least this MCU fails badly with the fix, and I think a couple of the others will too.