change external offset to float

[rene-dev]

change external offset to float, having an offset as integer makes absoluteley no sense.
in one place(eoffset_per_angle.comp) it is actually used as a fixed point integer, calculating the reverse scale!
please, someone check the plasmac changes.

[grandixximo]

If an integer offset makes no sense, does that also apply to axis.L.jog-counts? Same counts-times-scale interface, same design.

The s32 type comes from the MPG world: a handwheel emits integer pulses, counts*scale turns them into distance. Natively float sources needing conv_float_s32 is ugly, agreed. But is the answer to retype the pin, or to feed it better?

Every plasma config in the wild that nets an s32 signal into axis.z.eoffset-counts stops loading after this. HAL does no implicit s32-to-float conversion on nets, so there is no graceful path. What is the migration story for those configs?

Your own updown.comp change adds a count_f pin instead of retyping count. If preserving the s32 interface is the right call there, why is it the wrong call in motion?

And once the pin is float, what does "counts" still count? Would a separate float input (counts left untouched) reach the same goal with zero breakage?

[andypugh]

If an integer offset makes no sense, does that also apply to axis.L.jog-counts? Same counts-times-scale interface, same design

Jog-counts is typically scaled by a step-size under UI or separate switch control, so makes sense there.

Almost every use I have seen for external offsets has to jump through hoops to force the output of the calculations into counts+scale.

I think the original application was offsetting a path either an MPG but I can't recall what unusual application that was. Subsequent applications, like Sam's hexagonal boring would be better (and more accurately) served by a float pin rather than fixed-point.

[grandixximo]

The step-size switch sets jog-scale from the UI instead of HAL. Underneath it is the same counts times scale. What distinguishes them?

On accuracy: resolution is the scale value, range is 2^31 times the scale, and motion diffs the pin against its previous value and accumulates in double, so source-side rounding never accumulates. You said a float pin would serve applications like Sam's hexagonal boring better, and more accurately. More accurately how? Is there a concrete case where s32 counts at a chosen scale lose to a float, or is that assertion?

The integer-width question came up before with 64-bit encoder counts, and the answer was the new HAL API in #4247. I would rather Bertho weigh in on how this fits that track than settle it piecemeal here.

Still open: the migration story for existing configs, and what a retype achieves that an added float input does not.

[BsAtHome]

Just about every file touched in this PR and #4518 conflicts with #4247.