Re: [Pcb2gcode-devel] autoleveller

[Mathias K. <mk...@gm...>]

Hello Nicola,

On 06.02.2015 12:18, Nicola Corna wrote:
>> Firstly, I think I found another issue with the interpolation. It was
>> only correct with 4 probe points in 1in distance, here is a patch to
>> correct it:
> Committed, thanks
Could you check that commit once again, please ? I'm afraid
91dcdf40835a62af94a639e277d6397859ba15e4 just renamed variables. This is
what is left comparing HEAD against my local files:

204,205c204,205
<     x_minus_x0_rel = point.first - startPointX - xminindex * XProbeDist;
<     y_minus_y0_rel = point.second - startPointY - yminindex * YProbeDist;
---
>     x_minus_x0_rel = (point.first - startPointX - xminindex *
XProbeDist) / XProbeDist;
>     y_minus_y0_rel = (point.second - startPointY - yminindex *
YProbeDist) / YProbeDist;

>> The huge size is due to 'trivial G-Code' stemming from the outline
>> bitmap tracing. The 'optimise' command line option does not completely
>> remove the redundant steps. There is something similar in surface.cpp
>> around line 226, the 'simplifypath'-method. Switching that on and
>> setting the accuracy argument to 1/dpi dramatically reduces the file
>> size while keeping sufficient precision.
> Did you also activated the optimise switch? Does "simplifypath" includes all the optimizations done by "optimise"? I've never looked inside that part of code.
> I think that 2.0/dpi is a better choice, because the default g64 is 2.0/dpi and lower precisions are ignored by the CNC controller
Yes I did. But as predicted in the help text, --optimise does not reduce
the file size more than ~40%, because it just removes the redundant
intermediate positions
along vertical and horizontal moves. The paths for 45 degree traces and
pads are rectangular step curves, --optimise does not touch them because
adjacent segments
are short but perpendicular.

'simplifypath' is somewhat different from 'optimise':

        //take two points of the path
        // and their interconnecting path.
        // if the distance between all intermediate points and this line
is smaller
        // than the accuracy, all the points in between can be removed..

- If it really does what is advertised, I did not check that.

At least it does not only merge adjacent segments as 'optimise'.

I fully agree on the precision calculation - computing it all in terms
of dpi sounds good as well, so there is only one handle to turn.

>> There is one issue left:
>> simplifypath does not know about the autoleveller and can generate very
>> long moves crossing several cells of the probing grid. One should break
>> those long moves to interpolate at the cell boundaries.
> I've already created a function for that purpose: autoleveller.cpp, line 225
>
> subsegments = splitSegment( point, numOfSubsegments( point ) );
>
> This function splits a single segment in subsegments with a length of ~X(Y)ProbeDist, therefore any optimization shouldn't have any negative effect on autoleveller. Of course it increases the size, but we can't do much for that, if we want z-correction we need a bigger gcode.

That's great, I did not spot it.

 Bye
   Mathias