[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
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 <pcjc2@xxxxxxxxx>:
> 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)
>
>
>
> _______________________________________________
> 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