pcb2gcode-devel

[Pcb2gcode-devel] Won't create voronoi toolpath

[Christopher G. <su...@c-...>]

Hi!
I just cloned from the git repository about an hour ago. Latest commit is:
commit 7ca468cd8995926a03e26a6210daa43f56f64e7a
Author: Patrick Birnzain <pbi...@us...>
Date:   Tue Jul 5 11:15:22 2011 +0200

It compiled fine but the .ngc files it produces are almost empty (only 
the outline file actually does something) and no voronoi toolpath is 
created (judging from the .pngs, as the ngc files for back and front 
don't do anything), regardless of option offset's value.

Cheers,
Chris

Re: [Pcb2gcode-devel] Won't create voronoi toolpath

[Patrick B. <pbi...@us...>]

Hi,

pcb2gcode accepts board outlines as
	a) polygons that describe the exact shape or
	b) a sequence of lines and arcs of constant width that outline the board shape

b) is what most people want, but a) is the default. If you have drawn your board outline with e.g. 5mil thick lines, you can tell pcb2gcode about that by adding "--fill-outline --outline-width=0.005". If you don't do that, it will think your board shape is a 10 mil thin shape with a big hole in it, and since your traces don't seem to be on the board, they won't be engraved.

a) and b) needed to be treated differently because we originally planned to support boards with holes.
I will soon improve b) so it works with --outline-width=0, make b) the default and drop a) altogether or at least deactivate it.
Since all of this is documented very badly or not at all and apparently many users had that exact same problem that you have this will be the next thing I'll do when I work on pcb2gcode.

-- Patrick

Re: [Pcb2gcode-devel] Won't create voronoi toolpath

[Christopher G. <su...@c-...>]

Thanks a lot!
Works fine now. The drill file's name defaults to drill.ngc.ngc instead 
of drill.ngc but I guess you know that already :)

Chris

Re: [Pcb2gcode-devel] Won't create voronoi toolpath

[Christopher G. <su...@c-...>]

Am 12.08.2011 00:25, schrieb Christopher Gabriel:
> Thanks a lot!
> Works fine now. The drill file's name defaults to drill.ngc.ngc 
> instead of drill.ngc but I guess you know that already :)
>
> Chris
Fix attached.

Chris

[Pcb2gcode-devel] Problem with --basename and current HEAD (getopt vs program options)

[Christopher G. <chr...@st...>]

Am 2011-08-12 16:12, schrieb Patrick Birnzain:
>
> Good to hear it works for you now, if there are any further problems
> let me know.
>
> -- Patrick
As a matter of fact, I did run into another problem.
I just wanted to try and recreate it again on another machine and cloned 
the repository again. With the current version options are ignored (e.g. 
metric) and, to make it short, nothing is working any more.

With the "old version" (just before I applied the .ngc.ngc path) 
everything worked fine, as mentioned but then I found a strange bug. I 
wanted to have two different sets of G code files. One with normal 
traces and one with voronoi paths. I thus ran the program once with 
--basename voronoi, which worked fine, and once with --basename normal, 
which caused the program to crash. The funny thing is that it only 
crashes if the option's value is normal (case insensitive). norma, 
normall and the like work fine. I traced it down to line 84 of drill.cpp 
(program option's parse function) but haven't had a closer look at it 
yet. Might not be your fault :)
Besides, since --basename only applies to the G code files and not to 
the .PNGs, it would be nice to have an option like --basedir, to move 
the entire output (.NGCs and .PNGs) to another directory.

Chris

Re: [Pcb2gcode-devel] Problem with --basename and current HEAD (getopt vs program options)

[Patrick B. <pbi...@us...>]

> As a matter of fact, I did run into another problem.
> I just wanted to try and recreate it again on another machine and cloned
> the repository again. With the current version options are ignored (e.g.
> metric) and, to make it short, nothing is working any more.
>
> With the "old version" (just before I applied the .ngc.ngc path)
> everything worked fine, as mentioned but then I found a strange bug. I
> wanted to have two different sets of G code files. One with normal
> traces and one with voronoi paths. I thus ran the program once with
> --basename voronoi, which worked fine, and once with --basename normal,
> which caused the program to crash. The funny thing is that it only
> crashes if the option's value is normal (case insensitive). norma,
> normall and the like work fine. I traced it down to line 84 of drill.cpp
> (program option's parse function) but haven't had a closer look at it
> yet. Might not be your fault :)
> Besides, since --basename only applies to the G code files and not to
> the .PNGs, it would be nice to have an option like --basedir, to move
> the entire output (.NGCs and .PNGs) to another directory.
>
> Chris

I switched to getpot because program_options apparently couldn't handle
flags in config files. Turns out it can, it's just not documented, you have
to write "flag=yes".
GetPot worked for me except for the typo warnings,
but anyway, boost::program_options is back.

I was able to reproduce the --basename error, I think it happens only if the
basename is exactly 6 characters long, I'll look into that further.

--basename, --front-output, --back-output etc. were written by some
guys over @ metalab.at, and I've never needed them, so there's little
incentive for me to improve the program in that respect.
Of course, I'd be happy to accept contributions.
Maybe it makes sense to extend --basename to allow subdirectories
instead of introducing another option:
pcb2gcode --basename='voronoi/output'

-- Patrick

Re: [Pcb2gcode-devel] Won't create voronoi toolpath

[Patrick B. <pbi...@us...>]

> > Thanks a lot!
> > Works fine now. The drill file's name defaults to drill.ngc.ngc 
> > instead of drill.ngc but I guess you know that already :)
> >
> > Chris
> Fix attached.
> 
> Chris

Actually, I didn't know about that because it only happens when
--milldrill is used, and I never do that.

Thanks for your patch, it's already in the git repo, and I'll update
the tarball shortly.

Good to hear it works for you now, if there are any further problems
let me know.

-- Patrick