grblHAL
BACKLASH COMPENSATION ARC BUG
im try using backlash compensation on my Milling Machine , here is my settings step/mm is 500 backlash Compensation is 0.01
and lot of my pulse is missing after backlash compensation is actived , for example this gcode , i try send it by mdi , and it seems there is minus 1 pulse everytime this gcode is sent
N190G1X-187.914Y-187.140F2000 N191G3X-187.578Y-187.774Z14.664I0.593J-0.093
is this because miss calculation on arc or miss calculation on backlash ? , because when i try increase my step/mm into 1000 step/mm backlash compensation work normally
thanks in advance
Backlash compensation can only output a whole number of steps regardless of the setting, a recent change try to ensure this. And the finite resolution of floats may potentially result in lost steps.
Which version/build are you running? It is the first line in the $I output.
Similar to #452. @terjeio, I thing backlash parameters $160, $161, $162, etc. should be in steps, not in mm to avoid possibility to set any distance that wouldn't match to exact number of steps. Or backlash compensation logic should round it to distance that matches whole number of steps.
I also really don't like $100+ settings type "steps per mm": it works well for metric machines, but isn't work so well for imperial one. "mm per step" would be way better. For example with 5 mm vs 1/5 inch(5.08mm) ball screw and 4000 steps:
800 steps/mm vs 787.4015748031496062992125984252 steps/mm <- infinite rounded number 0.00125 mm/step vs 0.00127 mm/step <- finite unrounded number
I understand that it can't be changed because of backward compatibility... except it can: if those settings set above 1 it is "steps per mm", and if those settings set below 1 it is "mm per step". Internally all can be in "mm per step" and at startup if settings set to "steps per mm", we can calculate "mm per step" to use it during operation.
Or backlash compensation logic should round it to distance that matches whole number of steps.
It does so already - added in a recent commit.
I understand that it can't be changed because of backward compatibility... except it can
How do you change the settings UI for senders that uses hardcoded text for settings?
How do you change the settings UI for senders that uses hardcoded text for settings?
That is the beauty - you don't. Since it will be possible to set axis resolution both ways(old and new), text like "X travel resolution .... step/mm" and "Travel resolution in steps per millimeter" is still perfectly valid.
I couldn't imaging machine with 1 mm resolution, so number of steps per mm always will be greater than one and distance per step always will be less than 1. grblHAL could have shadow variables for axis resolution in mm per step. At startup(or if changed) grblHAL could check $100+ settings and if it is less than 1, value of this settings can be copied directly to those variables. If value of $100+ settings is greater than 1, grblHAL can divide 1 by this value and place the result in those variables.