Every few weeks a mold shop posts a job for a Python or C# developer who can automate their SolidWorks mold design pipeline. The scope is usually the same: take an incoming 3D model, run shrinkage, generate parting surfaces, split the core and cavity, and hand off tooling data. The assumption is that because SolidWorks has a documented API, every mold step is scriptable. It isn’t. Some steps map cleanly to IFeatureManager calls. Others still require a human to pick faces in the graphics area. Knowing which is which is the difference between a pipeline that ships and one that spends six months bouncing between the add-in and the user.
This post covers what mold tools are exposed in the COM API, where the gaps are, and how to architect an automation pipeline that accepts those gaps instead of fighting them.
The Mold Tools Feature Tree
SolidWorks’ Mold Tools toolbar is a linear workflow: scale the part, insert parting lines, build shut-off surfaces, construct parting surfaces, then do the tooling split. Each of these produces a feature in the tree. The API exposes almost all of them through IFeatureManager, but with a critical caveat — most of the methods are thin wrappers that depend entirely on selection state built up beforehand.
This is the pattern you see across the mold API:
// Select inputs with marks, then invoke the feature builder
ModelDocExtension ext = model.Extension;
ext.SelectByID2("Face<1>", "FACE", 0, 0, 0, false, 1, null, 0); // direction of pull, mark 1
ext.SelectByID2("Edge<1>", "EDGE", 0, 0, 0, true, 4, null, 0); // parting line edges, mark 4
IFeature partingLine = featureManager.InsertMoldPartingLine(true);
The SelectByID2 marks are not optional. InsertMoldPartingLine inspects the current selection set and routes each selected entity based on its mark. Direction of pull is mark 1. Parting line edges are mark 4. Miss one and the call returns null or throws. This design decision ripples through every mold method in the interop — you are not passing arguments to a function, you are preparing a selection context and then invoking a verb.
What Maps Cleanly to the API
The parts of mold design that are genuinely automatable:
Scale. IFeatureManager::InsertScale2 takes the scaling factor, the axis selection, and whether to scale about a point or the centroid. Straightforward — no complex selection dance.
Parting line insertion (once edges are picked). InsertMoldPartingLine works once you have the direction-of-pull face and the closed loop of edges selected with the right marks.
Tooling split. InsertMoldToolingSplit takes the block dimensions and produces the two solid bodies for core and cavity inserts, provided the parting surfaces and shut-off surfaces already exist in the MoldFolder.
Cavity feature in assembly context. InsertCavity2 on the assembly feature manager subtracts a chosen part from the block, which is the final subtraction step for multi-cavity molds.
Reading geometry. Extracting faces, edges, draft angles, and material properties is entirely scriptable. IBody2::GetFaces, IFace2::GetArea, IFace2::GetNormal — these give you everything you need to decide whether a part is mold-ready before you start building tools.
Material and property reads. Custom properties, configurations, bounding box via IPartDoc::GetPartBox — trivial to automate.
This subset is enough to build a useful add-in. You can accept a part, run a shrinkage factor from a customer record, generate a mold block at a calculated size, and commit the tooling split, all without the user touching the screen. Four levels of CAD automation frames this well — mold prep sits squarely at Level 3, where you want real API integration without a full configurator.
Where the API Forces You Back Into the UI
Parting line edge selection is not automatic. The API gives you InsertMoldPartingLine, but it does not give you a function that says “find the parting line for this part.” SolidWorks has a Parting Line PropertyManager that analyzes faces, classifies them as core, cavity, straddle, or positive draft, and suggests edges. That analysis is not exposed. You can read the resulting feature after a human creates it, but the automatic edge-detection logic lives behind the dialog and is not on any interface in SolidWorks.Interop.sldworks.dll.
Decompiling the interop DLL with ildasm SolidWorks.Interop.sldworks.dll /text confirms it: there is no AnalyzeDraft method, no SuggestPartingEdges method. What’s public are the verb methods — Insert*, Create*, Apply* — and getters to read back the resulting feature. The intelligence is internal.
Shut-off surface detection. Shut-offs seal through-holes so the parting surfaces can be knit into a closed boundary. The Shut-Off Surfaces command shows a list of detected holes with a traffic-light indicator (green = good, yellow = patch needed, red = no patch possible). The detection logic is not API-reachable. You can create shut-off surfaces manually via the filled-surface API, but you lose the tool’s classification and auto-patching.
Parting surface construction from parting lines. InsertMoldPartingSurface exists, but its tangent-to-surfaces and perpendicular-to-pull options need surface references that you typically pick interactively on the edge loop. For a uniform parting line on a simple part, you can script it. For anything with draft variations, the surface-reference selection becomes the bottleneck.
Core-side vs cavity-side classification. When parting surfaces don’t cleanly split the block, SolidWorks asks the user to resolve ambiguous regions. There’s no API hook for that resolution.
The pattern: the API gives you the construction verbs. It does not give you the reasoning that the interactive tools apply before construction.
A Realistic Automation Architecture
Given the gaps, the pipelines that work in production split into three phases:
Phase 1: Fully automated intake
Accept the incoming model (STEP, IGES, or Parasolid), classify it, and reject it if it’s not mold-ready. This phase uses only the geometry-reading side of the API:
// Walk all faces, classify by draft angle
IBody2 body = (IBody2)part.GetBodies2((int)swBodyType_e.swSolidBody, false)[0];
object[] faces = (object[])body.GetFaces();
double[] pullDir = new double[] { 0, 0, 1 }; // +Z
int positive = 0, negative = 0, straddle = 0;
foreach (IFace2 face in faces)
{
double[] normal = (double[])face.Normal;
double dot = normal[0]*pullDir[0] + normal[1]*pullDir[1] + normal[2]*pullDir[2];
if (dot > 0.01) positive++;
else if (dot < -0.01) negative++;
else straddle++;
}
// Reject if straddle > threshold, flag for manual review
This kind of intake filter catches 60-70% of the unsuitable parts before a human looks at them. It’s boring, tractable code, and it saves real time.
Phase 2: Semi-automated mold build
The part survived intake. Now you run shrinkage, create the mold block, and set up the selection state for parting line insertion — but you stop there and surface the draft analysis to the operator. The operator picks the parting edges in 30 seconds, clicks a button, and your add-in runs the rest of the pipeline: parting surfaces, shut-offs, tooling split.
This is where the naive “automate everything” approach fails. Trying to detect the parting edge loop programmatically is a PhD thesis. Letting the operator pick it and then automating the 15 clicks that follow is a two-week project.
Phase 3: Data extraction and handoff
Once the tooling split is done, everything downstream is scriptable: exporting cavity and core as separate parts, generating drawings, batch-exporting DXF of the cavity inserts for EDM or wire cut, embedding metadata into output files. This is the phase where tools like batch DXF export from SolidWorks live — once the mold bodies exist, getting them to the shop floor is solved terrain. Batch export respects the part-level properties that Phase 1 already validated, which is why those intake metadata reads are worth the upfront effort.
In-Process vs Standalone for Mold Automation
Mold automation is one of the clearer cases where the architecture matters. The parting line insertion, shut-off surfaces, and tooling split all depend on selection state that lives inside the SolidWorks session. Doing this via standalone COM from a Python script means marshaling every SelectByID2 call across the process boundary, which is slow and unreliable for the dozens of selections a single mold build needs.
An in-process add-in has direct access to the selection manager and the model document without marshaling. If you’re serious about shipping mold automation, it’s an add-in — not a script. The in-process vs standalone SolidWorks API question covers the full tradeoffs, but for this specific domain, the answer lands firmly on in-process.
Where AI-Generated Macros Fail on This
A recurring question is whether ChatGPT or similar tools can generate mold automation. For the Phase 1 geometry reads, yes — AI produces workable code because the API surface is well-documented and the input-output contract is clean. For Phase 2 and 3, AI-generated code consistently misses the selection-mark discipline. It will call InsertMoldPartingLine(true) without first calling SelectByID2 with marks 1 and 4, because the mark requirement is a remark in the API docs rather than a parameter. The code compiles, runs, and returns null. AI-generated SolidWorks macros still fail on coordinate systems and selection context for the same underlying reason — the API enforces invariants outside the method signature that LLMs don’t pick up from a single function description.
What CadShift Does in This Pipeline
CadShift sits in Phase 3. Once the mold is built and the cavity and core inserts are separate parts, CadShift’s batch export takes them to shop floor artifacts — DXF for wire EDM, PDF with QR codes for the mold assembly, embedded metadata for the CNC programmer. The export step is where most mold shops still manually click File > Save As on each insert, twice. Automating it saves 20-40 minutes per mold, and the metadata consistency matters when the same block is being quoted by multiple shops.
Mold Design Gotchas in the API
A few things that trip people up and aren’t in the docs:
Scale before parting line. Inserting a parting line before scaling breaks the feature when shrinkage is applied later. The SolidWorks UI enforces the order; the API doesn’t. Your script has to.
Direction-of-pull face must exist on the part. If you try to pass a coordinate system as the direction of pull, the parting line call silently fails. The face selection is the supported path. If you want coordinate-system-based pull, create a reference plane on the fly and use one of its faces.
InsertCavity2 requires the component being subtracted to be the selection. Not the block. This reverses the intuitive “subtract X from Y” ordering and catches every developer the first time.
Mold folders are populated but not always ordered. IFeatureFolder::GetFeatures returns the contents, but the order isn’t guaranteed across versions. If your script depends on finding “the first parting surface” by index, it will break on the next upgrade. Filter by IFeature::GetTypeName2() instead.
2025 changed corner relief processing on flat patterns. If your mold pipeline produces sheet metal cavity inserts or stripper plates, the 2025 flat pattern upgrade issues apply — worth checking before rolling an add-in forward.
The Honest Scope
If a mold shop asks for “full automation,” the right response is to scope it in phases. Phase 1 intake is a week. Phase 3 handoff is two weeks. Phase 2 — the part everyone assumes is the easy middle — is where the gaps live, and the realistic answer is semi-automation with a human in the loop for 30 seconds per mold. That’s the pipeline that ships. Anything else is a proposal, not a product.
The API is capable. It’s just not omniscient. Design around what it knows, keep the human where the intelligence lives, and the pipeline holds up.