Tip: Name Your Parent Model Differently

S1mon

I'm slowly figuring out that I typically only want to have configurations on individual parts, not a whole part studio - unless the config choices would actually affect all the parts in the part studio. So a natural step is to derive the part into a new part studio and do whatever additional modeling in that studio. By default, the derived part has the same name as the parent. This can lead to having multiple parts with the same name, which leads to a lot of possible confusion.

This is true regardless of the use of configurations. It's also the case if you choose to do detailed refinement in a separate child part studio derived from a master (parent) part studio which drives everything.

What I've done is add "[parent]" to the front of the name, so in my main part studio, I have "[parent] Motor Cover, M2". Then in the part studio where I derive and configure that part further, I have the name configured as "Motor Cover, M2" or "Motor Cover, Brake Side, M2". If you are deriving the part to just add more detail without configurations, just make sure to remove "[parent]" from the part name in the child part studio.

The nice thing about this is it helped immediately point out that I still had "[parent] Motor Cover, M2" in an assembly by mistake, when I do not want to do this any more.

Does anyone else have special techniques to help with this kind of thing?

eric_pesty

That seems like good practice for sure, it's easy at first to just change the name of the part studio but that doesn't really help when it comes to inserting something in an assembly!
We often use "master" in the name for parts that are going to be derived into something else as the most common scenario for us seems to be starting with an "infinitely configurable" part (using config variables) and deriving it to create a specific part or family of parts by narrowing the configuration options.
Another place where you can "catch" mistakes is with the "description" field of that parent making sure it's obvious when looking at a BOM that it's the master/parent instead of the actual refined/derive/child part. In our case the master will often say "infinitely configurable master" or something like this and won't have any vendor info etc so it stands out in a BOM if used by mistake.

I do find it can be hard to balance having multiple parts in a part studio with only some needing configuration vs breaking them out. We often do end up having to "live with" parts that have configuration inputs that don't actually change anything and it hasn't been too much of an issue. In these cases it helps to name the configuration in a way that it makes it obvious what it applies to as well as making sure the "default" make sense.

Another tip is to make sure you configure the "name" when using configurations otherwise it can be hard to tell what's what.

Lucas_Kuhns

Typically we just model all the parts in one part studio even if a few of them are "universal" and some are configured. I did do what you described once though when there were around 20 universal and only 3 that were configured. Those 3 I did in a 2nd part studio that was deriving some parts and a sketch from the first part studio.

Nick_Holzem

Separating the design into modular bits is helpful with configurations. In R&D this has been helpful when wanting to show more than one style of certain sections of a bike frame. At Trek, we have a highlight line that runs from the front of the bike and fades back. To be able to configure the surfacing during concept selection from a configuration toggle has been exciting.   My model starts with the frame geometry derived in from a Centerline document and simple tube members modeled in the first studio. Then I derive in the simple tubes to create the different blended sections in separate part studios, head tube, bottom bracket, and top tube & seat tube junctions, etc. These sections often require a list of surfacing features to complete. I may have multiple part studios for one similar section. This allows me combine all of the sections in the final part studio and use configurations to switch between the styles. Dividing the design into multiple part studios keeps feature count and rebuild time down per studio, while also organizing features by section. I can use versions with derived to further manage rebuilding. We can also configure the frame geometry across frame sizes.

billy2

Everything with part studios? No one is designing in an assembly? This is an important thread and following them is hard, it could be easier. If we only had a collaborative environment to share configuration management ideas. A system that allowed us to jointly define best practices. Wow, if only a system like this existed.

It'd be nice if someone created a document that could be used to control various project structural ideas. Every company is a little different and require different strategies but most don't stray from a common practice.

This forum has standardized on "public" as a way to share but this doesn't work because it's a copy. The individual who creates this document needs to "share" with individuals wishing to contribute. Then create a simple project and share it's structure. It'd be easier to follow threads that discuss project structure if the project actually existed in a simplified form.

I trained solidworks for many years and remember that in the advanced training course it devoted 2 paragraphs to incontext design. This is a subject that's been under-developed & un-defined in the CAD community for almost all time. I think simple examples of concepts could be the best approach when asking questions and exploring answers to configuration management. There's been no PDM system that's been able to handle configurations and now we have one.

If we only had a CAD system that allowed such a thing .

S1mon

Having spent far too many years with Pro/E and Solidworks, I'm a little shy of using assembly references. As far as I can tell "in context" is done much better in Onshape, but I would still only use it for things where there were multiple positions of a part and it would be awkward to develop the features any other way. It still adds complexity and risks of unintended consequences. The way that part studios work in Onshape was one of the first things that made me want to switch. They better support top down design the way that I've been doing it for years.

The main point of this tip was to avoid the situation where you are trying to reference a part for an assembly or release or whatever, and you accidentally grab the base/parent part instead of the real part.

The secondary point was that I've learned that I don't want things to be configured that don't need to be.

Nick_Holzem

It certainly is important to keep things organized. My complaint with in-context design, for our alloy frame designs, is the amount of time it takes to update. Things ramp up when you have many parts in an assembly individually modeled in-context. Sequence to update becomes important as well if they are spatially related, we dance around in circles with updating if we don't take note. Our company is somewhat new to Onshape now, going through our second year of projects. We're still developing our document structure and strategies. I agree, for us, once a concept is selected the configuration is removed and preserved in the history if we need to bring it back

billy2

@Nick_Holzem I think we're all still trying to figure it out. With OS it's all there, but how do you do it? I worked for Ellsworth and designed his line of aluminum mtn bikes. He had hydroformed shapes that were scanned and brought into CAD (solidworks). I created a common layout sketch with all the bike geometry then put it inside an assembly with attached hydro formed shapes. I then used the assembly to cope the hydro formed shapes. From this I created a 1:1 template drawing that they used to weld the frames together.  I had 5 sizes, the 1st was the hardest, the rest took minutes. There could have been a hundred sizes. 

I sent the manufacturer all the template drawings and also included all the coped geometry. He called later and thanked me for the geometry, who knew they had 5-axis? He said the bikes produced had the best welds he ever seen. There was no filling. He bought me lunch.

Do you know Tony?



@S1mon My 1st parametric modeler was pro/e. I went through a pro/e boot camp back in the early 1990's it was brutal. I agree assemblies probably aren't the solution. I went back to OS a few years ago trying to find a solution controlling 5 parts & an assembly. They drew a rectangle on a whiteboard with quadrants that were filled with configuration tasks and asked for a solution. Thinking it was a venn diagram I circled 2 of the quadrants and labeled them "released". They told me that could never happen. I decided to let Adrian figure it. It was a simple problem, 5 parts at different revisions and trying to control assemblies representing current builds.

If you figure it out, I liked to see your solution. Can you create a simple version of your project, make it public and share it with me? Someone needs to do this and you'd be great at it. You did fix surfaces you could fix this too.

matthew_stacy

billy2 said:

... If we only had a collaborative environment to share configuration management ideas. A system that allowed us to jointly define best practices. Wow, if only a system like this existed.

... This forum has standardized on "public" as a way to share but this doesn't work because it's a copy. The individual who creates this document needs to "share" with individuals wishing to contribute. Then create a simple project and share it's structure. It'd be easier to follow threads that discuss project structure if the project actually existed in a simplified form.

...If we only had a CAD system that allowed such a thing .

If only, indeed.  Well said Billy!  ROFLMAO

Nick_Holzem

@billy2 that is our best practice for alloy frames before (SW) and currently. Before the out-of-date context enhancement was released I completed another project that did alloy frames without the use of in-context editing. All raw tubes were derived into be mitered (Boolean) and post weld features added; exhaust holes, etc., this all in a single part studio. The first size raw tubes are constructed around a frame centerline sketch, so that when derived in they drop into place. The raw uncut tubes eventually move into their own documents, to potentially be used on other projects. For additional sizes the shared raw tubes are be derived in and repositioned then mitered according to the new frame size geometry. Finally the mitered parts are renamed and inserted to an assembly to create the final BOM. Its not a terrible method as the long as the part studio doesn't get too feature bloated. Around 20 second rebuild time I start to squirm, so I'm thinking I'll use this method for frames with less pieces. Or just use in-context editing.  I have been thinking, since this post, to try to daisy chain and version a few part studios to break up the part studio bloat; positioning and mitering, and then rederive in for the other machining steps and sketches for drawings. It also can help with organization. This has helped with carbon frames to section out the surface feature dense blends, keeping the feature count down, then combine the sections in altogether in another part studio. I can't say I know which Tony you might be referring to. 

billy2

@Nick_Holzem

My task was easy, I didn't have to worry about versions & I didn't design the hydro-formed shapes, I just created manufacturing documentation. It took only a few days to complete.

Assembly designing vs. chained derived parts, I use design in the assembly mostly because it's the 1st method I learned. It's backwards from how parametric modelers are written and makes it feel like something that was bolted on later (it was added later). Most my assemblies don't move so I don't worry about repositioning. I do assemble by coordinate a lot (stacking on top of the root origin) like your derived parts method. I've always thought of a derived part as an include statement in programming with it just adding to the long list of features. Possibly they're more like modules organizing large amounts of code.

Parts inside of parts has been around for a long time. The first instance was bringing a part into a mold base and subtracting it without the use of an assembly. The name of these feature were base & cavity. It's never moved beyond that in my mind.

Trying to handle a CAD structure that's good for design and manufacturing is still a conundrum for me. Perhaps using derived parts is the solution.  

When adding release controls to parts & configurations, I'm stumped. I think it's going to a combination of assemblies, part studios & parts. I don't know what it's going to be. I'm hoping someone figures it out and then tells me.

I been trying to figure out the best project structure for parametric modelers for a long time and I'm hoping that there can be a document created and shared to build various structures in such a way that's easy to follow and gleam insights on how to control designs, manufacturing, versions & configurations.

I've been here at OS since the beginning and have wanted to collaborate with the community since day one. I'm not sure it's ever going to happen. Making a document public isn't collaboration. Maybe we're just not a collaborative species.

Tony had a mountain bike company and lived down the street from me. I enjoyed working with him and the bike industry is exciting. I went to interbike several times with him.