Values of entities within a DXF file

[hendrikFXSD2]

I'm trying to code a solution that will slice an object for 3D printing, using a DXF file. So I drew this very simple object (3D solid) in AutoCAD 2019:

It's a cube 20x20x20, with a vertical hole troughout with a radius of 5. Then I saved it as an R12 DXF and started analysing the file.

All the information in the header section of the DXF file, like $EXTMIN and $EXTMAX are positive values, and this corresponds with the object drawn. However, when I view the entities for this geometry (either in BLOCKS or ENTITIES), I get the following:

0
CIRCLE
5
4FF
8
0
10
-40.0
20
40.0
30
0.0
40
5.0
210
0.0
220
0.0
230
-1.0

Now how on earth did I get a negative value for the X position of the centre of the circle, when every element of the entity is drawn in the positive X-Y plane in AutoCAD? The value of -40 indicated that it is measured from (0,0,0) in the DXF file. But in the wrong direction.

Also, where can I find the information in the DXF file that the 2 circles are actually the start end end circles that form a hole in the cube? As far as I can see there is no information available in the DXF file from which I can conclude that there is a hole, and not just 2 circles on the top and bottom of the cube.

I searched my heinie off trying to find answers, but there is no information available online from which I can conclude or derive info to solve this issue. 

[Alfred.NESWADBA]

Hi,

>> how on earth did I get a negative value for the X position

If we can look into the dwg-file we might know it ...

Otherwise the answer would be you have created a circle on negative X value (world coordinate system -X)

- alfred -

[hendrikFXSD2]

Thank you for your quick response. I can not attach the DXF file in this reply, because this forum kept giving me the error message :

The attachment's cube_r12_1.dxf content type (application/x-dxf) does not match its file extension and has been removed.

So I had to zip the file and that worked for uploading. The DXF file loads into AutoCAD without problems.

[Alfred.NESWADBA]

Hi,

please take care, seems like all entities inside your DXF are doubled.

And some of your circles are placed with a negative orientation (Z of the normal vector is negative) and this is why you see negative values.

- alfred -

[leeminardi]

The dxf codes 210, 220, 230 is the extrusion direction vector of the circle.  The components of a unit vector are essentially the cosines of the angle.  Since the z component is -1 (the circle is pointing downwards)  the plane is rotated 180 degrees and its value is -1 reversing the sign of the x component.

This link may help you visualize how this works.  In your case the cosine(angle) goes from 1 to -1 and the sine(angle) from 0 to 0.

[hendrikFXSD2]

Ah I'm starting to see now. The way that AutoCAD 1029 interprets an R12 DXF file is exacly what it says in the DXF, but that is not according to the R12 specification:

"Entities appear in both the BLOCK and ENTITIES sections of the DXF file. The use of group codes in the two sections is identical."

So AutoCAD:
1: Does not write DXF files according to the R12 specification (you can see the reference to the hole in de cube is lost, and only the circles remain when the DXF is read back in).

2: Does not read DXF files according to the R12 specification, instead it interprets entities under the BLOCK section and entities under the ENTITIES section as separate, and not in the R12 file structure specs. That's why you see double circles and double lines.

In my book this is a backwards compatability issue for sure.

Might this have something to do with the new "Print Studio" facilities in AutoCAD? Autodesk uses STL files for output to 3D printers, but these are rubbish when it comes to representing a geometry. If I print this cube it comes out with a diameter of 9.3 instead of 10 mm. for the hole.

[Alfred.NESWADBA · Accepted solution]

Hi,

>> Does not write DXF files according to the R12 specification (you

>> can see the reference to the hole in de cube is lost

The object types for 3D-Solids used in AutoCAD 2019 is based on a different kernel and these object types are not compatible to AutoCAD release 12 (not 2012). The result of this is that your current objects are converted to a very low level representation which can be opened in AutoCAD R12. Though you lose some informations like object references as these are not possible to represent in AutoCAD R12 in a way AutoCAD 2019 works with 3D-Solids.

So yes, you get something different to what you have in 2019, but what you get is compatible with the specifications of DXF-12.

>> That's why you see double circles and double lines.

I don't know which software wrote this DXF, but this is not an issue of READING the DXF as the DXF already holds these double entities. It could be a questions of writing that you get the 3D-Solid exploded to regions, the regions exploded to it's edges and so you get from the upper face a circle as island and from the cylinder a circle, that's why you might get 2 circles at each position.

But again, you try to convert an object from AutoCAD 2019 to a file version which has to be compatible with a software which is 30 years old. You can't convert an object from the current version to such an old format. You have to convert it to make it readable with AutoCAD R12 and you'll lose information which were not valid in R12.

- alfred -

[Alfred.NESWADBA]

Hi,

>> Might this have something to do with the new "Print Studio" facilities in

>> AutoCAD? Autodesk uses STL files for output to 3D printers

What does Autodesk PrintStudio has to do with such an old DXF-Format?
STL is a different format and also this format is not related to DXF.

- alfred -

[hendrikFXSD2]

STL is indeed not related to DXF, and that's why I wanted to use it. Because g-code generated from DXF-based geometry data is much more precise then g-code generated from STL-based geometry data. But I see now that is not possible. In later versions of DXF the dimensioning of entities in a drawing are no longer visible in the file, but replaced with proprietary code. I guess I'll have to find another way, or another drawing platform. Thank you both for your time though!

[Alfred.NESWADBA]

Hi,

>> Because g-code generated from DXF-based geometry data is much more

>> precise then g-code generated from STL-based geometry data

This sounds like you are generating the DXF from some other software?

As long as you work based on R12-DXF I would be very careful as this contains objects which current programs (slicers) could misread.

Back to AutoCAD and thinking about FDM or SLA printing .. both are based on raster steps and I would not see any quality issues using STL as export from AutoCAD (as long as FACETRES is set to 10).

>> In later versions of DXF the dimensioning of entities in a

>> drawing are no longer visible

Sorry to not understand this as every entity inside the DXF has it's dimensions. If entities would not have exact dimensions no CAD application would be able to import DXF files.

>> but replaced with proprietary code.

This is valid for proxy items or 3D-Solids ... but I have not understood yet why you need to save as DXF-R12 to get the file from AutoCAD printed to a 3D-Printer. Maybe some insights could help to find better workflows.

- alfred -

[hendrikFXSD2]

No, all my DXF files are generated from within AutoCAD 2019. There are currently no slicers that work with DXF files as input, so my plan is to write (program) my own slicer to do the work.

Here's a picture that shows the difference between CAD-based geometry and STL-based geometry (source: STL wiki):

It's clear to see that the CAD-based representation is geometrically far more accurate then the STL representation. This has been a mayor problem in the 3D printing community for years (see https://github.com/slic3r/Slic3r/issues/3323) , and the subject of a lot of discussion. To rule out the possibility of the STL file geometry being the lead cause of faulty dimensioning of a printed object, I thought of giving DXF a try, because it does not rely on triangles to describe a geometry.

R12 was just my attempt to start from the bottom (the most simple protocol) and save myself some time analysing the file. I have not analysed any other DXF types then R12. So that would be my first direction going forward.

FDM or SLA printing would also be worth while to read up on, thank you for bringing it to my attention.

But to say "and I would not see any quality issues using STL as export from AutoCAD (as long as FACETRES is set to 10)." is a bit of a misapprehension. If I draw a hole in CAD to suit an M5 bolt, and the 3D print facilitates only an M4 bolt, I'd say that's a problem.

Now where this problem lies is a different matter, it's a compound issue. But because different translation steps are made (CAD -> STL -> G-CODE), and I know CAD geometry data is accurate, my thought process was to first eliminate STL based geometry, and replace that with the CAD based geometry of a DXF file. 

Hope this clears things up a bit.

[Alfred.NESWADBA]

Hi,

>> If I draw a hole in CAD to suit an M5 bolt, and the 3D print facilitates

>> only an M4 bolt, I'd say that's a problem.

This is definitely not an issue of AutoCAD or the STL format or the exporter of an STL from AutoCAD.

I never had this issue with any of my prints.

A STL exports exactly the coordinates you draw in AutoCAD, if you draw a cylinder with 5 drawing-units diameter then the cylinder gets triangulated (needs to be as the STL does not have the option for arcs or circles), the density and accuracy of  the triangulation is based on the sysvar FACETRES, but can never make a difference from D=5 to D=4.

>> Here's a picture that shows the difference between CAD-based

>> geometry and STL-based geometry

This is absolutely correct, but lets get back to how 3D-printers work ... all coordinates are based on a raster. Layer thickness is controlled by a stepper motor, X and Y coordinates are based on stepper motor or based on pixel for the display of SLA printers), so you can't run curves which are 100% curves, they need to be segmented to fit to the raster of your printer.

And with AutoCAD setting FACETRES your geometry has a better accuracy than your printer can control by the stepper motors (or pixel). The worst case for such a type of printers would be a face with a very little slope, there you get a step when the thickness is to big to fit on the lower layer. But even this is not controllable by an STL file.

Anyway, good luck for writing your slicer software, will be an exciting job ;))

- alfred -