pcb2gcode-devel

[Pcb2gcode-devel] autoleveller

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

Hello,

  I got broken NGC output when trying the autoleveller with a specific
Gerber file created in KiCad.

It is because some pad in the Gerber file sticks out by ~0.01in from the
bounding box returned by the importer.

For myself I enlarged the probing area by one ProbeDist in both
coordinates. Of course that does not solve the root of the problem, but
adds robustness. I guess the actual bug is in gerbv or kicad - don't
know yet.

If you wish I can provide the Gerber file and / or patches

  Mathias

Re: [Pcb2gcode-devel] autoleveller

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

I don't like your solution, it forcefully increases the area, especially when there are only 4 probing points at each angle
Since the problematic points are very close to the border, we can simply do a linear interpolation of the closest points
Send me your Gerber file, I'll use it as a test
Thanks for your bug report

Nicola Corna

30 Gennaio 2015 12:27, "Mathias Katzer" <mk...@gm...> wrote: 
> Hello,
> 
> I got broken NGC output when trying the autoleveller with a specific
> Gerber file created in KiCad.
> 
> It is because some pad in the Gerber file sticks out by ~0.01in from the
> bounding box returned by the importer.
> 
> For myself I enlarged the probing area by one ProbeDist in both
> coordinates. Of course that does not solve the root of the problem, but
> adds robustness. I guess the actual bug is in gerbv or kicad - don't
> know yet.
> 
> If you wish I can provide the Gerber file and / or patches
> 
> Mathias
> 
> ------------------------------------------------------------------------------
> 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

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

Hello Nicola,

 yes of course it is a bad hack as I wrote.

So I wanted to know what is really going on and found out the size of
the error corresponds to the value of the 'dpi' option. Therefore I
believe it could just be quantisation error from the outline bitmap in
surface.cpp.
The patch below fixes the issue for me ( again it enlarges the probe
area, but only 4 dots of the outline bitmap this time ). Your
extrapolation proposal might even be better because it does not assume
so much about the max. possible error, but I'm not into the pcb2gcode
code enough to do it right now.

diff --git a/board.cpp b/board.cpp
index c8c1f9b..b9a673f 100644
--- a/board.cpp
+++ b/board.cpp
@@ -119,10 +119,10 @@ void Board::createLayers() {
             shared_ptr<Isolator> trace_mill =
boost::static_pointer_cast<Isolator>(prepared_layers.at("front").get<1>());
             ivalue_t radius = trace_mill->tool_diameter / 2;
             int passes = trace_mill->extra_passes + 1;
-            min_x -= radius * passes;
-            max_x += radius * passes;
-            min_y -= radius * passes;
-            max_y += radius * passes;
+            min_x -= radius * passes+2./dpi;
+            max_x += radius * passes+2./dpi;
+            min_y -= radius * passes+2./dpi;
+            max_y += radius * passes+2./dpi;
         }
         catch( std::logic_error& e ) {
             min_x -= margin;

Bye,

  Mathias


On 30.01.2015 15:07, Nicola Corna wrote:
> I don't like your solution, it forcefully increases the area, especially when there are only 4 probing points at each angle
> Since the problematic points are very close to the border, we can simply do a linear interpolation of the closest points
> Send me your Gerber file, I'll use it as a test
> Thanks for your bug report
>
30 Gennaio 2015 12:27, "Mathias Katzer" <mk...@gm...> wrote:
>> It is because some pad in the Gerber file sticks out by ~0.01in from the
>> bounding box returned by the importer.
>>
>> For myself I enlarged the probing area by one ProbeDist in both
>> coordinates. Of course that does not solve the root of the problem, but
>> adds robustness. I guess the actual bug is in gerbv or kicad - don't
>> know yet.
>>

Re: [Pcb2gcode-devel] autoleveller

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

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

31 Gennaio 2015 15:17, "Mathias Katzer" <mk...@gm...> wrote: 
> Hello Nicola,
> 
> yes of course it is a bad hack as I wrote.
> 
> So I wanted to know what is really going on and found out the size of
> the error corresponds to the value of the 'dpi' option. Therefore I
> believe it could just be quantisation error from the outline bitmap in
> surface.cpp.
> The patch below fixes the issue for me ( again it enlarges the probe
> area, but only 4 dots of the outline bitmap this time ). Your
> extrapolation proposal might even be better because it does not assume
> so much about the max. possible error, but I'm not into the pcb2gcode
> code enough to do it right now.
> 
> diff --git a/board.cpp b/board.cpp
> index c8c1f9b..b9a673f 100644
> --- a/board.cpp
> +++ b/board.cpp
> @@ -119,10 +119,10 @@ void Board::createLayers() {
> shared_ptr<Isolator> trace_mill =
> boost::static_pointer_cast<Isolator>(prepared_layers.at("front").get<1>());
> ivalue_t radius = trace_mill->tool_diameter / 2;
> int passes = trace_mill->extra_passes + 1;
> - min_x -= radius * passes;
> - max_x += radius * passes;
> - min_y -= radius * passes;
> - max_y += radius * passes;
> + min_x -= radius * passes+2./dpi;
> + max_x += radius * passes+2./dpi;
> + min_y -= radius * passes+2./dpi;
> + max_y += radius * passes+2./dpi;
> }
> catch( std::logic_error& e ) {
> min_x -= margin;
> 
> Bye,
> 
> Mathias
> 
> On 30.01.2015 15:07, Nicola Corna wrote:
> 
>> I don't like your solution, it forcefully increases the area, especially when there are only 4
>> probing points at each angle
>> Since the problematic points are very close to the border, we can simply do a linear
> interpolation
>> of the closest points
>> Send me your Gerber file, I'll use it as a test
>> Thanks for your bug report
> 
> 30 Gennaio 2015 12:27, "Mathias Katzer" <mk...@gm...> wrote:
> 
>>> It is because some pad in the Gerber file sticks out by ~0.01in from the
>>> bounding box returned by the importer.
>>> 
>>> For myself I enlarged the probing area by one ProbeDist in both
>>> coordinates. Of course that does not solve the root of the problem, but
>>> adds robustness. I guess the actual bug is in gerbv or kicad - don't
>>> know yet.