How Engineering Automation Can Process MBS Output Files

Copying MBS reactions by hand is slow and it is how digits swap. Automation is justified. Automation is not justified when a script reads every file in a working directory, including trial runs, and silently publishes a table. PEB teams need a narrower idea of automation: take an issued report, extract known fields, write a reviewable table, and stop. A person still confirms units, grid mapping, and load cases before foundations or CAD may use the result.

Because report layouts change between software versions, this guide does not invent a proprietary file specification. It describes a processing pattern: freeze the input, parse only the report your office standard names, map fields into a table, and keep an audit line that says which file produced which row. StruTools MBS Reactions is built around that reaction-table problem. Drawing-package repetition after the table exists is a different job, closer to the StruTools MBS Approval Package.

If you do not yet know which output is worth parsing, read Understanding MBS Output Files for PEB Engineering first. If you cannot yet read a reaction by hand, read How to Read and Use MBS Column Reactions. Automation that starts before those two skills exist will only produce wrong tables faster. The quality gate remains MBS Output Quality Checks Before Using Results in Design Workflows, and it still needs a named reviewer.

Automate the extract, not the engineering decision

A script may copy a number from a report into a cell. It may not decide that the run was complete, that wind was applied, or that a column is an endwall post.

• Input is a named issued file, not 'whatever is newest in the folder'.
• Output is a table plus an audit field (source file, run date, parser version).
• Unparsed or unrecognized rows become exceptions, not guessed values.
• A person signs that the table may be used. The script does not.

Pick one issued report family to parse

Member reports, geometry summaries, and reaction reports are different jobs. A first automation project should parse reactions only, because that is the handoff everyone waits on.

Agree on the report your office exports for reactions. Document the version of MBS that produced it. When the vendor changes column order, you will update one parser, not five ad-hoc spreadsheets. Do not scrape screenshots or PDF pages until a text or tabular export exists; image parsing is a last resort and a quality problem.

Geometry can be automated later as a check against CAD grids. Member-size extraction is useful but easier to get wrong because typical versus non-typical frames need human grouping.

A practical processing pipeline

Keep the pipeline short enough that a reviewer can still explain it in a meeting.

1. Receive the issued reaction report in a project folder that only holds issued files.
2. Read header information: project, units if present, date, and any load-case list.
3. Read each support row: ID, case, components.
4. Write a normalized table with stable column names your office defined.
5. Write exceptions for missing IDs, missing units, or cases not on the allowed list.
6. Stop for review. Only then copy the table toward CAD or foundations.

Where spreadsheets help and where they hurt

Excel is often the review surface even when a dedicated tool does the parse. That is fine if the workbook is a viewer, not a second undocumented parser.

If your office already lives in Excel for foundation handoff, pair the extract with StruTools Excel Programs or a controlled workbook template, but keep one official parse path. How to Organize MBS Reaction Data into a Usable Table defines the columns that template should show.

• Good: a workbook that formats the normalized table, filters load cases, and shows audit fields.
• Bad: a workbook with hidden macros that re-parse raw text differently from the official tool.
• Good: a checked conversion sheet with visible factors.
• Bad: cells that still contain hand-typed reactions mixed with imported ones and no flag.

Do not reverse-engineer undocumented binary formats

Tempting shortcuts—opening program data files with a hex editor, guessing record lengths—break on the next vendor patch and cannot be defended in a review.

Use exported reports the vendor documents. If an export is missing, ask for it or print to a text format the office can archive. Automation that depends on an unofficial layout becomes tribal knowledge, and tribal knowledge disappears when the one person who wrote the script leaves.

The same rule applies to CAD: once reactions are a table, drawing composition can be automated separately. Do not teach a script to draw footings from raw solver files.

Testing an MBS parser like an engineering tool

If you would not accept an unchecked connection spreadsheet, do not accept an unchecked parser.

• Keep a golden issued report and a golden table. Re-run the parser after every change.
• Include an endwall column, a crane case, and an uplift case in the golden set.
• Fail the test if row counts change or if a support ID disappears.
• Record parser version next to the MBS version on the calculation cover.

Standing up reaction automation on one project

Pilot on a single issued run before you touch the office standard.

1. Choose one completed project with a clean issued reaction report.
2. Build the normalized table by hand once so you know the target columns.
3. Parse that same report into the same columns and diff the two tables.
4. Add exception handling for missing units and unknown load-case names.
5. Have the project engineer review the automated table against the hand table.
6. Only then allow the parser on a live job, still with a human sign-off.

Engineering tips

• Parse issued files only. Ignore working directories.
• Store parser version and MBS version together.
• Prefer official tools such as StruTools MBS Reactions over a one-off script nobody owns.
• Keep the allowed load-case list in a project file, not hard-coded for last year's code edition.
• When a vendor update changes the report, fail loudly. Do not 'make it fit'.

Common mistakes

Watching a folder and trusting every new file

Trial runs, duplicate exports, and incomplete solves all look like files. Issuing is a human event.

Parsing PDFs because 'that is what we print'

Print is for people. Automation needs a tabular or text export. If you only have a PDF, fix the export path.

Letting the script drop rows it does not understand

Missing endwall posts are not a formatting issue. They are missing engineering data. Raise an exception.

MBS automation go-live checklist

If the parser cannot pass this list, keep extracting by controlled copy.

• Issued-file folder is separate from trial output.
• Target table columns are written down (see the reaction-table article).
• Golden report and golden table exist.
• Parser writes source-file and version audit fields.
• Unrecognized rows become exceptions.
• Unit conversion, if any, is visible.
• A named engineer still signs the table.
• Vendor version changes are a reason to re-test, not a surprise.

Frequently asked questions

Should we write our own parser or use an existing tool?

Use a maintained tool when it matches the job, such as StruTools MBS Reactions for reaction tables. Write a parser only if you can test it and own it after vendor updates.

Can automation skip the quality-check article?

No. MBS Output Quality Checks Before Using Results in Design Workflows is still the gate. Automation happens after a run is fit to issue, or it includes checks that fail the job.

Is Excel VBA a good parser?

It can be, if it is version-controlled, tested, and not hidden. A dedicated tool plus a dumb workbook for review is usually easier to audit.

When should drawing automation start?

After the reaction and geometry tables are reviewed. Then look at From MBS Output Files to PEB Approval Drawings and the StruTools MBS Approval Package.

Speed is only useful if the table is the issued table

Engineering automation earns its keep when it removes retyping and leaves a trail. It does damage when it publishes whichever file appeared last. Freeze the input, parse one report family, write exceptions, and keep a human on the sign-off.

Once the extract is trustworthy, shape it with How to Organize MBS Reaction Data into a Usable Table and only then feed CAD or the StruTools MBS Approval Package.