Closed GoogleCodeExporter closed 8 years ago
I have added support for G70, G71, G90 and G91 commands in the RS274.cpp file
and it
gets further but I'm afraid it still doesn't work correctly. The polygon
intersection code doesn't seem to be working as it hasn't merged intersecting
traces.
It also looks like some of the pad sizes are too big. I don't know if this is a
flaw in interpreting the aperture information or if these pads are constructed
by an
'area fill'. Is there any chance of getting a screenshot of what the board is
supposed to look like?
Original comment by David.Ni...@gmail.com
on 29 Oct 2009 at 11:57
I think this should go to heekscad's issue list, because the gerber support is
heekscad's feature, not heekscnc's. But not a big problem.
Original comment by celeron55@gmail.com
on 29 Oct 2009 at 12:24
It seems that someone has broken the UnionPolygon code in the gerber loading
code, it
doesn't work with an example gerber file i made it to work with...
Original comment by celeron55@gmail.com
on 29 Oct 2009 at 12:40
I got now the error:
->{ (44.577, -28.1305), (44.577, -28.1305), (44.577, -28.1305), (44.577, -28.1305),
(44.577, -28.1305), (44.577, -28.1305), (44.577, -28.1305), (44.577, -28.1305)
}: PolyCW
reversing polygon
...
reversing polygon
reversing polygon
terminate called after throwing an instance of 'Standard_ConstructionError'
Aborted
The image of the board is attached. Thanks! :-)
Original comment by casai...@gmail.com
on 29 Oct 2009 at 12:46
Attachments:
Perttu,
I'm sure it was me. I will work through the changes I made. I made some changes
in an attempt to support arc-based traces. I got them to work but the area fill
traces still didn't work with my example. I tried changing the system to use
OpenCascade curves (made up of lines and arcs) but I could never get the union
code
to work. I must have inadvertently checked some of these attempts into the main
branch. I will try to revert my changes.
Is there any chance you could add your Gerber file to this fault so that I have
another example data file? The one I had never did work completely due to the
arc-based traces and area-filled pads.
Thanks
David Nicholls
Original comment by David.Ni...@gmail.com
on 29 Oct 2009 at 8:33
I think Perttu was right originally. It doesn't make any difference if I
rollback
all my RS274X changes. If I rollback to the second last version of Polygon.cpp
in
HeeksCAD then the intersections are much closer although they're not perfect.
Sorry but I will have to leave this for another day. It's too late for me to
start
looking into this code now.
Original comment by David.Ni...@gmail.com
on 30 Oct 2009 at 12:49
I have tried rewriting this using FastCurves as well as straight OpenCascade
'faces'
but I can't get the intersection functionality to work in all situations. I
don't
understand the intersection functionality well enough to change anything yet.
I'm going to give this one a rest for a while now. I have other things I need
to
focus my time on.
Original comment by David.Ni...@gmail.com
on 31 Oct 2009 at 10:20
I have tried using opencascade too, but it seems not to be useful in this. I
have
attached the two test files which i used for testing the polygon code.
I think maybe we should just use a raster-type conversion. It would be quite
trivial
and easy, and at least we could get it done.
There is one open source program for generating g-code from gerber files, which
uses
the raster method:
http://sourceforge.net/projects/pcb2gcode/
Maybe we should ask the developer if he'd like to make a library out of that,
so it
could be used as a backend in programs like HeeksCAD. It would benefit both, i
guess.
I'm not quite interested in developing the current gerber loading code either,
so we
need to find a new, more fun way to do it. :-)
Original comment by celeron55@gmail.com
on 3 Nov 2009 at 9:15
Attachments:
I have been playing with this (still) with the hope of getting the OpenCascade
library version of it working. I did this based on a comment Dan made in one
of his
blogs regarding the fusing of solids. There are two OpenCascade routines that
will
do it and one works for solids where the faces are all at the same Z height. I
changed the code to project the various trace and pad shapes into 3D solids and
then
used BRepAlgo_Fuse() to tie them together. It then explores the faces to find
the
face at the bottom.
This has all worked well for my example data file but it still fails on Perttu's
"test1.gbr" file. I get a SIGSEGV from the OpenCascade libraries on the 15th
filled
area.
This code still doesn't work for the micropendous.gbr example but that's
because it's
using square apertures and my code doesn't handle them properly yet. I am
ignoring
this at the moment because I think the intersections code is more important at
this
stage.
I am nearly at the point where I will take Perttu's advice and write a logical
photoplotter to do the intersection work. I would really like this module to
work.
I like the flexibility offered by having the PCB design within the Heeks model.
We
can do straight isolation routing but we could also have Heeks remove all the
copper
from between traces by using the pocketing operation. I am also hopeful that we
will, eventually, be able to use the probing/fixture rotation functionality to
accurately measure the raw board's position and 'level-ness'. This is
especially
important considering the small depths required when doing isolation routing.
I will add my version of RS274X.h/cpp here just in case anyone wants to look at
it.
I haven't checked it in as I am not yet sure if it's more or less functional
than the
one that's there now.
Sorry to ramble but I just wanted to get my thoughts down so that I don't
forget what
I've done (and still need to do).
Original comment by David.Ni...@gmail.com
on 6 Dec 2009 at 12:02
Original comment by David.Ni...@gmail.com
on 6 Dec 2009 at 12:04
Attachments:
I believe this is fixed with the recent changes to RS274X.h/cpp. If there are
subsequent issues with RS274X, we should open a separate problem so that the
details
don't get too confused with this one (assuming the problem is different, of
course).
Original comment by David.Ni...@gmail.com
on 19 Dec 2009 at 8:58
Original issue reported on code.google.com by
casai...@gmail.com
on 29 Oct 2009 at 9:54Attachments: