RS274X -- Unexpected command 'G70'

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Import the file "Micropendous1-Component.gbr"

I was expecting to be able to import that gerber file. I saw an error on shell:

RS274X::Read(/media/disk/micropendous/Design/Micropendous1/Micropendous1-Compone
nt.gbr)
Unexpected command 'G70'

I did build on Ubuntu Linux 8.04 (because I have here installed EMC2)
heekscad SVN rev: 948 and heekscnc SVN rev: 804.

NOTE: that gerber file belongs to http://code.google.com/p/opendous/

Original issue reported on code.google.com by casai...@gmail.com on 29 Oct 2009 at 9:54

Attachments:

• Micropendous1-Component.gbr

[GoogleCodeExporter]

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

• Changed state: Accepted

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• micropendous.tar.bz2

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• pcbtest.rs274x.front.gbr
• test1.gbr

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Original comment by David.Ni...@gmail.com on 6 Dec 2009 at 12:04

Attachments:

• RS274X.h
• RS274X.cpp
• Probe_v1.6.back.gbr

[GoogleCodeExporter]

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

• Changed state: Fixed