Insufficient dynamic range on AMASS

[andrewmarles]

First, I would like to thank @J-Dunn for the work on this issue mentioned here:

https://github.com/Schildkroet/GRBL-Advanced/issues/58

In particular this post: https://github.com/Schildkroet/GRBL-Advanced/issues/58#issuecomment-871296602

I think it's relevant to open this issue here since the results are interesting for this project.

I think that the point is valid even if the original poster does not wish to engage on this issue.

[terjeio]

For most of the grblHAL drivers this is not an issue as I use a 32 bit timer whenever possible. In fact I have had to limit the maximum step time to avoid what seemed to be occasinally hangs but were overly long step intervals during deceleration.

[J-Dunn]

For most of the grblHAL drivers this is not an issue

Presumably the idea of a HAL is that it works all the time not whenever possible. If you support <32bit architectures in your HAL, the AMASS mod would remove the issue for all h/w archs. You comment does point out that it may be better to fix expand the GRBL code to use 32bit counters on STM32 and keep AMASS as it was. Though that would require more thought and testing.

Is AMASS redundant on 32bit, or does it have other benefits?

[terjeio]

Presumably the idea of a HAL is that it works all the time not whenever possible.

grblHAL is designed to be flexible and offers different features for the MCUs/boards supported via the HAL implementation (drivers). Some drivers are limited by the MCU capabilities, some by the effort to needed to implement support for specific features such as those required by plugins.

For MCUs not having a 32 bit timer it is sometimes possible to make use of a prescaler in the driver code, I cannot remember now if I have done this for all those drivers and I am lazy to check this now.

Is AMASS redundant on 32bit, or does it have other benefits?

AFAICT it has other benefits.

[terjeio]

I think it's relevant to open this issue here since the results are interesting for this project.

It is relevant but IMO slowing the probing speed to get more precise positions is not the necessarily the complete solution. The probe input is polled on every step in the stepper ISR, a problem with this is that if the probe has contact bounce the initial contact might be missed. A possible solution for this is to add interrupt support for the probe pin and use that to trigger a virtual SR latch and then read probe status from the latch output. @Volksolive did that for the RP2040 driver. I want to do the same for the other drivers where possible...

[J-Dunn]

AFAICT it has other benefits.

Thanks

"In fact I have had to limit the maximum step time to avoid what seemed to be occasinally hangs but were overly long step intervals during deceleration."

so maybe increasing DR of AMASS is a better solution than probably unnecessarily using 32bit counters which can produce other unexpected consequences.