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.
Moving Origin
dave_schrat
Member Posts: 19 ✭✭
I created a part studio in context to an assembly and used the origin of the assembly. Now the origins no longer aligns, and the right plane is 1.9 degrees off the original right plane in the assembly. I look back at a previous version and they are aligned. I can not find a way to move the origin. Is there a way? How did I do this?
There is not a lot in the part studio and recreating it will not take near as much time as I have spent attempting to fix the current one. Also, it is a concerning since it is only a little off, easy not to notice and I really would like to understand how this happens/ed.
Best Answer
-
Options
NeilCooke
Moderator, Onshape Employees Posts: 5,432 
When you create a Part Studio in context, the reference you select becomes the origin in the Part Studio. When you “go back to the assembly” the Part is in the correct position but it is NOT mated or constrained in any way. If there is a change to the assembly then the part may move and that is what you are seeing.Senior Director, Technical Services, EMEAI0
Answers
Thanks, the constraint in the Assembly was broken. In an attempt to understand it, I played with it and concluded the following:
When selecting the origin when creating a part studio in context only temporary aligns them and they are not bound by some global coordinates. If you then create a part in context and constrain it in the assembly in the exact same place it was created in context then the origins will stay aligned. It you constrain it in a location that differs from where it was created in context to the assembly it will move the relational position of the two origins.
Your understanding is correct, but there's more...
There's a different way to think about OS assemblies that differs from other CAD systems. I wouldn't ever tie a part to an assembly's origin.
I don't know of a good way to explain assemblies in OS, but I like them.
The 1st idea is an assembly moving into another assembly, all mates in the the lower assembly get inherited in the top assembly except for those mates that are tied to something in the lower assembly. This is why you don't want to mate parts to an assembly. These mates to the assembly won't inherent. Typically one part is fixed and everything is mated to that part. This is a past xphilipism (OS support engineer & good friend).
So what's inheritance? I can define an assembly with mates that describe a motion, then I can drag that assembly into another assembly. The higher level assembly inherits the mates from the lower assembly and the lower assemblies motion is preserved in the higher level.
So let's say you have a library of 1,000s of assemblies of mechanisms and your job today is to build a piece of automated equipment. So you start in an assembly and drag in all the cylinders, slides & 4 four linkages into your assembly. Because you defined the limits in the cylinder, it'll only move what the spec sheet called out. By the end of a day, you can have a functioning prototype in CAD.
You can add more constraints to a mechanism in higher level assemblies and it becomes more constrained. This is a typical automation requirement that all this stuff needs to be orchestrated into a concert that plays music. Or, builds a product. OS works the way it should.
OS assemblies build up just like a piece of equipment that you'd have on the shop floor.
The problem is working library assemblies. I spend most my day downloading step files from vendors and building up assemblies for my library. It'd be nice if a supplier would give us working assemblies so I could download the CAD assembly and use it in my design. I'm wasting to much time doing what they should be doing.
Moving parts in from a part studio, all the parts move independently because there are no mates to inherit from a part studio. So now what do you do? My thinking, every part studio has an assembly associated with it that controls the parts contained inside the part studio. If there's only one part in a part studio, I don't create an assembly.
At the end of the day, I don't care about part studios and how the geometry was created. My focus is on assemblies and getting them right.
The problem with this approach, creating parts in an assembly, is that you'll probably end up having a part studio for every part. This is circumventing an important improvement that OS is proposing. A part studio contains parts that are related. The references between parts are cleanly contained inside the part studio. In the past, other CAD systems, people used incontext for all the references between parts and things quickly became an entangled mess. Many companies outlawed incontext and some CAD companies added a toggle to disable it.
Incontext is a can of worms, it works well inside OS, but you need discipline to use it successfully. If you're starting out, I'd start the parts in a part studio and drag them into an assembly. Parts that are related, have them all inside one part studio.
What you're wanting to do, design in an assembly, is complicated and you'll quickly get lost in a forest assembly references.
Thanks for mind expanding!
Let's expand in-context. What it means is that I want to "design in the context of an assembly", I prefer "designing in an assembly".
In-context is a broad statement and emcompasses many things:
1. the ability to see the other parts of an assembly while designing
2. available entity id's to assign references
3. the ability to create a reference to another part through the assembly
These are the basics of in-context.
1. Seeing the other parts of an assembly is best the feature of in-context. There is no way to design a part without seeing how it interacts with others in an assembly. It's impossible.
2. Highlighting faces, edges & vertices, who cares.
3. Making an assignment using in-context, an in-context reference. These are pure evil, over used & the source of unlimited pain for organizations who misuse them.
It's not a software problem, it's more of a user problem. Give me a good reason to use a in-context reference. They do exist.
Parametric modelling doesn't work without them and I was key to their integration inside OS. It took a lot of bitch'n & moaning to get them added.
I'm not against in-context, I'm against people using them improperly.
pick the assembly origin
now what do you pick?
Parametric modellers remember everything you pick, so pick wisely. You only get 3 strikes.
Creating a simple sketch in your new part
So you pick a plane & an origin. What'd you actually pick?
-the sketch reference is easy to control by picking the part studios front plane in the feature tree, it's now a local reference in the part studio
-the origin, not so easy. Creating a circle and picking the origin makes an assignment to the assembly's origin, which is in-context.
One circle in your new part and you could have 2 strikes against you. Did you drop out of in-context to create a circle and insure that all references stayed in the part studio? I did.
I think it's best to create a new part studio, sketch and insert it into the assembly.
Part studios can cleanup in-context references if we give them a chance. It's a good thing. Try to organize parts inside parts studios. Those parts that have common references are the best candidates to include in a part studio.
I'm trying to explain why OS has part studios. They have a purpose.
I have experienced the incontext can of worms. Thought it was just me. A while back I had given up on using incontext. The feature tree would get long and tedious to work though (the addition of folder did help) so for my current creation I thought I would give incontext a try again. And again I am starting wonder which “worm” needs updating and is there a correct order I need to update.
billy2 Thank you for your insight! I have read it several times and have so many questions but I believe I have narrowed it down to:
So you use incontext as a visual portal to the assembly from the part studio? Thus creating the part virtually in the assembly. When done there is no incontext references? Changes in one PS that cause problems in another PS need to be manually/visually recognized in the assembly? Or if you think this may be a problem, you put them in the same PS? No matter the tree size?
Thanks for the kind words.
It's not you, I believe most people should stick to just the visual side of in-context.
My goal here is not to be an asshole, but to promote good modelling techniques. I post here often, possibly too often.
In-context is important. Look at the history of parametric modelling. It took PTC 2 years to release it. Pro-Engineer was hard to put down once they had it. I was there and I remember.