A user on the SOLIDWORKS 3DEXPERIENCE forum posted a question about elliptical cutouts in a sheet metal flat pattern. After exporting the flat pattern to DXF, every elliptical hole appeared as a SPLINE entity in the file. The laser cutter’s controller — a Trumpf TruTops installation — rejected the file. TruTops can cut true ellipses from native ELLIPSE entities but has no NURBS solver for arbitrary-degree SPLINE entities, so the holes were silently dropped from the cutting plan.

The fix the community landed on: change the DXF/DWG export version from R12 to R14. The ellipses came out as ELLIPSE entities. The controller accepted them.

This post explains why that fix works, why only direct flat-pattern exports are affected, and how to apply it programmatically so a batch export macro doesn’t produce the wrong entity type.

What’s actually in an R12 vs R14 DXF file

The DXF format is versioned at the file level via the $ACADVER header variable. Each AutoCAD release extended the entity set. The two versions that matter here are:

R12 (AC1009): The entity set dates from 1992. The geometry entities are LINE, ARC, CIRCLE, POLYLINE/VERTEX, 3DFACE, TRACE, and a handful of block/annotation types. There is no SPLINE entity. There is no ELLIPSE entity. A true ellipse in R12 must be approximated as a POLYLINE composed of short arc segments.

R14 (AC1014): Released in 1997. R14 introduced both the SPLINE entity (NURBS curve stored as control points + knot vector) and the ELLIPSE entity (centre, major axis vector, axisRatio, start/end parameter). A true ellipse can now be written as a single ELLIPSE entity that any R14-capable reader reconstructs exactly.

The ELLIPSE entity group codes look like this in a raw DXF file:

  0
ELLIPSE
  5
2F3
  8
0
 10
125.0
 20
75.0
 30
0.0
 11
50.0
 21
0.0
 31
0.0
 40
0.5
 41
0.0
 42
6.283185307

Group 10/20/30 is the centre point. Group 11/21/31 is the major axis endpoint vector (50mm in X here). Group 40 is the minor-to-major axis ratio (0.5 means the minor axis is 25mm). Groups 41/42 are the start and end parameters (0 to 2π = full ellipse). One entity, zero approximation, exact reconstruction.

Why SOLIDWORKS writes SPLINE entities in R12 mode

The R12 entity set has no SPLINE and no ELLIPSE. A strictly correct R12 writer would approximate both as POLYLINE chains. SOLIDWORKS does not do this.

When you export a flat pattern in R12 format, SOLIDWORKS writes elliptical geometry as SPLINE entities rather than POLYLINE chains. The SOLIDWORKS DXF writer uses the NURBS spline representation internally for all non-arc curves. When the target version is R12 — which cannot represent SPLINE — the writer writes SPLINE entities anyway, violating the format version constraint. The resulting file has an R12 $ACADVER header but SPLINE entities that AC1009 cannot describe. Most modern DXF readers ignore the header and parse what they find, so the file opens without error. But downstream firmware that validates against the declared version rejects it.

This is a SOLIDWORKS implementation detail. The R12 export does not compute a POLYLINE approximation from the NURBS curve. It writes the NURBS control points directly and calls it an R12 file. The format version check is nominal.

R14 mode fixes this because the target version actually supports the ELLIPSE entity. The writer now has a valid entity for a closed ellipse: it writes the centre, major axis, axis ratio, and parameter range directly. No SPLINE. No POLYLINE. A single exact entity.

Why drawing-view export does not exhibit this problem

The behaviour above is specific to direct flat-pattern export: File → Save As → DXF from a sheet metal part with the flat pattern option active, or the programmatic equivalent IPartDoc.ExportFlatPatternView / IModelDoc2.Extension.SaveAs with swExportFormatType_e.swExportFormat_Dxf.

When you export from a drawing view — that is, create a SolidWorks drawing, insert the flat-pattern view into a sheet, then File → Save As → DXF from the drawing document — the geometry goes through the drawing annotation pipeline before it reaches the DXF writer. The drawing pipeline converts the flat-pattern view to a set of projected sketch entities. Circles and arcs in the projected sketch are written as CIRCLE and ARC entities regardless of the DXF version setting. Ellipses in the projected sketch are written as ELLIPSE entities because the drawing pipeline uses the R2000 entity model as its internal representation, independent of the export version setting.

This is why some users report that their flat-pattern exports are fine and some report the spline problem: the ones who export via drawing views never see it. The ones who use direct export with R12 format see it.

The direct export path is generally preferred for batch automation because it does not require creating and saving a drawing document. It is also the path most likely to hit the format version constraint.

Checking what entity type your DXF actually contains

Before you change anything, verify what the current export is producing. The fastest way on Windows is ezdxf from the command line:

pip install ezdxf
python -c "
import ezdxf
doc = ezdxf.readfile('your_flat_pattern.dxf')
msp = doc.modelspace()
entity_types = [e.dxftype() for e in msp]
from collections import Counter
print(Counter(entity_types))
"

If you see SPLINE: 3 for a part with three elliptical holes, the export is broken. After switching to R14, you should see ELLIPSE: 3 (or ELLIPSE: 3, LINE: ... etc).

Alternatively, open the DXF in a text editor and search for the string SPLINE. Any SPLINE entities appear as:

  0
SPLINE

And ELLIPSE entities appear as:

  0
ELLIPSE

Fixing it in System Options

Go to Tools → Options → System Options → Export and find the DXF/DWG Version dropdown. Change it from R12 to R14 (or R2000 if your downstream tool supports it — R2000 preserves everything R14 does and adds multiple paper space layouts).

The setting is per-user and per-machine. It persists until someone changes it. For shops running batch exports from multiple workstations, a manual System Options change is not a reliable solution.

Fixing it via API

The DXF export version is controlled by the swDxfOutputType user preference. When running a macro or batch export, set this immediately before each export call. Do not rely on the System Options dropdown being set correctly — any user on the workstation may have changed it.

Option Explicit

Sub ExportFlatPatternR14(filePath As String)
    Dim swApp As SldWorks.SldWorks
    Dim swModel As SldWorks.ModelDoc2
    Dim swPart As SldWorks.PartDoc
    Dim swExt As SldWorks.ModelDocExtension
    
    Set swApp = Application.SldWorks
    Set swModel = swApp.ActiveDoc
    
    If swModel Is Nothing Then
        MsgBox "No active document"
        Exit Sub
    End If
    
    If swModel.GetType() <> swDocumentTypes_e.swDocPART Then
        MsgBox "Active document is not a part"
        Exit Sub
    End If
    
    ' swDxfFormat_R14 = 14
    ' Values from swDxfOutputType_e (stable since SW 2018):
    '   R12=12, R13=13, R14=14, R2000=15, R2004=18
    '   R2007=21, R2010=24, R2013=27, R2018=32
    Dim previousVersion As Long
    previousVersion = swApp.GetUserPreferenceIntegerValue( _
        swUserPreferenceIntegerValue_e.swDxfOutputType)
    
    ' Set R14 for this export
    swApp.SetUserPreferenceIntegerValue _
        swUserPreferenceIntegerValue_e.swDxfOutputType, 14
    
    Set swPart = swModel
    Set swExt = swModel.Extension
    
    ' Export the flat pattern directly
    Dim errors As Long
    Dim warnings As Long
    Dim bRet As Boolean
    
    bRet = swExt.SaveAs3(filePath, _
        swSaveAsVersion_e.swSaveAsCurrentVersion, _
        swSaveAsOptions_e.swSaveAsOptions_Silent, _
        Nothing, Nothing, errors, warnings)
    
    If Not bRet Then
        Debug.Print "Export failed: errors=" & errors & " warnings=" & warnings
    End If
    
    ' Restore previous version to avoid side effects on other macros
    swApp.SetUserPreferenceIntegerValue _
        swUserPreferenceIntegerValue_e.swDxfOutputType, previousVersion
End Sub

The version values come from the swDxfOutputType_e enum in SolidWorks.Interop.swconst.dll. As noted in the DXF version guide for SolidWorks, these values mirror the AC version digits (R14 = AC1014 = 14) so the mapping is consistent across releases.

If you’re using ExportFlatPatternView specifically:

' ExportFlatPatternView signature:
' Function ExportFlatPatternView(FileName As String, Options As Long,
'     SheetMetalOptions As Long, Entities As Object) As Boolean
'
' The DXF version is controlled by the same swDxfOutputType preference,
' not by any parameter on this method.

Dim swPart As SldWorks.PartDoc
Set swPart = swModel

' Set R14 before calling
swApp.SetUserPreferenceIntegerValue _
    swUserPreferenceIntegerValue_e.swDxfOutputType, 14

Dim bRet As Boolean
bRet = swPart.ExportFlatPatternView( _
    "C:\output\flat_pattern.dxf", _
    1 + 2, _   ' swExportFlatPatternViewOptions_e - geometry + bend lines
    0, Nothing)

The ExportFlatPatternView method has no version parameter. It reads the same System Option. Set it in code before calling and restore it after.

Choosing R14 vs R2000

R14 is the minimum version that supports the ELLIPSE entity. It is sufficient if your downstream tool can consume ELLIPSE entities and you don’t have multiple-sheet drawings.

R2000 (AC1015) is the better default for most shops. R2000 adds multiple paper space layouts (irrelevant for flat-pattern exports), full TrueType text, and 255-character layer names. The ELLIPSE entity is supported identically to R14. There is no reason to use R14 specifically unless a downstream tool explicitly rejects R2000+ files, which is rare.

Stay below R2013 if you’re sending to older laser controller firmware. R2013 and above use a different encoding for some annotation entities that older TruTops and Bystronic installations don’t parse. For geometry-only flat-pattern exports (no dimensions, no annotations), this doesn’t matter — but it’s worth knowing.

For a complete breakdown of what each version adds and removes, see the DXF R12 vs R2000 vs R2010 reference table.

What about batch exports with CadShift

CadShift stores the DXF export version as part of the export profile, not as a global System Option. When you configure a profile to export in R14, every export from that profile uses R14 regardless of what version is set in System Options and regardless of who is logged in. A separate profile for a customer that requires R12 does not affect any other profile. For the SOLIDWORKS API DXF export approaches compared in detail, the per-profile version setting is one of the places where the add-in approach avoids the fragile global-setting dependency that macro-based exports inherit.

Summary

The problem occurs because SOLIDWORKS in R12 export mode writes ellipses as SPLINE entities (violating the R12 spec) rather than computing a POLYLINE approximation. Laser cutting controllers that validate DXF entity types against a known set reject SPLINE entities or drop them silently.

The fix is to export in R14 or R2000. Both versions support the native ELLIPSE entity, which laser controllers handle correctly.

The issue is specific to direct flat-pattern export. Drawing-view DXF export projects the geometry through the drawing annotation pipeline, which uses the R2000 entity model internally and produces ELLIPSE entities regardless of the System Options version setting.

For programmatic exports, set swDxfOutputType to 14 (R14) or 15 (R2000) before calling SaveAs3 or ExportFlatPatternView, and restore the previous value afterwards. Do not depend on the System Options dropdown being in the correct state.