Menu
▾
▴
pcb2gcode-devel
|
From: Bernhard K. <ber...@gm...> - 2010-11-15 09:47:37
|
Hi Crysn!
Hi Patric, hi everybody else!
a short status update after a couple of night working on PCB2Gcode:
* there is now a switch -metric. A variable double unit=1 will be
overwritten by 1/25.4 for that, and used for lenghts. dpi and output are
unchanged
* You can specify preamble und postamble files, with individual start up/end
commands for your mill.
* path-optimisation One routine calculates the distance betwwen a punkt and
a linie. The rastered path is an array of x-y coordinaten. For each point of
this array x_n is is evaluated if its already on the line between
neighboring pixels: If the point x_n' distance to the line x_{n-1}x_{n+1}
is smaller than a threshold,it is deleted.This is done until there no more
change. The deletion is done using std::list...
First, I wanted to delete longer tracks at once, however it was slow as
hell:
(int from=0;from<n-2;from++)
(int to=from+2;to<n;to++)
(int testpoint=from+1;testpoint<to;testpoint++)
if all testpoints obsolet->delete
Result: duplicated paths are not 100% equal. The simplification depends of
the rotational direction. But the deviations are in the range of one pixel..
* The floodfill needs "components", groups of pixels with same colors,
based on the black/white rendered gerber. Outlines have 1 pixel width. If
this line is not arranged vertical/horizontal, the floodfill needs to
respect diagonal pixels. Otherwise one outline=multiple components.
* -drilmilll mills holes by using the same tool as for the outline milling.
E.g. the depth-steps and diameter. Larger holes are done by circle
movements..
* debug-images have useful names, partially "callingfunction_layername.png".
* metaboard2.sh is a bash script that exports the layers from a eagle brd
file per command line option, and calls pcb2gcode with some settings.
* output gcode now uses variables for z values, emc style #1, #2,...
Open problems:
* Outline does not work for me. My testing-pcb has a large interior hole (
eagle puts it both in outline and drill/wtf?). In this case, the outline
calculation is faulty or creates an endless loop. One problem was the
nondiagonal floodfill, sadly not the only one.
* I would like that the exporter-classes return a string to the main,
instead of writing files by them selfs. Thereby one can create combined
files, for drilling+milling, and drilling+milling+outline, to check the
output in e.g. EMC.
This is not so easy, as ngc-exporter exists only once, and i need multiple
layers individually.
* offset und mill-diameter should be differentiated, otherwise the outline
milling is corrupted while creating large offsets.
* Style... I am used to tabs and other braket rules.
* I need a way of making my changes available to you. Imho a patch is not
the best solution, and I am not confident enough with git to just upload it.
Maybe chrysn can help me there.
If somebody could solve some of these problems, it would be awesome.
I would propose that chrysn and me will combine our changes, and the bring
them back to the community.
Otherwise, if somebody wants my current code, i can send it by mail...
I am a bit helpless with version-management...
Bernhard Kubicek
Metalab/Vienna/Austria
0664 620 7748
|
|
From: Bernhard K. <ber...@gm...> - 2010-11-16 11:24:14
|
Hi, i just updated my git, and some features i added is already in the git.
I will merge my stuff with the current git, and then try to upload it..
sorry...
On Mon, Nov 15, 2010 at 10:39 AM, Bernhard Kubicek <
ber...@gm...> wrote:
> Hi Crysn!
> Hi Patric, hi everybody else!
>
> a short status update after a couple of night working on PCB2Gcode:
>
> * there is now a switch -metric. A variable double unit=1 will be
> overwritten by 1/25.4 for that, and used for lenghts. dpi and output are
> unchanged
>
> * You can specify preamble und postamble files, with individual start
> up/end commands for your mill.
>
> * path-optimisation One routine calculates the distance betwwen a punkt and
> a linie. The rastered path is an array of x-y coordinaten. For each point of
> this array x_n is is evaluated if its already on the line between
> neighboring pixels: If the point x_n' distance to the line x_{n-1}x_{n+1}
> is smaller than a threshold,it is deleted.This is done until there no more
> change. The deletion is done using std::list...
> First, I wanted to delete longer tracks at once, however it was slow as
> hell:
> (int from=0;from<n-2;from++)
> (int to=from+2;to<n;to++)
> (int testpoint=from+1;testpoint<to;testpoint++)
> if all testpoints obsolet->delete
>
> Result: duplicated paths are not 100% equal. The simplification depends of
> the rotational direction. But the deviations are in the range of one pixel..
>
> * The floodfill needs "components", groups of pixels with same colors,
> based on the black/white rendered gerber. Outlines have 1 pixel width. If
> this line is not arranged vertical/horizontal, the floodfill needs to
> respect diagonal pixels. Otherwise one outline=multiple components.
>
> * -drilmilll mills holes by using the same tool as for the outline milling.
> E.g. the depth-steps and diameter. Larger holes are done by circle
> movements..
>
> * debug-images have useful names, partially
> "callingfunction_layername.png".
>
> * metaboard2.sh is a bash script that exports the layers from a eagle brd
> file per command line option, and calls pcb2gcode with some settings.
>
> * output gcode now uses variables for z values, emc style #1, #2,...
>
> Open problems:
> * Outline does not work for me. My testing-pcb has a large interior hole (
> eagle puts it both in outline and drill/wtf?). In this case, the outline
> calculation is faulty or creates an endless loop. One problem was the
> nondiagonal floodfill, sadly not the only one.
>
> * I would like that the exporter-classes return a string to the main,
> instead of writing files by them selfs. Thereby one can create combined
> files, for drilling+milling, and drilling+milling+outline, to check the
> output in e.g. EMC.
> This is not so easy, as ngc-exporter exists only once, and i need multiple
> layers individually.
>
> * offset und mill-diameter should be differentiated, otherwise the outline
> milling is corrupted while creating large offsets.
>
> * Style... I am used to tabs and other braket rules.
>
> * I need a way of making my changes available to you. Imho a patch is not
> the best solution, and I am not confident enough with git to just upload it.
> Maybe chrysn can help me there.
>
> If somebody could solve some of these problems, it would be awesome.
>
> I would propose that chrysn and me will combine our changes, and the bring
> them back to the community.
> Otherwise, if somebody wants my current code, i can send it by mail...
> I am a bit helpless with version-management...
>
> Bernhard Kubicek
> Metalab/Vienna/Austria
> 0664 620 7748
>
>
|
|
From: Bernhard K. <ber...@gm...> - 2010-11-16 12:36:52
|
I have made a small patch. On this machine, i am not able to actually test the patch, so these are rather small changes.. Implemented: * improved color choosing. It's quite unnecessary, as there is little change for conflicts, but now there is no chance that stupid colors like black/white are picked. * I was trying to understand the underlying workflow in surface.*, and made some comments. * I fear, that there is a still a problem in calculate_outline. If the outline is curved and only one pixel thin, like in standard eagle export, it does not work as expected, and the loop will not be left. For error checking i hence put some range checking. As mentioned this is my first patch. Ever. So please point out any problems.. bernhard |
|
From: Bernhard K. <ber...@gm...> - 2010-11-16 22:20:16
Attachments:
0001-nicer-image-name.patch
0002-added-a-metric-option-so-that-the-drill-diameters.patch
0003-path-simplification-implementation.-It-is-however-di.patch
0004-milling-of-holes-using-a-small-mill-head-activated.patch
0005-an-possibility-to-specify-gcode-files-that-are-used.patch
0006-diagonal-pixels-need-to-be-included-in-the-flood-fil.patch
0007-i-dont-unterstand-why-this-patch-is-necessary.patch
|
Hi, so i spent the last couple of hours creating the patches of the stuff i changed the last week. It seems that i made some minor mistakes in using git: some changes i wanted to have in one patch are only in the next one. Still, if applied in chronological order, things should be alright. Hope you like it, the patches are based on todays git version... greetings, bernhard On Tue, Nov 16, 2010 at 1:36 PM, Bernhard Kubicek < ber...@gm...> wrote: > I have made a small patch. On this machine, i am not able to actually test > the patch, so these are rather small changes.. > > Implemented: > * improved color choosing. It's quite unnecessary, as there is little > change for conflicts, but now there is no chance that stupid colors like > black/white are picked. > * I was trying to understand the underlying workflow in surface.*, and made > some comments. > * I fear, that there is a still a problem in calculate_outline. If the > outline is curved and only one pixel thin, like in standard eagle export, it > does not work as expected, and the loop will not be left. For error checking > i hence put some range checking. > > As mentioned this is my first patch. Ever. So please point out any > problems.. > > bernhard > > |
|
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 |
|
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: 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-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: 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: 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: 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-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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X