Ball screw mapping details question -SOLVED

Hi,

When you have lineair interpolation, just like Andy proposed.

I wonder as it currently allows about 250 remapped points per axis so does it just take those as absolute points or does it smooth the error between them?

Let's give the interpolation the accuracy of float instead of double.
float: 0.3333333
double: 0.333333333333333

The software will alway's go with the float value until the end. In cnc we will not use integer value's for positioning. Minimal is float.
You final output (hardware) will decide if the resolution will be less then float presision.

There are two ways you can automatically gather data in Linuxcnc but I'm to lazy tonight to find the references. I have used both. One is to use halsampler to stream data to a file. I've used this to capture 16000 data points for further regression analysis in a spreadshseet.

The other way which is probably more useful for calibration is to save probe data into a file from within gcode. I used this to map the material surface before capturing my data points so I could adjust for surface irregularities.

rodw wrote: There are two ways you can automatically gather data in Linuxcnc ... The other way which is probably more useful for calibration is to save probe data into a file from within gcode.

That was the aim of my automatic leadscrew characterization project which was reported in Possible error in logic of LinuxCNC homing with leadscrew compensation . That report includes the G-code I produced to log leadscrew non-linearity data to a log file. I processed the logged data with some other scripts to turn it into proper charts with gnuplot, generating something like the calibration metrology report you would get from the manufacturer when buying a new precision ballscrew.

The charting was successful. Then I applied more scripts to generate compensation files for LinuxCNC, activated LinuxCNC compensation, and demonstrated that the basic idea works. I was able to refine some truly sloppy leadscrews into +/- 0.0005in open-loop repeatability.

This led to the disappointing conclusion that there are many other mechanical weakest-link factors that spoil the repeatability from holding up over time. The first factor is the need for extremely precise-repeatable closed-loop adaptive homing at start-up, which LinuxCNC is not yet plainly capable. I did manage to customize LinuxCNC to get sub-thou homing on start-ups. Then I found the other mechanical factors that frustrate long-term repeatability, even if you solve the homing and compensation functions perfectly.

I abandoned the open-loop compensation project and have developed the closed-loop adaptive-positioning method in run-time G-code, which actually works. The catch to that success is that the loop is closed in G-code, which means the logic has to be implemented in the CAM generation of G-code. Compensation (or adaptive positioning) is necessarily path-dependent due to never-zero backlash, and this is impossible to plan in CNC, it *must* be provisioned and solved in CAM where the path logistic and part geometry are knowable. So I spent another month implementing a proper CAM tool incorporating that adaptive run-time intelligence. It does work splendidly, positioning to the precision of the DRO scales via sloppy leadscrews. With homing and positioning solved to +/- 5 microns, I found what I hope is the last weakest-link devil-detail, which is automatic tool calibration. Everthing there is a factor: tools, toolholders, quick-change posts, fixtures. That's a lot of links in a weakest-link regime.

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)

And yes, I'm no expert but I remember enough from my 1970's engineering to know precision is not simple to achieve with each tolerance having a multiplier affect.

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.