Re: gEDA-user: Enhancements for gEDA/pcb G-code export
Hello, here some comments about your patches; I think most of them are good, but the gcode simplifications should not be enabled by default; in fact the most commonly used CNC controllers (EMC and MACH3) support all of the gcode features, it's RepRap that is behind an not standard. In detail: Avoid more than one G or M code per line. Please use a flag to enable this, as it tends to generate less readable files (esp. drilling with standard codes). Introduce a flag on whether to use a drill cycle for drilling. I would instead have a flag to disable M81 drill cycles, disabled by default. Add a flag whether to use variables in G-code. I would instead have a flag to disable variables, something like: avoid using G-code variables. Some non-standard machine controllers don't understand them switch from tool-radius to tool-diameter in the user interface. What is the reason for switching from tool radius to tool diameter? I think tool radius gives a better understanding of the effective distance between track and cut; in fact don't you find the following a little hard to read? Milling tool diameter, or twice the offset of the G-code track from the resulting copper track Simplify code a bit I don't understand what simplification is done here; the new code is longer and has more variables; is it easier to read? I find it less immediate. Sort drills not only by distance, but also by diameter. I probably didn't explain correctly the original feature: it doesn't really sort by distance from origin, it puts drills in the lowest relative distance sequence, starting from zero. This way the tool starts from zero and makes the least amount of movement to reach the new hole; now, I know that there is probably an entire class of very smart path minimization algorithms but this one proved to decrease the overall length quite a bit, so don't remove it. Regarding the hole diameter not everybody uses different bits for different hole sizes, so this feature should be enabled via a flag; and for every diameter I would run the path minimization as well. By the way, even without tool changer there's no need to split drills in different files, just insert M60 (pause) after every set of holes. Anyways it's good that somebody else is finally using the g-code exporter. Too bad the PCB documentation doesn't mention it; some time ago I did write a patch to update docs but it never went to the repository. Best regards, Alberto 2010/10/23 Markus Hitter m...@jump-ing.de: Am Freitag, den 22.10.2010, 23:54 +0200 schrieb Markus Hitter: https://sourceforge.net/tracker/?func=detailaid=3093302group_id=161080atid=818428 Traumflug's wishlist in the Patches section, in case this long link doesn't work. New patches today: HID-gcode: remove a leftover debug-printf. HID-gcode: provide info about drill diameters in G-code as well. While this is currently unsorted, it's helpful for hand-editing already. HID-gcode: sort drills not only by distance, but also by diameter. This should help greatly when using a tool changer. Next step would be to actual insert tool change commands and/or split G-code output files by drill diameter. The later is for manual tool changing, then. HID-gcode: report one drill diameter only once in the output file. Cheers, Markus ___ 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: Enhancements for gEDA/pcb G-code export
Introduce a flag on whether to use a drill cycle for drilling. I would instead have a flag to disable M81 drill cycles, disabled by default. Well, the flag is supposed to do exactly this. Do you think there should be a better wording? All I was saying is that advanced features should be enabled by default, and I think it's better to have something like: Disable feature XX (unchecked by default) than: Enable feature XX (checked by default) Add a flag whether to use variables in G-code. I would instead have a flag to disable variables, something like: avoid using G-code variables. Some non-standard machine controllers don't understand them idem Sort drills not only by distance, but also by diameter. I probably didn't explain correctly the original feature: it doesn't really sort by distance from origin, it puts drills in the lowest relative distance sequence, starting from zero. This way the tool starts from zero and makes the least amount of movement to reach the new hole; now, I know that there is probably an entire class of very smart path minimization algorithms but this one proved to decrease the overall length quite a bit, so don't remove it. The sorting by distance is still there, just sorting by diameter takes precedence. Now, this is plain wrong: your replacement algorithm orders holes by distance from origin; the original algorithm does something very different: starting from the origin it builds a sequence of holes so that the path from one to the next is lowest. This has to be the last operation, because if you swap again the order you have the same problem you started with, i.e. the drill jumping all over the board wasting time. So I repeat that if you want to order also by size you should create a separate list of holes for every size you have, and for each list run my original algorithm. Try yourself the difference by visualizing the tool path in both cases. Regarding the hole diameter not everybody uses different bits for different hole sizes, so this feature should be enabled via a flag; Uh, yet another flag. And I consider at least three additional flags, e.g. feed rates for vertical vs. horizontal movement, as unavoidable. How many flags can be put into this dialog before it no longer fits onto the screen? Hmm. Looks a bit difficult to find an agreement. If there's hand-editing of the G-code needed, I'd consider this as a failure of the exporter. And I hate adding user-visible features, stuff should just work. Hence the tendency to switch flags on the safe, works everywhere side by default. This is not something that can be substituted by hand editing, it has to do with the equipment you have: how many people do you think will use a tool changer? Right now 0 out of 2 users, but I bet only a very small percentage will ever do it, so the most common drill operation will be done with only one drill. So I'd say that drill sorting definitely has to be optional. What you define safe features is just the set of features supported by a not yet mature particular machine (RepRap) which accounts for an extremely small percentage of hobby machines; G-code has been working with variables and multiple commands for tens of years, and probably your machine will be upgraded shortly. Also, hand editing is very common in the CNC world, due to the fact that you often adjust your codes on the field, based on what you equipment can do at the moment. Best regards, Alberto ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Spice Netlists from Schematics with Hierarchy
On Oct 27, 2010, at 4:03 PM, Shane Kaiser wrote: Hello All: I am trying to create hierarchy in my schematics. I have read the brorson info on using .subckt. I really like to be able to push down into and pop out of schematics for readability. Is it possible to use .subckt and be able to push/pop through the schematic hierarchy using gschem and gnetlist? Yes. What you want to do is disable hierarchy traversal in gnetlist, so you can use source= attributes to navigate in gschem but not have them generate a flat netlist. See: http://archives.seul.org/geda/user/Nov-2008/msg00489.html John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Enhancements for gEDA/pcb G-code export
Am 27.10.2010 um 22:57 schrieb Alberto Maccioni: Actually the code is already working; I'm glad the current code works for you, it doesn't for me. Please pick up what you think is useful, I'll maintain a patch for the remaining customisations in the RepRap Wiki. We need software working out of the box there, educating people about something is almost no option. 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
