Actual vs/and Logical position reporting

[nickshl]

Hi @terjeio, is there a way(settings or something) to switch position reporting from actual to logical(or even better - get reported both)?
For example, if we have step 0.010 mm, and ask grblHAL to move 0.004 mm(from position 0) there will not be any movement. grblHAL will report actual position(0.000), but inside it holds logical position(0.004) and if we ask to move 0.004 mm again, it will move(I assume) to 0.010 and report that, but logical position will be 0.008. Additional confusion happens when we try to zero axis. In this example after axis is zeroed, grblHAL will report 0.002 mm instead 0.000(0.008 is zero, actual is 0.010, so 0.010 - 0.008 = 0.002). And it is especially annoying when ball screws has pitch of 5.08 mm(1/5 of an inch) instead 5 mm and steps per mm is 787.4015748...(which is rounded by grblHAL to 787.4016) - in this case virtually all actual and logical position isn't match each other.

[terjeio]

The logical position you ask for is not available as real-time data since motion happens in steps and there is no way to convert that accurately back as you have discovered. With a plugin you can get it from the parser (these fields) and add it to the real-time report, or output by other means, but will only be valid if there is no motion.
Another issue in addition to the step quantization is that floats has finite resolution and will also add some quantization.

... steps per mm is 787.4015748...(which is rounded by grblHAL to 787.4016)

The input parser does not round float values, the finite resolution of floats does. FYI ioSender reads the format from the controller and this was recently changed, allowing greater precision in the input - up to 5 digits in the fraction. If setting the value form the MDI there is no limit to the number of accepted (and stored) digits in the fraction - but the value will still be rounded to 5 when it is reported back. Legacy Grbl does the same but rounds to 3 digits.

[nickshl]

but will only be valid if there is no motion.

So, then real position can be reported when state is Run, Jog or Home, and Logical position in all other states.

With a plugin you can get it from the parser (these fields) and add it to the real-time report

I would prefer to replace, not to add - in this case it will be compatible with existing senders. Is it possible to do it with a plugin?

that floats has finite resolution and will also add some quantization.

It looks weird to me that GRBL uses steps per mm, not mm per step. 5.08 mm / 4000 steps = 0.00127. Perfectly fine finite number doesn't affect by float finite resolution. It works with other imperial pitch and different mictostepping too.
Then instead division:
position[idx] = steps[idx] / settings.axis[idx].steps_per_mm;
Multiplication can be used:
position[idx] = steps[idx] * settings.axis[idx].mm_per_step;
And I know - not going to happen.

[terjeio]

I would prefer to replace, not to add - in this case it will be compatible with existing senders. Is it possible to do it with a plugin?

No, currently not. It is only possible to add to the report.

It looks weird to me that GRBL uses steps per mm, not mm per step.

Well, there are other means than ballscrews to translate steps to motion, belts, acme screws, rack & pinion, ..., which might not be that precise.

And I know - not going to happen.

I can be changed internally to save some cycles, but changing the meaning of the setting externally is not a good idea - that could upset senders. BTW I have it on my todo list to make a double precision (64 bit) version some time in the future. The iMXRT1062 and the STM32F7xx MCUs has a double precision FPU that would be nice to utilize.

[nickshl]

I can be changed internally to save some cycles, but changing the meaning of the setting externally is not a good idea - that could upset senders.

Technically it can be done: since steps per mm is always greater than 1 and mm per step is always less than 1 this can be used to figure out which format is used. But if comes at a price for additional overhead - every place that uses settings.axis[idx].steps_per_mm should have additional if() statement.

Other option to use use only "mm per step" internally and at startup(or settings change) calculate "mm per step" from "steps per mm" if setting is greater than 1.

Well, there are other means than ballscrews to translate steps to motion, belts, acme screws, rack & pinion, ... which might not be that precise.

I have feeling, that if we take finite number and divide it by number of steps(200, 400, 800, 1000, 1600, 2000, 3200, 4000, etc.) result still be finite number.