The Elegant Solution to Assembly Machining: "Made From" Flag on Derive

Alex_Theodossiou

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

1. Part Studio A: 3 individual components, each released
2. Part Studio B: Derive all three (Made From ✓), apply shared machining, Composite into one PN
3. Drawing BOM automatically lists all input PNs with quantities
4. Where Used on any input traces to the composite

Casting → Machined Part

1. Part Studio A: casting, released as PN 100-001
2. Part Studio B: Derive the casting (Made From ✓), machine it, Composite it, release as PN 100-001-M
3. Drawing of 100-001-M automatically shows a BOM: PN 100-001, Qty 1
4. 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.

romeograham

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?

martin_kopplow

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.

Philip_Thomas_PTC

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.

• What would happen if multiple Parts were generated by the PS - would each part have the same indented made-from list?
• This does work for composite parts as the input list is a 1-1 mapping.
• This also works for weldments (a single booleaned part) - the boolean feature would theoretically have a made-from option that likewise would generate an indented BOM.
• What about split - would that need a made-from flag?

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 -

• Is this a standard BOM generation practice at your company (indented made-from)?
• How would this be differentiated from a standard indented BOM (that shows sub assembly components)?

(one can assume that there is a BOM option to show made-froms or not).

Derek_Van_Allen_BD

https://forum.onshape.com/discussion/comment/127802#Comment_127802

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.

EvanReese

This 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:

1. It turns part studios into assemblies - if the weldment is really big, it's tough. You can mitigate it by using a top-down approach across multiple part studios and keeping things separate until the very end where you bring it all back together, but it's not ideal. It's also a tough sell to people who finally talked their whole team into NOT modeling everything in one part studio and NOT modeling duplicate parts in the same studio to be like, "well it's actually okay, but only for this".
2. It doesn't handle standard content, which often needs to become part of a weldment. Workarounds include duplicating the standard content to the part studio via in-context "copy in place", or just modeling/downloading the hardware from elsewhere.
3. Release workflow is still not as streamlined as I'd like - you can release the drawing and weldment composite, but need to workaround manually to get the weldment component parts in the release.
4. The table isn't a real BoM - This matters most on the PDM side and syncing it with things like Arena. So far it seems possible via API, but again, a 1st party solution is preferable.
5. It takes a number of steps and knowhow to set up right - To really get the data looking right for drawings, you need to use configs to show pre and post machining states, and possibly weldment steps. For the pre-machined weldment, you want to track the part numbers and releases of the component parts, but for the post machined one you just want to treat it as 1 part and not release the machined state of the constituent parts. Not Revision Managed can be configured for this, but it's pretty manual. Oh and don't forget to set the config to "Exclude from properties".
6. It's tricky to re-use subweldments - In the scenario where a certain thing is welded, and warehoused for later use in multiple products, this workflow breaks down (at least we've not yet applied the effort to solve it). Those need to be tracked to the source released composite weldment, but deriving them in makes that tough, for all the reasons @Alex_Theodossiou mentions.

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.

S1mon

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.