[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Enhancements for gEDA/pcb G-code export
Thanks for looking into this, Alberto
Am 27.10.2010 um 08:33 schrieb Alberto Maccioni:
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.
While these "common" controllers - I have seen many real world
controllers but none with the parameter feature, yet - understand
parameter-less G-code as well, it's no problem to swap the default.
"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?
"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"
dito
"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;
It's a simple change for ease of use. Milling tools are sold by
diameter and a user is not really interested in which algorithms or
geometrical adjustments are needed to get the correct results.
"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.
In conjunction with the following patches, yes.
"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.
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.
Whatever, outline milling hasn't appeared yet, so back to coding :-)
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user