There is a company I know that sells conveyor stands in four nominal widths, six lengths, and two leg styles, which is forty-eight machines that differ in maybe six dimensions. When I first walked their CAD library, they had forty-eight separate assemblies, each built by a different engineer with a slightly different idea of how a leg should be modeled. Every mirror image was a hand-built copy. Every length change took an afternoon and produced a drawing that had to be re-checked by hand. It was not a CAD skill problem; it was a total absence of configuration strategy. This article is the strategy I installed there, and the same one I use on any family of parts or machines that keeps coming back with the same shape and a different size.
What Configuration-Driven Design Actually Means
Configuration-driven design is not a feature you switch on; it is a way of deciding which dimensions are allowed to vary and which are sacred. In practice it means one master model, a short list of driving variables, and a table that maps those variables to named sizes. The master model is the geometry with every dimension tied to a variable, and the configuration is just a row in the table that says width equals nine hundred, height equals one thousand, and plate thickness equals six. When a quotation needs a size that is not in the table, you add a row, not a new model, and the geometry, the BOM, the drawing, and the weight all update from that single addition.
| Approach | Setup cost | Per-size cost after release | Where it breaks |
|---|---|---|---|
| Copy the assembly | Low, feels fast | High forever, every change is manual | First revision to a family |
| Configuration table | One-time medium | Near zero | When temptation adds exotic rows |
| Scripted generator | High, needs code owner | Zero, but fragile | When the script outlives its author |
I usually land in the middle column. Scripted generators are seductive and I have built a few, but they rot when the engineer who wrote them leaves and the next person is scared to touch the macro. A configuration table is dumb enough to survive and smart enough to pay for itself, which is exactly the trade I want from production tooling.
Naming Your Variables Like an Accountant
Most parametric models die not from bad geometry but from bad variable names. I once inherited a part where the width was driven by a dimension labeled d1, and d1 turned out to be the thing nobody could find, because d1 meant pressure, length, and plate size across three different sketches. My rule is that every driving variable gets a name that would survive a stranger reading it in five years: W_FRAME, H_CLEARANCE, T_PLATE, D_HOLE_PITCH. I put the driving table at the top of the feature tree, one section, alphabetized, with a comment column explaining what each variable controls. It sounds like housekeeping; it is actually the difference between a model future-you can edit and a model that future-you will redraw secretly behind the project manager’s back.
A configuration is a promise about a set of dimensions. If the table does not say what it changes, the model will change something it shouldn’t, on the worst possible afternoon.
On the design table itself I keep the discipline that saved the conveyor company: the table dims everything over the range you actually sell, and nothing more. When a customer asks for a nine hundred and fifty millimeter version that no other machine has ever used, the correct answer is usually a new row, evaluated once, and if it triggers a geometry failure, that failure is the design telling you nine fifty does not work with the current topology, which is exactly the information you want before you quote it, not after.
The Mirror and Pattern Traps
Configuration families have two classic traps, and I have fallen into both with my eyes open. The first is mirroring. A mirrored part is a new file with its own identity, and if you configure it by hand every time the base changes, you are maintaining a lie: you will update the base, forget the mirror, and ship a left-handed machine with a right-handed mounting pattern. My solution is to mirror late and derive early: build the mirrored instance as a configuration of the same master where a mirror switch flips the hand, so both hands live in one table and can never drift apart. When that is truly impossible, I derive the mirror file from the base and treat any manual edit as a red flag during review.
| Feature | Configuration-safe habit | Deadly habit |
|---|---|---|
| Mirror hand | Mirror switch in the table | Hand-editing the mirror file |
| Hole patterns | Driven by pitch and count variables | Individually placed circles |
| Member lengths | Derived from envelope dims | Typed values that shrug as the envelope moves |
| Suppressed bodies | Config-driven suppression states | Manual suppression nobody logs |
The second trap is the hole pattern. I still meet designers who place eight circles by hand in a pattern and then wonder why the nine hundred millimeter configuration has the holes in the wrong place. Every repeating hole gets a pitch and a count as variables, and the pattern references the envelope, never a fixed dimension. When the frame grows, the holes follow, and the drawing balloons match the model, which is the only way a family drawing stays honest across six sizes.
Making the Drawing and BOM Follow the Table
The whole point of a configuration family collapses if the drawing and the bill of materials still have to be redone by hand for each size, so I spend real effort making the paper follow the model. In the drawing, every dimension that the table drives is attached to a driving dimension or a global variable, and the title block shows the configuration name, so the drawing for the nine hundred version differs from the one thousand version only where it should: a few numbers and a configuration label. The BOM is generated from the model, with quantity, material, and length derived, and the config drives the whole sheet in one shot.
Here is where the conveyor company story pays off. After the first two weeks of table building, a new quotation stopped being an afternoon of drawing and became a five-minute exercise: open the master, add or select the row, export the drawing, check the BOM, done. The engineering manager told me their quoting backlog melted because the answer to “how much for a nine-fifty?” was no longer a full design cycle, it was a configuration review. That is the economic case for all of this: not elegant models on a screen, but a supplier that can answer a sizing question in minutes instead of days.
The Regression Rule That Keeps It Honest
Configurations rot in one specific way: someone changes a rule to fix one size and silently breaks six others, and nobody notices until a drawing ships wrong. The cheapest guard is a check list generated by the model itself, a small table that reports weight, bounding box, and hole count for every configuration, and I compare that table against the released values whenever the master is edited. If the nine hundred version suddenly weighs forty kilos less and no one changed its row, the regression detector raises the alarm and the review catches it while it is still a chat, not a recall. I do not trust my memory to audit twenty configurations, and neither should you; make the model audit itself.
| Audit check | What it catches | Frequency |
|---|---|---|
| Weight per config | Accidental material or geometry change | Every master edit |
| Bounding box | Drifting envelope dimensions | Every master edit |
| Hole count | Lost pattern instances | Every master edit |
| BOM part list | Silent part removals | Before every release |
None of this is heroic. The master model, the driving table, the named variables, the derived drawings, and the self-reports are each unglamorous, and together they turn a family of forty-eight machines into one file with forty-eight honest rows. The last piece is emotional rather than technical: you need to resist the urge to solve every new order by copying the closest file and tweaking it, because that is exactly how the forty-eight identical but different assemblies got built in the first place. When the order does not fit the family, that is information, and the family should grow one row at a time, deliberately, with a reviewer watching the table.
I still keep a hand-built special now and then, because some requests genuinely do not belong in a family, a one-off with a strange gusset or an odd motor pocket. The discipline is to know the difference and to say it out loud: this is family, or this is special. Families get configuration rows; specials get their own file and their own review, and the two never share a tree. Get that boundary right, and configuration-driven design stops being a buzzword and starts being the boring, reliable way you quote the next machine before lunch.
A Quick Start in Five Steps
If you want to convert your next recurring part into a configurable family, here is the order I actually follow, and I have done it enough times to know the shortcuts are traps.
- List the sizes you have actually sold in the last two years. That range, not your imagination, is the table you need.
- Identify the six to ten dimensions that really drive the design. Everything else stays fixed until the geometry proves otherwise.
- Rename those dimensions as global variables with readable names, and build the master from them.
- Create the configuration rows from your sales list, and fix whatever geometry breaks, because a break now is a quote error later.
- Derive the drawing, the BOM, and the audit report, and only then declare the family released.
| Term | What it means in this workflow |
|---|---|
| Master model | The single geometry that all sizes share |
| Driving variables | The named dimensions that the table sets |
| Configuration table | The rows that map variable values to named sizes |
| Derived drawing | A sheet that updates from the model, not from retyping |
| Regression audit | The self-report that catches silent changes |
Five steps sounds small because it is. The work is not in the mechanics, it is in the refusal to copy files, in the discipline of named variables, and in the honesty of the audit. I have watched teams adopt configuration design on a Tuesday and abandon it by Friday because the first master took three days and the bean counter saw no drawing produced; the payoff lands on the second order, the third, and every order after. If your parts keep coming back the same shape with different numbers, you are not saving time by rebuilding them, you are paying a standing tax. Configuration-driven design is how you stop paying it.
One honest warning before you start: the first configuration master always feels slower than copying the file, and it is. The second one is faster, and by the third you will be angry at every past-you that rebuilt a family by hand. Keep the table small, name every variable, mirror only through the model, and let the drawing and BOM follow the table instead of the other way around. That is the whole recipe, and it is worth every minute of setup the first week.
I will leave you with the metric I use internally: a family is working when a new size becomes a one-line change and a five-minute check, and failing when it still needs a designer’s afternoon. Watch that cost on your next recurring part, and once you see it, you will never build the same machine twice by hand again.
