Broken In-Context & Derived References
Understand why in-context edits and derived parts go stale, and adopt the version-locked derive workflow that keeps a multi-Part-Studio robot coherent.
Sign in to track progress, earn XP, and save lessons.
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 in-context feature) 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.
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
Go deeper
Lesson quiz
RequiredAnswer all 3 questions correctly to complete this lesson.
1.In Onshape, when the source assembly used to create an in-context feature changes, what happens to that in-context reference?
2.To keep a Derived feature from breaking when the upstream model is edited, what should you derive from?
3.Which workflow best reduces the risk of broken in-context references in an FRC Onshape design?
Answer every question to submit.