[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
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 <mah@xxxxxxxxxxx>:
> Am Freitag, den 22.10.2010, 23:54 +0200 schrieb Markus Hitter:
>>
>> https://sourceforge.net/tracker/?func=detail&aid=3093302&group_id=161080&atid=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@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user