When a board revision arrives as a STEP file, the mechanical model doesn’t degrade. It breaks completely. Mates fail. References go dangling. Sketches lose their parents. Parametric relationships that drove your enclosure geometry are gone on import.
This happens every time, on every revision, because of what a STEP file is. STEP carries shape. It does not carry how that shape was constructed — no feature history, no sketch constraints, no parametric dimensions, no material assignments. It is a static geometric snapshot of a model that was built with living, editable logic. The moment it crosses the boundary, that logic is gone.
The mechanical engineer is not doing anything wrong. The enclosure model is not badly built. The problem is structural: ECAD and MCAD tools were never designed to share design intent across their boundary. ECAD to MCAD integration, at every tool in the stack, moves geometry. It does not move intent. The structured engineering data that made the original model parametric — the feature relationships, the constraint logic, the dimension hierarchy — does not cross that boundary. They share geometry. Intent loss at that handoff is the root cause. Everything downstream — the failed mates, the stale keep-outs, the misaligned cutouts — is a symptom.
A mechanical engineer building an enclosure around a PCB needs more than accurate geometry. They need parametric geometry — a model whose dimensions are editable, whose constraints are enforceable, and whose relationships survive a revision.
STEP delivers none of that. Consider what gets discarded on export:
Matt Berggren, who built EDA tools at Altium and Autodesk before founding Neurocad, is direct about it: “A STEP file breaks 100% of the joints in my design every time I import it. It’s a nice thing to have as an interim exchange format, but it’s not how it’s going to be in the final mechanical model.”
The joints he’s describing are parametric relationships. Every one of them requires manual reconstruction after import. That is the tax.
The reconciliation tax in PCB enclosure design: what every board revision costs mechanical
The cycle runs like this: a board revision exports from ECAD as a new STEP file. The mechanical engineer imports it. Mates fail. Keep-out zones are wrong. The connector cutout is misaligned. The standoffs don’t reach the mounting holes. The engineer rebuilds the constraints, re-checks interference, updates the enclosure. The board changes again the following week.
Each pass looks like a few hours. Across a program with six board revisions, two mechanical engineers, and tight packaging constraints, it becomes weeks of engineering time spent on reconstruction rather than design. That time doesn’t go into thermal analysis, tolerance stack-ups, or DFM review. It goes into rebuilding what should never have been lost.
For an engineering manager, the reconciliation tax compounds in a second way: schedule risk. Every rebuild cycle is a dependency. The enclosure cannot be finalized until the board stabilizes, but every board revision restarts the enclosure work. The handoff format is the bottleneck, and it’s invisible until someone asks why mechanical is always waiting on electrical.
The mechanical assembly should survive a board revision. Constraints intact. Parametric relationships preserved. No rebuild cycle.
That requires the electrical-to-mechanical handoff to carry design intent, not just geometry. In SolidWorks, the correct output is a feature tree — every element its own editable feature: the board body, the component envelopes, the material assignments. In Fusion 360, it’s a timeline with the same properties. Not a static solid with a color. A model where changing the material changes the physics in simulation. A model where updating a dimension cascades through the assembly correctly.
When the board changes, the model updates. It does not reset.
This is what zero re-entry at the ECAD-to-MCAD boundary means in practice. The transition between electrical and mechanical design doesn’t require starting over. The enclosure model the mechanical engineer built is still valid. The revision propagates. The work continues.
Neurocad performs native synthesis — generating parametric, design-ready 3D models directly inside the target MCAD environment. The output is not a translated STEP file. It is a model built for SolidWorks or Fusion 360 with a complete feature history, editable parameters, and constraints that hold through revisions. When the board changes, the assembly survives the update. The pcb to enclosure workflow becomes a continuous design process rather than a series of reconstruction cycles. Design intent extraction happens at the source — from the board file, the schematic, and the component documentation — and what crosses the ECAD-MCAD boundary is structured engineering data the mechanical environment can act on directly.
The engineer stays in control throughout. Before any asset enters the design environment, Neurocad surfaces what it extracted and inferred from the source data. The engineer confirms it. The output is a decision the engineer made, not something handed to them without review. Human-in-control isn’t a guardrail — it’s the design philosophy.
Don't take our word for it. Run one of your own datasheets through Neurocad™ and review the intent model yourself. 14-day free trial → https://neurocad.com
Neurocad™ is built by engineers who spent their careers inside the workflows this platform is designed to fix. Previously at Accel EDA, Altium, Autodesk, Meta, Microsoft, HP, and Siemens, building tools used by millions of designers, engineers, and consumers worldwide.
Neurocad™ is a vendor-agnostic intent compiler for hardware design workflows that converts engineering content (PDFs, specifications, images) and user intent into tool-native, parametric, design-ready assets in EDA and mechanical CAD systems such as Altium and SolidWorks, with human-in-control checkpoints.