Ball screw mapping details question -SOLVED

Thanks all for the input

rodw wrote:

Just curious Richard, did you consider using external offsets to adjust for linearity? If you could use them, you could remove the dependence on Gcode. (You need V 2.8 or above)

No, not sure of the concept there. I imagine you mean, that a run-time compensation table could be developed as positions are sampled and injected via HAL and external axis offsets computed in real time from the linear scales, instead of a static compensation table. That might be feasible, but it doesn't gain the one-sided feedback loop that's needed on top of all other loops. You need that loop, and CAM-level part intelligence, to tame the backlash dragon tail.

I implemented the adaptive positioning feedback loop in G-code for prototyping convenience, but it could just as well (or better) be done in Python or added to LinuxCNC itself. So that much is not necessarily G-code.

What is necessarily G-code is that the part intelligence is only available at the CAM level, which gets expressed in the CAM-generated G-code. But not strictly G-code, if one has some other low-level part programming facility, such as the LinuxCNC Python interface.

It's similar to tool-radius offsetting. G-code has that feature, but the use of it has to be governed by the part intelligence available at the CAM stage and unknown at the CNC level. Likewise backlash has to be managed at the CAM level based on the part intelligence. CNC and G-code implement a machine model and motion, not part models or tool logic. This is a consequence of the logical distinction between part features vs tool paths, which is why there is CAM vs CNC, and they can't be merged.

Non-existant user wrote:

No, not sure of the concept there.

Refer: linuxcnc.org/docs/devel/html/motion/external-offsets.html
And axis.L.eoffset-counts linuxcnc.org/docs/devel/html/man/man9/motion.9.html
These are 2.9 docs but it also applies to 2.8

This is very cool and how we manage torch height control on plasma machines.

Think of eoffsets acting as a MPG so it has a scaled count
To play, you need apportion a percentage of your velocity and acceleration in your axis set up in your ini file (eg limiting your max values)

So you introduce a scaled count to the eoffset-count pin that represents your deviation from the actual true axis reading, Linuxcnc will offset the axis accordingly. There are some sims to illustrate this provided in 2.8 and 2.9

So for a simple example to see this in action on a live machine, imagine that you had a non-square axis. We actually did this for a user on the forum. Say we are out of square by 10 cm per metre (10%) along the Y axis in relation to X.

If you multiplied axis.Y.pos−cmd x 0.1 and your scaling factor and send that to the eoffset-count pin for Axis X, you should see the axis move diagonally as you jogged along that axis to compensate for your supposedly crooked axis..

So in your application, if you had reduced the error to a formula or a lookup table, you could easily adjust for the error independent of any Gcode. You may need to write a small component.

Think about how you could apply it. It will work.

EDIT, my maths might be a bit sloppy there but I'll leave you to think about it.