A user on r/SolidWorks described building a car-configurator-style model. A global variable NumSlots drove both the count of a linear sketch pattern and a sweep feature that read the slot spacing. After dragging the configuration slider, the sweep updated. The sketch pattern did not. Opening the sketch, closing it without touching anything, then rebuilding — slot count finally snapped to the new value.

This is not a bug report. It is a predictable consequence of how SolidWorks schedules equation evaluation during a model rebuild. Once you understand that schedule, you stop designing models that depend on the wrong evaluation order and start structuring equations so they survive a Ctrl+B.

Two kinds of equation-driven dimensions

SolidWorks equations appear to work uniformly: you type "D1@Sketch3" = "NumSlots" * 12 and the dimension updates. Under the hood, there are two completely different evaluation paths depending on where the dimension lives.

Feature-driven dimensions are parameters of features in the feature tree: a linear pattern’s count (D1@LPattern1), an extrusion depth (D1@Boss-Extrude1), a fillet radius, a hole size. These are owned by the feature and evaluated during the feature’s rebuild pass. When the model rebuilds, SolidWorks walks the feature tree from top to bottom, running each feature’s equation set before executing the feature geometry.

Sketch-driven dimensions are dimensions inside a sketch (a SmartDimension on a sketch line or arc). These belong to the sketch’s own constraint solver. The sketch solver runs when the sketch is opened, or when a rebuild explicitly touches that sketch because a parent feature it depends on changed.

The problem is that SolidWorks rebuild does not always treat a sketch as “needs re-solving” just because a global variable changed. It marks the sketch dirty only if a parent feature that geometrically feeds into the sketch is marked dirty. A global variable change — on its own — is not a geometric parent.

The evaluation schedule

The full rebuild pipeline for a parametric SolidWorks part looks like this:

  1. Global variable equations — computed once, in the order they appear in the Equations dialog. Circular dependencies generate a warning here.
  2. Suppression equations — features that evaluate a true/false expression to determine if they are suppressed. These run before geometry.
  3. Feature tree, top to bottom — each feature is evaluated in order. If the feature’s inputs are unchanged (by SolidWorks’s dependency graph), the feature is skipped.
  4. Open sketches — if you have a sketch open in edit mode when you force a rebuild, the sketch constraint solver runs again.

The critical point is step 3: SolidWorks builds a dependency graph when you add equations. If the graph says “Sketch3 doesn’t depend on NumSlots”, it will skip Sketch3 even if NumSlots just changed and Sketch3 has an equation that references it.

This graph is conservative. It tracks geometric parents (features that produce bodies or edges the sketch snaps to) rather than equation-level references. A global variable does not create an edge in this graph.

The linear sketch pattern trap

Here is the exact scenario that caused the Reddit thread:

NumSlots = 5

Linear Pattern Feature:
  count = "NumSlots"        ← feature-driven, evaluates correctly
  spacing = 20mm            ← fixed, no equation

Sketch inside the linear pattern:
  slot_width = "NumSlots" * 2   ← sketch-driven, evaluates only when sketch rebuilds

When you change NumSlots from 5 to 8:

  1. Global variables update: NumSlots = 8
  2. The linear pattern’s count evaluates: 8 instances are created
  3. SolidWorks checks Sketch3 — it has a geometric parent (the pattern feature). That parent changed (count changed). So the sketch IS marked dirty… but the sketch constraint solver only updates dimensions that depend on sketch geometry changes, not equation re-evaluations of already-existing dimension values.

The result: you get 8 pattern instances, but the slot_width dimension inside the sketch still shows the old value until the sketch is explicitly opened and closed.

In SW2025, linear sketch patterns received a partial fix — the pattern count now directly links to equations without the old “you can only type a number here” limitation. But the propagation issue for sketch-internal dimensions driven by global variables was not fully resolved. The constraint solver still does not treat a global variable change as a trigger for a sketch-level re-solve on its own.

How to see what is happening: the Evaluation Order view

The Equations dialog has an Evaluation Order tab (Tools → Equations → Evaluation Order). This view shows you which features depend on which equations and in what sequence they will resolve.

If you see a sketch dimension listed as depending on a global variable but the feature that uses that sketch appears before it in the evaluation order, you have a problem. The feature will rebuild before the sketch equation resolves.

The evaluation order list is editable — you can drag entries to change the sequence. For most models this is not needed. For configurators, it is the first place to look when a rebuild produces wrong geometry.

Three patterns that break

Pattern 1: Global variable drives a sketch pattern count

"D1@[email protected]" = "Rows"

This works in SW2025 and later. In SW2022 and earlier, SolidWorks rejects this with “you can only type a number here” — instance counts in sketch patterns only accepted literals. The workaround was a feature-level linear pattern (not a sketch-level one) or a design table.

If you are on pre-2025 and need configurable sketch patterns, replace the linear sketch pattern with a feature linear pattern (ILinearPatternFeatureData in the API) and drive the count with an equation at the feature level.

Pattern 2: Global variable drives both feature count and sketch spacing

This is the car-configurator scenario. The count updates immediately; the spacing does not.

Fix: put the spacing computation in a feature-level dimension, not a sketch dimension. Create a reference plane at the computed offset, use that plane to locate the sketch. The reference plane is a feature — its position equation evaluates in the feature tree, not in the sketch solver.

"Distance@Plane1" = "NumSlots" * "Pitch"   ← feature-level: evaluates reliably

Pattern 3: Configuration-specific equations with suppressed features

A common configurator pattern: if ConfigType = "Heavy", suppress a lightweight extrusion and unsuppress a heavy one. The suppression equations are run in step 2 (before geometry), so the suppression state is correct. But if a sketch inside the now-active feature also has an equation referencing ConfigType, that sketch equation may not re-evaluate because SolidWorks saw the sketch as unchanged (it was suppressed in the previous configuration’s rebuild state).

Ctrl+Q flushes this. But production configurators should not depend on Ctrl+Q — that is a workaround, not a design.

Fix: restructure so configuration-specific sketches do not contain equations that reference configuration-specific global variables. Instead, drive those sketches from the configuration’s own dimension values in the configuration properties, not from global variables.

The Ctrl+Q vs Ctrl+B distinction

Ctrl+B (Rebuild) rebuilds features that SolidWorks marks as dirty based on its dependency graph. Fast, but skips what the graph believes is unchanged.

Ctrl+Q (Force Rebuild All) forces every feature to rebuild, in order, discarding the dirty-state cache. This guarantees correct geometry but is expensive — on assemblies with hundreds of parts, it can take minutes.

For debugging evaluation order problems, always start with Ctrl+Q. If Ctrl+Q fixes the problem but Ctrl+B does not, you have a dependency graph gap: something changed that SolidWorks’s graph does not track as a dependency. Usually this is a global variable → sketch dimension relationship where no geometric edge exists in the graph.

The fix is to make the dependency explicit. Either:

  • Add a driven dimension (a reference dim that does not constrain geometry) that references the global variable inside the sketch — this creates a graph edge
  • Or better: restructure so the sketch derives its values from a feature (plane, reference axis) that does already depend on the global variable

API implications for automation

If you are writing a SolidWorks macro or add-in that changes global variables programmatically, you cannot assume the model is correct after a single IModelDoc2.EditRebuild3() call. For configurator-style automation, the safe sequence is:

// Change a global variable
bool ok = swModel.SetGlobalVariable(varName, newValue);

// Force full rebuild — do not use EditRebuild3 alone
swModel.ForceRebuild3(false);  // false = do not rebuild all configurations

// For assemblies with dependent parts:
swModel.ForceRebuild3(true);   // true = rebuild all open components

ForceRebuild3 with true is equivalent to Ctrl+Q applied to the whole assembly. It is slower but produces a consistent state. In batch-export scenarios — where you are driving configurations programmatically and then exporting DXFs — using EditRebuild3 without a forced rebuild can silently export stale geometry. CadShift’s export pipeline calls ForceRebuild3 before each DXF write precisely because VBA macros routinely miss this step.

For configuration switching, the correct sequence is:

swModel.ShowConfiguration2(configName);
// At this point, the model may not be in the correct state yet

swModel.ForceRebuild3(false);
// Now geometry reflects the configuration

The ShowConfiguration2 call marks the configuration as active and fires the suppression equations, but the feature tree rebuild is deferred. The rebuild does not complete until you call a rebuild method or SolidWorks does it automatically (which it will, but only for interactive use — not in background/macro contexts where SolidWorks runs headless).

A reliable configurator checklist

  1. Global variables first. All shared constants (material thickness, pitch, mounting hole size) live in global variables, not as hardcoded sketch dimensions.

  2. Feature-level for counts and spacing. Pattern counts, offsets, and dimensions that control geometry arrangement are driven at the feature level, not inside sketches.

  3. Sketches contain only geometric constraints. Sketch dimensions reference parent feature geometry (intersection points, projected edges) rather than global variables directly. This makes the dependency graph complete.

  4. Test with Ctrl+B after Ctrl+Q. If the two produce different geometry, you have a dependency gap that needs to be closed structurally, not patched with force-rebuild.

  5. For configurations: use configuration-specific dimension overrides (right-click dimension in feature tree → Configure Dimension) rather than if(config = "A") then ... equations. Configuration dimension overrides are stored per-configuration and always evaluate correctly.

  6. For automation: always ForceRebuild3(false) after any equation or global variable change before reading geometry or triggering an export.

The underlying principle is that SolidWorks’s dependency graph is geometry-first, not equation-first. Design models so that the geometry structure makes the right dependencies explicit, and the evaluation order problem goes away without workarounds. For the batch DXF export workflows that configurators typically feed into, model correctness before export is non-negotiable — stale geometry in the DXF is worse than no DXF at all.