dxf, CAM and other comments

Don't read this if you could care less about .dxf files and how they get
turned into G-codes. A lot of this may be very, very basic stuff to many
of you I suspect. But there may be some others who may, as I am, be
curious about the whole process.

If this is too far "OFF TOPIC" please let me know. If anyone else wants
to jump in, you can download the .pdf files describing .dxf format like
I did from the AutoDesk site, create an "empty file" and "test files"
(described here later) and let me know what you find out.

There are a lot of interesting aspects of the whole CAD/CAM arrangement
which one does not have to investigate in order to "make stuff". This is
why we buy software to do certain things for us. As I have been
investigating, the most interesting and most complicated part of the
process seems to be the translation of the CAD (in most cases .dxf
files) to G-codes. This also seems to be the most misunderstood. We all
understand our drawing (CAD) programs to one extent or another and we
all pretty much understand G-codes (at least the basic ones) ... but how
does the "magic" which changes a .dxf ASCII text file into a G-code
ASCII text file which can be fed happily to our
"read-my-Gcode-and-make-my-motors-go" program happen.

There isn't a lot of discussion about how this "magic" happens. Most
discussions are like, "well I use this black-box and the .dxf goes in
here and the G-code comes out here". I also see people continually
confusing CAM programs with the program which takes G-codes and makes
the motors run with CAM. Taking G-codes and making the motors run is not
really what I consider CAM. CAM is Computer Aided Manufacturing and the
computer is not aiding you a whole lot in "manufacturing" if it's just
taking a G-code file and making your table move around. The real "aid"
that we're all after is "getting from the drawing to the G-code". In
other words, getting from a virtual imaginary frame on the monitor to
the real world of "making chips" taking into account that in one place I
have pixels on a screen and in the other I have a whirling sharp thing
which can make a mess of things if the drawing to G-code translation
doesn't go well. What does it mean to "go well"? Things like if the
G-code translator doesn't take into account the fact that you are using
a 1/4 milling cutter and not a "virtually dimensionless imaginary line
cutter" you don't get a pocket which is 2" square but one that is
"somewhat less than that". And many other decisions that have to be made
by the CAM program as it translates your drawing to machine motions
commands. This is the "real CAM" ... all these decisions which need to
be made intelligently in order to "aid" us in manufacturing what it is
we are drawing. The G-code to table motion software is "machine
control". I suppose you could quibble over semantics but I've seen a lot
of situations where people putting together systems think they have CAM
when all they have is "machine control". In fact, I would go as far as
to say it's probably THE most common misconception I seen in all the
various CNC groups I read and the least understood issue.

As I said, you don't have to understand all this to "make stuff". But I
was curious.

The first part of the process has to be understanding how a .dxf file
records information about all the wonderful stuff you can draw. If you
and I were talking about a drawing conversationally I would say
something like, "start at the bottom left corner of the paper and
measure up 4" then over to the right 3" and make a dot then put a
compass on the dot set for a two inch radius and draw a circle". Well
.dxf files are "sort of" like that but the good folks ate AutoCAD needed
to come up with a drawing description system that could encompass a huge
number of variables in terms of the drawing environment (color, line
weight, layers, etc, etc.). If you look at a .dxf file (which you can by
opening it with any text editor) there is a huge amount of "stuff"
which is not strictly of interest if all you want to do is parse out
tool paths ex: "this is a line and it starts here and ends there". The
more flexible you make a system, the more complicated it has to be to
incorporate all the variables. That's why, if you've programmed before,
you know you might spend 1 hour on the code that does "X" and 10 hours
more coding making sure that the USER can do whatever he wants with "X"
in terms of inputs and conditions and flavors and intentions for the end
use of "X" etc.

In order to ignore the "lets cover everything in the world of drawing
stuff" and just parse out the "here's how the stuff you draw is
described and recorded" I created an empty file in my CAD program and
exported it as a .dxf file establishing the "base line" and then created
some simple files (a line, a circle, a rectangle, etc) and exported
them. I used a "compare" function in my text editor to find what was
different between the empty and the test file (typical reverse
engineering procedure) and made some comments on the results.

Below I list the differences and make some notes and observations. Don't
misconstrue this as some type of tutorial on .dxf files, it's just a
hour or two of poking around and trying to understand what's going on.
You might be interested, you might not. You might know a whole lot more
about this than I've been about to find in my poking.

IF SO I'D LOVE TO HEAR FROM YOU and would appreciate any pointers to
information on understanding .dxf files. The stuff from AutoCAD
"assumes" you know a lot about their world already ... I don't. I use a
program called VECTORWORKS on a Mac ... very "outside" their world.

The second part of the process after understanding how basic graphic
elements are recorded in the .dxf file is to understand what goes into
converting them to machine movement descriptions aka G-code. How well
this is done and how many specific G-code "built in" functions can be
employed in the process is the difference between a CAM program which
costs $0.00 and one that costs $1000.00.

Included in this understanding would be things like tool offsets,
backlash compensation adjustments to G-code values, lead-in/lead-out
etc.

Like I said, I wanted to know how dxf files work. So I went to the
AutoDesk site and downloaded the .pdf file for version 2002.

AUTOCAD 2002 DXF REFERENCE GUIDE

The first thing to know about .dxf files is they come in "many flavors".
The lines in your .dxf file which describe "what flavor" or release
version of AutoCAD (or what version rules some other drawing program
which uses the .dxf format used to create it's .dxf files) are at the
beginning in the header section.

Also there is a lot of terminology I don't fully understand in terms of
defining the parts of the dxf file. There are blocks, sections,
entities, objects, group codes, classes, layers, etc. ... I haven't
sorted all these out just yet (again jump in if you care to).

The line numbers down the left are NOT part of the .dxf file. I added
them in my text editor for clarity

These lines describe the version of AutoCAD dxf format

5 9
6 $ACADVER
7 1
8 AC1015 <--- I'm exporting in 2000 format (which is also 2002 and 2000i)

Version identifier table

$ACADVER AutoCAD release
AC1018 2004 <--- the people at AutoDesk are obviously time travelers
AC1015 2002, 2000i, 2000
AC1014 14
AC1012 13
AC1009 12, 11
AC1006 10
AC1004 9
AC1002 2.6
AC1.50 2.05

Notes:

* AutoCAD 2000, 2000i, and 2002 all have the same identifier because the
drawing format is fully compatible in these releases.

* If you are editing a DXF file in a text editor, you must save the file
in ASCII text format.

* The AutoCAD Release 14 Customization Guide states the $ACADVER for
Release 14 is AC1013.
This is a documentation error and is corrected in the Help update.

* The AutoCAD Release 14 sample drawings contain the version identifier
AC1013.

* AutoCAD Release 11 and 12 have the same identifier because Release 12
was backward compatible with Release 11.

So, as I said, to find out how these suckers are put together I generated a
empty file in VectorWorks (hence refered to as VW) and exported it in
AutoCAD dxf 2000 flavor. Then I generated other files to compare it to. A
single line, a single circle, a single
rectangle, etc.


--------These lines all differ in the header part -------------------------

and they will always be different because they are the time/date stamp for
when the file was saved.

446 $TDCREATE <-----$ prefix indicates a "system" variable TIME DATE
CREATE
447 40 <--group code
448 2452940.713969907 <-----.pdf manual describes how this date/time is
derived mathematically
I don't really care at this point.

This next lines that differ are still a bit of a mystery (jump in if you
know!)

Described in the documentation as: "Next available handle"
A DXF system variable but otherwise not sure what it is or does.
The two files I created after "empty.dxf" have 2F here. My guess is
that as you create objects/entities "handles" are assigned in
sequence. How these are used I don't know exactly. If it's a single
byte HEX number that would seem to limit the number of "handles" to 256
which certainly doesn't seem right for complicated drawings unles they're
reused or something.

506 $HANDSEED <----we need to "seed" the handle id with a start number
507 5 <----group code saying handle is coming up
508 2E <----why 2E to start ... no idea

Now until you get down about another 1500 lines there is no difference
between an empty
file and one with a single line drawn in it. So what is all this code in
between. Well
things like what the world coordinate system looks like, and what units are
you using,
and a LOT of other stuff which I'm not interested in at the moment.

What I want to know is "where are my line, circle, rectangle and their
dimensions stored?"

Again the line numbers I added for ease of reference they do not appear in
the dxf files

This describes the single line test (i.e. these are the lines which are
different
than in the "empty" file). One would assume that a file which contained 500
lines
would look the same as this ... just more-ish

2123 0 <---this is a group code, specifically it indicates that
the
next line contains a string describing the entity type
2124 SECTION <---in this case a "section"
2125 2 <---this is the group code for a name "attribute tag, block
name and so on"
2126 ENTITIES <---ENTITIES are graphic elements (OBJECTS are not)
2127 0 <---this is a group code, specifically it indicates that
the
next line contains a string describing the entity type
2128 LINE <---hey a "line" ... my line .. now we're talking, we're
2000 lines of
code into the .dxf file and now my line appears hurrah!
2129 5 <---a "common group code for entities" this means "handle"
assignment is coming up and since this is the first
2130 2E "handle" created it is the value set in $HANDSEED (see
above) one would guess the next entity would get
a handle 2F, etc. One would also guess handles are used
to move things around, align things, etc. .... I don't
know.
2131 100 <---subclass marker (AcDbLine) This is a "block group
code" coming next
2132 AcDbEntity <---AcDbEntity is a "class" ... this describes "things
about the line which is to follow what layer, what
weight, what color (and from the color (neg or pos)
you can tell if the layer is on
2133 8 <---Layer name coming up
2134 Layer-1 <---This entity belongs to "Layer-1"
2135 370 <---Lineweight enum value stored and moved around as a 16
bit integer
2136 5 <----default in VW if I change to 40pt in VW this =
100. I'm not sure of the exact relationship
between line thickness in
VW and lineweight in dxf yet. Thicker in VW =
bigger number here
2137 6 <---This is a layer group code and this one says linetype
coming up
2138 Continuous <---This is a linetype, I think it just means a
start-to-finish line which is uninterrupted i.e. not
dashed etc. just goes from here to there
2139 62 <---Color of the line follows (if negative then this layer
is turned off)
2140 7 <----black line? default in VW (reminder
VW=VectorWorks my CAD program)
2141 100 <---subclass marker (AcDbLine) This is a "block group
code"
2142 AcDbLine <---AcDbLine is a "class" and what follows tells us about
the line

The numeric values given below are in WCS (World Coordinate System) which is
based on how the software which made the file views the "world" in terms of
a cartisian coordinate system. Where is 0,0,0 origin defined as you start
adding stuff to it or around it.

2143 10 <---first corner in WCS x value coming up
I never thought of a "line" having a corner
but ... hey
2144 -2.75 <---this is the x origin of the line
2145 20 <---first corner in WCS y value coming up
2146 0.0 <---this is the y origin of the line
2147 30 <---first corner in WCS z value coming up
2148 0.0 <---this is the z origin of the line
2149 11 <---second corner in WCS x value coming up
2150 -0.3749999999999999 <---this is the x value of the end of the line
2151 21 <---second corner in WCS y value coming up
2152 0.0 <---this is the y value of the end of the line
2153 31 <---second corner in WCS z value coming up
2154 0.0 <---this is the z value of the end of the line

It's not important what the values are here since you can manipulate them
mathematically relative to the WCS to find out how long the line is and
where it is, etc

Because I just plopped it on the page the values above are what they are,
if I use the SET ORIGIN function in my CAD program to make the left end or
start point of my line equal to the "ORIGIN" then the values above would
be 0,0,0 x,y,z

2150 2.375
2152 0.0 the "second corner" or end of the line
2154 0.0

2155 0 <---this is a group code, specifically it indicates that
the next line contains a string describing the entity
type
2156 ENDSEC <---in this case a "end of section"

So if I were looking to find all the simple lines in my .dxf file I could
search for the AcDbLine "class" and find the start and end points of the
line and of course it's length by looking at the 10,20,30 codes. That
was easy.

This next bit is from comparing the "empty" file with a file containing a
single circle (again just plopped down on the page).

From 2123 to 2141 see the comments above about handle number, linewweight,
color, layer, etc.

It it perhaps worth mentioning (and perhaps painfully obvious) that
things like lineweight, color and layer don't really have those
meanings when a G-code file is created. There is no G-code for
"now mill this in blue" ... but these values can be used (if we assume an
understanding on the part of the draftsman and the G-code conversion
program as to what they will stand for) as "keys" to doing "real world"
stuff like separating out machining functions.

If the line is "blue" use this diameter cutter, if the layer is #2 then
that's where my drilling functions reside, etc.

Again for what this next section of uncommented code does, refer to the
commments above.

2123 0
2124 SECTION
2125 2
2126 ENTITIES
2127 0
2128 CIRCLE
2129 5
2130 2E
2131 100
2132 AcDbEntity
2133 8
2134 Layer-1
2135 370
2136 5
2137 6
2138 Continuous
2139 62
2140 7
2141 100 <---ok here's our block group code
2142 AcDbCircle <---and this tells us a circle entity is coming up
2143 10 <---here's the old 10,20,30 x,y,z but since this is a
circle, this describes the center point
2144 -2.0
2145 20
2146 2.125
2147 30
2148 0.0
2149 40 <---ah ... and here's something new, code 40 which
says "radius to follow"
2150 1.0702722283113835 <---the radius of the circle
2151 0 <---and the usual "end of section"
2152 ENDSEC

So if I were looking for all the circles in my .dxf file I would search for
AcDbCircle and then parse the center point and radius from the above.

The next bit describes the comparison between "empty file" and the test file
with the simple rectangle.

From 2123 to 2141 see the comments above about handle number, linewweight,
color, layer

2123 0
2124 SECTION
2125 2
2126 ENTITIES
2127 0
2128 POLYLINE
2129 5
2130 2E
2131 100
2132 AcDbEntity
2133 8
2134 Layer-1
2135 370
2136 5
2137 6
2138 Continuous
2139 62
2140 7

Now things get a bit more interesting but not really difficult

2141 100
2142 AcDb2dPolyline <---here's our new "thing" the "polyline" which makes
sense why would you bother to come up with a way to
describe a closed path 4 sided object when you
can describe more generally any group of connected
lines no matter how many are involved and it doesn't
matter if the last one connects to the first one
or not. You could use this approach to describe a
lightning bolt design or an octagon. So unlike LINE
and CIRCLE there is no "RECTANGLE" or "SQUARE"
also if you "explode" the rectangle (or whatever
your CAD program uses to describe this function
SMASH, BASH, DEMOLISH, etc. .. mine calls it
"CONVERT TO LINES") before exporting the file you
won't get a ployline sequence you'll get 4 LINE
entity descriptions instead.

2143 66 <---apparently as of AutoCAD 2002 this is obsolete
and we are to ignore it and the operand which
follows it and get right on with the first line
2144 1 <---ok ... I'm ignoring you
2145 10 <---here starts the first 10,20,30 xyz set describing
the first line
2146 0.0 <---the docs say this is always 0 ... what!!!??? so how
do I know where it is in the WCS? probably has to
do with VERTEXs which are coming up
2147 20
2148 0.0 <---y always 0
2149 30
2150 0.0 <---z always 0
well that wasn't much help with my rectangle yet

2151 70 <--group code for polyline flag which is "bit coded"
meaning the numbers here will be 1, 2, 4, 8, 16,
32, 64 or 128 (bit position in binary)
2152 1 <--a "1" means its a closed polyline (or "polygon
mesh closed in the M direction" which means
nothing to me)
The fact that it is closed means we don't get
an "ending vertex which describes the same
point as the beginning ... this is assumed
because it is "closed" and you have to connect
the dots (pun intended)
2153 75 <--curves and smooth surface type
2154 5 <--this code says this is a Quadratic B-spline
surface I think this is because my CAD
program considers everything to be made of
B-Splines of one sort or another. For those
of you familiar with ADOBE Illustrator the
pen creates B-Splines which can be straight
lines also as they are here.
2155 0 <---here's the "get ready for an entity type string
2156 VERTEX <---and here it is the first VERTEX i.e. the start point
of my rectangle
2157 5 <---of course it has to be assigned a handle
2158 2F
2159 100
2160 AcDbEntity <---and we need to know the usual about layer, color,
and linetype ... I guess ... didn't we do this
above right before "AcDb2dPolyline"
anyway ... 2161-2168 are the typical descriptions
2161 8
2162 Layer-1
2163 370
2164 5
2165 6
2166 Continuous
2167 62
2168 7
2169 100 <---subclass marker AcDb2dPolyhline or AcDb3dPolyline
2170 AcDbVertex <---hey it's a vertex
2171 100 <---subclass marker AcDb2dPolyhline or AcDb3dPolyline
2172 AcDb2dVertex <---hey it's a 2d vertex in this case
2173 10 <---ok here's the 10,20,30 codes x,y,z of the vertex
2174 0.0
2175 20
2176 2.0
2177 30
2178 0.0

So after all that I know where I go to start to draw the first line of
my rectangle (or "rather closed polyline"). So now I need to know where
to draw it "to" ... I need another vertex.

2179 0 <---so here it is along with the lineweight, linetype,
color info, etc.
2180 VERTEX
2181 5
2182 30
2183 100
2184 AcDbEntity
2185 8
2186 Layer-1
2187 370
2188 5
2189 6
2190 Continuous
2191 62
2192 7
2193 100
2194 AcDbVertex
2195 100
2196 AcDb2dVertex
2197 10 <-----here's the 10,20,30 codes with the x,y,z
location
2198 2.5
2199 20
2200 2.0
2201 30
2202 0.0

2203 0 <---and the next one
2204 VERTEX
2205 5
2206 31
2207 100
2208 AcDbEntity
2209 8
2210 Layer-1
2211 370
2212 5
2213 6
2214 Continuous
2215 62
2216 7
2217 100
2218 AcDbVertex
2219 100
2220 AcDb2dVertex
2221 10
2222 2.5
2223 20
2224 0.0
2225 30
2226 0.0

2227 0 <---and the last one (remember from here because this
polyline has been identified as "closed" I know to
draw a line (toolpath) back to the first vertex
2228 VERTEX
2229 5
2230 32
2231 100
2232 AcDbEntity
2233 8
2234 Layer-1
2235 370
2236 5
2237 6
2238 Continuous
2239 62
2240 7
2241 100
2242 AcDbVertex
2243 100
2244 AcDb2dVertex
2245 10
2246 0.0
2247 20
2248 0.0
2249 30
2250 0.0

2251 0 <---entity coming
2252 SEQEND <---sequence end ... this sequence of vertices is over with

2253 5 <---assign a handle ... but to what?
<---I suppose this next bit just kinda tidies up a bit after
the polyline, maybe it sets things back to the way they
were before the polyline ... don't know
2254 33
2255 100
2256 AcDbEntity
2257 8
2258 Layer-1 <--layer
2259 370
2260 5 <--line weight
2261 6
2262 Continuous <--line type
2263 62
2264 7 <--color
2265 0
2266 ENDSEC

So that's what I know so far. Of course if you want to stay very basic,
thats all you need to know. Everything can be drawn with polylines. A
curve can be turned into "polylines" by a function in most CAD programs.
As I mention above it typical has some violent descriptor (SMASH, BASH,
EXPLODE,etc.) Therefore a curve can be converted (reduced, if you will)
into a lot of little short straight lines which approximate the path of
the curve. A circle, being a curve, can be treated the same way, as can
an arc, etc. All you really need are polylines. Of course the "smoothness"
of your curve will depend on how many little straight lines your drawing
program converts it to. A lot makes for a smoother approximation, and a
few makes the curve more like a jagged line. You can generally tell your
CAD program how short to make these little straight lines when it converts
curve to polylines. You can imagine certain drawings that when SMASHED
produce literally thousands of polylines, which then convert to thousands
of G-code set to make those lines and sometimes this can be too much for
the particular software you are using to control your machine (buffer
overflow ---- or "this is just too much crap for me to deal with syndrome")
and the program will crash or hang.

Well that's what I know so far. Obviously this is all 2D, things get a lot
more complicated when you add the 3rd dimension I suppose.

Now the next step is how do we parse out the lines, polylines and circles
and make decision about "tool paths". Since toolpaths involve moving
stuff in space time we'd like to be efficient. If I draw a star, for
example, I don't want the my cutter always return to the center of the star
before it cuts one of the points. I want the toolpath to cause the cutter to
cut the items closest to where it's at currently to eliminate having to
move all over the place trying to emulate the way the drawing was created.
So there has to be some tables made of dimensions and locations and some
sorting and ordering of these tables before I can create efficient G-code.

Cheers,

Ken Jenkins
kjenkins@...