Export to DXF/DWG - Joined polycurves always segmented even if arc/line only data

CNC centerline toolpath data export question for manual 3D contour development: Is it at all possible to export—in DXF or DWG format—a JOINED 3D polycurve—comprised entirely of tangent arcs and lines (i.e., NO NURBS or splines)—without the Rhino export engine meddling with the underlying (geometrically valid and simple) polycurve curves?

The desired 3D output would be the exact data set of Z-axis stacked, Ogee-ed contours—again, only arcs and lines—but simply tied together within Rhino into one long, valid, “open polycurve with 107 curve segments”) centerline tool path AND saved in AutoCAD AXF or DWG format.

From the numerous Rhino Forum threads (specifically #22469 and #86445), wiki.mcneel.com, docs.mcneel.com for CNC/CAM, laser/waterjet data prep, it appears that the only way to “save” the original arc & line data is to explode any/all polycurves prior to export which, unfortunately, defeats the whole purpose of tying the contours together into one long polycurve within Rhino and exporting.

Note #1: the original contouring data is “G-Code friendly” arc and straight line-only data. Everything is tangent; the data is really clean. We know how to create the necessary geometry. #OldSchool

Note #2: I have run numerous tests using the “Convert” command with different settings using the CAM Imperial and other export schemes (including the R12 and R14 format factor). As long as the polycurve is not exploded, everything always blows up the underlying tangent arcs and lines data into segments.

Note #3: The Rhino-exported “toolpath of ten thousand segments” CNC toolpath data runs but the export geometry (a) is simply huge compared to the simple and elegant original data and (b) has way too many random “stop-starts” inevitable with segmented data.

Note #4: Our CNC router’s CAM system version can’t accept STEP or IGES. Short a $17K controller lobotomy/upgrade, we are limited to DXF and DWG data input. We would just like Rhino to squirt back the arc and line data we developed… but with all the contour polycurves tied together and in DWG or DXF format.

Note #5: Currently using Rhino 5 (I can’t get the V6 license (re)activated for my office PC until tomorrow).

What am I missing?

I apologize for this being so long and involved. What we are doing—manually developing 2-1/2 dimensional edge and profile contouring toolpaths and how we are doing it—may seem unnecessarily “old school” but we have our reasons for wanting to teach our students these geometrically-based problem solving and product development skills. Thank you for your time and attention in this perplexing matter.

Hello- I believe what you are looking for in the dxf/dwg export schemes is this:

It may pay to SimplifyCrv before export as well.

Any luck?

-Pascal

I think it is not possible to have 3D polyline with arcs. I tried to join exploded 3D polyline imported from Rhino in AutoCAD and BricsCAD and in both I got splines.

Yep… AutoCAD will not join the XY contours with 3D transitions from one contour line to the next without converting the whole thing into a single spline. This is why we need Rhino to export the single, joined polycurve as a, well, single, joined polycurve (or polyline as AutoCAD calls them).

Thank you for your prompt reply and suggestions.

FYI: The snapshot settings provided were identical to the last test I ran with the exceptions that I (a) had used “CAM Imperial” and (b) set the “AutoCAD version” to “Release 14” in the General tab. Over the years, we have used these “R12 Natural” scheme settings and lived with the consequences of the “exported 3D polyline of a thousand (joined) segments.”

I ran the SimplifyCrv command and received a “No curves were simplified.” response [which would make sense as all of the objects (i.e., arcs or lines) comprising the open polycurve are all good Ogees (i.e., tangent)].

But per your suggestions, I ran the “Export Selected” command with your provided settings (again with the AutoCAD version set to Release 14 as somewhere in a thread the R12 formatted data ALWAYS exports to segments but the R14 format should export true arcs and lines). Here’s what i got in three screenshots:
From Rhino (ready for Export):

Export Settings used (again with R14 version in the “General” tab):

Results of exported data opening within AutoCAD showing the resulting segmentation:

In an ideal world, if we were ready for export within Rhino with a long, single open polycurve comprised of, say, 107 tangent arcs and/or lines, the result of the export processing would be simply a single, joined polyline (or polycurve) comprised of those same 107 tangent arcs &/or lines. Elegant in; elegant out.

One last screenshot… Opening the exported DXF file within Rhino and opening up the Object Description window from Properties -> Object -> Details tab yields the following:
04-Result_of_Export_from_Rhino_to_DXF-Per_Pascal-Opened_In_Rhino

Please note that the resultant 3D DXF data is identified as a single “open polyline” (no longer an “open polycurve”) with ~3600 “points” (no longer “curve segments”). I am learning the terminology as I am trying to articulate the problem.

I think the DXF and DWG formats don’t have 3D polylines with arcs. Only line segments.

If you explode the “open polycurve with 107 curve segments” into 107 separate arcs and lines prior to export, they export perfectly into 107 (non-joined) objects. Correct data but not joined.

Maybe the question should be “Are joined 3D polycurves impossible to export as a connected series of arcs and lines in either DXF or DWG format because the Autodesk-written DXF or DWG specifications specifically prohibit arcs within joined polylines that containing any 3D data?”

Maybe there is a way to “game” the data (i.e., just output the 3D Z-transitions as line segments)… I wish I knew what I was talking about.

Well, maybe the question (or more of a statement actually) would be

“Are joined 3D polycurves impossible to have as a connected series of arcs and lines because Autodesk AutoCAD software doesn’t support this configuration and therefore has no reason to include it in DXF/DWG specification?”

i.e. If you can’t make it actually happen by joining the exploded curves from within AutoCAD into a 3D polyline with lines and arcs, why to you think importing a file from Rhino that can actually join them will fix the problem in AutoCAD?

So, that’s it… The problem isn’t with the Rhino export engine/algorithm at all but rests squarely within the (Autodesk AutoCAD) programmers’ specification(s) for the DWG &/or DXF file formats that simply do not allow for joined 3D polylines that include one or more arcs (and convert any/all 3D contouring toolpath data containing arcs to splines).

Which is OK. We’ve lived for nearly a decade using Rhino to edit our 2D and 3D contour toolpaths tying them together with Rhino’s robust curve creation capability then spitting out a joined polyline approximation (the “toolpath of a thousand line segments”). These open polylines “work” but often just don’t work that well (e.g., huge files, inelegant geometry, and all those annoying stops and restarts).

As an aside, it is good to know that this is in no way a “Rhino export problem” but an underlying deficiency/incompatibility of the DWG/DXF specification to support what could be elegant 3D G-code for legacy CAM/CNC systems (i.e., those that do not support splines or NURBS).

You’d think that in the nearly three decades that the DWG/DXF specification has been around that some enterprising algorithmist would have been given permission to evolve the DWG/DXF specification to include 3D polyline/polycurve support for an occasional arc or two (or hundreds). We do so live in a sub-optimized world. #Sigh

Did you try to export without curve tesselation?

Because of this issue, CAM software almost always has some type of “chain” command or similar to join arc and line entities before applying toolpaths. Usually there is some user defined tolerance for precision, so if the endpoints don’t share exactly same coordinates they may be recognized as coincident.