Re: gEDA-user: PCB gcode generation
Am 01.05.2011 um 03:18 schrieb Peter Clifton: As a feature request which came from that discussion, it seems that it might be nice to provide the option of special casing the handling of outline layers. The expected convention is to put a narrow series of lines around the boards to denote their outline, the path of these lines forms the the centre-line of the finished board. The problem we were addressing is that the gcode export (not unreasonably) treated this as a track to be isolation routed. See patches 0018 ... 0020: https://bugs.launchpad.net/pcb/+bug/699497/+attachment/1786373/ +files/0018-HID-gcode-don-t-do-isolation-milling-on-the-outline-.patch https://bugs.launchpad.net/pcb/+bug/699497/+attachment/1786374/ +files/0019-HID-gcode-fetch-the-board-s-extents-from-the-outline.patch https://bugs.launchpad.net/pcb/+bug/699497/+attachment/1786375/ +files/0020-HIG-gcode-limit-the-produced-G-code-to-the-outline.patch Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB gcode generation
On Sun, 2011-05-01 at 14:33 +0200, Markus Hitter wrote: Am 01.05.2011 um 03:18 schrieb Peter Clifton: As a feature request which came from that discussion, it seems that it might be nice to provide the option of special casing the handling of outline layers. The expected convention is to put a narrow series of lines around the boards to denote their outline, the path of these lines forms the the centre-line of the finished board. The problem we were addressing is that the gcode export (not unreasonably) treated this as a track to be isolation routed. See patches 0018 ... 0020: Doh! Duplicated effort :( Anyway, the workaround I had was quick, and I suspect orthogonal: http://repo.or.cz/w/geda-pcb/pcjc2.git/commitdiff/f8007dfb9846854521d9812930d6b6284523b7dd (Which involves converting the board's outline into a polygon representing the board area.) https://bugs.launchpad.net/pcb/+bug/699497/+attachment/1786373/ +files/0018-HID-gcode-don-t-do-isolation-milling-on-the-outline-.patch https://bugs.launchpad.net/pcb/+bug/699497/+attachment/1786374/ +files/0019-HID-gcode-fetch-the-board-s-extents-from-the-outline.patch https://bugs.launchpad.net/pcb/+bug/699497/+attachment/1786375/ +files/0020-HIG-gcode-limit-the-produced-G-code-to-the-outline.patch -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB gcode generation
Probably we won't agree on that ever. The patchset is there, do with it what you think is the best thing to do. At the time I posted very specific objections to some of the patches; if you didn't bother to answer is your problem. Of course none of the developers will ever commit a patch that breaks functionality for any of the users. 2011/4/29 Markus Hitter m...@jump-ing.de: Am 29.04.2011 um 08:47 schrieb Alberto Maccioni: ... but it broke the minimum distance path optimization, This was fixed the day you mentioned it. Perhaps a day later :-) Probably you didn't notice that it is still boken, as I wrote again. Probably we won't agree on that ever. The patchset is there, do with it what you think is the best thing to do. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB gcode generation
Am 30.04.2011 um 09:14 schrieb Alberto Maccioni: At the time I posted very specific objections to some of the patches; if you didn't bother to answer is your problem. Your message was clearly a don't touch anything. You had objections with about any of the enhancements, couldn't propose solutions and didn't bother to recognize adjustments made for your single use-case. Of course none of the developers will ever commit a patch that breaks functionality for any of the users. OK, let's one user be happy and cripple all others. This is at least a strategy. It whouldn't bother me to leave the patchset where it is if I hadn't difficulties to convince people to use gEDA. Which leads to the question: is there a way to compile exporters as a plug-in? Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB gcode generation
On Sat, 2011-04-30 at 12:24 +0200, Markus Hitter wrote: Am 30.04.2011 um 09:14 schrieb Alberto Maccioni: At the time I posted very specific objections to some of the patches; if you didn't bother to answer is your problem. I've not been following the technical details of this discussion, but I find the tone it is taking quite concerning. The gEDA and PCB projects very strongly aim to foster a friendly working environment and encourage contribution to the project. There is obviously a feature here that people have requested or required, and more importantly - that someone has taken the effort to implement. That merits effort in trying to constructively review and improve the patches if necessary. Without referring to each others answers (and starting a flame war!), I think it would be useful if Markus and Alberto both sent a brief summary email detailing the issue under debate, trying to objectively present BOTH points of view. I don't want to see any personal attacks, please remain diplomatic! I don't know enough of the gcode HID to know how to review or test effectiveness of patches, so someone needs to explain the issues for me. Finally.. It whouldn't bother me to leave the patchset where it is if I hadn't difficulties to convince people to use gEDA. Which leads to the question: is there a way to compile exporters as a plug-in? It is currently very important NOT to do this, and to get any useful outstanding patches landed. Andrew Poelstra and I are both working on quite invasive refactoring within PCB, and it is highly likely that the longer patches stay outstanding, the harder they will be to get applied. It is also very probable that plugins will need patching to keep them in sync with the core PCB changes. (Depending on what data-structures and APIs they use). The scope we are working on is everything which can be built and tested from PCB's build system. We can't commit to providing patches for external plugins or patch series. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB gcode generation
Peter, my intention was not to start any war and I provided my review of the patches to improve them; you can check the archives and judge for yourself; in fact I agree 100% with what you said. Now I'll just list my objections trying to be more descriptive than before. An introduction to what the gcode exporter does: it prints a pcb like the png exporter, bloating the elements by some amount, then extracts the edges and prints them in a format that is understandable to CNC milling machines; also prints another file containing all drills. Now the patches that in my opinion cause problems: 1-HID-gcode: let the system library allocate the temporary file. Milling pcbs has one fundamental limit, which is the diameter of the milling tool; since you cannot cut anything smaller than that, all tracks and elements must have a minimum separation. But how would you check if this is the case? You can just look at the intermediate png file, the one that has the bloated elements; if you see that two distinct elements touch, it means that the chosen tool is too large so you can either use a smaller tool or move the elements further away. This is the reason why the intermediate file is needed and cannot be temporarily allocated. So I would advise to insert a configuration switch to remove or not the file. 5-HID-gcode: add a flag wether to produce advanced G-code. Gcode is a language, and as such there are many ways to do one thing; for example a drilling cycle can be done as the sum of single operations (go to the surface, drill, retract at various speeds) or as a single drilling cycle which has a code by itself. As you can imagine a file that uses the latter is more readable. The original exporter uses such enhancements, which by the way have been in the language from the beginning and are supported by the major interpreters (Mach and EMC2). The patch adds the possibility to produce a more basic gcode, which is longer and less readable but apparently can be digested by a larger amount of interpreters. My concern is that using the basic version by default makes the output files less readable and more bulky when in fact in 99% of the cases the advanced would be fine. I would do the opposite, produce basic code only when commanded to do so. 16-HID-gcode: sort drills not only by distance, but also by diameter. Currently all the drills are written in the same file, and the only ordering that is done is based on the minimum distance from the previous drill, starting from the one closest to the origin; this prevents the milling machine from jumping all around the board. This is a very crude way of operating, in fact some people requested to distinguish drills of different size. The patch does the following; drill = sort_drill_distance (drill, n_drill); qsort (drill, n_drill, sizeof (struct drill_struct), compare_drill_diameter); The result is that drills are sorted by size and is possible to insert a stop code to change the drill bit when needed; unfortunately the path minimization is not good any more, because it acted before. However the fix is fairly easy, just perform the path optimization for every set of drills that have the same size. One more important thing is that not everyone may like to sort by size, so I would add a configuration switch for that. I hope these comments won't be interpreted again as don't change my code. By the way, it seems that my original gcode patch is formally still uncommitted; since it has already made it to a release (ok, a real developer cleaned everything up) why not change its status? Or is it dependent on the documentation? Best regards, Alberto 2011/4/30 Peter Clifton pc...@cam.ac.uk: On Sat, 2011-04-30 at 12:24 +0200, Markus Hitter wrote: Am 30.04.2011 um 09:14 schrieb Alberto Maccioni: At the time I posted very specific objections to some of the patches; if you didn't bother to answer is your problem. I've not been following the technical details of this discussion, but I find the tone it is taking quite concerning. The gEDA and PCB projects very strongly aim to foster a friendly working environment and encourage contribution to the project. There is obviously a feature here that people have requested or required, and more importantly - that someone has taken the effort to implement. That merits effort in trying to constructively review and improve the patches if necessary. Without referring to each others answers (and starting a flame war!), I think it would be useful if Markus and Alberto both sent a brief summary email detailing the issue under debate, trying to objectively present BOTH points of view. I don't want to see any personal attacks, please remain diplomatic! I don't know enough of the gcode HID to know how to review or test effectiveness of patches, so someone needs to explain the issues for me. Finally.. It whouldn't bother me to leave the patchset where it is if I hadn't difficulties to convince people to use gEDA.
Re: gEDA-user: PCB gcode generation
On Sun, 2011-05-01 at 00:11 +0200, Alberto Maccioni wrote: I hope these comments won't be interpreted again as don't change my code. By the way, it seems that my original gcode patch is formally still uncommitted; since it has already made it to a release (ok, a real developer cleaned everything up) why not change its status? Or is it dependent on the documentation? Thanks for the explanation. I was actually helping someone on #geda IRC earlier who was using the gcode HID to produce a toolpath to cut out a panel of boards, so I got a chance to dig into it a little, even firing up EMC2 in simulation mode to view the toolpaths it produced. I'm uncertain what you mean by you original gcode patch is formally still uncommitted. Do you mean that the bug is open, or that not all of your work has been committed? If it is just a matter of closing the bug, please feel free to mark the bug Fix released, it is probably just an oversight on our part. We're all keen for interested parties to contribute and take action on those areas of the project which interest them. In case you're interested about the stuff I was talking about on #geda: As a feature request which came from that discussion, it seems that it might be nice to provide the option of special casing the handling of outline layers. The expected convention is to put a narrow series of lines around the boards to denote their outline, the path of these lines forms the the centre-line of the finished board. The problem we were addressing is that the gcode export (not unreasonably) treated this as a track to be isolation routed. As a quick workaround, I patched a new action on top of the PCB+GL code-base. The PCB+GL branch contains a simple algorithm to calculate a polygon (or polygons for a panel of boards) representing the physical board shape. PCB+GL uses this to render the solder-mask layer accordingly in its 3D (and 2D) rendering. The simple action I wrote uses the existing outline layer to determine the board shape, then rips out the contents of the original outline and replaces it with polygons. (One polygon per board). The gcode exporter then produced output suitable for cutting the boards out (using EMC2 to handle the tool offset etc..). Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB gcode generation
... but it broke the minimum distance path optimization, This was fixed the day you mentioned it. Perhaps a day later :-) Probably you didn't notice that it is still boken, as I wrote again. The point is that the above optimization has to be applied as the last operation on every set of drills (meaning a set of same size); and above all, if someone doesn't need the splitting by size there should be a switch to enable/disable it. 2011/4/29 Markus Hitter m...@jump-ing.de: Am 28.04.2011 um 11:14 schrieb Alberto Maccioni: There was a patch that did something like that, ... You probably mean this set of patches: https://bugs.launchpad.net/pcb/+bug/699497 ... but it broke the minimum distance path optimization, This was fixed the day you mentioned it. Perhaps a day later :-) Am 26.04.2011 um 21:26 schrieb Mikey Sklar: - Is there a way to break up the drill file so that I can switch bits? I'm getting by with using one bit for all vias, but it is not ideal. With the above patchset, drills are sorted by diameter and marked with comments, so it isn't too difficult to hand-edit the G-Code file. You can get G81 drill cycles with advanced g-code or a replacement using G0/G1 by default. - I'm struggling with cut lines. Specifically, cutting out the mounting holes and the circuit board edges. The patchset also introduces milling the outline layer, if only a rectangle one for now. Holes can be drill-milled, so the most common cases go automatically. For more complex cases, make one layer for each type of milling, then export with only that layer visible. Layers in the solder/bottom group are mirrord, others not. Repeat for each milling case. Not exactly ideal, but a more general approach quickly becomes pretty complex. Oh, and I hope the patchset still applies, it was last adjusted on march 7th. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB gcode generation
Am 29.04.2011 um 08:47 schrieb Alberto Maccioni: ... but it broke the minimum distance path optimization, This was fixed the day you mentioned it. Perhaps a day later :-) Probably you didn't notice that it is still boken, as I wrote again. Probably we won't agree on that ever. The patchset is there, do with it what you think is the best thing to do. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB gcode generation
There was a patch that did something like that, but it broke the minimum distance path optimization, so your machine will do a great deal of jumps while drilling. I can write a new patch, hoping that someone will ever review and merge it; what G codes do you use for changing bits? Regarding the milling cuts I really don't know how it could be done; in principle it's possible to use different depths for different layers, but how would you choose which paths to mill? Some help will be needed from the ones that know how the png exporter works. A.M. 2011/4/28 John Griessen j...@ecosensory.com: On 04/26/2011 02:26 PM, Mikey Sklar wrote: Is there a way to break up the drill file so that I can switch bits? I'm getting by with using one bit for all vias, but it is not ideal. I've not used the Gcode export yet, but this sounds like something you can postprocess. grep or sed on the drill file should get you the separation you want... Nope. I ran export and it gives 387 G81 lines where I get a fab drawing with three different sizes totalling 387 holes on one of mine... - I'm struggling with cut lines. Specifically, cutting out the mounting holes and the circuit board edges. It would great if there was a way to select specific traces or vias for different mill-depths. Even better if I could control the order in which the cuts are made so I don't have a circuit board that has been cut free from it's clamping before the mount holes were cut. When I export Gcodes, I get a file, tek_7k_flex.gcode.outline.cnc that seems to be only about the outline, I get a sequence of 389 polygons that start and stop near eachother. Nothing is mentioned about the cutter size, but I guess they overlap so as to cut out the outline along the centerline of the outline trace. (My outline was defined by a layer called outline holding just a 10 mil wide trace, the center of which was the desired board edge.) tek_7k_flex.gcode.front.cnc contained 465 polygons, so it was different... John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB gcode generation
Am 28.04.2011 um 11:14 schrieb Alberto Maccioni: There was a patch that did something like that, ... You probably mean this set of patches: https://bugs.launchpad.net/pcb/+bug/699497 ... but it broke the minimum distance path optimization, This was fixed the day you mentioned it. Perhaps a day later :-) Am 26.04.2011 um 21:26 schrieb Mikey Sklar: - Is there a way to break up the drill file so that I can switch bits? I'm getting by with using one bit for all vias, but it is not ideal. With the above patchset, drills are sorted by diameter and marked with comments, so it isn't too difficult to hand-edit the G-Code file. You can get G81 drill cycles with advanced g-code or a replacement using G0/G1 by default. - I'm struggling with cut lines. Specifically, cutting out the mounting holes and the circuit board edges. The patchset also introduces milling the outline layer, if only a rectangle one for now. Holes can be drill-milled, so the most common cases go automatically. For more complex cases, make one layer for each type of milling, then export with only that layer visible. Layers in the solder/bottom group are mirrord, others not. Repeat for each milling case. Not exactly ideal, but a more general approach quickly becomes pretty complex. Oh, and I hope the patchset still applies, it was last adjusted on march 7th. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB gcode generation
On 04/26/2011 02:26 PM, Mikey Sklar wrote: Is there a way to break up the drill file so that I can switch bits? I'm getting by with using one bit for all vias, but it is not ideal. I've not used the Gcode export yet, but this sounds like something you can postprocess. grep or sed on the drill file should get you the separation you want... Nope. I ran export and it gives 387 G81 lines where I get a fab drawing with three different sizes totalling 387 holes on one of mine... - I'm struggling with cut lines. Specifically, cutting out the mounting holes and the circuit board edges. It would great if there was a way to select specific traces or vias for different mill-depths. Even better if I could control the order in which the cuts are made so I don't have a circuit board that has been cut free from it's clamping before the mount holes were cut. When I export Gcodes, I get a file, tek_7k_flex.gcode.outline.cnc that seems to be only about the outline, I get a sequence of 389 polygons that start and stop near eachother. Nothing is mentioned about the cutter size, but I guess they overlap so as to cut out the outline along the centerline of the outline trace. (My outline was defined by a layer called outline holding just a 10 mil wide trace, the center of which was the desired board edge.) tek_7k_flex.gcode.front.cnc contained 465 polygons, so it was different... John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB gcode generation
Thank you for adding gcode export to gEDA/PCB. I've been using it to mill boards PCBs with great results using with EMC2 and a $600 zentoolworks CNC. Two questions: - Is there a way to break up the drill file so that I can switch bits? I'm getting by with using one bit for all vias, but it is not ideal. - I'm struggling with cut lines. Specifically, cutting out the mounting holes and the circuit board edges. It would great if there was a way to select specific traces or vias for different mill-depths. Even better if I could control the order in which the cuts are made so I don't have a circuit board that has been cut free from it's clamping before the mount holes were cut. I've been creating multiple pcb files with the objects that I need different mill-depths. This kind of works, but quickly turns into a nightmare when changes are made to the original circuit. Does anyone have more elegant solutions? I'm happy to use a 3rd party program like gcam or even inkscape if necessary. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
