pcb2gcode-devel

Re: [Pcb2gcode-devel] autoleveller

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

Hello Nicola,

 with those changes LinuxCNC accepts the NGC output here as well.

I tried the autoleveller superficially in the LinuxCNC simulator (probe
close is a button) but not on the real mill yet. It seems to interpolate
the tracks well so far, however the initial Z-move after the rapid x/y
to the start of a chain is produced directly in ngc-exporter.cpp:344 and
is not interpolated from the probed Z positions:

[...]
G0 Z0.25000 ( Move Z to safe height )
(PROBECLOSE) ( Close the probe log file )
( Probing has ended, each Z-coordinate will be corrected with a bilinear
interpolation )
(MSG, detach the probe tool)
M0 ( Temporary machine stop. )

M3 ( Spindle on clockwise. )
G04 P0 ( dwell for no time -- G64 should not smooth over this point )
G00 Z0.25000 ( retract )

G00 X2.12901 Y2.17717 ( rapid move to begin. )
==> G01 Z-0.00100   <==
G04 P0 ( dwell for no time -- G64 should not smooth over this point )
o1000 call [#<_0_1>] [#<_1_1>] [#<_0_0>] [#<_1_0>] [2.17717] [2.12901]
[...]


I like the autoleveller feature a lot. Previously I worked with
pcb-gcode for Eagle and a self written tool that generated probe g-code
and accepted the probe log in a second run to modify the z moves in the
pcb-gcode output. That's obviously complicated because files have to be
copied around during the job, so the interpolation within the g-code is
much more elegant. Now that I decided to switch to kiCad, this comes in
perfectly on time, thanks :-).

When I started experimenting with the probing, I noticed that there is a
temperature (?) drift of ~0.1mm if I start the probing several times
after initially powering on the mill. It stabilized after 5~10min of
operation, the second and 3rd probing run produce similar results but
the 1st and second don't. I wonder whether that is just a bug of my
homegrown mill or happens elsewhere, too.
I do need a lot of probing points by the way because I use cheap and
bit-friendly FR2 baseboard. It is not level at all and too flexible to
pin larger pieces down perfectly.

Bye,

 Mathias


On 31.01.2015 17:38, Nicola Corna wrote:
> I've added both solutions in commits 118a9af7d27049b4fdfda8723d2d0bb5349f51c4 and 4bc07773f3c0945a2ca1729eb871f90c621f47a7
> Your patch should fix every bad point and, if it does not work, my patch should still make a correct gcode
> I've tested your gerber's output with LinuxCNC and everything seems to be ok, can you confirm it?
> Can you please tell me if the autoleveller works for you? It's still experimental and any feedback is very appreciated
> Thanks
>
> Nicola Corna
>

Re: [Pcb2gcode-devel] autoleveller

[Nicola C. <ni...@co...>]

You're welcome!
I've pushed a commit (ba90eac95d503952f5f35b5a095a0dc0e1fa9917) that fixes that bug. Now also the 1st point of the chain has interpolation.
That ~0.1mm is curious... I don't have a probe tool yet, I'll let you know when I get it.

Nicola Corna

1 Febbraio 2015 23:15, "Mathias Katzer" <mk...@gm...> wrote:

> Hello Nicola,
> 
> with those changes LinuxCNC accepts the NGC output here as well.
> 
> I tried the autoleveller superficially in the LinuxCNC simulator (probe
> close is a button) but not on the real mill yet. It seems to interpolate
> the tracks well so far, however the initial Z-move after the rapid x/y
> to the start of a chain is produced directly in ngc-exporter.cpp:344 and
> is not interpolated from the probed Z positions:
> 
> [...]
> G0 Z0.25000 ( Move Z to safe height )
> (PROBECLOSE) ( Close the probe log file )
> ( Probing has ended, each Z-coordinate will be corrected with a bilinear
> interpolation )
> (MSG, detach the probe tool)
> M0 ( Temporary machine stop. )
> 
> M3 ( Spindle on clockwise. )
> G04 P0 ( dwell for no time -- G64 should not smooth over this point )
> G00 Z0.25000 ( retract )
> 
> G00 X2.12901 Y2.17717 ( rapid move to begin. )
> ==> G01 Z-0.00100 <==
> G04 P0 ( dwell for no time -- G64 should not smooth over this point )
> o1000 call [#<_0_1>] [#<_1_1>] [#<_0_0>] [#<_1_0>] [2.17717] [2.12901]
> [...]
> 
> I like the autoleveller feature a lot. Previously I worked with
> pcb-gcode for Eagle and a self written tool that generated probe g-code
> and accepted the probe log in a second run to modify the z moves in the
> pcb-gcode output. That's obviously complicated because files have to be
> copied around during the job, so the interpolation within the g-code is
> much more elegant. Now that I decided to switch to kiCad, this comes in
> perfectly on time, thanks :-).
> 
> When I started experimenting with the probing, I noticed that there is a
> temperature (?) drift of ~0.1mm if I start the probing several times
> after initially powering on the mill. It stabilized after 5~10min of
> operation, the second and 3rd probing run produce similar results but
> the 1st and second don't. I wonder whether that is just a bug of my
> homegrown mill or happens elsewhere, too.
> I do need a lot of probing points by the way because I use cheap and
> bit-friendly FR2 baseboard. It is not level at all and too flexible to
> pin larger pieces down perfectly.
> 
> Bye,
> 
> Mathias
> 
> On 31.01.2015 17:38, Nicola Corna wrote:
> 
>> I've added both solutions in commits 118a9af7d27049b4fdfda8723d2d0bb5349f51c4 and
>> 4bc07773f3c0945a2ca1729eb871f90c621f47a7
>> Your patch should fix every bad point and, if it does not work, my patch should still make a
>> correct gcode
>> I've tested your gerber's output with LinuxCNC and everything seems to be ok, can you confirm it?
>> Can you please tell me if the autoleveller works for you? It's still experimental and any
> 
> feedback 
>> is very appreciated
>> Thanks
>> 
>> Nicola Corna

Re: [Pcb2gcode-devel] autoleveller

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

Hello,

 I milled a board with 'autolevelling' today and the result was quite
nice. However I had to change a few things beforehand:

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:

diff --git a/autoleveller.cpp b/autoleveller.cpp
index e9e30c9..a44c63c 100644
--- a/autoleveller.cpp
+++ b/autoleveller.cpp
@@ -196,20 +196,21 @@ void autoleveller::probeHeader( std::ofstream &of,
double zprobe, double zsafe,
 string autoleveller::interpolatePoint ( icoordpair point ) {
     int xminindex;
     int yminindex;
-    double x_minus_x0;
-    double y_minus_y0;
+    double x_minus_x0_rel;
+    double y_minus_y0_rel;
    
     xminindex = floor ( ( point.first - startPointX ) / XProbeDist );
     yminindex = floor ( ( point.second - startPointY ) / YProbeDist );
-    x_minus_x0 = point.first - startPointX - xminindex * XProbeDist;
-    y_minus_y0 = 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;
    
+    //    std::cerr << "IPP " << xminindex << "," << yminindex << " "
<< XProbeDist << "," << YProbeDist << " " << x_minus_x0 << "," <<
y_minus_y0 << "\n";
     return str( boost::format( callSub[software] ) %
BILINEAR_INTERPOLATION_MACRO_NUMBER %
                                                       getVarName(
xminindex, yminindex + 1 ) %
                                                       getVarName(
xminindex + 1, yminindex + 1 ) %
                                                       getVarName(
xminindex, yminindex ) %
                                                       getVarName(
xminindex + 1, yminindex ) %
-                                                      y_minus_y0 %
x_minus_x0 );
+                                                      y_minus_y0_rel %
x_minus_x0_rel );
 }

The "_x_y"-Variables are only Z coordinates, so the #5 and #6 in the
macro below must be relative positions (from [0,1]) within a rectangle
of probe points:

o1000 sub ( Bilinear interpolation macro )
#7=[#3+[#1-#3]*#5] ( Linear interpolation of the x-min elements )
#8=[#4+[#2-#4]*#5] ( Linear interpolation of the x-max elements )
#100=[#7+[#8-#7]*#6] ( Linear interpolation of previously interpolated
points )
o1000 endsub


The second change I made is not really related to autolevelling, but the
'optimization'. Initially I got 14Mb of G-Code for the bottom layer of
my test board. It's 90x55mm and is not very dense. I run the
'machinekit' offspring of linuxcnc on a Beaglebone Black to control the
mill - the step timing is so much more precise (and the machine quieter
and faster) with the hardware generated step timing. However 160k lines
of G-Code in 'Axis' is no fun on a 512Mb ARM system.
The largest board I milled with the Eagle-pcbgcode-Toolchain was
~100x80mm large and had much more components on it, and it used
~550kByte / 16k lines of G-Code.

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. 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.
With 'simplifypath' enabled I got ~680k of G-Code.

Regards,
 Mathias



On 02.02.2015 22:57, Nicola Corna wrote:
> You're welcome!
> I've pushed a commit (ba90eac95d503952f5f35b5a095a0dc0e1fa9917) that fixes that bug. Now also the 1st point of the chain has interpolation.
> That ~0.1mm is curious... I don't have a probe tool yet, I'll let you know when I get it.
>
> Nicola Corna
>
> 1 Febbraio 2015 23:15, "Mathias Katzer" <mk...@gm...> wrote:
>
>> Hello Nicola,
>>
>> with those changes LinuxCNC accepts the NGC output here as well.
>>
>> I tried the autoleveller superficially in the LinuxCNC simulator (probe
>> close is a button) but not on the real mill yet. It seems to interpolate
>> the tracks well so far, however the initial Z-move after the rapid x/y
>> to the start of a chain is produced directly in ngc-exporter.cpp:344 and
>> is not interpolated from the probed Z positions:
>>
>> [...]
>>
>> Can you please tell me if the autoleveller works for you? It's still experimental and any
>> feedback 
>>> is very appreciated
>>> Thanks
>>>
>>> Nicola Corna
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Pcb2gcode-devel mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel

Re: [Pcb2gcode-devel] autoleveller

[Nicola C. <ni...@co...>]

> 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

> 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

> 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.

Nicola Corna

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

Re: [Pcb2gcode-devel] autoleveller

[Nicola C. <ni...@co...>]

> Could you check that commit once again, please ? I'm afraid
> 91dcdf40835a62af94a639e277d6397859ba15e4 just renamed variables.
My bad... To keep the history clean I had to do a rebase; sorry!
Now the commit is c962e7bb53aedaf28dcc9600b07fa77f1d6d6c16

> 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.
I've also noticed that the code for simplifypath was created by Bernhard Kubicek in commit b49f0f1f70dfc0ad7c31fb8a250dc85b3a9ff361 in 2010, and no one has modified it since then. He also has his fork of pcb2gcode (https://github.com/bkubicek/pcb2gcode), but I don't think that a pull from him is a good idea, the repo changed a lot since his last commit (2012) and the current simplifypath function works well enough without the need of a merge with an unmaintained repo.

I've done some tests on my gerber file, here's are the sizes of the front output gcode:
no optimization: 432 KB
"optimise" optimization: 245 KB
simplifypath optimization: 27 KB
both: 27 KB
A diff between "simplifypath optimization" and "both" returns that the two files are identical, therefore the optimise code should be completely redundant. In the simulator, the simplifypath's output seems to be ok, the only thing that doesn't work is the "bridge" option (with simplifypath enabled only 2 bridges of 4 are created, I'll work on it).
I hadn't tested autoleveller + simplifypath yet.

If we fix this bug, do you think it's reasonable to remove the current optimise code and replace it with simplifypath?

Nicola

Re: [Pcb2gcode-devel] autoleveller

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

On 07.02.2015 18:18, Nicola Corna wrote:
>>  --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.
> I've also noticed that the code for simplifypath was created by Bernhard Kubicek in commit b49f0f1f70dfc0ad7c31fb8a250dc85b3a9ff361 in 2010, and no one has modified it since then. He also has his fork of pcb2gcode (https://github.com/bkubicek/pcb2gcode), but I don't think that a pull from him is a good idea, the repo changed a lot since his last commit (2012) and the current simplifypath function works well enough without the need of a merge with an unmaintained repo.
>
> I've done some tests on my gerber file, here's are the sizes of the front output gcode:
> no optimization: 432 KB
> "optimise" optimization: 245 KB
> simplifypath optimization: 27 KB
> both: 27 KB
> A diff between "simplifypath optimization" and "both" returns that the two files are identical, therefore the optimise code should be completely redundant. In the simulator, the simplifypath's output seems to be ok, the only thing that doesn't work is the "bridge" option (with simplifypath enabled only 2 bridges of 4 are created, I'll work on it).
> I hadn't tested autoleveller + simplifypath yet.
>
> If we fix this bug, do you think it's reasonable to remove the current optimise code and replace it with simplifypath?
From my (little) experience with both I would say yes.
A little test checking the precision on sample files would give some
more confidence.

Bye

 Mathias