Almost nothing in signage or fit-out is built from the first model. The fascia measures 280 mm longer than the survey said, the client moves from 4 mm composite to 3 mm, the landlord wants the logo 100 mm lower, and the twentieth shop in a rollout has a soffit nobody warned you about. None of that is a design failure, it is the normal rhythm of the job. What decides whether a change costs twenty minutes or two days is how the model was built before anybody asked for one.
Two lists, written before the first sketch
Before drawing anything it is worth splitting the job into two lists.
The first is what will change: overall length and height, panel thickness, the number of joints, letter height, the depth of the wall build-up, handing, finish. These are decided by the site, the brand rules or the price, and all of them are still open when you start modelling.
The second is what must not be re-decided every time: the minimum flange length the press brake can hold, the bend radius for the material you actually buy, fixing centres that suit the substrate, the clearance a service run needs behind a tray, the return depth that keeps a long panel from reading as wavy. That list is fabrication knowledge, not client input.
The first list becomes named parameters. The second becomes relations inside the model, formulas and constraints, so that a revision cannot quietly break a rule the workshop depends on. Typed-in numbers are where both lists get mixed up, and a mixed model is the one that has to be redrawn.
A skeleton the parts read from
For anything with more than a couple of components, the setting-out belongs in one place: a skeleton. One file holding the lines that matter, wall face, fascia line, floor datum, the fixing grid, the centre line of each letter, plus the handful of parameters that drive them. Every part then derives its shape and position from that skeleton instead of from its neighbour. Move the fascia line and the tray, the end caps and the frame follow.
Two things keep a skeleton useful. Keep it dumb: lines, planes, named parameters, no fillets, no material, no detail that belongs to a part. And when a job grows sub-assemblies, a tray, a frame, a set of letters, derive a second skeleton for each of them from the master rather than letting one file collect forty sketches.
There is a choice worth making consciously in Inventor: components can be derived so they inherit both shape and position from the skeleton, or shape only, with position held in the assembly. Inheriting both is tidier for a one-off structure. Shape only is better when the same part appears at several positions, or at the next site, because moving it no longer counts as a revision of the part.
Where references break
Most models that die on the first change die for the same reason: a feature was attached to geometry that was itself a result. A hole placed on a face created by a fillet. A sketch constrained to the edge of a chamfer. Change a dimension three features earlier and that face no longer exists under the same identity, and the model comes back with a list of sick features.
The rule is to reference only geometry you created on purpose: origin planes, named work planes, and sketches you placed yourself. It costs a minute more while modelling and it is the difference between a rebuild and a repair.
Two habits help. Push cosmetic features to the end of the tree, fillets, chamfers, branding reliefs, the small holes for a cable gland, so that suppressing them is safe and nothing structural depends on them. And constrain sketches to the datum rather than to a neighbouring edge. A fully constrained sketch, dimensioned to something stable, is what makes a parameter change propagate instead of collapse.
Parameters with names, not numbers inside features
Name parameters the way the shop talks: fascia_length, panel_thickness, return_depth, letter_height,
fixing_pitch. The point is not elegance, it is that eight months later a change can be made from a list of
named values without opening a single feature.
Derive the rest. The number of panel joints follows from the length and the maximum sheet width you can buy. The flange allowance follows from the thickness. Keep derivation shallow, one or two levels, because a formula that depends on four other formulas is a thing you have to debug at the worst possible moment.
Where the logic stops being arithmetic, choosing a frame section by span, swapping a fixing type when the wall build-up changes, picking a different panel breakdown above a certain length, a parameter table is no longer enough and a rule or a script earns its place. That is the point where modelling turns into CAD automation, and it is worth crossing deliberately rather than by accident.
Twenty sites: one file or twenty?
For a rollout the structural question is where the variants live.
| Approach | Good for | What it costs |
|---|---|---|
| Variants inside one file (model states or configurations) | 3 to 8 versions of the same product: widths of one tray, two illumination options | Everything shares one base, so one mistake affects every variant; the file grows and gets slower |
| One file per site | Sites that genuinely differ: another wall, another planning constraint, another installer | A correction has to be applied as many times as there are files |
| Generated from a rule set | A product that repeats at scale with a stable rule set | The rule set itself becomes the thing you maintain and test |
In Inventor there is a practical catch worth knowing before you start: a file uses either model states or the older iPart and iAssembly mechanism, not both. Choosing late means converting a file that is already in production.
My working split would be this. Under roughly ten variants of one product, keep them in one file, because one place to fix a mistake is worth more than tidy separation. For a chain rollout where each unit has its own survey, its own permission and its own install date, one file per site from a shared template, with the template holding the brand rules. The moment the same decision has to be repeated on the fifteenth site, it belongs in the rule set, not in a file.
The revision test, before the client asks for one
A model is revision-ready when you have proved it, not when it looks right. The test takes a few minutes:
- Change the main driving dimension by plus and minus 300 mm and rebuild.
- Step the sheet thickness one gauge up and down.
- Check the flat patterns, not just the 3D: bend lines, flange lengths, corner reliefs.
- Open the drawings. Are the views still on the sheet, are dimensions still attached to live geometry, do balloons still point at parts that exist?
- Check the parts list and the cut list quantities changed the way you expected.
Anything that needs hand repair at this stage is a fault you have found on your own time instead of on the day the panels were due at the cutter.
What to do with this
- Split the job into what the client can change and what the workshop decided, before the first sketch.
- Put the setting-out in a skeleton, keep it dumb, and derive parts from it rather than from each other.
- Reference origin planes and your own sketches, never a face produced by a fillet, a chamfer or a mirror.
- Name parameters as the shop names dimensions, derive the rest, and keep derivation shallow.
- Decide once whether variants live in one file or one file per site, and write the rule down.
- Run the revision test on every model that has a second version coming, which is all of them.
A model built this way is not more elegant, it is cheaper on the second phone call, and that call is usually where the margin on a job is decided. If you need a model that holds up across a whole rollout, that is what structural design and CAD automation are for.
