Menu
▾
▴
pcb2gcode-devel — PCB to Gcode - Developers
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(20) |
Dec
(9) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(9) |
Apr
(1) |
May
(4) |
Jun
(9) |
Jul
(10) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(2) |
Dec
(10) |
| 2012 |
Jan
(10) |
Feb
(1) |
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
(7) |
| 2013 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(10) |
Feb
(13) |
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Patrick B. <pbi...@us...> - 2011-02-28 12:20:32
|
Hi, welcome to the pcb2gcode mailing list! I have confirmed the problem and am working on it. In the meantime, you can put parameters that don't work on the command line in a config file. pcb2gcode looks for a file named "millproject" in the directory it is run from and loads parameters from there. An example millproject file is included with the source. By the way, the parameters are in inches by default, so you'll most likely want someting like --zsave=0.1 (~2.5mm safety height) instead of --zsave 10. You can override this using the --metric parameter, but that's a user-supplied patch and largely untested. -- Patrick |
|
From: Lucas R. D. <luc...@gm...> - 2011-02-28 06:03:05
|
Hi, Im kind of new to all this but, when trying to execute the program, gives me an error saying: >pcb2gcode --front qtop.gbr --zsave 10 Note that spindle speeds are integers! Details: unknown option zsave Even thought I clearly specify the --zsave option. Please, Im doing something wrong? I couldn't find any thing on the help. Thanks in advance, Lucas. |
|
From: Patrick B. <pbi...@us...> - 2011-01-18 13:56:23
|
============ 1.1.0 Release ============ As the only major bug with pcb2gcode known to me in the previous month(s) is it's incapability to deal with guard rings and heat traps properly (which is not something that can be dealt with very easily), I propose changing the version number to 1.1.0 and start packaging. Unless there are further issues to discuss, I will do so by Saturday 22nd. ============ Documentation, GUI ============ Given the ever-growing number of features and parameters, it would be nice to have some more documentation on some of them on the wiki, esp. the outline cutting. Unfortunately the SF mediawiki version requires me to give each user write permissions separately, so if you want to change anything, please let me know. As a python exercise, I'm thinking of programming a simple graphical "wizard" that creates custom millproject files, with the intent do reduce the learning curve for new users somewhat. I'll possibly use AVC [1], pygtk and glade. Any thoughts? ============ Packaging ============ I intend to build a rpm package for Fedora 14 myself (unless someone volunteers to do that) and leave possible debian-ish packages to others. @chrysn: what's your status concerning the debian packages? -- Patrick [1] http://avc.inrim.it/html/ |
|
From: Alan C. <ac...@ip...> - 2010-12-29 21:20:15
|
William, I got it to compile on my mac. I have xcode-3.2.5 installed. The biggest problem was getting all of the necessary packages installed. I downloaded most of the stuff using MacPorts. Alan --- Alan Condit 1085 Tierra Ct. Woodburn, OR 97071 Email -- ac...@ip... Home-Office (503) 982-0906 On Dec 29, 2010, at 12:18 PM, pcb...@li... wrote: > Message: 1 > Date: Mon, 06 Dec 2010 10:22:13 -0800 > From: "William \"Chops\" Westfield" <we...@ma...> > Subject: [Pcb2gcode-devel] compiling for Mac > To: pcb...@li... > Message-ID: <A7D...@ma...> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Has anyone tried compiling pcb2gcode on a Mac? > > The assorted Yum install advice is useless, of course. I use fink as > a package manager and eventually got configure to work, but make > doesn't get very far at all. > It looks like some basic problem with boost data types (sorry, I'm > also only an embedded C programmer, mostly, so a lot of these advanced > C++ libraries go over my head), but I've tried both the boost that > fink wants to install (boost1.41.cmake) and the most recent > sourceforge download (1.45) and they produce the same errors... > > Any advice? > > Thanks > Bill W > > make all-am > g++ -DHAVE_CONFIG_H -I. -I/sw/include -I/sw/include/gtkmm-2.4 -I/sw/ > lib/gtkmm-2.4/include -I/sw/include/giomm-2.4 -I/sw/lib/giomm-2.4/ > include -I/sw/include/pangomm-1.4 -I/sw/lib/pangomm-1.4/include -I/sw/ > include/gtk-2.0 -I/sw/include/gtk-unix-print-2.0 -I/sw/include/ > atkmm-1.6 -I/sw/include/gdkmm-2.4 -I/sw/lib/gdkmm-2.4/include -I/sw/ > include/glibmm-2.4 -I/sw/lib/glibmm-2.4/include -I/sw/include/glib-2.0 > -I/sw/lib/glib-2.0/include -I/sw/include/sigc++-2.0 -I/sw/lib/sigc+ > +-2.0/include -I/sw/include/cairomm-1.0 -I/sw/lib/cairomm-1.0/include - > I/sw/include/pango-1.0 -I/sw/include/cairo -I/sw/include/freetype2 -I/ > sw/include -I/sw/lib/gtk-2.0/include -I/sw/include/atk-1.0 -I/usr/ > X11R6/include -I/usr/X11/include -I/sw/include/gerbv-2.4.0 -I/sw/ > include/glib-2.0 -I/sw/lib/glib-2.0/include -I/sw/include/gtk-2.0 -I/ > sw/lib/gtk-2.0/include -I/sw/include/atk-1.0 -I/sw/include/cairo -I/sw/ > include/pango-1.0 -I/sw/include/freetype2 -I/sw/include -I/usr/X11R6/ > include -I/usr/X11/include -g -O2 -MT board.o -MD -MP -MF .deps/ > board.Tpo -c -o board.o board.cpp > board.cpp: In member function 'void Board::createLayers()': > board.cpp:80: error: 'class std::map<std::string, > boost::tuples::tuple<boost::shared_ptr<LayerImporter>, > boost::shared_ptr<RoutingMill>, bool, bool, boost::tuples::null_type, > boost::tuples::null_type, boost::tuples::null_type, > boost::tuples::null_type, boost::tuples::null_type, > boost::tuples::null_type>, std::less<std::string>, > std::allocator<std::pair<const std::string, > boost::tuples::tuple<boost::shared_ptr<LayerImporter>, > boost::shared_ptr<RoutingMill>, bool, bool, boost::tuples::null_type, > boost::tuples::null_type, boost::tuples::null_type, > boost::tuples::null_type, boost::tuples::null_type, > boost::tuples::null_type> > > >' has no member named 'at' > board.cpp:80: error: expected primary-expression before ')' token > board.cpp:113: error: 'class std::map<std::string, > boost::shared_ptr<Layer>, std::less<std::string>, > std::allocator<std::pair<const std::string, boost::shared_ptr<Layer> > >>> ' has no member named 'at' > board.cpp: In member function 'boost::shared_ptr<Layer> > Board::get_layer(std::string)': > board.cpp:154: error: 'class std::map<std::string, > boost::shared_ptr<Layer>, std::less<std::string>, > std::allocator<std::pair<const std::string, boost::shared_ptr<Layer> > >>> ' has no member named 'at' > make[1]: *** [board.o] Error 1 > make: *** [all] Error 2 > |
|
From: Patrick B. <pbi...@us...> - 2010-12-29 20:18:54
|
Definitely, yes. You can send what you have to the list or my address, I will add the package to the file downloads and auxiliary files (if any) to the git repository. You will be credited where appropriate. Thank you! -- Patrick 2010/12/28 <ne...@di...>: > > Would you like a .deb file ( Debian package) for pcb2gcode? It's not an > official Debian package and it hasn't been signed but it would make it easier > for Debian Squeeze ( on i386) users get started with pcb2gcode. It probably > installs on Ubuntu as well. > > - neil > > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Pcb2gcode-devel mailing list > Pcb...@li... > https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel > |
|
From: <ne...@di...> - 2010-12-28 22:59:48
|
Would you like a .deb file ( Debian package) for pcb2gcode? It's not an official Debian package and it hasn't been signed but it would make it easier for Debian Squeeze ( on i386) users get started with pcb2gcode. It probably installs on Ubuntu as well. - neil |
|
From: Patrick B. <pbi...@us...> - 2010-12-08 11:31:11
|
If there are no copyright issues or anything, can i have your gerber file(s) for debugging purposes only? Large copper areas are very problematic for pcb2gcode due to limitations of the algorithms used, the program also ignores heat traps etc. The clearance warning is nothing unusual, for most settings it will appear more often than not, it's just to warn the result will not be exactly what the gerber file looks like. -- Patrick On 12/08/2010 03:24 AM, Alan Condit wrote: > Patrick, > > I have submitted this board to BatchPCB.com to check it with their DRCBot and it passed with no problems. The gerbers are not from gEDA but rather from Osmond-Cocoa for the Mac. I have a bunch of existing designs from before I got gEDA compiled. > > The problem with failing to "fulfill all clearance requirements" seems to be related to when I set the board up with "copper flood" on the front and/or back. > > The .png files look like I would expect the pcb to look. However, the front.ngc and back.ngc files don't have any gcode for any traces. > > ---- > ( pcb2gcode 1.0.6 ) > > G94 ( Inches per minute feed rate. ) > G20 ( Units == INCHES. ) > G90 ( Absolute coordinates. ) > S30000 ( RPM spindle speed. ) > M3 ( Spindle on clockwise. ) > > G64 P0.002 ( set maximum deviation from commanded toolpath ) > > > G00 Z1.00000 ( retract ) > > M9 ( Coolant off. ) > M2 ( Program end. ) > > ---- > > I had these values set, for a 1/32" milling cutter and a 0.007" engraver. > > cutter-diameter=0.03125 > offset=0.0035 > > Alan > --- > > Alan Condit > 1085 Tierra Ct. > Woodburn, OR 97071 > > Email -- ac...@ip... > Home-Office (503) 982-0906 > >> Hi Alan, >> >> this is what the --offset= parameter is used for. >> You can set it to the radius of your isolation cutter to mill everything >> exactly as specified in your gerber file, but you will frequently want >> to set it to a higher value (double or more). >> If there are contentions due to a high offset (e.g. between IC pins), >> the program warns you and temporarily reduces the milling offset. >> >> I suggest you take a small testing gerber file and try different values >> for --offset so you see how it works. >> >> -- Patrick >> >>> I have set up a millproject file for my parameters. How do you specify the diameter of your isolation cutter, if it is different from the end mill that you use for cutting the board outline? >>> >>> Alan >>> --- >>> >>> Alan Condit >>> 1085 Tierra Ct. >>> Woodburn, OR 97071 >>> >>> Email -- >>> ac...@ip... >>> >>> Home-Office (503) 982-0906 > > > ------------------------------------------------------------------------------ > What happens now with your Lotus Notes apps - do you make another costly > upgrade, or settle for being marooned without product support? Time to move > off Lotus Notes and onto the cloud with Force.com, apps are easier to build, > use, and manage than apps on traditional platforms. Sign up for the Lotus > Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d > _______________________________________________ > Pcb2gcode-devel mailing list > Pcb...@li... > https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel > |
|
From: Alan C. <ac...@IP...> - 2010-12-08 02:24:42
|
Patrick, I have submitted this board to BatchPCB.com to check it with their DRCBot and it passed with no problems. The gerbers are not from gEDA but rather from Osmond-Cocoa for the Mac. I have a bunch of existing designs from before I got gEDA compiled. The problem with failing to "fulfill all clearance requirements" seems to be related to when I set the board up with "copper flood" on the front and/or back. The .png files look like I would expect the pcb to look. However, the front.ngc and back.ngc files don't have any gcode for any traces. ---- ( pcb2gcode 1.0.6 ) G94 ( Inches per minute feed rate. ) G20 ( Units == INCHES. ) G90 ( Absolute coordinates. ) S30000 ( RPM spindle speed. ) M3 ( Spindle on clockwise. ) G64 P0.002 ( set maximum deviation from commanded toolpath ) G00 Z1.00000 ( retract ) M9 ( Coolant off. ) M2 ( Program end. ) ---- I had these values set, for a 1/32" milling cutter and a 0.007" engraver. cutter-diameter=0.03125 offset=0.0035 Alan --- Alan Condit 1085 Tierra Ct. Woodburn, OR 97071 Email -- ac...@ip... Home-Office (503) 982-0906 > Hi Alan, > > this is what the --offset= parameter is used for. > You can set it to the radius of your isolation cutter to mill everything > exactly as specified in your gerber file, but you will frequently want > to set it to a higher value (double or more). > If there are contentions due to a high offset (e.g. between IC pins), > the program warns you and temporarily reduces the milling offset. > > I suggest you take a small testing gerber file and try different values > for --offset so you see how it works. > > -- Patrick > >> I have set up a millproject file for my parameters. How do you specify the diameter of your isolation cutter, if it is different from the end mill that you use for cutting the board outline? >> >> Alan >> --- >> >> Alan Condit >> 1085 Tierra Ct. >> Woodburn, OR 97071 >> >> Email -- >> ac...@ip... >> >> Home-Office (503) 982-0906 |
|
From: Patrick B. <pbi...@us...> - 2010-12-07 09:54:00
|
Hi Alan, this is what the --offset= parameter is used for. You can set it to the radius of your isolation cutter to mill everything exactly as specified in your gerber file, but you will frequently want to set it to a higher value (double or more). If there are contentions due to a high offset (e.g. between IC pins), the program warns you and temporarily reduces the milling offset. I suggest you take a small testing gerber file and try different values for --offset so you see how it works. -- Patrick |
|
From: Alan C. <ac...@ip...> - 2010-12-07 00:46:42
|
I have set up a millproject file for my parameters. How do you specify the diameter of your isolation cutter, if it is different from the end mill that you use for cutting the board outline? Alan --- Alan Condit 1085 Tierra Ct. Woodburn, OR 97071 Email -- ac...@ip... Home-Office (503) 982-0906 |
|
From: William \Chops\ W. <we...@ma...> - 2010-12-06 18:22:22
|
Has anyone tried compiling pcb2gcode on a Mac? The assorted Yum install advice is useless, of course. I use fink as a package manager and eventually got configure to work, but make doesn't get very far at all. It looks like some basic problem with boost data types (sorry, I'm also only an embedded C programmer, mostly, so a lot of these advanced C++ libraries go over my head), but I've tried both the boost that fink wants to install (boost1.41.cmake) and the most recent sourceforge download (1.45) and they produce the same errors... Any advice? Thanks Bill W make all-am g++ -DHAVE_CONFIG_H -I. -I/sw/include -I/sw/include/gtkmm-2.4 -I/sw/ lib/gtkmm-2.4/include -I/sw/include/giomm-2.4 -I/sw/lib/giomm-2.4/ include -I/sw/include/pangomm-1.4 -I/sw/lib/pangomm-1.4/include -I/sw/ include/gtk-2.0 -I/sw/include/gtk-unix-print-2.0 -I/sw/include/ atkmm-1.6 -I/sw/include/gdkmm-2.4 -I/sw/lib/gdkmm-2.4/include -I/sw/ include/glibmm-2.4 -I/sw/lib/glibmm-2.4/include -I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include -I/sw/include/sigc++-2.0 -I/sw/lib/sigc+ +-2.0/include -I/sw/include/cairomm-1.0 -I/sw/lib/cairomm-1.0/include - I/sw/include/pango-1.0 -I/sw/include/cairo -I/sw/include/freetype2 -I/ sw/include -I/sw/lib/gtk-2.0/include -I/sw/include/atk-1.0 -I/usr/ X11R6/include -I/usr/X11/include -I/sw/include/gerbv-2.4.0 -I/sw/ include/glib-2.0 -I/sw/lib/glib-2.0/include -I/sw/include/gtk-2.0 -I/ sw/lib/gtk-2.0/include -I/sw/include/atk-1.0 -I/sw/include/cairo -I/sw/ include/pango-1.0 -I/sw/include/freetype2 -I/sw/include -I/usr/X11R6/ include -I/usr/X11/include -g -O2 -MT board.o -MD -MP -MF .deps/ board.Tpo -c -o board.o board.cpp board.cpp: In member function 'void Board::createLayers()': board.cpp:80: error: 'class std::map<std::string, boost::tuples::tuple<boost::shared_ptr<LayerImporter>, boost::shared_ptr<RoutingMill>, bool, bool, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::tuples::tuple<boost::shared_ptr<LayerImporter>, boost::shared_ptr<RoutingMill>, bool, bool, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' has no member named 'at' board.cpp:80: error: expected primary-expression before ')' token board.cpp:113: error: 'class std::map<std::string, boost::shared_ptr<Layer>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<Layer> > > >' has no member named 'at' board.cpp: In member function 'boost::shared_ptr<Layer> Board::get_layer(std::string)': board.cpp:154: error: 'class std::map<std::string, boost::shared_ptr<Layer>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<Layer> > > >' has no member named 'at' make[1]: *** [board.o] Error 1 make: *** [all] Error 2 |
|
From: jmcgee <jm...@je...> - 2010-12-04 22:04:14
|
On Fri, 2010-11-26 at 15:54 -0800, jmcgee wrote: > I'm happy to change the name to --multipass=X, but then I'm not certain > how the parameter should work. If multipass is set to zero should the > default path be generated or not? How would --extra-passes=X be? That > way the zero case is well defined (0 means that 0 extra passes are > generated, but the normal first pass is generated -- 1 would mean 1 > extra path generated, for a total of two)? I've attached my patches for increasing the isolation width. Since I did not get any feedback on the what to call the feature I've named it extra-passes. Both multipass and extra-passes is included in the patches, so you should be able to choose one or the other rather easily. |
|
From: Patrick B. <pbi...@us...> - 2010-11-30 16:25:47
|
On 11/30/2010 03:08 PM, chrysn wrote: > On Tue, Nov 30, 2010 at 01:48:33AM +0100, chrysn wrote: >> i saw it made its way back in -- were there problems? (besides, when i >> do an `autoreconf`, not only Makefile.in, but also aclocal.m4 and >> configure change, so they might be in for removal as well, as is the >> "missing" file. the sequence for building then becomes `autoreconf`, >> `./configure` etc.; but i'm talking about tools i don't understand here, >> so maybe i'm all wrong. > > i've dug a bit deeper now, and created a commit that should get rid of > all the generated files [1533e473]. the remaining issue with INSTALL (it > is overwritten automatically by autotools, removing the custom section > about quick installation) was resolved in [2459ec3dd2]. > > another commit [ae710b583e9] tries to reduce dependencies and libraries > linked in, but with hardly any result (a single library gets dropped by > moving from gtk to glib+gdkmm). Makefile.in is needed by configure, I didn't pay enough attention when I removed it. Are you sure it's a good idea to remove configure and the associated files? Most programs can be installed using the usual ./configure && make && sudo make install command, and I don't want to unnecessarily complicate the installation procedure if I can avoid it. Sure, running autoreconf isn't that much effort, but I'm a bit concerned about how well everything will work with different versions of libtool, m4, the autotools, etc. If the finished configure script is included, everything's fine. Anyway, what's your opinion? |
|
From: chrysn <ch...@fs...> - 2010-11-30 15:30:49
|
On Tue, Nov 30, 2010 at 01:48:33AM +0100, chrysn wrote: > i saw it made its way back in -- were there problems? (besides, when i > do an `autoreconf`, not only Makefile.in, but also aclocal.m4 and > configure change, so they might be in for removal as well, as is the > "missing" file. the sequence for building then becomes `autoreconf`, > `./configure` etc.; but i'm talking about tools i don't understand here, > so maybe i'm all wrong. i've dug a bit deeper now, and created a commit that should get rid of all the generated files [1533e473]. the remaining issue with INSTALL (it is overwritten automatically by autotools, removing the custom section about quick installation) was resolved in [2459ec3dd2]. another commit [ae710b583e9] tries to reduce dependencies and libraries linked in, but with hardly any result (a single library gets dropped by moving from gtk to glib+gdkmm). -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom |
|
From: chrysn <ch...@fs...> - 2010-11-30 00:48:43
|
On Fri, Nov 26, 2010 at 03:12:29PM +0100, Patrick Birnzain wrote: > "make distcheck" gives me an error when ./man is processed, could you > please verify if that happens for you too? yes, i see that too. after $ automake $ ./configure $ make distcheck the pcb2gcode.1 is missing in pcb2gcode-1.0.7/man -- the latest patch [4a5949247] fixes that. > Also, I think you had concerns about something concerning the autotools, > but I can't find the message anymore. If it's about the inclusion of > Makefile.in in git, I just ripped that out ;-) i saw it made its way back in -- were there problems? (besides, when i do an `autoreconf`, not only Makefile.in, but also aclocal.m4 and configure change, so they might be in for removal as well, as is the "missing" file. the sequence for building then becomes `autoreconf`, `./configure` etc.; but i'm talking about tools i don't understand here, so maybe i'm all wrong. regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom |
|
From: jmcgee <jm...@je...> - 2010-11-26 23:55:24
|
I'm happy to change the name to --multipass=X, but then I'm not certain how the parameter should work. If multipass is set to zero should the default path be generated or not? How would --extra-passes=X be? That way the zero case is well defined (0 means that 0 extra passes are generated, but the normal first pass is generated -- 1 would mean 1 extra path generated, for a total of two)? Or should it be --multipass=X where X defines the number of passes, so zero means an empty milling file is generated? I'm not certain how to send you the patch, so I've attached the patch for the drill-front change. If it does not make it through the email list please let me know where to send it... This change only affects the drilling, not the cutting, so it may not be useful to anyone else. --madscifi |
|
From: Patrick B. <pbi...@us...> - 2010-11-26 14:34:49
|
Hi! > 1) A command line option (drill-front) and code so that the drilling > gcode is generated for drilling into the front of the pcb (as opposed to > the back). I use this since I've been making single sided boards using > only the front side copper. I've thought of this possibility. The pre-1.0-versions of pcb2gcode automatically did everything from the top side if there was no bottom layer specified, but this functionality is not yet implemented in the rewrite. If your patch does this for the outline too, I can directly add it. Otherwise, it's still a good starting point for the mentioned feature. > 2) A command line option (extra-isolation) and code that makes the > Surface::get_toolpath function generate multiple passes of the mill bit > around each track. Each extra pass is made by growing the track 1/2 the > tool diameter and then generating a new set of tool paths (collecting > all the milling paths together). This results in larger isolations > between used paths and unused copper while keeping fine detail, with the > obvious trade off of increased milling time and tool wear. Also, no > attempt has been made to collapse redundant paths. I find the larger > isolation makes it easier to solder components without inadvertently > shorting something to the unused copper. This is something I'd wanted to have somewhere far down the line too, If it's ok for you, I'll call the parameter --multipass=x or --passes=x, what do you think? I think gcam does something similar too, but I haven't used it's gerber importer for a year or so. > If you would be interested in considering either patch for inclusion in > the codebase I would be happy to provide the code in whatever form would > be most useful, and/or make any requested changes necessary for > inclusion. git patches or a clone/repo that i can pull your changes from would be ideal, but diffs are ok too. Heck, you can tar everything and send it to me if you want ;-) Thanks! -- Patrick |
|
From: Patrick B. <pbi...@us...> - 2010-11-26 14:12:43
|
On 11/20/2010 08:09 PM, chrysn wrote: > On Wed, Nov 17, 2010 at 09:58:05PM +0100, chrysn wrote: >> On Wed, Nov 17, 2010 at 09:41:45PM +0100, Patrick Birnzain wrote: >>>> Hi, so i spent the last couple of hours creating the patches of the >>>> stuff i changed the last week. >> >>> I'll try to apply your patches to the SF master this week. >> >> [...] i suggest to stay tuned to my patches branch at [1], where i >> expect the patches to end up in the course of the evening. > > i have now integrated all patches, and pushed them to gitorious. Since you seem to be working together in the metalab, I guess that's where I'll be getting your patches in the future, right? VERY convenient! ;-) > the basename setting is now integrated with my own output naming > settings; it's not good c++/boost code (it even casts around a bit > *duck*), so patrick, if you could have a look and maybe enhance this > particular section, i'd appreciate that. (the c2a0133a4c patch) I certainly hope I'll get to work a bit on pcb2gcode soon. If I do, I'll check this first, unless you were faster. :-) chrysn: "make distcheck" gives me an error when ./man is processed, could you please verify if that happens for you too? Also, I think you had concerns about something concerning the autotools, but I can't find the message anymore. If it's about the inclusion of Makefile.in in git, I just ripped that out ;-) -- Patrick |
|
From: jmcgee <jm...@je...> - 2010-11-26 04:03:49
|
I've added two very simple features to pcb2gcode for my own use: 1) A command line option (drill-front) and code so that the drilling gcode is generated for drilling into the front of the pcb (as opposed to the back). I use this since I've been making single sided boards using only the front side copper. 2) A command line option (extra-isolation) and code that makes the Surface::get_toolpath function generate multiple passes of the mill bit around each track. Each extra pass is made by growing the track 1/2 the tool diameter and then generating a new set of tool paths (collecting all the milling paths together). This results in larger isolations between used paths and unused copper while keeping fine detail, with the obvious trade off of increased milling time and tool wear. Also, no attempt has been made to collapse redundant paths. I find the larger isolation makes it easier to solder components without inadvertently shorting something to the unused copper. The changes were made to the 1.0.6 version of pcb2gcode. If you would be interested in considering either patch for inclusion in the codebase I would be happy to provide the code in whatever form would be most useful, and/or make any requested changes necessary for inclusion. --madscifi |
|
From: chrysn <ch...@fs...> - 2010-11-21 11:22:32
|
On Wed, Nov 17, 2010 at 09:58:05PM +0100, chrysn wrote: > On Wed, Nov 17, 2010 at 09:41:45PM +0100, Patrick Birnzain wrote: > > >Hi, so i spent the last couple of hours creating the patches of the > > >stuff i changed the last week. > > > I'll try to apply your patches to the SF master this week. > > [...] i suggest to stay tuned to my patches branch at [1], where i > expect the patches to end up in the course of the evening. i have now integrated all patches, and pushed them to gitorious. the path simplification stuff is still disabled at compile time (there are no settings for it yet). i am not sure if there aren't large patterns that will be reduced to zero, but those should be corner cases. the basename setting is now integrated with my own output naming settings; it's not good c++/boost code (it even casts around a bit *duck*), so patrick, if you could have a look and maybe enhance this particular section, i'd appreciate that. (the c2a0133a4c patch) the milldrill does not yet respect absolute mirroring; i've added a check so that it fails if there is a problem, and will extend that to work properly soon. concerning the preamble stuff, i'm not sure if we are "there yet". some parts are essential for the resulting ngc to work and maybe should never be omitted (unit mode, absolute mode), others depend on the machine settings a lot (eg coolant). there are still parts of the code that have their own preamble hardcoded. i'll post an update to the list as soon as i get more done chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom |
|
From: Patrick B. <pbi...@us...> - 2010-11-20 12:14:02
|
Hi! Given the kind of insufficient documentation of the program there ain't no stupid questions ;-) I've tested this with the Generation 7 Board, your millproject file and both the pcb2gcode 1.0.6 file release and the current git version. Works for me, so it hopefully shouldn't be a bug. The ability to calculate voronoi regions is not an actual feature per se, but a nice side effect of pcb2gcode's clearance issue resolver. A short description of how it works can be found here: https://sourceforge.net/apps/mediawiki/pcb2gcode/index.php?title=Voronoi_region Basically, you only have to change "offset=1.0" in your millproject file to e.g. "offset=0.006" (for a 12mil diameter bit). Please try that an let me know how it works out. I'm mostly using SMC's too and usually choose to add some "bloating" to the traces by using an offset a bit higher than the actual engraving bit radius. -- Patrick 2010/11/19 Mathias Johansson <bm...@te...>: > Hello! > > I'm sorry to disturb you whide a probably stupid question, but I have > tried '--help' and to RTFM to no avail :'( . > > Is it possible to turn off voronoi regions in version 1.0.6 and use > 'normal' outlines instead? The reason is that I have a hard time > figuring out where to place and solder the components (I'm using some > SMC) ;-) . > > The "millproject" file at http://reprap.org/wiki/PCB_Milling#Fritzing > turns them ON using "generate voronoi regions" but that is no longer a > valid argument and I want them OFF (I guess that it was the default in > earlier versions). > > If it is of intrerest to any one I'm testing the following tool chain; > Fritzing -> Gerber file -> pcb2gcode -> G-Code -> EMC2 > and it works grate. > > WR/ B Mathias Johansson > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > Pcb2gcode-devel mailing list > Pcb...@li... > https://lists.sourceforge.net/lists/listinfo/pcb2gcode-devel > |
|
From: Mathias J. <bm...@te...> - 2010-11-19 21:53:07
|
Hello! I'm sorry to disturb you whide a probably stupid question, but I have tried '--help' and to RTFM to no avail :'( . Is it possible to turn off voronoi regions in version 1.0.6 and use 'normal' outlines instead? The reason is that I have a hard time figuring out where to place and solder the components (I'm using some SMC) ;-) . The "millproject" file at http://reprap.org/wiki/PCB_Milling#Fritzing turns them ON using "generate voronoi regions" but that is no longer a valid argument and I want them OFF (I guess that it was the default in earlier versions). If it is of intrerest to any one I'm testing the following tool chain; Fritzing -> Gerber file -> pcb2gcode -> G-Code -> EMC2 and it works grate. WR/ B Mathias Johansson |
|
From: chrysn <ch...@fs...> - 2010-11-18 08:27:37
|
On Tue, Nov 16, 2010 at 11:20:03PM +0100, Bernhard Kubicek wrote: > Hi, so i spent the last couple of hours creating the patches of the stuff i > changed the last week. im a bit confused by the 0004 patch (especially the basename thing): is this supposed to work in a way that if you give a basename, all files are named "basename_foo", but the --foo-output options can override this? (because it does not seem that way, but i'm not sure if i miss something that makes it work) up to the preceding patch, it's merged and published in my patches branch. regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom |
|
From: chrysn <ch...@fs...> - 2010-11-17 20:58:16
|
On Wed, Nov 17, 2010 at 09:41:45PM +0100, Patrick Birnzain wrote: > >Hi, so i spent the last couple of hours creating the patches of the > >stuff i changed the last week. > I'll try to apply your patches to the SF master this week. i am just as of receiving that mail going though them myself, and merging them with my patches (especially, i've written a man page, and the new options need documenting there) -- i suggest to stay tuned to my patches branch at [1], where i expect the patches to end up in the course of the evening. (@bernhard: i probably won't merge it on the cnc machine immediately lacking vpn access to 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 |
|
From: Patrick B. <pbi...@us...> - 2010-11-17 20:42:00
|
> Hi, so i spent the last couple of hours creating the patches of the > stuff i changed the last week. Looks like i have a lot of catching up to do. I'm sincerely sorry i haven't answered sooner, it's just that i am awfully busy at the moment. I'll try to apply your patches to the SF master this week. -- Patrick |
