ScottA's Compensation Component for Uneven Table (was "Probekins"?)

Not having enough trouble already, I decided to "customize" my AXIS display by adding a "checkbutton" and an LED to toggle Z-compensation ON and OFF and show its status.  (I did it less from deep understanding and more from the tried-and-troo monkee-see-monkee-doo.)  Details are here .

Incidentally, one has to take care with the formatting of the 'probe-results.txt' if created by hand. My attempts to "prettify" the results, by adding spaces to line up columns, to make them more "readable" had the effect of causing, I theorize, of 'compensation.py' to interpret the numbers as strings leading to failure. Files created with probing G-code typically won't have this problem, but numbers should be separated by a single space.

Also, I noticed that 'compensation.py' finds the extrema of the extents (min-max X-Y) but then truncates them to integers before fitting a surface to the gridpoints. I don't know what if any effect this would have on the effect, but I point it out. In my case, 8.75 inches gets rounded to 8, a fairly substantial change. I'll take my next measurements only on integer bounds.

The filename for the probed points, 'probe-results.txt', can be changed in the .hal file. (I use compensation.gridpoints to associate it more closely with compensation.py and keep both in the config/ folder for the machine that will use compensation.)

Python codes to visualize the compensation surface can be downloaded from scotta's github site for the purpose :
probe2stl[.py]
stlvis[.py]

and used like this:
% ./probe2stl < probe-results.txt | ./stlvis [-b xmin,ymin,xmax,ymax]
giving you something like the attached. NB yellow is high, dark-blue is low.

One More Thing: I'm in the habit of picking Z=0 at the lowest spot on the stock because in my application I'm going to carve away the entire top anyway.  I'm interested in using 'compensation.py' in this instance because the curvature is so radical it would require a loss of too much material, and compensation appears to offer "terrain-following", bending the model to fit the stock.

However, before probing I instinctively set Z=0 to the lowest spot on the stock, which happened to be the lower left-hand corner, and then recorded the Z values at every other point on the grid RELATIVE to that zero.  My MODEL ZERO on the other hand is in the exact center of the stock, and I suspect that the probe-results.txt file should have its Z=0 at the same point, with every other Z-value measured and recorded relative to that. 

Otherwise--I'm trying to get my head around it--IF the center of the stock is higher than the LLH corner AND I zero the model at the center of the stock, THEN when compensation is enabled, LinuxCNC will make NO adjustments in Z at the LLH corner, which is lower than the center, thus cutting too high, and will adjust Z higher when it gets to the center because the compensation surface is higher there than the LLH corner, thus also cutting too high.

I think I've convinced myself that, yes, the probe-results.txt data need to have Z=0 at the model origin. (OTOH, given ten more minutes I could convince myself of nearly anything.)

clunc wrote:

Also, I noticed that 'compensation.py' finds the extrema of the extents (min-max X-Y) but then truncates them to integers before fitting a surface to the gridpoints. I don't know what if any effect this would have on the effect, but I point it out. In my case, 8.75 inches gets rounded to 8, a fairly substantial change. I'll take my next measurements only on integer bounds. 
 

To try to address this, I went back and re-took Z-measurements at top-of stock on a 3x3 matrix: x={-8,0, 8}, y={-10,0, 10} to compare with the original, measured on x={-8.75,0, 8.75}, y={-10,0, 10}.

I visualized the results of each with:
./probe2stl < probe-results.txt | ./stlvis -b -8,-10,8,10
so that both were scaled to the same x-axis, and saved the results off to separate .png files for import into GIMP, the graphics editor.

Inside GIMP I subtracted one image from the other which, surprising to me, showed virtually no difference in the surfaces matched.  Even the color legend matched perfectly. I sense a slight difference along the left and right edges. These are the first three figures.

I also measured Z values on a 5x5 grid x={-8,-4,0,4,8} and y={-10,-5,0,5,10} and generated its plot and diff, attached as the last two figures. The differences between the 3x3 grid and the 5x5 are more pronounced, as could probably be predicted from the difference in granularity.

After I had started G-code run, I aborted it after about 10 minutes because I didn't have a sense that the compensation was working. I don't blame the code, but my greatly under-populated sampling grid (25 gridpoints as compare to--likely--dozens if not hundreds).

I ended up being able to cut without compensation, but I'm looking forward to getting a good touchprobe and trying again.