Configurations vs. Parametric Variables: Designing One Model, Many Robots

Advanced teams rarely model the same family of parts twice. The tools are parametric variables and configurations, and choosing the right one is a design-intent decision.

Parametric variables live as features in the Part Studio (#track, #centerDist, #web). They drive geometry within one design and are unit-sensitive. They are perfect when you want a single part that resizes — change #centerDist and the gearbox plate's bores move together. They do not create separate selectable variants; there is one part whose dimensions you tune.

Configurations create named variants of the same Part Studio or Assembly — e.g., a side plate in 'short', 'medium', 'long' lengths, or a swerve mount for MK4i vs MK4n. Each configuration is a distinct selectable option, and configuration variables can be enforced with default/min/max limits and are accessible across tabs and documents. You can mix configuration inputs (a dropdown like motor = NEO/Kraken) with configuration variables (a numeric like length = 6/8/10 in). The Onshape rule of thumb: use a parametric variable when there is one design that flexes, and a configuration when you need discrete, named alternatives that coexist.

Worked example — a configurable gearbox plate. Build the single-stage plate from Mini-Project 2 with a configuration input motor (NEO / Kraken X60 / Falcon 500). Drive the bolt pattern from the configuration so each option lays down the correct footprint. Add a configuration variable ratio that swaps the gear teeth (and thus #centerDist). Now one Part Studio yields every gearbox your team needs, and the BOM lists exactly which configuration each instance uses.

Worked example — passing values between studios. When a configured sketch needs to drive a downstream Part Studio, instantiate the configured sketch into the destination and pass the configuration value through. This keeps a family of mounts in sync with a single source of truth.

Pitfall: configurations multiply quickly. A 3-option motor × 3-option ratio × 2-option length = 18 variants; only the ones you actually instantiate get computed, but the table can get unwieldy. Keep configuration tables small and meaningful, and reach for a FeatureScript (next lesson) when the logic is more complex than a table can express.