Broken In-Context & Derived References

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.

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

This lesson was adapted from learnfrc.com.