pcb2gcode-devel — PCB to Gcode - Developers

Re: [Pcb2gcode-devel] millproject file

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

2011/6/22 Demetris Zavorotnitsienko <giz...@gm...>:
> Can you please tell me how the offset works?
>
> Say I have an outline of a PCB. Mu Router Bit is 1mm in diameter
>

--cutter-diameter=0.0394 (0.0394 is ~1mm in Inches) tells pcb2gcode
that you're using a 1mm bit to cut out the boards. Since your outline
is not a filled polygon, you have to specify --fill-outline and
--fill-outline=0.005 to tell pcb2gcode that you've drawn the outline
in 5mil lines and arcs.

All of this is already in the command i sent you, EXCEPT FOR A TYPO:
it's supposed to be --fill-outline=0.005, not 0.050.

The --offset Parameter modifies how the traces are engraved, I
recommend you try different values (--offset=0.010 is a good starting
point) and see how it works. --offset does not influence how the
boards are cut out.

Does that answer your question sufficiently?

-- Patrick

Re: [Pcb2gcode-devel] pcb2gcode-1.1.2 doesn't generate pcb2gcode binary

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

> Hi,
> 
> there is no pcb2gcode binary. The make process stops
> without any visible complains.

Hi,

you can fix this by running libtoolize before autoreconf, i just updated the INSTALL file accordingly.

There are a lot sent-in patches in 1.1.2 and I'm behind on testing, so I recommend using pcb2gcode 1.1.0 for now.

-- Patrick

[Pcb2gcode-devel] pcb2gcode-1.1.2 doesn't generate pcb2gcode binary

[Robert F. <rob...@in...>]

Hi,

I just downloaded and installed pcb2gcode-1.1.2 and noticed that after
configure and make there is no pcb2gcode binary. The make process stops
without any visible complains.

I verified that issue on different Ubuntu systems and also tried the
previous pcb2gcode version where everything works fine.

/bin/bash ./libtool --tag=CXX   --mode=link g++  -g -O2 -L/usr/lib
-R/usr/lib  -o pcb2gcode board.o drill.o gerberimporter.o layer.o mill.o
ngc_exporter.o surface.o options.o main.o  -pthread -lglibmm-2.4
-lgobject-2.0 -lsigc-2.0 -lgthread-2.0 -lrt -lglib-2.0   -pthread
-lgdkmm-2.4 -lgiomm-2.4 -lpangomm-1.4 -lgtk-x11-2.0 -lglibmm-2.4
-lcairomm-1.0 -lsigc-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
-lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
-lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0  
-pthread -lgerbv -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0
-lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lcairo -lpango-1.0
-lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt
-lglib-2.0   -lboost_program_options-mt
make[2]: Verlasse Verzeichnis '/home/robert/Desktop/pcb2gcode-1.1.2'

I had a quick look at the makefiles.am of the different versions, but
could not see any difference... However I'm also not expert with build
tools :)

If you need any information/outputs please let me know.

Cheers,

Robert

[Pcb2gcode-devel] packaging for Fedora 15

[Pierre D. <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"

Regards

Pierre

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

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

Hi,

Sorry for being late. Attached you can find a non-working Gerber file
for the back and a drill file. Please find also attached my millproject.

cu, Stefan.

Re: [Pcb2gcode-devel] millproject file

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

> Hi everyone. Can someone please send me the MillProject file because I cannot find it.

I forgot to add it to the tarball, just uploaded a new one that includes the example millproject file.

> pcb2gcode --front=bottom_panel_15_x_20.gtl
> --outline=bottom_panel_15_x_20.gm1 --zwork=-0.008 --zsafe=0.8 --zchange=1.0
> --offset=0.006 --mill-feed=6 --mill-speed=30000 --cutter-diameter=0.0394
> --zcut=-0.08 --cut-feed=3 --cut-speed=20000 --cut-infeed=1 --dpi=1000

Try adding --fill-outline. If that's not specified the program assumes the outline gerber file includes a polygon instead of lines.
If it still doesn't work, please send me your gerber files for debugging (you can send them to my email address instead of the list if you don't want them to be accessible by others).

> Also does the "metric" command actually work?

Hopefully? Although I live in (metric) europe, I haven't tested it extensively myself yet, it's a downstream patch.

-- 
Patrick Birnzain <pbi...@us...>

[Pcb2gcode-devel] millproject file

[Demetris Z. <giz...@gm...>]

Hi everyone. Can someone please send me the MillProject file because I
cannot find it. I am trying to process a gerber file with the following
command: 

 

pcb2gcode --front=bottom_panel_15_x_20.gtl
--outline=bottom_panel_15_x_20.gm1 --zwork=-0.008 --zsafe=0.8 --zchange=1.0
--offset=0.006 --mill-feed=6 --mill-speed=30000 --cutter-diameter=0.0394
--zcut=-0.08 --cut-feed=3 --cut-speed=20000 --cut-infeed=1 --dpi=1000

 

but all I get are images of the traced outline and in the "front" file there
is almost no Gcode, only the outline code seems to be processed.

 

I am only trying to process the TOP and Mechanical1 layers. Any help would
be appreciated. Also does the "metric" command actually work?

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

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

hi guys,

if the contour algorithm detects a problem with the outline of a
trace, it simply rips out a few pixels to remove it and starts over -
a rather dirty little hack. The problem seems to be that in this case
this happens right next to the reference point of the trace, although
I'm not sure why.

-- Patrick

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

[chrysn <ch...@fs...>]

hi stefan,

On Mon, Jun 13, 2011 at 07:35:52PM +0200, Stefan May wrote:
> Please find attached the problematic section from the PNG files created
> in this run. As you can see in the original image, there is only one
> pixel at the problematic position. Maybe that leads to the problem?

it really seems to stem from the first found pixel not having a
neighboring one.

could you send your gerber file (or, if not legally possible, a stripped
down yet breaking version) and the options used, so it can be
reproduced?

for a quick workaround, i suggest you change the dpi by a little, until
it works.

regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

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

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

Bonjour list,

When I try to use pcb2gcode, I get the error:

Internal Error: run_to_border: start_color == 0 at (1253,529)

Please find attached the problematic section from the PNG files created
in this run. As you can see in the original image, there is only one
pixel at the problematic position. Maybe that leads to the problem?

ciao, Stefan.

Re: [Pcb2gcode-devel] outline filling

[chrysn <ch...@fs...>]

On Thu, May 12, 2011 at 06:13:10PM +0200, Patrick Birnzain wrote:
> Your new feature is finally in the SF master branch now.

cool, thanks. i've just built updated debian and ubuntu packages;
ubuntu's are available at [1], debian's at [2] until it gets sponsored
and the version shipped with debian is updated.

regards
chrysn

[1] http://launchpad.net/~chrysn/+archive/pcb2gcode/
[2] http://archive.amsuess.com/pool/main/p/pcb2gcode/

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

Re: [Pcb2gcode-devel] outline filling

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

Your new feature is finally in the SF master branch now. Nice work, thanks!
I've added a warning for large values of the outline-width parameter,
I somehow assumed I had to enter mils at first, so somebody else might
too.

-- Patrick

Re: [Pcb2gcode-devel] problems building under Ubuntu 11.04

[chrysn <ch...@fs...>]

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

[Pcb2gcode-devel] problems building under Ubuntu 11.04

[Mark D. R. <mra...@gm...>]

Hello,

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.

Thanks for your help - I am pretty new to Linux.

Mark

Re: [Pcb2gcode-devel] outline filling

[chrysn <ch...@fs...>]

hello patrick,

On Wed, Mar 30, 2011 at 02:32:32AM +0200, chrysn wrote:
> there's a new feature (or regression fix) in my patched branch at [1].
> [1] git://gitorious.org/pcb2gcode/pcb2gcode.git

i've seen there is a new version online since a few hours ago. did you
have a look at the patch branch as well? i'd like to have a second
opinion on that, i think it's useful bit i'm not sure i didn't miss
something somewhere.

there is a problematic recent commit: 0eb6a32d. while it appears to only
add an autogenerated file back, it also reverts some changes in main.cc,
one of which subtly changes the meanings of length given. (i already
wondered in which commit that happened *g*.) let me know if you need
help dissecting that.

regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

Re: [Pcb2gcode-devel] outline filling

[chrysn <ch...@fs...>]

hi list, hello patrick,

there's a new feature (or regression fix) in my patched branch at [1].

it contains:

* use of infinity constants instead of large values (328e45a9),
  accompanied by kicking out a leftover reference to Fixed.h which is
  unused (re-enabling it might require an alternative solution to the
  infinity constant thing, but i doubt that would be the only problem;
  2a47492968)

* man page fixes (559313, 30eb1bd79)

* a series of patches culminating in 1182d633 that adds back support for
  contour outlines instead of polygon outlines. i needed some safety
  measures in Surface::fill_a_component (using it with a component that
  touches the border caused segfaults; f214d7cd), from then it was just
  a matter of filling the outside of the contour, growing it a bit to
  compensate for line thickness, and changing the colors back to get the
  proper layer contents (that is, the shape of the part to be produced).

i've done some testing on my own, but would very much appreciate if
someone else have that a try (especially, i did not yet produce real
boards with it).

regards
chrysn

[1] git://gitorious.org/pcb2gcode/pcb2gcode.git

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

[Pcb2gcode-devel] visual options overview

[chrysn <ch...@fs...>]

hi pcb2gcode people,

as of trying to wrap my mind around the various offset lengths we have,
i've assembled a visualization of all the options that can reasonably
visualized. (for the outlines, i'm planning to add an option that says
how thick the outlines actually are, which used to be hardcoded to
10mil -- that's why i started drawing this.)

the image could also be helpful for cleaning up options; for example, if
my understanding is correct, there is no reason to have independent
zchange and zsafe options, while we can't express different cut-infeed
values for cutting and milldrilling (if we don't need them, do we need
zcut and zdrill?).

any comments on that? is my understanding of the options correct? (i
took everything from the man page, but as i wrote that myself it's prone
to be equally wrong.)

for the moment, i'll attach it here; it could be kept in a documentation
subdirectory of the code base later on.

regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

[Pcb2gcode-devel] outline filling

[chrysn <ch...@fs...>]

hi list,

in order to avoid duplicate simultaneous work, i'd just like to inform
you that i'm working on some options to fill the outline before masking
so real out*line*s can be used again; additionally, there should be a
line thickness compensation for the milling part -- let's see if i get
there too.

i'll send code once it is presentable
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

[Pcb2gcode-devel] new patches

[chrysn <ch...@fs...>]

hello developers,

my patches branch at [1] recently got a few bugfixes / features, namely:

* d3eb27ff

    fix for incorrect api usage resulting in non-black background pixels

* a3f43143

    narrower sampling raster to avoid missing narrow lines

* d2a34132, 056395a7

    make sure an outline is always milled completely. this rarely shows
    up with voronoi style outlines as they always mill everything twice,
    but does so with lower limits (e.g. for large unwired regions on a
    board). the fixes make sure the outline is completely closed even
    for small dpi (c5578fca) and the movement isn't smoothed over by the
    machine.

* f4dfbacd

    configure smoothing in a dpi-dependent way instead of a hard-coded
    distance; thus, movements are always smooth instead of the aliased
    zig-zagging. the discrepancies are always below a pixel now.

    (this was actually a side effect of experimenting with the above)

* 55d33410, 829e20be

    replace the optimizations of f87577f5, which optimize out one point
    too much. i hope the new version is more readable too.

    i would have removed the code duplication if it was not explicitly
    commented to be on purpose:

    /** if we're cutting, perhaps do it in multiple steps, but do
     * isolations just once.  i know this is partially repetitive, but
     * this way it's easier to read
     */

    i respect the author's choice, but would kindly ask to reconsider,
    given the amount of code duplicated is larger now.

i'd like to use the opportunity to point out 91b2b2dd as well, which
fixes the documentation to reflect the current code.

regards
chrysn

[1] git://gitorious.org/pcb2gcode/pcb2gcode.git

-- 
Reflection. Surprise. Terror. For the future.
  -- Kosh

Re: [Pcb2gcode-devel] endless loop in surface.cpp

[chrysn <ch...@fs...>]

On Thu, Mar 10, 2011 at 06:09:15PM +0100, Patrick Birnzain wrote:
> I've just commited a fix, works for me now.
> Please let me know whether it's working for you as well, thanks.

yes, works for me too, thanks.

before i pull in that patch into my debian branch, would you consider
picking the latest man page fix (cfc3b5467) from the `patched' branch of
[1]? if it makes it into your branch before i release the next debian
package (which will at latest be with 1.1.1), that would be great.

thanks
chrysn

[1] git://gitorious.org/pcb2gcode/pcb2gcode.git

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

Re: [Pcb2gcode-devel] endless loop in surface.cpp

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

Hi,

I've just commited a fix, works for me now.
Please let me know whether it's working for you as well, thanks.

-- Patrick


2011/3/6 chrysn <ch...@fs...>:
> hello pcb2gcode developers,
>
> a back+outline run causes pcb2gcode to get stuck in an endless loop. the
> command line i am using is
>
> pcb2gcode --back main.back.gbr --outline main-onlypoly.outline.gbr
>
> with the files attached. also attached is a patch which adds a counter
> to the endless loop and dumps a debug image when enough steps have been
> made to go over every edge between two pixels twice. (i did not, as
> usually, add the patch to my package's patched branch as i'm not sure my
> understanding of how many times the loop can run through is correct.)
>
> the patch does not solve the problem, but it shows when it should
> already have completed its calculations and aborts.
>
> i currently don't have the time to look for the deeper roots of the
> problem myself, so i'm posting it here. slight changes in the gerber
> files make it work again (it seems to get stuck at the left side where
> the six vertically aligned drill holes have the line going right; if the
> line is attached somewhere else, no problem).
>
> regargs
> chrysn
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>  -- Bene Gesserit axiom
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk1zBrkACgkQX+8/P49kuRiOQgCfT3kJv86mYIXCidpK5S1iqmPm
> oXkAnR7rUs/tK49zFAXA2yaaxiOggjvX
> =gGoG
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Pcb2gcode-devel mailing list
> Pcb...@li...
> https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel
>
>

Re: [Pcb2gcode-devel] Debian package

[chrysn <ch...@fs...>]

On Wed, Dec 29, 2010 at 11:43:21AM +1300, ne...@di... wrote:
> Would you like a .deb file ( Debian package) for pcb2gcode?

there are already complete debian packages at [1] and ubuntu packages at
[2].  they are in the process of being included in debian and (with the
next pull) ubuntu [3].

sorry you did duplicate work -- i forgot to file an ITP (intent to
package) bug in debian when i first wrote them.

hth
chrysn

[1] http://archive.amsuess.com/pool/main/p/pcb2gcode/
[2] https://launchpad.net/~chrysn/+archive/pcb2gcode
[3] http://bugs.debian.org/616626

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

[Pcb2gcode-devel] endless loop in surface.cpp

[chrysn <ch...@fs...>]

hello pcb2gcode developers,

a back+outline run causes pcb2gcode to get stuck in an endless loop. the
command line i am using is

pcb2gcode --back main.back.gbr --outline main-onlypoly.outline.gbr

with the files attached. also attached is a patch which adds a counter
to the endless loop and dumps a debug image when enough steps have been
made to go over every edge between two pixels twice. (i did not, as
usually, add the patch to my package's patched branch as i'm not sure my
understanding of how many times the loop can run through is correct.)

the patch does not solve the problem, but it shows when it should
already have completed its calculations and aborts.

i currently don't have the time to look for the deeper roots of the
problem myself, so i'm posting it here. slight changes in the gerber
files make it work again (it seems to get stuck at the left side where
the six vertically aligned drill holes have the line going right; if the
line is attached somewhere else, no problem).

regargs
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

Re: [Pcb2gcode-devel] pcb2gcode 1.1.0 release, packaging, gui

[chrysn <ch...@fs...>]

hello patrick,

On Tue, Jan 18, 2011 at 02:56:16PM +0100, Patrick Birnzain wrote:
> @chrysn: what's your status concerning the debian packages?

i've been somewhat inactive on that project, but just toda^Wyesterday
pulled the current status again.

the packaging is pretty complete; i've just filed an ITP (intent to
package) bug in debian to get it included [1]. in the meantime, packages
compiled for debian can be obtained from my server [2]. ubuntu users can
use the pcb2gcode ppa [3].

when pulling the changes i noticed that some new commands were not
reflected in the documentation. fixed that; patch can be fetched from my
'patched' branch as usual [4].

regards
chrysn

[1] http://bugs.debian.org/616626
[2] http://archive.amsuess.com/pool/main/p/pcb2gcode/
[3] https://launchpad.net/~chrysn/+archive/pcb2gcode
[4] git://gitorious.org/pcb2gcode/pcb2gcode.git

-- 
Yesterday is history, tomorrow is a mystery, and today is a gift. That
is why it is called the present.
  -- ancient saying

Re: [Pcb2gcode-devel] zsave trouble

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

I just noticed the millproject example is only in the git repository,
not the tarball.
You can hopefully get it here:
http://pcb2gcode.git.sourceforge.net/git/gitweb.cgi?p=pcb2gcode/pcb2gcode;a=blob_plain;f=millproject;hb=HEAD

-- Patrick