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
gEDA-user: Can i use geda for electric indoor installation?
i want to make a scheme like this: http://images.autodesk.com/emea_dach_main_germany/images/2g_acadelec_2012_auto_wire_number_1_large_1264x711.jpg Is geda the right tool for it? Has anyone experience with that? Do you have some screenshots of nice schemes of house electric indoor installation? Additional information like wiretype or wire ID would be nice to have next to the line of the wire. Kind regards, -- Jonas Stein n...@jonasstein.de ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Can i use geda for electric indoor installation?
Jonas Stein n...@jonasstein.de writes: i want to make a scheme like this: http://images.autodesk.com/emea_dach_main_germany/images/2g_acadelec_2012_auto_wire_number_1_large_1264x711.jpg Is geda the right tool for it? Yes, I'd think so. You will need to make a library of symbols. Or is there such a library for gschem already? Has anyone experience with that? Do you have some screenshots of nice schemes of house electric indoor installation? Additional information like wiretype or wire ID would be nice to have next to the line of the wire. Sure, you can attach attributes to wires. -- Stephan ___ 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
