Structural Analysis
Structural Model to CAD Workflow: Data, Geometry and Drawing Coordination
How to move structural models into CAD without losing identity: which data stays tabular, which geometry may convert, and how drawings stay coordinated when analysis revises.
A structural model holds more than lines. It holds coordinates, incidences, properties, supports, loads and results. CAD drawings need only some of that, in a different language: views, marks, notes and schedules. The workflow that respects both is a mapping problem. If you dump everything into a DWG, you get clutter. If you type everything by hand, you get drift. If you convert lines and then let CAD own depths, you get a second structure.
This article is the coordination layer above STAAD.Pro to AutoCAD conversion and model to drawing production. It applies when the model is STAAD.Pro, when PEB geometry also lives in MBS, and when the drawing environment is AutoCAD or a BIM tool that still issues 2D PDFs. The PEB-specific people process is in design coordination.
Automation belongs on the geometry copy and on repetitive sheet setup, not on inventing sections. StruTools Staad2CAD is a geometry carrier in that sense. Identity — marks, sizes, reaction tables — should travel as controlled data, sometimes in Excel, sometimes as a plotted schedule, never as an anonymous CAD colour.
Data, geometry, drawings — three channels
| Channel | Examples | Master at issue |
|---|---|---|
| Data (tabular) | Marks, sizes, reactions, combination names | Analysis extract + controlled table |
| Geometry | Grids, centrelines, work-points | Frozen analysis coordinates |
| Drawings | Views, notes, clouds, title blocks | Issued PDF / sheet set |
| Results diagrams | Moments, deflections | Calculation sheets, not shop drawings |
| Cladding / architecture | Openings, grids, underlays | Named architectural revision |
Stop treating the model as a picture to be traced
Tracing a screenshot of STAAD is the worst of both worlds: no intelligence, plenty of error. Conversion of coordinates is legitimate. Interpretation of what those coordinates mean — a rafter versus a dummy load line — is a human filter before conversion. Data such as Fy or a combination name should never become a CAD entity that someone might snap to.
Think in channels. Geometry may xref. Data may sit in a schedule. Drawings reference both and add notes. When analysis revises, you replace the channel that changed. You do not reconstruct the whole set from memory.
Geometry mapping: axes, units, identity
Map global axes to CAD UCS once. Map units once. Map member numbers to marks once, then maintain the map. Nodes and coordinates are the raw geometry. Without identity, reconversion produces unlabelled lines and the annotation layer cannot find its host.
Replaceable geometry
Store converted centrelines in an xref or a dedicated layer set that can be swapped. Annotation lives outside that container. This is the same idea as in the model-to-drawing sheet strategy, stated here as a data rule.
Non-converted geometry
Haunch outlines, base plates, purlin ticks and architectural openings may be drawn in CAD from data, not from a stick model that never contained them. That is allowed if the driving dimensions still come from the freeze.
Data that should remain tabular
Some information gets worse when it becomes a drawing object. Reaction components, combination lists, long member schedules and comment logs belong in tables with revision headers. CAD can plot those tables. CAD should not be the database.
Keep it in a table unless you have a good reason
| Information | Why tabular wins | CAD role |
|---|---|---|
| Support reactions | Axes, cases, envelopes need sentences | Reference the table on the base plan |
| Member size list | One list, many views | Schedule on the drawing, sourced from the list |
| Mark map (node → mark) | Audit trail | Optional key plan, not the only copy |
| Load combination names | Must match the design basis | Notes cite names, do not redraw factors |
| Comment log | Status and owners | Clouds point to log IDs |
Annotation and sheet coordination when the model moves
Revision of analysis geometry should break CAD notes that attached to moved members. That pain is cheaper than silent wrong dimensions. Use associative ties lightly; prefer notes that cite marks (“RF3 haunch length as analysis Rev C”) so a human can update from the table.
- Title blocks cite analysis file, CAD file and architectural underlay revisions.
- A sheet index states which views are model-derived versus drafted.
- If PEB purlins come from another model, the roof plan says so.
- Reconversion has a written trigger: which changes require it.
- Superseded xrefs are not left with the same filename as the current one.
- PDF issue bundles the tables that the sheets reference.
Handoffs: analysis, CAD, detailing, civil
Civil wants reactions and anchors. Detailers want sizes and hold areas. CAD technicians want a replaceable skeleton. Analysis engineers want CAD not to invent steel. Write those handoffs as artefacts, not as chat. This is the STAAD/CAD slice of the same idea as PEB coordination.
When tools help, they help a named handoff: Staad2CAD for geometry into AutoCAD, a reaction extractor for tables, LISP for sheet setup. If a tool’s output cannot be revisioned, it is a sketch generator, not a workflow step.
Standing up a model-to-CAD data path on a project
Do this at kickoff so reconversion is boring instead of heroic.
- Name masters: analysis file for geometry and sizes, sheet set for issued views, workbook for reactions if used.
- Define axis and unit mapping; write it on the CAD template and the analysis notes.
- Create the mark map structure before members proliferate.
- Decide what will be converted versus drafted from data.
- Set xref or layer containers for replaceable geometry.
- Run a one-bay pilot: convert, schedule, dimension, reconvert, see what breaks.
- Write the reconversion trigger list (grids, eave, brace bays, member layout).
- Issue the first coordinated bundle: PDF + tables + analysis revision name.
Engineering tips
- If two analysis programs exist, only one feeds CAD geometry.
- Do not bind xrefs “to be safe” if you plan to reconvert; you will have nowhere to put the new lines.
- Store converter settings next to the analysis file.
- A mark that exists in STAAD, the schedule and CAD is a coordinated mark; two out of three is a defect.
- When architecture revises grids, treat it as a geometry-channel event, not a CAD stretch.
- Keep results graphics out of the contractual sheet set.
Coordination mistakes that look like CAD skill
Making CAD the size master because “the model is ugly”
Ugliness is a display problem. Sizes are a design problem. Fix properties, then convert.
Embedding reaction numbers as plain CAD text on the plan
The next analysis revision will not update them. Point to a revised table instead, or use a linked, controlled schedule.
Reconverting into the sheet file and exploding
You destroy replaceability. Convert into the container, then xref.
Different mark systems in STAAD, MBS and CAD with no map
Civil, shop and analysis cannot attend the same meeting. Map or unify.
Calling the DWG “coordinated” because layers are pretty
Coordination is matching revisioned channels, not colour.
Model–CAD coordination checklist
Run at each analysis-driven drawing issue.
- Masters named for geometry, sizes, drawings and reactions.
- Axis and unit mapping documented.
- Mark map current.
- Replaceable geometry container in use.
- Converted content matches the frozen analysis revision.
- Tabular data issued with the same revision letter.
- Sheets cite analysis and architecture revisions.
- No results diagrams on contractual views.
- Reconversion trigger list still accurate.
- Pilot dimensions still hold after the latest convert.
- Detailing and civil received the bundle, not only a DWG.
- Superseded geometry files cannot be mistaken for current.
Frequently asked questions
Should every analysis revision trigger a CAD reconvert?
No. Reconvert when geometry or layout that drawings show has changed. Load-only or parameter-only changes may need table and note updates. Write the trigger list so the team does not argue each time.
Is BIM a way around this workflow?
BIM still has channels: analysis, fabrication model, issued 2D. If the fabrication model becomes a silent redesign, you have the same problem with nicer graphics. Keep an issued view and a size list that analysis recognises.
Where do PEB secondaries fit if STAAD only has frames?
They are another geometry/data source. The roof plan should state that purlins come from the PEB layout, while frame lines come from STAAD (or MBS). Eave and ridge must still match. See purlins and girts.
Can Staad2CAD own the whole workflow?
No. Staad2CAD can own the geometry-copy step after the model is checked. Data tables, sheet coordination, marks and review remain the team’s. That is the point of splitting channels.
Coordinate channels, not screenshots
Moving a structural model into CAD is not tracing. It is keeping geometry, tabular data and issued drawings in named channels that can update without inventing a second building. Convert centrelines, keep reactions and sizes as data, cite revisions on the sheets, and reconvert when the trigger list says so.
Use this with STAAD to AutoCAD, model to drawing and PEB design coordination. The workflow does not design members or approve combinations. Those remain with the responsible engineer and the project design basis. StruTools documents the path; it does not replace professional review.
This article provides general educational information. Project-specific structural design, calculations and drawings should be reviewed by appropriately qualified engineering professionals and checked against applicable project requirements and standards. StruTools does not replace engineering judgement or professional design review.