SOLIDWORKS Design Approach · Part 16
Getting a model out of one system and into another
Every CAD system stores models in its own proprietary format, and no other system can read it. Everything about interoperability follows from that single fact.
The problem
Why exchange is unavoidable
Data exchange is routine in practice. A company that outsources manufacture must send models to subcontractors who may not run the same system. A supplier provides a component model built in something else. An analysis house, a mould maker, a machine shop and a customer each work in different software, and the design has to reach all of them.
The obstacle is structural rather than commercial. Each system, like any application, saves models in its own proprietary native format. Such a file is not transferable; other systems cannot open or read it. The common solution is to save in neutral formats that all systems can read — some of them formal standards, others de facto standards established by widespread adoption.
Export and import, precisely
Consider a file moving from system A to system B. The user exports from system A by saving it there in a neutral format. The user imports into system B by reading that neutral file, which system B converts into its own native format. Both halves involve a translator, and each system maintains two of them — one out, one in.
The landscape
Categories of format
The formats a modern system can write fall into five groups, and choosing correctly means knowing which group the recipient needs.
| Category | Examples | Use it when |
|---|---|---|
| Native | The system's own part, assembly and drawing formats, plus template and library-feature formats. | The recipient runs the same system. Full fidelity, full history, full parametrics. |
| Standard neutral | STEP; IGES; the older surface-exchange standards. | The recipient runs different software and needs usable geometry. STEP is more comprehensive and encompassing than IGES and is the default modern choice. |
| De facto neutral | ACIS; Parasolid text and binary; DXF. | The recipient's system is built on, or reads, that particular geometric kernel. Frequently cleaner than a standards translation because there is one implementation rather than an interpretation of a specification. |
| Manufacturing | The triangulated prototyping format described in Part 18. | Driving an additive machine. Faceted, unit-less and approximate — correct for its purpose and wrong for design exchange. |
| Presentation and web | Raster images; PDF and 3D PDF; web-viewable 3D formats; lightweight review files. | The recipient needs to see the model, not modify it. Covered under model communication below. |
Send STEP unless there is a specific reason not to. It carries solid bodies and assembly structure, it is a formal standard rather than a vendor artefact, and every serious system reads it. Reach for IGES only when the recipient explicitly asks for it or when the content is surfaces rather than solids; reach for a kernel format when you know which kernel the recipient runs.
The catch
Why translation loses data
Data exchange comes with potential problems, and the mechanism is worth understanding rather than merely being warned about. Translators for standards such as IGES and STEP are written by interpreting sets of published specifications. Interpretation opens the door to translation error. Converting from native to neutral, and again from neutral to native, therefore carries a genuine possibility of data loss in either direction.
Vendors run extensive test suites against their translators, and the results are good enough that exchange is routine. They are not good enough that it is automatic. Exchanged files should be inspected carefully, visual inspection included, to confirm that nothing was lost or corrupted.
What survives, and what does not
Generally survives
- Solid body geometry and topology
- Assembly structure and component placement, in the more capable formats
- Face and body naming, in some formats
- Units, where the format declares them
Generally does not
- Feature history and the modelling plan
- Sketches, relations and equations
- Configurations and design tables
- Design intent in any recoverable form
- Tolerances and annotations, unless a model-based-definition capable format is used deliberately
An imported model is a result without a recipe. There are no parameters to change, because the parameters never crossed. Editing it means direct face, body and surface operations rather than dimension edits — which is why round-tripping a model through a neutral format is a one-way trip in practice, and why the native file must remain the master.
Typical import defects and how to deal with them
- Gaps and missing faces Most common with surface-oriented formats. The body arrives as a set of surfaces that does not close, so it cannot be converted to a solid. Knit the surfaces, identify open edges, and patch with filled or planar surfaces as described in Part 12.
- Tolerance mismatch The exporting and importing systems disagree on what counts as coincident. Faces that touched now overlap or separate by a fraction of a micron. Import diagnostics and healing tools exist precisely for this.
- Degenerate or sliver faces Very small faces produced by translation of a trimmed surface. They cause downstream fillet and shell failures. Delete and patch them.
- Unit misinterpretation The model arrives at 25.4 times its intended size, or one twenty-fifth of it. Check overall dimensions immediately on import.
- Lost assembly structure A multi-component assembly arrives as a single multi-body part. Split into bodies and save out as components if the structure is needed.
The fastest single verification of an imported model is the one described in Part 17: assign the correct material and read the mass and centre of gravity against expectation. Unit errors, missing bodies and unclosed volumes all show up there immediately, and none of them are obvious on screen.
The other audience
Model communication beyond the engineering office
CAD models are shared by two distinct groups with entirely different needs. Technical people — CAD designers, design engineers, manufacturing engineers — work with the model itself. Professional people — marketing, sales, purchasing, management, customers — need something else entirely: screenshots for reports, images for proposals and presentations, attachments for email.
The asymmetry is not only in need but in capability. Technical people know how to use the CAD system; professional people generally do not, and have no reason to learn. Engineering drawings are the formal method of documenting and communicating a design among technical people, and viewing them properly requires the software. Everyone else needs a route that does not.
Lightweight review files
Self-contained files that open in a free viewer or a browser, allowing pan, zoom and rotate. The important capability is that a recipient can mark up a drawing or model and send it back — making review a loop rather than a broadcast.
Free viewers
Applications that open part and assembly files for viewing and manipulation without a modelling licence. Useful for shop floors, inspection and clients alike.
Documents and images
PDF for drawings, 3D PDF where an interactive model is wanted inside an ordinary document, and raster images for reports and slides.
Web formats
Browser-viewable 3D representations for online catalogues and configurators, generally requiring no installation on the viewer's part.
Vector illustration formats
Exported line art for manuals, brochures and technical illustration, where a raster screenshot would not scale or print acceptably.
Analysis handoff
Neutral solids for external analysis — mould flow, computational fluid dynamics, specialist structural work — as noted in Parts 17 and 20.
Choose the lightest format that answers the recipient's actual question. A customer approving an appearance needs an image. A reviewer checking clearance needs a lightweight viewable model. A machine shop needs a STEP file and a drawing. Sending native files to everyone is not generosity — it hands out your full design definition, including geometry you may not have intended to release.
Practice
A working protocol
- Step 1 Establish what the recipient's system reads, and ask rather than assume.
- Step 2 Choose the lightest format that satisfies the purpose.
- Step 3 Export, then re-import your own file into a clean document and inspect it before sending.
- Step 4 Check mass properties and overall dimensions against the native model.
- Step 5 Record what was sent, in what format, and on what date — exchange files are revisions and behave like them.
- Step 6 Keep the native file as the master. Never treat a returned neutral file as the new source of truth.
Key takeaways
- Native formats are unreadable across systems; neutral formats exist solely to solve that.
- Export writes a neutral file from the source system; import converts it into the destination system's native format. Each direction uses a separate translator.
- STEP is the sensible default — more comprehensive than IGES and read by every serious system.
- Translators interpret specifications, so translation can lose or corrupt data. Inspect every exchanged file, visually included.
- Geometry crosses; history, sketches, relations, equations and configurations do not. Imported models are dumb geometry.
- Check mass properties and overall size on every import — it catches unit errors and unclosed volumes instantly.
- Non-technical recipients need viewable and markable formats, not CAD files; send the least that answers the question and keep the native file as master.
Series
Continue the pathway
The SOLIDWORKS Design Approach series works through computer aided design as an engineering discipline, from first principles to manufacture.