Problem exporting to dxf

I have had success in the past exporting to some plasma cutters. But I have one I don’t know how to solve. It is a simple drawing.
dekker-floor-2522mar.dxf (33.1 KB)
dekker-floor.3dm (23.9 KB)
And when I open the dxf file in Rhino it looks fine and when I open it in LibreCAD it looks fine. When I viewed it on Autodesk’s online viewer there appeared to be a gap in the arc. When I sent it to the plasma cutter he says his AutoCAD LT2022 just kicks it out and refuses to accept it. Anybody have any ideas?

Hi Joe - I do not see anything amiss so far - the only thing that comes to mind is trhat maybe the arc is being flipped - it may be that setting arc normals to Z, in the export scheme, might help.


The end points of the segments and arc are not coincident by an incredibly small amount, like you would need far more than 3 or 4 decimal places to see the difference. This is not unusual though so it should not be a problem.

I suspect someone at your service has inadvertently changed their tolerance out to many more decimal places than usual. You could try the Join command in Rhino and resave the DXF file … it won’t improve the incredibly small difference in coordinates but it might show up their software as closed, which for all intents and purposes, it is.

As they’re using AutoCAD have you tried DWG? Strange AutoCAD just kicks the DXF out, it opens fine in Autodesk Fusion.


I’m not sure the CAM operator fully described the issue to Joe.
Nesting software typically has a chaining function for entities with non coincident endpoints (gap) within a variable tolerance. I suspect someone at the plasma cutting service changed the threshold to a much smaller value so its indicating the object is not closed.

I do see the gap\overlap in the DXF in DWG trueview. If I join the curves in the 3dm then export as DXF the ends seem to match in trueview, so joining before export might help.

Okay. I appreciate all the ideas. Flipping the arc normals had no effect on the Autodesk online viewer. In my Rhino file the arc is an arc is an arc. Why should there be a gap in the dxf file? I am not an expert on these things.
I’m afraid the CAM operator at the steel supply house is not an expert either. I think they just got the LT2022 and it is running with whatever defaults it comes with. I’ve not worked with LT2022. Is there a way, if I can get time on their machine, where I can look at settings? I may end up taking my computer over and trying some different things but that seems a bit silly. Seems as though LT2022 ought to give some kind of error message.
Here is a new Rhino file where I did a join. See if you still see a gap. I don’t in the Rhino file.
dekker-floor-2622mar.3dm (21.0 KB)
And here is a new dxf file made with ACAD 2000 instead of release 14. That might make a difference also. Although it still looks the same in Autodesk online viewer.
dekker-floor-2622mar.dxf (153.9 KB)

Hi Joe,

I suspect its not so much whether you see the gap, it is that the end point coordinates do not match.
That tiny gap typically not a problem and can happen for many reasons. The values are consistent within 10 decimal places or so and that should be good enough for any CADCAM system generating toolpaths for CNC.

The problem I believe is that the CAM system is set to reject points that do not match beyond 10 decimal places or so.
Since I don’t know how their CAM systems works, it may be that the decimal accuracy need to be set in AutoCAD or in their CAM or nesting software.

If the shape is open (points are not sufficiently coincident) then the CAM system cannot apply kerf (offset of the radius of the tool or plasma arc in this case) and the tool path will be centered on the the original lines and arcs rather than offset for the kerf, which would result in the part being cut to a slightly smaller size.
I used the List command in Rhino to display the endpoint coordinates.

DXF dekker-floor-2622mar

DXF dekker-floor

3DM dekker-floor

3DM dekker-floor-2622mar

Your latest DXF had the arc separated from the lines; however, your latest Rhino 3DM file had the arc joined to the segments.
I exported a v12 DXF from your latest Rhino file and the arc is joined to the segments (attached below).
dekker-floor-2622mar from Rhino 3DM.dxf (6.5 KB)

This may work since although the endpoints do not match exactly, their system may interpret it as closed. If this does not work, I think you will have to speak to them about checking the decimal place tolerances set in their software.

Hello all,
I just wanted to close the loop on this thread in case anyone else has a similar problem and finds this by searching. Here’s the dang deal. I was able to get the steel company to send me the file that I had sent them and the one they claimed did not work. I found the problem. The file they returned to me had an extra carriage return inserted on every line. So instead of a decimal 13, 10, there was a decimal 13, 13, 10. I don’t know whether this happened in their email system or in their computers. I don’t know if they run Linux or Mac. But that’s what happened. My Rhino3D ver 7 would not open it either. Interestingly LibreCad didn’t care and would open it anyway. One friend who is an IT person suggested that next time I should try zipping up the file to see if it could get through unscathed.
Many thanks to all for the suggestions.

1 Like