The request surfaces a few times a month on r/SolidWorks and in engineering Slack channels. Someone has two hundred parts. They need a drawing for each one. Same template, same three views, title block linked to the same properties. They want to leave it running overnight. The top replies say “use Task Scheduler” or “ask ChatGPT to write a macro” and the original poster comes back in a week saying neither worked.

Task Scheduler (the SolidWorks add-in, not the Windows one) does a lot of things, but creating drawings is not one of them. ChatGPT can scaffold a macro, but it routinely picks the wrong API for view creation and silently produces drawings with no geometry. The actual automation path is small, well-documented inside the sldworks type library, and stable across the last five major releases. This is what it looks like.

What Task Scheduler actually does — and why drawing generation isn’t on the list

Open the SolidWorks Task Scheduler add-in (installed separately under C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS Task Scheduler\) and look at the task list. Update Files. Convert Files. Import Files. Print Files. Export Files. Run Custom Task.

Notice what’s missing: no “Create Drawing”. The scheduler wraps SldWorks.Application with a headless runner, but every task is a transform on an existing document — open it, change it or write a variant, close it. There is no template instantiation step in the scheduler’s internal vocabulary, because it was built for PDM migration loads and bulk conversions, not for generation of new derived documents.

The “Run Custom Task” option technically lets you drop a DLL in and do anything, but that DLL has to implement ITaskSpecification and ITaskExecutor from SolidWorksTools.TaskExecutor.Interop.dll, and it runs in the scheduler’s own process with the scheduler’s own threading rules. If you’re going to write a DLL, you’ve already left the scheduler behind — you might as well run a proper out-of-process console against SldWorks.Application.

This is the same in-process vs standalone decision covered in our breakdown of in-process and standalone SolidWorks API modes. Drawing generation is a perfect candidate for a simple standalone console; the Task Scheduler is the wrong shape for it.

The macro skeleton

Strip away the ceremony and a drawing-automation macro is four API calls.

Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swDraw As SldWorks.DrawingDoc
Dim errors As Long
Dim warnings As Long

Sub main()
    Set swApp = Application.SldWorks

    ' 1. Open the part or assembly
    Set swModel = swApp.OpenDoc6( _
        "C:\work\parts\bracket-001.sldprt", _
        swDocPART, _
        swOpenDocOptions_Silent, _
        "", errors, warnings)

    If swModel Is Nothing Then
        Debug.Print "Open failed: " & errors
        Exit Sub
    End If

    ' 2. Create a new drawing from a template
    Set swDraw = swApp.NewDocument( _
        "C:\work\templates\A3_landscape.drwdot", _
        0, 0#, 0#)

    ' 3. Drop standard three-view projection
    Dim ok As Boolean
    ok = swDraw.Create3rdAngleViews2("C:\work\parts\bracket-001.sldprt")

    ' 4. Save
    swDraw.Extension.SaveAs _
        "C:\work\drawings\bracket-001.slddrw", _
        0, swSaveAsOptions_Silent, Nothing, errors, warnings
End Sub

Run it inside SolidWorks and a drawing appears. That’s the whole happy path. Everything else in drawing automation — property-driven title blocks, BOM tables, flag notes, custom views — is structure built around this four-call core.

The arguments that matter

OpenDoc6

The sixth argument, configurationName, is easy to leave blank and forget. If the part has multiple configurations and you want the drawing to reference a specific one, pass it here. Blank means “the active configuration at last save”, which is whatever random state the model happened to be in.

swOpenDocOptions_Silent suppresses the “document saved in older version, please convert” dialog and any rebuild prompts. Without it, a batch run on 200 files will stall on the first legacy document waiting for a button click. If you have old files, also add swOpenDocOptions_OverrideDefaultLoadLightweight to force full mode — lightweight mode cannot feed drawing view generation.

NewDocument vs INewDocument2

NewDocument takes a template path. INewDocument2 takes a template path and sheet-format path separately. Use the second one if you keep your templates generic and swap sheet formats at runtime, which is the cleaner pattern for multi-size drawings:

Set swDraw = swApp.INewDocument2( _
    "C:\work\templates\generic.drwdot", 0, 0#, 0#)

Dim sheet As SldWorks.Sheet
Set sheet = swDraw.GetCurrentSheet
sheet.SetSize swDwgPaperA3size, 0#, 0#
sheet.ReloadTemplate True  ' True = reload custom properties

Create3rdAngleViews2

The “2” suffix matters. There’s a legacy Create3rdAngleViews (no suffix) in the type library that returns nothing useful and doesn’t take a path argument. Decompiling SolidWorks.Interop.sldworks.dll with ildasm shows:

.method public hidebysig newslot abstract virtual instance bool
    Create3rdAngleViews2([in] string modelName) runtime managed

One argument, boolean return. If you see Create3rdAngleViews without the 2, you’re looking at a stale AI-generated macro. The method finds the model by the exact string you pass, so the path must match the OpenDoc6 path character-for-character — including drive letter case on some Windows builds.

For first-angle projection (common in Europe and Asia-Pacific), the parallel method is Create1stAngleViews (no suffix, but also no “2” version — asymmetric naming is a SolidWorks hallmark).

Saving with Extension.SaveAs

The top-level SaveAs and SaveAs2 methods are deprecated. ModelDocExtension.SaveAs is the current one. The third argument takes an or-ed set of swSaveAsOptions_e values; swSaveAsOptions_Silent suppresses confirmations, and swSaveAsOptions_Copy creates a copy without switching the active document context — useful in batch runs where you want to keep the same drawing open and re-save under different names.

Property-driven title blocks

The whole point of automating drawings is that you shouldn’t have to edit each one. The title block reads custom properties directly; all you have to do is set up the template once and the data flows at drawing creation time.

Inside the template, every text note in the title block can use the linked-property syntax:

$PRPSHEET:"PartNumber"
$PRPSHEET:"Description"
$PRPSHEET:"Material"
$PRP:"DrawnBy"

$PRPSHEET reads from the model the sheet references. $PRP reads from the drawing document itself. If the part has PartNumber = "BR-100" and Material = "6061-T6", those notes resolve to those values the moment Create3rdAngleViews2 completes, because the sheet now has a reference.

If the title-block notes show up blank, three things are usually wrong:

  1. The property is on a configuration, not the file-level. $PRPSHEET reads from the active configuration first and falls back to file-level; if you write via CustomPropertyManager without specifying a config, the property ends up at file-level and the active-config lookup can miss on rebuild. Write with the config name set explicitly and this goes away.
  2. The sheet was created before the property was written. Sheet.ReloadTemplate True re-reads properties; call it after setting them.
  3. You used curly quotes ("like this") in the template instead of straight quotes. SolidWorks parses the token literally and silently fails with curly quotes. Set your editor to straight quotes only — this trips up anyone who edited the template in Word.

Setting properties from the macro before the save:

Dim cpm As SldWorks.CustomPropertyManager
Set cpm = swDraw.Extension.CustomPropertyManager("")
cpm.Add3 "DrawnBy", swCustomInfoText, "J. Nguyen", _
    swCustomPropertyReplaceValue
cpm.Add3 "DrawnDate", swCustomInfoDate, Format(Now, "yyyy-mm-dd"), _
    swCustomPropertyReplaceValue

Add3 is the right method — Add and Add2 are deprecated. The fourth argument decides what happens if the property already exists: swCustomPropertyDeleteAndAdd replaces, swCustomPropertyOnlyIfNew skips. swCustomPropertyReplaceValue updates the value if the property exists without changing its type.

Batch driving this from outside SolidWorks

For a single part the macro runs inside SolidWorks and that’s fine. For 200 parts, you want the driver out-of-process so SolidWorks can restart when the memory usage climbs. The equivalent skeleton in C# connecting to SolidWorks via COM interop:

using SolidWorks.Interop.sldworks;
using SolidWorks.Interop.swconst;
using System.Runtime.InteropServices;

var type = Type.GetTypeFromProgID("SldWorks.Application");
var swApp = (SldWorks)Activator.CreateInstance(type);
swApp.Visible = true;
swApp.UserControl = false;  // suppress dialogs

int errors = 0, warnings = 0;
foreach (var partPath in partPaths)
{
    var model = swApp.OpenDoc6(
        partPath,
        (int)swDocumentTypes_e.swDocPART,
        (int)swOpenDocOptions_e.swOpenDocOptions_Silent,
        "",
        ref errors, ref warnings);
    if (model == null) { Log($"Open failed {partPath}: {errors}"); continue; }

    var draw = (DrawingDoc)swApp.INewDocument2(templatePath, 0, 0, 0);
    var ok = draw.Create3rdAngleViews2(partPath);
    if (!ok) { Log($"Views failed {partPath}"); }

    var drawPath = Path.ChangeExtension(partPath, ".slddrw")
        .Replace(@"\parts\", @"\drawings\");
    ((ModelDoc2)draw).Extension.SaveAs(
        drawPath, 0,
        (int)swSaveAsOptions_e.swSaveAsOptions_Silent,
        null, ref errors, ref warnings);

    swApp.CloseDoc(((ModelDoc2)draw).GetTitle());
    swApp.CloseDoc(model.GetTitle());
    Marshal.ReleaseComObject(draw);
    Marshal.ReleaseComObject(model);
}

A few non-obvious things.

UserControl = false tells SolidWorks the user is not driving this session. Dialogs that would normally block (failed rebuild, missing reference, configuration prompt) are auto-dismissed. Without this, your batch hangs on the first part with a stale external reference.

ReleaseComObject on every model and drawing. SolidWorks holds RCW references until they’re explicitly released, and the process leaks native handles each time a document is opened and closed. After ~50 documents without releases, you start seeing “unable to obtain write access to file” errors on the save step because the previous document’s handles are still open.

Restart the SolidWorks process every N parts. Even with clean releases, SolidWorks’ internal caches grow. A batch of 500 drawings benefits from splitting into chunks of 50-100 with a full process restart between them. This is exactly the pattern used by the four levels of CAD automation — long-running batches graduate from macros to supervised multi-process runners.

Where AI-generated macros break

AI-assisted macro generation has improved a lot recently, but drawing automation is where it still consistently fails. The failure modes, in order of frequency:

  1. Wrong method name. Create3rdAngleViews instead of Create3rdAngleViews2, SaveAs2 instead of Extension.SaveAs, AddCustomInfo instead of Add3. The macro runs, returns no error, and produces a drawing with no views. The LLM is pulling from training data spanning 15 years of API evolution and mixing eras.
  2. Hardcoded sheet orientations. AI will set swDwgPaperAsize without checking the template’s actual format, so the sheet size changes and the title block no longer fits. Use ReloadTemplate True after any sheet size change.
  3. Missing UserControl = false. The macro works perfectly for the demo run and then hangs three hours into a batch because one part had a bad reference and a modal dialog appeared.
  4. No configuration awareness. The macro reads properties at file-level but the part stores them at configuration-level. Title block shows blanks. The AI has no way to know which level your shop uses.

If you’re using an LLM to bootstrap this kind of macro, paste the sldworks type library method signatures into the prompt as context. That single change raises the first-pass success rate from roughly 30% to above 80% in our testing.

Where SW 2026 Auto Drawings fits

SolidWorks 2026 introduced Auto Drawings, which is marketed as “create drawings automatically from any part or assembly”. What it actually does: applies a set of view layout rules (standard views, section if there’s a hollow body, detail if there’s a small feature), populates annotations from the model, and saves a drawing to a configured location. Essentially the same four API calls wrapped in a UI, plus some view-placement heuristics.

The surprising thing about Auto Drawings is that it doesn’t replace macros — it replaces the user clicking through the New Drawing wizard. You still need a template. You still need custom properties set up to feed the title block. You still need a way to kick it off on 200 parts, which it doesn’t provide. The only piece that a well-built macro didn’t already have is the view-placement heuristic, and even that you can replicate with DrawingDoc.CreateDrawViewFromModelView3 calls with explicit positions.

For teams with a solid macro already, Auto Drawings is a nice UX improvement for one-off drawings. For automation at scale, the macro approach outlined above is still what production batches look like.

The template is where the effort actually goes

Most failed drawing automations fail at the template, not the macro. Every minute spent on template setup saves ten minutes of macro debugging. What a production-grade template needs:

  • Sheet formats for every size you use. A3 landscape, A2 landscape, A1 landscape, Letter. Kept as separate .slddrt files so you can swap via Sheet.SetTemplateName.
  • Title block built with linked notes only. Every field resolves from a property. If you have to type into the title block, the template isn’t done.
  • Layers configured for printing. Pen widths and colors set per layer. Laser-cut geometry on CUT, bend lines on BEND, dimensions on ANNOTATE. This matches what fabricators expect in DXF output and is the same layer conventions that flow through drawing-to-DXF export.
  • Default view settings baked in. Shaded with edges off, tangent edges hidden, view scale matches sheet size automatically via a document property.
  • A saved BOM template if you’re generating assembly drawings. BomTemplate path pointed at a .sldbomtbt.

Once the template is right, Create3rdAngleViews2 does the heavy lifting. The drawing that comes out is properly sized, properly labelled, properly linked, and ready for print with zero manual steps.

Where this plugs into a real export flow

The drawing is the intermediate artefact. What fabrication actually consumes is the DXF (for laser/waterjet/plasma) or the PDF (for shop-floor reference and inspection). The pattern that works in production is:

  1. Macro opens the part.
  2. Macro generates the drawing from template.
  3. Macro exports the drawing to DXF and PDF at known paths.
  4. A separate process (or a later step in the same macro) cleans up the DXF — removes construction geometry, merges collinear lines, fixes layer mapping — and ships it to the CAM station.

The cleanup step is where CadShift fits. The macro gets you a drawing and a raw DXF; the cleanup pipeline turns that DXF into something a machine operator can actually load without fighting layer mismatches and hidden geometry.

For weldment assemblies, SolidWorks Tab and Slot changes the flat pattern geometry before the macro even runs — the self-locating joints appear as cut features in the sheet metal body, which affects how views look in the drawing and what ends up in the DXF. Worth understanding before you automate weldment drawings at scale.

Drawing automation is small once you see the shape of it. Four API calls, one decent template, a property flow that runs on save. The reason most shops don’t have it isn’t the difficulty — it’s that the Task Scheduler and the AI-macro dead ends eat the time budget before anyone writes the actual macro. The macro is sixty lines. Write it once, run it for a decade.