Notice of some bugs either from HAL Core or vanilla grbl

[SienciLabs]

Done my best to look through the outstanding issues and thing these are unique contributions, if not, feel free to let me know. It's also possible some bugs have already been addressed or only exist on my SLB setup:

• $484 unable to be changed / set to =0
• Changing steps per mm values result in the next jog movement to reference the coordinate system as it was before the step/mm changed($100-$103)
• 'Keep homed status on reset' doesn't seem to do anything
• The only way to home any axis independently is to add it to the master homing cycle even if $22 'Allow manual' is enabled
• Sometimes there's 'stickyness' using M104QX where you’re unable to switch back to the default spindle
• G3 movements in the XY direction appear to cause a ‘hang’ but not a crash. In some situations, small pauses or stutters are seen. In other situations the movement stops for 10+ seconds and does not appear to restart. Could have something to do with motion planner math?
• Overrides on shorter files won't take effect if the buffer is large enough to fit the whole file when run (I think this is similar to Overrides have no effect once job is fully in planner buffer #118 (comment))
• Hard limits don't seem to turn off for rotary axes (this seems to be addressed in a new version as mentioned in Home position of rotational axis A #371 (comment)

[engigeer]

I have also come across the issue with changing setting $484 and traced it back to this line:

core/settings.c

Line 1105 in 7cf8687

settings.flags.no_unlock_after_estop = int_value != 0;

It seems that the flag is for the inverse of the setting (i.e., no_unlock) so I think the boolean operator should be == rather than !=. This change should make it comparable to other flags that are inverse of settings (e.g., $346):

core/settings.c

Line 1326 in 7cf8687

settings.flags.no_restore_position_after_M6 = int_value == 0;

[terjeio]

$484 unable to be changed / set to =0

Bug, will fix in next commit.

Changing steps per mm values result in the next jog movement to reference the coordinate system as it was before the step/mm changed($100-$103)

The coordinate systems does not change on step/mm changes. What is changed is the the step count in order to keep the current position the same as before the change. Legacy Grbl does not do that. Should I revert to legacy Grbl behaviour?

'Keep homed status on reset' doesn't seem to do anything

A reset during motion will always invalidate the current position including the homed status, a reset during no motion will keep it if this flag is set. The description should be updated to reflect this.

The only way to home any axis independently is to add it to the master homing cycle even if $22 'Allow manual' is enabled

To enable homing of individual axes Enable single axis commands has to be checked. Allow manual is for setting the current position as the home position for axes not part of configured passes ($44-...), useful for axes that does not have limit/home switches. Note that Enable single axis commands may have to be checked to make use of Allow manual, e.g. if a rotary axis with no limit/home switch is to be homed.

Sometimes there's 'stickyness' using M104QX where you’re unable to switch back to the default spindle

I am not able to replicate this. Does it happen often?

G3 movements in the XY direction appear to cause a ‘hang’ but not a crash.

Stepper settings and example gcode please since this has not been reported by anyone else. Is the hang permanent or a random delay? Could be driver specific?

Overrides on shorter files won't take effect if the buffer is large enough to fit the whole file when run

I'll revisit this.

Hard limits don't seem to turn off for rotary axes

$21 - Hard limits enable has a flag Disable for rotary axes.