$34 spindle off PWM and $35 minimum spindle PWM seems offset by an amount relative to PWM frequency

SuperLongBoard ❓Question
1

Hi, I am trying to understand the implementation of the $34 and $35 registers to hunt down a discrepancy between configuration and measured PWM output on a Sienci SLB. I’m unclear whether this is an issue with the sienciHAL fork of grblHAL, or with grblHAL itself. If this seems like an issue with grblHAL let me know and I’ll re-open the issue there.

I used firmware build 5.0.5b linked from the Technical Manual for the following investigation.

Regardless of what non-zero value I set $35 to, if I measure PWM output duty cycle with an oscilloscope, I get the value of $35 plus some offset. Same for $34.

For a concrete example, it is easier to use $34 as there’s no subsequent interpolation of RPMs within the speed range.

$33=1000 // default-ish PWM rate?
$34=1
m3 s8000
m5

This results in a PWM duty cycle of 6%, rather than the desired 1%, for an offset of 5%.

Lets try an 8b PWM range for comparison:

$33=256
$34=1
m3 s8000
m5

This results in a PWM duty cycle of 2.3%, rather than the desired 1%, for an offset of ~1.3%.

So for some reason reducing the PWM resolution improves the minimum offset, and increasing the PWM resolution makes the offset worse by ~1.25% per ~250Hz increment. Is this tied to some base clock rate that a minimum PWM period is being calculated from?

Is this expected behavior? It is certainly annoying when trying to dial in the actual use of either $34 or especially $35.

Thanks for considering!

2

@drilling-vagueness, I’m not exactly sure, but this sounds similar to what @johanncc noticed when doing in-depth testing for the AutoSpin and I can’t recall the outcome of that right now

3

thanks @chrismakesstuff . I guess this is just more motivation to get a modbus VFD :face_with_raised_eyebrow:

4

It is hardware related (U4 rise/fall times) - higher PWM frequency → larger error.

1 Like
5

Thanks for chiming in Terje, that was the issue yes - no issue with grblHAL firmware just a U4 component issue on the board

6

Ah got it, I think that makes sense. I guess I’ll throw the scope back on to confirm that the minimum pulse width is staying the same regardless of refresh rate.

@terjeio is there a tradeoff on going slower with respect to PWM resolution? I had a look through your source and there are some comments in there mentioning that it’s an 8b PWM, but the implementation looks like 16b to me? If I slow it down to 40Hz or something I assume that’s still fast enough to propagate speed changes in a responsive manner, but will provide more resolution to the PWM clock? Is there a rate that is too slow here?

Thanks!

7

That depends on the receiving end, too low and you may experience jitter in the RPM?

It is 16 bit for the STM32 drivers. The 8-bit comments are from the legacy Grbl source code.

Again this depends on the receiving end. I auto-tune the PWM timer prescaler for maximum resolution so it is pretty good even at high frequencies, range is 5000 steps at 20KHz for the SLB (at the MCU pin). Below 2KHz you will likely get 15-16 bit of resolution.

Too slow will be when the response time at the receiving end gets too long and/or the spindle RPM starts to jitter at the PWM period? If for dynamically controlling laser power the frequency should be at the higher end and is the reason that grblHAL defaults to 5KHz.

1 Like
8

Ah copy, thanks so much for the insights @terjeio.

Makes sense for a laser that can change rates quickly - I’m using a spindle without a brake so I guess it shouldn’t care too much?

Bummer that the performance is so good at the MCU pin but gets eaten by the slow optocoupler.