Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
The Elegant Solution to Assembly Machining: "Made From" Flag on Derive
Alex_Theodossiou
Member Posts: 5 ✭
Assembly-level cuts are a common request for weldments, casting-to-machined-part workflows, and post-assembly machining. But FeatureScript and the parametric feature tree are fundamentally Part Studio constructs, and extending them to assemblies is a deep architectural challenge. There is a workaround by using Part Studios. Derive parts in, apply your machining, Composite the result. It's not a true assembly context, but you can get the geometry you want while building from the original parts.
Where this falls short is that the BOM doesn't know what went into it. The Derives that brought components into the machined Part Studio are invisible to BOMs and Where Used. Your weldment drawing can't list the input PNs. Where Used on a plate doesn't show the weldment that consumes it.
The Fix: Two Changes
1. Add a "Made From" checkbox on the Derive dialog.
When checked, the Derive is registered as a manufacturing input, not just a modeling reference. This makes it visible to Where Used.
2. Composite Parts with Made From Derives automatically get a BOM.
Today, Composite Parts don't have BOMs. They're treated as single parts with no record of their inputs. With this change, when a Composite contains Made From Derives, it automatically gets a BOM populated from those Derives, and that BOM can be placed on the drawing just like an assembly BOM. Composites without Made From Derives behave exactly as they do today. Nothing breaks for existing workflows.
(Or introduce an "assembly specific" composite part)
One flag. One new BOM behavior. No assembly features needed. No new architecture. Fully backward compatible. The data already exists in the feature tree, it just needs to be visible to the PLM layer.
Examples
Weldment / Post-Assembly Machining
- Part Studio A: 3 individual components, each released
- Part Studio B: Derive all three (Made From ✓), apply shared machining, Composite into one PN
- Drawing BOM automatically lists all input PNs with quantities
- Where Used on any input traces to the composite
Casting → Machined Part
- Part Studio A: casting, released as PN 100-001
- Part Studio B: Derive the casting (Made From ✓), machine it, Composite it, release as PN 100-001-M
- Drawing of 100-001-M automatically shows a BOM: PN 100-001, Qty 1
- Where Used on 100-001 returns 100-001-M
Same flag for both. If it's made from something, check Made From on the Derive and Composite the result. One input or five, doesn't matter.
Why This Matters
Many threads have asked for assembly features to solve these workflows. This achieves the same result without touching the assembly architecture. The Part Studio stays the modeling environment. The assembly stays for positioning and motion. The Derive just needs to stop being invisible to the PLM layer.
Comments
This is a good idea for anyone that applies transformations to parts - and wants to control the revisions (or history, provenance, or BOM) of the source / upstream inputs. I love it.
We make several parts that have Released parts in WIP - and this 'history' is hard to track / express in a way that makes sense. This would help.
@Derek_Van_Allen_BD ? @EvanReese ? @jelte_steur_info ?
What do you guys think - is this doable?
This could be useful, E.G. for molded carbon composite parts.
I currently usually design them in the final state as used in the product, and then derive them to say a moldmaking part studio, where all the additions get applied like extension surfaces, parting surface, cut lines, and the like, but that is certainly not optimal, because it sidetracks part of a part's history. It would make sense to include all that into a part's creation and approval timeline.
Hello. This is of great interest to us as we are thinking through some of the very same issues. You have probably noticed an increase in the feature enrichment of the edit-in-context workflows (and there are more to come), and this discussion is definitely an adjacent activity.
Starting state - Onshape has had the ability to optionally bring forward metadata (PN etc) when deriving. Yes one could use two derives to bring in some parts with metadata and some without. Yes there is a performance penalty dependant on the size of the Part Studio. Side note - as a general rule for performance, we should strive to keep our Part Studios as small as possible.
Going through the suggestions:
Add a made-from flag - This might be a good idea as it would allow (theoretically) a part generated from a derived Part Studio (PS) to have an indented BOM listing with the made-from Parts listed beneath.
I started typing a bunch of things that we are thinking about, but so that my ADD doesn't derail this thread, I will stop and ask -
(one can assume that there is a BOM option to show made-froms or not).
Not to derail this thread with my own ADD but coming at this from a different but related direction, my entire team's workflow has shifted towards derive based workflows due to the pure drafting horsepower you can get from defining core geometry in one place and have it repeated across many documents or projects with centralized source control.
As a consequence we've been entirely neglecting the BOM for our projects due to the inherent desync from those source documents. CADsharp has an Assembly Imposters feature / app that attempts to resolve the BOM discrepancies with a swap of the derived bodies (or other stand-ins) in the assembly for the true source bodies, but this metadata approach could better resolve duplicate parts being reported in the BOM.
The other way I've daydreamed about resolving BOM duplicates is an approach like the ones taken by EXALEAD OnePart where they do geometric analysis of the whole library and find shape matches of identical bodies across an entire CAD database and allow you to treat all of the duplicates as the same for BOM purposes and point you back to the original part if one can be determined. This approach could even handle duplicates resultant from frames or sheet metal workflows, or a dump of import geometry from other CAD if taken.
I built some infrastructure into Query Variable Plus that allows you to at least query for matching bodies in one part studio, and there are custom features that use the same core queries to sort parts into groups of like-geometry to build a custom not-BOM table to throw into drawings for reporting but because featurescript doesn't apply to assemblies you end up having to collate all the tables in a different program which breaks the parametric link.
Derek Van Allen | Engineering Consultant | MeddlerThis is a very important topic. I'm currently working with clients on developing workflows and custom FeatureScript to address it, but a 1st-party solution will always be better because there are so many more options for how to solve it when you can change the core of the software (not to mention the devs are geniuses, and there are more of them). We've been solving it essentially by using a custom feature that riffs on Cutlist, but is better for weldments with post-machining operations and possibility of sub-weldments that need to be tracked as their own "part" in the top-level weldment. The feature finds all identical parts in a part studio, compositing them and creating the table for the drawing. Later that same weldment can be added to an even bigger weldment and treated as a single line-item. The same challenges arise for any product that bonds things together, like composite layups, or thermoformed parts that have blocks epoxied on, or things that get crimped together, etc.
What we're doing is a big improvement over out-of-the box methods, but there are still big challenges and downsides with this approach though:
Pretty much all of this gets solved by the ability to make cuts on multiple parts in an assembly at once. Right now a context is limited to 1 part studio at a time, but for this to work using in-context, there needs to be a way to modify parts from multiple studios (or documents) at once. Alex's approach might be workable, but I'm possibly not thinking of edge cases. Maybe another approach would be even better. I am typically more happy with whatever implementation Onshape comes up with than if they'd just made what I imagined, so I'm glad to hear from @Philip_Thomas_PTC that it's being discussed! This need isn't going away.
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com
I'm very excited to see this move forward.
One ask: please make it so that derived parts have some more automatic rules around naming (and meta data). I've mentioned this before in the forum, but for top down design, I like to use "[parent]" in the name of parts which are in a upper level studio that will later be derived and the "[parent]" part removed. I also like "[ID]" for imports from industrial design CAD (e.g. not production surfaces, more for reference), and "[ref]" for parts that are not part of a BOM and just for reference. The goal is to avoid having multiple parts with the same name come up in search. It's a little too easy to do that now by mistake with typical Derive workflows.
Simon Gatrall | Product Development, Engineering, Design, Onshape | Ex- IDEO, PCH, Unagi, Carbon | LinkedIn
Love this proposal. We ran into the same problem: Cast → Machined → Anodized via Derive chains, and the BOM has no clue they're connected.
Our workaround until something native lands: a custom text property called "Made From" on the Part category, set as required in the release workflow. Value is just the source PN, e.g.
100-001-CorRound bar 6061-T6 Ø20mm × 100mmfor stock material. Shows up in BOM columns and drawing title blocks.Not a live link, but it enforces traceability where it counts — no one can release a machined part without declaring its input. Works well enough for shop floor docs and audits.
This property also works, if you don't use the derive feature. If they ever add this functionality to the derive dialog, it should be possible to override it. Because you could also model the final part and derive in the cast direction, then the automatic "Made From" doesn't make sense.
Curious if anyone else is doing something similar.
@Philip_Thomas_PTC thanks for engaging with this, really encouraging to hear it's adjacent to what you're already thinking about.
I'm in the middle of a SW migration and 300 of 1000 assemblies have post machining in them, so it messes up the imported versions.
To your questions:
Is this a standard BOM generation practice at your company (indented made-from)?
Yes. Mainly for our parts made from castings. In SolidWorks, the machined part is modeled as an assembly with the casting as a component and assembly features representing the machining ops. The machined part drawing has a BOM that lists the casting PN as an input. The same casting can be used to make different parts, and nice to have, the model BOM matches the production BOM.
But i also saw a lot of people requesting this for weldments so i included that example.
How would this be differentiated from a standard indented BOM?
I don't think it needs to look different. It is just allowing a composite to have children just as an assembly would.
On your edge case: what happens if the Part Studio produces multiple output parts?
This is partially the reason I chose composites to carry the where used. If additional single parts come out of the part studio, thats fine, a part shouldnt have BOM anyways. But if its a composite (even a composite of one part, like for a casting) then it would enable this feature and the composite can tell what parts were used as input into its features.
Actually, thinking through this more, I think the proposal simplifies down to a single UI change:
Add a "Link Source Parts" checkbox on the Composite Part dialog. No separate checkbox needed on Derive.
When checked, the Composite reads the Derives in its feature tree and exposes the source PNs as a BOM that can be placed on a drawing. Where Used on any source part traces forward to any Composite that has "Link Source Parts" checked. Composites without this checked behave exactly as they do today.
Booleans and splits: Should be treated as any other feature that results in parts, if you want it linked to the derive inputs (is there any other way to bring in parts) you need to use the Composite with sources linked.
Thanks everyone for the additional feedback, I think this is one of the biggest pain points when switching over to Onshape, but I'm encouraged by the response here.
Thank you all for your feedback - this is just the beginning.
In no particular order;
Did I miss any of the big ideas being discussed here?
@Philip_Thomas_PTC I'm not sure if a 'made from' flag by itself fully covers all of the potential BOM deduplication cases a user is likely to encounter in drawing their part studios (like frames or sheet metal) but like all things that hit featurescript, once the circuitry for something like that is in place the rogues gallery gets some new tools to commit villainy. Looking forward to seeing what comes of this discussion.
Derek Van Allen | Engineering Consultant | Meddler