Possible to automatically compensate for irreguarities on the XY plane?

I gave this more thought cycling home from work, and reckon that there should be a Python front-end which either does the probing there and then, or loads a file. Then it can be a well-defined square grid, to make life easier.
A good application of this would be engraving uneven surfaces, jog the probe to the corners of the area to be probed, hit a GUI button, run the probe sequence, load the height map, engrave away.

Yeah if the hardware exists. In python I store the numpy data array in a python pickle file and 10,000 (100x100 grid) sample points is less than 100kb. It’d be good to have no constraints on grid size. Keeping things in python to extrapolate a given height position allows you to leverage scipy and all the many interpolation options it has.

I’m running a build of LinuxCNC that got pushed to the Debian packages and it’s running python3. I wouldn’t be caught dead writing python2 these days.

I’m really interested in trying to get this working in LinuxCNC because it would allow you through software to improve the capabilities of a machine through further calibration. You could run it like the 3d printers do with automatic bed leveling for engraving or you could give it a calibration map with more points and that would be used for more conventional cnc machining.

If such a thing were to be integrated into linuxcnc, it would be good if it could be overwritten easily as to how the data acquisition works. For instance I use a second computer running windows and a python tool that solely is made to read the webcam sensor values of the laser position. That way I don’t overload the processing power on the linuxcnc machine. The tool driving linuxcnc remotely really just wraps gcode in python with some extra steps where it requests sample data from the other computer over a socket connection. Then it controls LinuxCNC with MDI commands.


I’ll have to sit down and read through what scotta got working with the code on github. I’ve never tried python component in linuxcnc but it looks like it could be a good starting off point.

I’ve got a bunch of changes (software and hardware) that should improve the way I’m taking samples. I also think adding a sensitive temp sensor and including those data points with time could allow me to correct for thermal expansion drift that I find happens. The machine takes 2-3 hours to take 100x100 samples and that is enough time to warm up the garage and all the metal parts.

I’m not sure how out-of-flat my XY plan of my cnc machine is. I’ll probably run a high number of samples over the entire work area just to get a clearer picture of it and reduce the numpy array size after if necessary.

bhowiebkr wrote:

Keeping things in python to extrapolate a given height position allows you to leverage scipy and all the many interpolation options it has.

Yes, but the actual offset value _must_ be calcuated in Realtime, and that means in C in a realtime HAL component. 

Python HAL components are _always_ non-realtime. 

 

@ andy

Just out of interest:

it would not be too unmanageable to pass a set of XYZ probe points in as a parameter array (max 4096 characters)

I guess this would not be enough to pass 10'000 Z values (even if we could somehow use the array position to represent the xy position)?

On the other hand 'classicladder' seems to manage to load fairly substantial 'clp' files. But I assume that is not kept in shared memory?

I think that the trick would be to load a C strict with the X and Y axis breakpoints and an array of Z heights.

If you were probing a part for engraving then the X breakpoints might be
0, 100, 105, 110, 115, 120, 125, 130, 400
2D interpolation of such a map is something that vehicle ECUs do millions of times a second, and it's pretty simple code.

So the realtime part is simple.