pcb2gcode-devel — PCB to Gcode - Developers

Re: [Pcb2gcode-devel] Avoiding of milling the traces twice

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

On Wed, 16 Nov 2011 21:56:40 +0100
Filip Dominec <fil...@gm...> wrote:

Hi Filip,

good to hear it works for you.
My machine has play-free guides and actuators, so repeatability is not
an issue for me (even with 0.5mm pitch TQFP ICs).

I've been thinking about the optimisation you propose, but I don't see
any work on it from my side happen anytime soon (not this year), I'd
rather improve --extra-passes.

Internally, pcb2gcode represents toolpaths as huge lists of coordinates
(icoords; coordinate list using inches), and for each layer a list of
toolpaths is created. That list is passed down from the "Surface" class
that does the image processing to "Layer", "Board" and then an
"Exporter".

I think Layer::get_toolpaths() could be a good starting point here.
Might even be not that much effort.

If you get something to work, I'm always happy to accept patches ;-)

-- Patrick


> Hi, I have succesfully tested pcb2gcode on my home-build PCB milling
> robot and it works great, except for one issue. I use the Voronoi
> feature and I need that no path is milled twice. 
> 
> Not only the double-pass of almost all traces doubles the manufacture
> time, but also the second pass sometimes wipes off the subtle 
> connections for SOIC circuits due to little imprecision of my machine. 
> 
> What should I do to help fix this? Is some work underway or should I
> download the sources and begin experimenting with the code?
> Filip Dominec
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Pcb2gcode-devel mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel

[Pcb2gcode-devel] Avoiding of milling the traces twice

[Filip D. <fil...@gm...>]

Hi, I have succesfully tested pcb2gcode on my home-build PCB milling
robot and it works great, except for one issue. I use the Voronoi
feature and I need that no path is milled twice. 

Not only the double-pass of almost all traces doubles the manufacture
time, but also the second pass sometimes wipes off the subtle 
connections for SOIC circuits due to little imprecision of my machine. 

What should I do to help fix this? Is some work underway or should I
download the sources and begin experimenting with the code?
Filip Dominec

Re: [Pcb2gcode-devel] A simple (I hope) request

[Stefan M. <sm...@4f...>]

On Thu, 2011-09-15 at 14:32 -0500, kqt...@co... wrote:
> > Paint the silkscreen onto the pcb with a pen?
> Exactly

Your PCB tool should also have an export to HPGL or similar. In Eagle
this is easily possible without the indirection of Gerber.

cu, Stefan.

Re: [Pcb2gcode-devel] A simple (I hope) request

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

We can't really process the silk screen like the other layers because
we're trying to do something different here, but libgerbv has an API
that allows us to extract vectors from the silkscreen file...
What you want is a lot of work and I don't think many people would use
that feature if we had it. I can't justify spending that much time on
this myself, sorry.

-- Patrick

Re: [Pcb2gcode-devel] A simple (I hope) request

[<kqt...@co...>]

On Thu, 15 Sep 2011, Patrick Birnzain wrote:

>> As a beginner pcb2gcode has been a great help but I have one request
>> To also create a gcode file for the silkscreen
>> This would add the finishing touch
>>
>> Thanks
>> Richard
>
> Hi Richard,
>
> Welcome to the pcb2gcode mailing list!
>
> What do you want that gcode file to do?
> Paint the silkscreen onto the pcb with a pen?
> I'm not sure what you're trying to accomplish

Exactly

Richard

Re: [Pcb2gcode-devel] A simple (I hope) request

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

> As a beginner pcb2gcode has been a great help but I have one request
> To also create a gcode file for the silkscreen
> This would add the finishing touch
>
> Thanks
> Richard

Hi Richard,

Welcome to the pcb2gcode mailing list!

What do you want that gcode file to do?
Paint the silkscreen onto the pcb with a pen?
I'm not sure what you're trying to accomplish

-- Patrick

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] problems building under Ubuntu 11.04

[Peter U. <pet...@gm...>]

>On Wed, May 11, 2011 at 01:53:22AM -0500, Mark D. Ratzburg wrote:
>> I have been working with Ubuntu for several hours today, getting an install
>> done to try out pcb2gcode. Running into a bit of a glitch when running make:
>>
>> libtool: link: cannot find the library `/usr/lib/libatk-1.0.la' or unhandled
>> argument `/usr/lib/libatk-1.0.la'
>> make[2]: *** [pcb2gcode] Error 1
>> make[2]: Leaving directory `/home/mark/pcb2gcode'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/home/mark/pcb2gcode'
>> make: *** [all] Error 2
>>
>> I agree with make that libatk-1.0.la does not live in /usr/lib. Any ideas on
>> how to fix the issue? I have the same issue if I use git or if I download
>> the tarball.
>
>you need to install the "libatk1.0-dev" package ('sudo apt-get install
>libatk1.0-dev') in order to build pcb2gcode -- however, especially if
>you're new to linux, i recommend not to compile anything yourself at all
>and instead use ready-made packages. those for pcb2gcode are not
>available directly in ubuntu, but can be downloaded from my ppa at>http://launchpad.net/~chrysn/+archive/pcb2gcode <http://launchpad.net/%7Echrysn/+archive/pcb2gcode> -- there, you'll find
>detailled instructions on how to install software from a ppa.
>
>the packages there were built for ubuntu maverick, but should work for
>natty as well.
>
>let me know if there are any problems
>
>chrysn

First time replying to a mailing list topic, so hope it goes well.

I was also trying to install pcb2code on Ubuntu 11.04 and ran into the
same problem. After some help from a more experienced Ubuntu user we
discovered 2 issues.


1. It only searches in the "usr/lib" folder for libraries, and in my
case some where located in "/usr/lib/x86_64-linux-gnu".
We told it to also search into this folder using:
LDFLAGS=-L/usr/lib/x86_64-linux-gnu ./configure

But we kept getting errors. The next thing he tried was removing the
following part from the last part of make and running that part again.
-R/usr/lib

We also added some symbolic links, but I think that unnecessary when
you add this flag to configure.

Hope this helps somebody.

Peter Uithoven

[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] 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

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

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

[Pcb2gcode-devel] A simple (I hope) request

[<kqt...@co...>]

As a beginner pcb2gcode has been a great help but I have one request
To also create a gcode file for the silkscreen
This would add the finishing touch

Thanks
Richard

[Pcb2gcode-devel] Fw: Re: pcb2gcode oddities

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

On Tue, 26 Jul 2011 22:35:31 -0600
John Bump <joh...@gm...> wrote:

> I'm not calling these bugs because the program works, but they might help
> other people who are running into the same problems I ran into and they
> might be things the developers might want to change.  I'm running pcb2gcode
> 1.1.2 on ubuntu 11.04
> 
> 1.  If there's a millproject in the directory, pcb2gcode seems to use it,
> even if it's not asked to.  If I run pcb2gcode --front="front.gbr" [lots of
> options] and I have a millproject around that contains an
> "outline=outline.gbr" line, I get an outline.ngc as well as front.ngc -- and
> in that case it's obvious what's happening, but if the only difference is
> something like offset=0.003 when millproject has an offset=0.010, that's
> more difficult to track down.

The idea was:
* parameter values can be set via arguments on the command line, or placed
  in a config file called "millproject" to save typing
* command line parameters override stuff set in the config file, so you can
  for example run "pcb2gcode --offset=0.05" to quickly try a different offset

This is, however, undocumented.
If you think you have a better idea, shoot! I'll be glad to put it on my
TODO list if it's an improvement.

> 2.  When I run, let's say, "pcb2gcode --front "driver.front.gbr"
> --cutter-diameter 0.004 --zcut 0.007 --cut-feed 10 --cut-speed 20000
> --cut-infeed 0.007 --zsafe 0.025 --mill-speed 20000 --mill-feed 10 --offset
> 0.004 --zchange 2.00 --zwork 0.004" I get a good front.ngc output, with a
> good toolpath.
> If I then run " "pcb2gcode --front "driver.front.gbr" --cutter-diameter
> 0.004 --zcut 0.007 --cut-feed 10 --cut-speed 20000 --cut-infeed 0.007
> --zsafe 0.025 --mill-speed 20000 --mill-feed 10 --offset 0.004 --zchange
> 2.00 --zwork 0.004 --outline "driver.outline.gbr" -- just adding the one
> extra parameter that has it process a second file -- the front.ngc is
> essentially blank.  It has a 5-item preamble, issues a G64, a G04 P0, a G00
> Z2.0000, an M9, and an M2, and that's it.  The same thing happens when I add
> all the relevant parameters for the outline cutter, or if I have a
> driver.back.gbr that I try to isolate along with the front.
> So if I want to get good front and back isolation files I need to run each
> of them separately, and then run the drill and outline files.
> It works just fine when I do that... but since it can process multiple
> files, and produce outputs, it took me a while to figure out why I was
> getting blank front and back isolation layers, which might be confusing to
> other beginners.
> 
> I've had exactly the same thing happen with any millproject file I've used,
> but I haven't actually tried a millproject that just works on one layer at a
> time.
> 
> Anyway.  When I crank out one layer at a time it works great and the output
> is lovely, and it's awesome to be able to mill my own PCB's, so thank you
> very much for making this piece of software.

pcb2gcode <= 0.4.5 used to process each layer individually like you do, but
it was cumbersome to get the layers to align because it was usually necessary 
to reset the machine's coordinate system and do some calculations by hand.
Since 1.0 or so, pcb2gcode can process all files at once and do that
automatically, so you only have to flip the board once.

The problem you most likely have is that pcb2gcode misinterprets your outline
file.
You can read why this happens, how to fix it and why it's all my fault ;-) here:
https://sourceforge.net/mailarchive/message.php?msg_id=27934225

It's nice to hear you like the output, I'm quite content with it myself ;-)
Ease of use could still be improved though, and there's almost zero
documentation. I've wanted to write a tutorial since last year now, but
there's always been someting more urgent to fix, hope I'll get to it sometime.

Again, if you have any ideas on how to improve the program, please share them.

-- Patrick

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

[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

[Pcb2gcode-devel] compiling for Mac

[Joris [v. Tubergen] <jo...@pr...>]

can i download a mac compiled version somewhere...
compiling is quite difficult for a GUI user like me....

or: which file is the 'command file' i can use in terminal... [or is that a
complete stupid question...?!]

cheer\joris

[Pcb2gcode-devel] pcb2gcode oddities

[John B. <joh...@gm...>]

I'm not calling these bugs because the program works, but they might help
other people who are running into the same problems I ran into and they
might be things the developers might want to change.  I'm running pcb2gcode
1.1.2 on ubuntu 11.04

1.  If there's a millproject in the directory, pcb2gcode seems to use it,
even if it's not asked to.  If I run pcb2gcode --front="front.gbr" [lots of
options] and I have a millproject around that contains an
"outline=outline.gbr" line, I get an outline.ngc as well as front.ngc -- and
in that case it's obvious what's happening, but if the only difference is
something like offset=0.003 when millproject has an offset=0.010, that's
more difficult to track down.

2.  When I run, let's say, "pcb2gcode --front "driver.front.gbr"
--cutter-diameter 0.004 --zcut 0.007 --cut-feed 10 --cut-speed 20000
--cut-infeed 0.007 --zsafe 0.025 --mill-speed 20000 --mill-feed 10 --offset
0.004 --zchange 2.00 --zwork 0.004" I get a good front.ngc output, with a
good toolpath.
If I then run " "pcb2gcode --front "driver.front.gbr" --cutter-diameter
0.004 --zcut 0.007 --cut-feed 10 --cut-speed 20000 --cut-infeed 0.007
--zsafe 0.025 --mill-speed 20000 --mill-feed 10 --offset 0.004 --zchange
2.00 --zwork 0.004 --outline "driver.outline.gbr" -- just adding the one
extra parameter that has it process a second file -- the front.ngc is
essentially blank.  It has a 5-item preamble, issues a G64, a G04 P0, a G00
Z2.0000, an M9, and an M2, and that's it.  The same thing happens when I add
all the relevant parameters for the outline cutter, or if I have a
driver.back.gbr that I try to isolate along with the front.
So if I want to get good front and back isolation files I need to run each
of them separately, and then run the drill and outline files.
It works just fine when I do that... but since it can process multiple
files, and produce outputs, it took me a while to figure out why I was
getting blank front and back isolation layers, which might be confusing to
other beginners.

I've had exactly the same thing happen with any millproject file I've used,
but I haven't actually tried a millproject that just works on one layer at a
time.

Anyway.  When I crank out one layer at a time it works great and the output
is lovely, and it's awesome to be able to mill my own PCB's, so thank you
very much for making this piece of software.

Re: [Pcb2gcode-devel] Question about drilling with height probing

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

Hi,

it's good to hear you like pcb2gcode!
I use etch_z_adjust only with the gcode files for the front and back side, and never used the milldrill option personally.

If the probing grid is not too dense, it should be possible to drill the pilot holes first, then mill the back side, but that would mean having to probe the board a second time unnecessarily.

I too suspect you should be able to just insert the body of the drill file after the preamble or before the finale of the back file, then run etch_z_adjust.
It's not possible to have pcb2gcode do this automatically yet, but it seems to be very reasonable and should possibly even be done by default if --milldrill is used.

I'm going to be away for a week now, but I have a whole week in August just to work on pcb2gcode and will probably fix this.
If you have any further input I'd be interested to hear about it.

-- Patrick

[Pcb2gcode-devel] Question about drilling with height probing

[Bryan P. <pol...@um...>]

Hello,

I am very pleased with pcb2gcode. I have one issue I am trying to figure 
out.

I use etch_z_adjust to take the output gcode files from pcb2gcode and 
create versions that perform automatic height-probing prior to milling. 
I have a simple mill with no tool wheel and since I don't want to put 
holes in my work surface I prefer to drill out vias and pins with a 
separate drill press. I am able to get much better holes if I make small 
pilot holes with the mill where I need to drill.

If I weren't using height-probing I could simply execute the back 
milling gcode with EMC2 and then open up the drill file without unhoming 
the machine and mill out small pilots for drilling. Unfortunately, since 
the drill file is separate the program etch_z_adjust would make the 
drill file re-probe, which is impossible once the traces are cut out. 
Thus, I am in a situation where the pilot holes are not cut using 
height-probing at all and some are too deep and some are too shallow 
(don't even touch the board).

This leads me to my question. Is there a way to make pcb2gcode include 
the drilling (with the milldrill option) gcode in the "back" gcode file, 
rather than making it its own file? Perhaps this is a silly question and 
I apologize if it is. If not, can I just copy the body of the drill file 
into the end of the back file? Thank you for your help.

Bryan

Re: [Pcb2gcode-devel] packaging for Fedora 15

[Pierre D. <pi...@eq...>]

 Hi,

 Here's the new build of your software for Fedora 15.

 Regards

 Pierre


 On Tue, 5 Jul 2011 11:34:21 +0200, Patrick Birnzain wrote:
> 2011/6/23 Pierre DOUCET <pi...@eq...>:
>> Hi,
>>
>> I build a little pcb2gcode package for Fedora 15. Here's the RPM 
>> source
>> file.
>>
>> P.S: why did you use another libtool than system provides ? I can't 
>> link
>> pcb2gcode on fedora 15 with your libtool, it doesn't work ( It exit 
>> with no
>> error... ). I need to build it with "make LIBTOOL=libtool"
>
> Hi,
>
> thanks a lot, I'll be happy to add it to the sourceforge page if you
> can update it, version 1.1.3 contains important bugfixes.
> You can also have write access if you want to do it yourself.
>
> The build system has been set up using autoproject if I remember
> correctly, and I've generated the tarballs by running "make 
> distcheck"
> ever since without giving much thought.
> So I'm supposed to have libtool.m4 ltoptions.m4 ltsugar.m4
> ltversion.m4 and lt~obsolete.m4 excluded from the tarball, right?
>
> -- Patrick

Re: [Pcb2gcode-devel] packaging for Fedora 15

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

2011/6/23 Pierre DOUCET <pi...@eq...>:
> Hi,
>
> I build a little pcb2gcode package for Fedora 15. Here's the RPM source
> file.
>
> P.S: why did you use another libtool than system provides ? I can't link
> pcb2gcode on fedora 15 with your libtool, it doesn't work ( It exit with no
> error... ). I need to build it with "make LIBTOOL=libtool"

Hi,

thanks a lot, I'll be happy to add it to the sourceforge page if you
can update it, version 1.1.3 contains important bugfixes.
You can also have write access if you want to do it yourself.

The build system has been set up using autoproject if I remember
correctly, and I've generated the tarballs by running "make distcheck"
ever since without giving much thought.
So I'm supposed to have libtool.m4 ltoptions.m4 ltsugar.m4
ltversion.m4 and lt~obsolete.m4 excluded from the tarball, right?

-- Patrick

[Pcb2gcode-devel] packaging for Archlinux

[Pierre D. <pi...@eq...>]

Hi,

I build a source package for Archlinux. You can find it in AUR 
repository. https://aur.archlinux.org/packages.php?ID=50457

Regards

Pierre

Re: [Pcb2gcode-devel] Internal Error: run_to_border: start_color == 0

[Stefan M. <sm...@4f...>]

Hi Patrick,

First tests are successful. Good work, thanks for the fix.

cu, Stefan.


On Sat, 2011-07-02 at 22:47 +0200, Patrick Birnzain wrote:
> Hi,
> 
> I've just uploaded a patch that should fix this, it's both in the
> 1.1.3 tarball and the git repository.
> Can you verify whether this works for you too?
> Thanks!
> 
> Patrick

Re: [Pcb2gcode-devel] Internal Error: run_to_border: start_color == 0

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

Hi,

I've just uploaded a patch that should fix this, it's both in the
1.1.3 tarball and the git repository.
Can you verify whether this works for you too?
Thanks!

Patrick