As robots grow, teams split work across many Part Studios and pull geometry between them with Derived features and in-context edits. Done carelessly, this is where models silently go wrong.
Symptom: an in-context part stops updating when the master changes. In-context geometry is captured against a specific assembly context. If you edit the source after that context was created, the dependent part keeps using the old snapshot. Fix: update the context — right-click the part in the Assembly and choose Update context, or in the Part Studio open the three-dot menu on the Assembly contexts list and choose Update context — or, better, migrate to a derive-from-version workflow so the dependency is explicit.
Symptom: a Derived part shows an out-of-date or broken reference after the source edits. Derive grabs specific entities; rename or delete the source face/sketch and the derive loses them. Fix: re-edit the Derived feature and re-select, or derive whole parts/sketches (more stable than deriving individual faces).
The durable workflow (used by advanced teams): derive from a version, not live. In Onshape you can create a Version of the document, then point a Derive feature at that version — even within the same document. The downstream Part Studio only changes when you deliberately bump it to a new version. This gives you reproducibility (a teammate opening the file sees exactly what you saw) and it can improve performance, because Onshape treats a version as immutable/static instead of recomputing the live source.
Pattern for a robot: keep one Master Sketch/Layout Part Studio that holds critical dimensions. Version it. Each subsystem Part Studio derives the relevant layout sketch from that version. When the layout changes, you make a new version and update each subsystem's derive on purpose — no surprise breakage mid-build.
Debugging checklist when a reference breaks: (1) Identify whether it is in-context or derived (the icon differs). (2) Check whether the source was renamed/deleted. (3) Prefer re-selecting whole entities over faces. (4) If it is live-derived and keeps breaking, convert to derive-from-version. (5) Communicate to the team that the layout version bumped, so no one is editing an old context.
The root cause is almost always an undisciplined dependency graph; the cure is making every cross-Part-Studio link explicit and version-locked.
the part worth keeping
Key takeaways
- In-context geometry is a snapshot; it goes stale unless you update the context or move to derive-from-version
- Derive whole parts/sketches rather than individual faces so renames don't orphan references
- Version your master layout and derive subsystems from that version for reproducibility and steadier performance
CAD & DesignCommon Mistakes & Troubleshootinglesson 2 of 5
Keep going
Take the quiz+10 XP with an accountMore in Common Mistakes & Troubleshooting
where this came from
Sources and corrections
This lesson is AI-assisted: drafted from primary sources, then reviewed and edited by hand. Errors still get through. When one is reported we fix it and write down what changed, in public, in the corrections log.
sources and further reading
- frcdesign.orgFRCDesign.org Learning Course — Top Down Design (layout-driven)
- cad.onshape.comOnshape Help — Performance Considerations
- forum.onshape.comOnshape Forum — strategies to address slow regeneration
clipped to this lesson
Articles that go further on this
The lesson gets you through the topic. These go wider on it, and they read in one sitting.
- 13 min readWPILib Won't Deploy: Every Cause and How to Fix ItYour WPILib deploy is failing? Work the decision tree: wrong folder in VS Code, team number, roboRIO image, JDK version, macOS network privacy. Fixes for each./blogread it
- 8 min readFRC Onshape Tutorial: How to CAD Your First Robot PartA beginner Onshape tutorial for FRC: sign up free, learn Part Studios and Assemblies, sketch and extrude your first part, and pull in COTS parts./blogread it
answer sheet
Lesson quiz
All 3 right completes the lesson. Miss one and only that question comes back, anything you already answered correctly stays banked.
0 of 3 answered
01In Onshape, when the source assembly used to create an in-context feature changes, what happens to that in-context reference?
02To keep a Derived feature from breaking when the upstream model is edited, what should you derive from?
03To make cross-Part-Studio references survive a source edit, what should you prefer when creating a Derive feature?
Answer every question to submit.
All 31 lessons in CAD & Designopenclose
01 / prerequisites
02 / getting-started-cad-and-the-design-process
03 / onshape-fundamentals
04 / vendor-libraries-mkcad-featurescripts
05 / manufacturability-drawings-bom-design-reviews
06 / worked-examples-mini-projects
07 / common-mistakes-troubleshooting
- Not read yet:Mate & Assembly Failures: Why Parts Float, Spin, or Won't Move
- Not read yet:Broken In-Context & Derived References
- Not read yet:Slow Regeneration in Big Drivebase Assemblies
- Not read yet:Manufacturability Mistakes That Become Scrap
- Not read yet:Version Control & Team Collaboration Disasters
08 / advanced-techniques-case-studies
- Not read yet:Configurations vs. Parametric Variables: Designing One Model, Many Robots
- Not read yet:FeatureScript Automation for FRC
- Not read yet:Browser-Based FEA: Weight-Optimizing Real Structures
- Not read yet:Swerve System Geometry & Motion Math
- Not read yet:Case Study: FRC 6328's Modular Gusset-and-Tube Methodology