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.
Options
Best practices for in-context editing?
andrew_jorgensen202
Member Posts: 12 ✭✭
Working on the following:
https://cad.onshape.com/documents/3091571674f76746f9d3e18e/w/7aab4f6a71fd7f65dc55d9f5/e/d793696e944278174df72160
My workflow for this project was as follows:
1. Place all known sub-assemblies, and pre-existing parts (e.g. Servos, Switches, Battery Pack, etc) into an assembly.
2. Orient above parts to desired position because of known intent.
3. Use generate a new part studio in-context of the above main assembly.
4. Utilize above created part studio as a multi-part studio to make the laser-cut frame, brackets, and other remaining parts etc...
5. Insert new parts from single multipart studio into main assembly.
While this workflow worked really well in many regards... I don't think I am fully understanding an appropriate workflow with in-context edits when trying to utilize a single parent multi-part part studio.
The major issue being how to insert parts into the assembly after creation. Sometimes I didn't need to create multiple contexts to build the next part, but the dialogue for "insert part and goto assembly" dissapears. Then I had to manually position with mate connectors etc in the assembly. Is it possible to get back to that dialogue somehow? And out of my own confusion I would break my own workflow and create a random single part studio to avoid having to manually insert and mate in the assembly.
I'm sure my headaches are coming from some bad practices i'm doing that I haven't identified yet.
In context editing is amazing... But my small brain is still trying to wrap my head around using it with a multi-part studio for the best of both worlds. Especially in my case where many of the frame pieces utilized a feature script for auto generating mating tabs for laser-cut parts and would not work unless both parts were in the same part studio.
https://cad.onshape.com/documents/3091571674f76746f9d3e18e/w/7aab4f6a71fd7f65dc55d9f5/e/d793696e944278174df72160
My workflow for this project was as follows:
1. Place all known sub-assemblies, and pre-existing parts (e.g. Servos, Switches, Battery Pack, etc) into an assembly.
2. Orient above parts to desired position because of known intent.
3. Use generate a new part studio in-context of the above main assembly.
4. Utilize above created part studio as a multi-part studio to make the laser-cut frame, brackets, and other remaining parts etc...
5. Insert new parts from single multipart studio into main assembly.
While this workflow worked really well in many regards... I don't think I am fully understanding an appropriate workflow with in-context edits when trying to utilize a single parent multi-part part studio.
The major issue being how to insert parts into the assembly after creation. Sometimes I didn't need to create multiple contexts to build the next part, but the dialogue for "insert part and goto assembly" dissapears. Then I had to manually position with mate connectors etc in the assembly. Is it possible to get back to that dialogue somehow? And out of my own confusion I would break my own workflow and create a random single part studio to avoid having to manually insert and mate in the assembly.
I'm sure my headaches are coming from some bad practices i'm doing that I haven't identified yet.
In context editing is amazing... But my small brain is still trying to wrap my head around using it with a multi-part studio for the best of both worlds. Especially in my case where many of the frame pieces utilized a feature script for auto generating mating tabs for laser-cut parts and would not work unless both parts were in the same part studio.
0
Best Answer
-
Options
billy2
Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,014 PRO
As projects grow in size, I think In-context becomes more of a requirement. In the beginning, I think a multi-part partstudio is the best way to handle relations between parts. What's exciting about partstudios is the concept of a 'layout' which can be one sketch at the top of your feature tree controlling your design. With this you can design for the next guy and give him an entry path into your design. Have you ever worked on a project that's a mess? Most large project are poorly defined and rarely do they have a project structure to follow.
As your project grows and more is added, it doesn't make sense to keep everything inside one part studio. Think of a rack of equipment and each component in the rack is a partstudio while the rack of equipment is an assembly of partstudios.
The problem comes at the rack level. Let's say you might need components in the rack to talk to each other which would require an in-context reference. Think of 'in-context' as designing in an assembly. For a smaller project you shouldn't need this. As your project grows, you'll need it. Please don't force it into something where it's not needed.
On a lighter note, one trick that I'm doing a lot these days (that's not documented, at least I haven't seen it). While in an assembly, double click on the part from the feature manager. This switches to the partstudio (you can now hide/show other parts in partstudio, or just isolate the single part) and Onshape ghosts the assembly so you can design your part while seeing the assembly. This is brilliant. You don't have to create an in-context, just double click your part in the assembly feature tree. I'm careful not to pick anything from the assembly while working in the partstudio which would create an in-context reference. To me this is what I want onshape to do, I want to see the part in-context of the assembly but don't necessarily want to make a permanent assignment/reference, a reference made in the assembly or an in-context reference. These are all the same thing, an in-context reference is a reference made in an assembly.
If you change the assembly, and there's an in-context defined (by creating a reference in the assembly), you will need to refresh to update the ghosted image in the partstudio. It's confusing at first, but it does work nicely once you get the hang of things.
I'm using the ghosting more than in-context. These 2 things are not being differentiated but I think it's important to point them out as different. I think forcing in-context with a smaller project makes it confusing. Maybe waiting until your project gets larger, maybe this will make in-context more relative and easier to understand.
Me, I'm not a fine of in-context, but sometimes you have to use them, especially as your projects get larger. I don't think it's something you have to have. It's kinda of funny because I was like a rabid dog when Onshape didn't have in-context. Now that they do, I say proceed with caution. It works really well, much better than SW.
7
Answers
Check out these two courses in the Learning Center:
- Managed In-Context Design
- Multipart Part Studios
Onshape provides two different workflows to achieve geometric or spatial relationships between parts (top-down design): multipart Part Studios and Managed In-Context Design.Multipart Part Studios allow you to achieve top-down design all within one Part Studio. Managed In-Context design allows you to achieve top-down design between parts in an assembly. This is especially useful in the part's position is important for the in-context reference, or the parts needing geometric references between one another are in different Part Studios.
Check out the above courses to learn more! Also take a look at our instructor-led course on Top-Down Design Techniques.
As your project grows and more is added, it doesn't make sense to keep everything inside one part studio. Think of a rack of equipment and each component in the rack is a partstudio while the rack of equipment is an assembly of partstudios.
The problem comes at the rack level. Let's say you might need components in the rack to talk to each other which would require an in-context reference. Think of 'in-context' as designing in an assembly. For a smaller project you shouldn't need this. As your project grows, you'll need it. Please don't force it into something where it's not needed.
On a lighter note, one trick that I'm doing a lot these days (that's not documented, at least I haven't seen it). While in an assembly, double click on the part from the feature manager. This switches to the partstudio (you can now hide/show other parts in partstudio, or just isolate the single part) and Onshape ghosts the assembly so you can design your part while seeing the assembly. This is brilliant. You don't have to create an in-context, just double click your part in the assembly feature tree. I'm careful not to pick anything from the assembly while working in the partstudio which would create an in-context reference. To me this is what I want onshape to do, I want to see the part in-context of the assembly but don't necessarily want to make a permanent assignment/reference, a reference made in the assembly or an in-context reference. These are all the same thing, an in-context reference is a reference made in an assembly.
If you change the assembly, and there's an in-context defined (by creating a reference in the assembly), you will need to refresh to update the ghosted image in the partstudio. It's confusing at first, but it does work nicely once you get the hang of things.
I'm using the ghosting more than in-context. These 2 things are not being differentiated but I think it's important to point them out as different. I think forcing in-context with a smaller project makes it confusing. Maybe waiting until your project gets larger, maybe this will make in-context more relative and easier to understand.
Me, I'm not a fine of in-context, but sometimes you have to use them, especially as your projects get larger. I don't think it's something you have to have. It's kinda of funny because I was like a rabid dog when Onshape didn't have in-context. Now that they do, I say proceed with caution. It works really well, much better than SW.
I've always been a big advocate for project structure and trying to get everyone on the same design page. Turns out OS has a lot more capability than other CAD systems and laying out the structure, although fun, is more arduous just because it's more powerful. Getting rid of file references and dealing with a fat table, OMG, structures in OS are more refined, sophisticated and powerful. It's going to get interesting.
I think project structure in parametric CAD is going to become front and center for most organizations as it gets more powerful & robust. Having everyone on the same page will become more critical as we implement these new tools.
I don't see this as a bad thing because it is more difficult, but, we finally have the document controls we've always wanted.
I'm interested in seeing your project structure if you want to share. billc@rndengineering.com
In my case, I have in-context manage mounting conditions for motors, cylinders & fixtures. I tend to design using datums and controlling the function of a mechanism. When adding components to the assembly I mate to the functioning axis of a motor, servo, cylinder and then let the in-context arrange the mounting brackets and mounting holes for me. I don't mount motors to mounting holes, I let the CAD do that. This way is a very fast way to design equipment. It's top down. Not bottom up. It's powerful.
With this backwards design structure, I can change the function of the equipment and have all the brackets/mountings update. It's rare that my prototypes have holes in the wrong location when building the 1st article. I can burn through several concepts while the bottom up guy barely finishes one iteration. It's good that your fixture designers want to do this. I'd try to get them to standardize your design pattern (project structure) picking the best ideas from all of them and writing them down. I've tested engineers before allowing them to work on a project making sure they get the project structure. Maybe I'm an asshole.
A well defined project structure allows rapid development of automated equipment, fixtures and other mechanisms.
I still struggle with making this structure transparent, understandable and obvious for the next guy. I'm hung up on this next guy concept worried that engineers get the design intent. I feel we have a lot of work to do in this arena making our design patterns better understood.
I love comments, use them a lot. It's great to see the guys come online in the morning. I'm usually the 1st one in and change everyone's stuff before they arrive. I do use branching so they can elect to merge my suggestions. I'm trying not to be an asshole. We're designing and reviewing in less than a day. You can't beat that.
Comments work great on the day to day stuff. In fact I use words like 'revolutionary' as opposed to just good or great to describe commenting/collaboration.
It is great to hear that Onshape comments and collaboration answer your day-to-day needs. In fact, it is most gratifying to hear that
I'd like to pursue the topic of documenting the project structure a little further. If we give you a tool to visualize the dependency graph of the document(project) would it help? You probably would want to attach comments to edges and vertices of that graph. What other tools could help?
This is getting very interesting. I shared a couple docs with you privately (although now thinking about it I will just make them public). We have long used SW and not done any structure outside of each project. I am excited to consider structure across projects for common parts, boiler-plate designs, standard & purchased parts, etc. I like your example of making change suggestions on a branch. Wow!
My guys know to version before they leave, because they know what'll happen in the am. Me branching is a nice gesture and after all I like to let engineers be engineers offering only suggestions. Branching allow them to remain in power which is important to me.
If you have early visibility, I'd like to see it.