Ball screw mapping details question -SOLVED

Hi all

How does the ballscrew mapping work ?

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?

So say at 10mm I was reading 10mm true, commanded 11 and got 11.5 then commanded 12 and got 12.9. Would it assume each .1 of a mm was in fact .15 of a mm between commanded 10-11mm and that between 11-12mm each .1mm was.19mm?

Jools

tommylight wrote:

Are you sure your screws are not imperial ?

Very sure. The question uses hypothetical measurements and readings. I just wanted to explain things easy.

jools wrote:

How does the ballscrew mapping work ?

The concept is sound but in LinuxCNC imperfectly implemented.

My opinion is that the error characteristic must be automatically generated such as with an automatic scan via a G-code program reading a DRO scale. Manually surveying a useful amount of error data is impractical (hundreds or thousands of samples), especially if you consider that any survey is instantly invalidated by any trivial budge in the machine bearings, ways, or table assembly.

There's also a bigger problem of compensation being predicated on having a precise, repeatable homing to the same accuracy as your compensation goal. The compensation table is necessarily indexed relative to the homed position, and if the homing is not repeatable to the precise non-linearity you're attempting to correct, then the basic principle is useless. So you need a flawless automatic homing, otherwise you have to manually dial-indicate the home position on every start-up. The weakest-link principle applies, and there are a lot of links in the absolute positioning chain.

Backlash and hysteresis are the big devil. You can't compensate an open-loop system more precisely than the worst-case hysteresis. Hysteresis in ordinary ballscrews is around 0.003in, and if you can afford the $$$$ for a better ballscrew, then it won't need compensation.

See my comments in these threads from earlier this year:

Possible error in logic of LinuxCNC homing with leadscrew compensation

Lead-screw Compensation

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.