Parts built in-context do not end up where expected when inserted

billyzelsnack

https://cad.onshape.com/documents/50ca1d6a3b1c361f33bc508f/w/10e2e1365da2c87614bb51a1/e/cac687e6b8233d2b8bc76acc

The above file should show you in "hip roll LR" part studio with "Context 1" of "Assembly" enabled.

Notice the two cube parts 16 and 32 and where they are relative to the other parts.

Click on "Go to assembly."

Zoom out so that you can see the entire model on a stick.

Try and insert those two cubes (Part 16 and Part 32) from "hip roll LR."

Why are the parts inserted upside down and at the origin? I built the other parts of "hip roll LR" this way and when inserted they positioned and oriented in the assembly as expected.

billyzelsnack

The first thing I do is delete the initial part studio and do a "Create Part Studio in context" from the assembly and choosing the origin is the only option at that point. That initial part studio typically does not even end up with a context until after I have other parts that interact with it.

This is a new workflow for me and I'm learning more little details all the time so I probably just did something dumb early on in that file and I am just going to chalk it up to learning experience. I'll close this thread out and if it shows up again I'll post again and try to build a simple minimal example.

billyzelsnack

I figured out a way to get the insertions positioning where I expect them to again. All I had to do was create at the top of my feature tree (not sure if the top is required) a sketch with a single point at the "assembly origin" (which I happen to have that stick geometry at) and then add the sketch to the assembly and set it as the primary instance. This will pop the part studio origin to that "assembly origin" and from there the insertions will be positioned as expected. If you want you can change the primary instance to another inserted part from that part studio and then delete the single point sketch and insertions will continue to be positioned as expected. I feel a lot better knowing I can fix this issue when it shows up.

billyzelsnack

I've had a few days now with the new context workflow and have not run into any problems so far. I also now think that my problem of parts not staying where I put them were due to an adhoc use of contexts without really being able to track all the regeneration relationships in my head. Even with the very simplistic and very intentional way I use them now I still can be surprised when a regen does not go exactly as planned but if do take a second and think about it it will make sense. That said, we will see if it stays that way as the document proceeds and all the specific details of how I created something are no longer fresh in my head.

As for disappearing contexts I think I have this issue resolved as well. Just "paying the price" of using a fake part that is instanced in the hierarchy's parent has just made this problem go away and if it does show up in the future I think it is something that I will be able to fix. I still need to come up with a better naming convention though. Currently I have been calling that part in the parent  the name of the Part Studio which is ok, but not great. However I am happy with naming the context of the assembly where I assemble a given Part Studio as "this."

https://cad.onshape.com/documents/255be450463faf2e3590ad39/v/2b050d56379c5fd6a4ec5d7c/e/d353847a3b7a5e9f30d1a4e0

billyzelsnack

I noticed that I had built the cubes off of the Front plane and thought that maybe the default planes were special and lived outside of contexts. I tried creating a plane directly off a ghosted context part to get the little left arrow next to its feature and then building a part off of that but it gave me the same result with the new part inserted near the origin rather than where they where within the part studio.

billyzelsnack

I ran out of ideas so I tried just deleting the context, creating a replacement, and fixing up all the broken context arrows. It actually was pretty fast to do so but I still ended up with the same results of inserted parts showing up at the origin. After that failure I just started over and was very careful when I started to not move the pelvis around as everything is built off of that. Also I am trying to absolutely minimize referencing context geometry whenever possible. So far so good, but I'm a little anxious that it's going to break at some future point.

NeilCooke

@billyzelsnack when you create a part in-context, the origin and planes you see are for the part studio, so when you insert it into the assembly it will appear at the origin of the assembly. To do what you want, select the assembly origin when you create the part in-context. It will appear at some “random” place in the part studio away from the origin and planes but will insert into the correct location when your go back to the assembly. 

billyzelsnack

The first thing I do is delete the initial part studio and do a "Create Part Studio in context" from the assembly and choosing the origin is the only option at that point. That initial part studio typically does not even end up with a context until after I have other parts that interact with it.

This is a new workflow for me and I'm learning more little details all the time so I probably just did something dumb early on in that file and I am just going to chalk it up to learning experience. I'll close this thread out and if it shows up again I'll post again and try to build a simple minimal example.

billyzelsnack

I figured out a way to get the insertions positioning where I expect them to again. All I had to do was create at the top of my feature tree (not sure if the top is required) a sketch with a single point at the "assembly origin" (which I happen to have that stick geometry at) and then add the sketch to the assembly and set it as the primary instance. This will pop the part studio origin to that "assembly origin" and from there the insertions will be positioned as expected. If you want you can change the primary instance to another inserted part from that part studio and then delete the single point sketch and insertions will continue to be positioned as expected. I feel a lot better knowing I can fix this issue when it shows up.

owen_sparks

This shouldn't be necessary, there's something odd going on in your workflow.  Not once have I had an ICE part come in at the wrong place so I feel there is an easier solution somewhere.

Owen S.

billyzelsnack

I am glad that I now have a tool to dig my way out of whatever hole I may have dug myself into.

billy2

@billyzelsnack

I'd use 2 in-contexts and each hip n roll would have it's own primary view. One for each hip n roll. This will prevent the flipping you're experiencing. With 2 in-contexts, you won't have to understand primary views.

I don't like one context for a part studio and have experienced the same problems you describe.

Philip suggested a named position in the assy to help control the state for the incontexts, this helps. Most my in-context have to deal with mounting holes for gearboxes, motors and other items. If the context is based on a position when something can move, then save that position.

I'm thinking a context for each part. This is my new thinking and it's working so far. I have many contexts and could combine some if I put some thought into it.

I would change up your entire workflow. I'd have a part studio with everything in it. Not sure why you have 2 part studios. I'd have sub assemblies instead of part studios. I'd break your top assy into more manageable chunks. I'd start naming parts to avoid confusion.

One of the things that I do inside OS is to get the sub-assembly's to function using limit mate features. Punch each mechanism out in it's own smaller subassy. Then when they're brought into the top, those mates work. It's truly like building up something on a bench getting the subassy working and then bolting into the top. I've got some amazing mechanism designs using this work flow. Get the pieces working correctly and then aggregate them in the next level up. I've even made assignments in the higher level to further control motion. ie.. the sub-assy controls some aspects and then the top adds further control. I've never seen this in CAD before and think OS is great for this assy aggregate approach. It's the closest thing to assembling real life mechanisms and designs.

Your mechanism looks like a lot of fun to build up. 

Me, I'd have one part studio, many working sub-assy's, multiple contexts and start naming your parts.

Wish I could help more, but I'm busy working trying to get my company to do the same thing I just outlined.

billy2

Thinking more about your project: I'd keep the multi-part studios and drop in-context. You don't have to use in-context. Delegate sub-assemblies to your part studios. Just like you're doing, add some sub-assys. Don't roll it up in one assembly & use a sub-assembly for each part studio. Then roll them up to the top. Still get your sub-assemblies working before rolling up, This is really cool when you get motion to inherit to the next level up. Works really well. Look at named positions to help control key points in either assy.

Now for the radical idea. When in an assembly, double click a part from the feature manager, this ghosts the assembly in the part studio. A context is not necessary for this behavior and most of the time it's what I'm wanting. I just want to see everything my part studio. Now for the 1,000 arrows flung into my back. When you create a context, you have to continually update for things to show correctly. Not true with double clicking. To me, double clicking is faster and in most cases this is preferred. 

Now don't get me wrong, I'm an old time top down designer who's mastered project datum creation. Top down is everything for a piece of equipment. especially when assembling automated equipment. I mate shafts to shafts and let the CAD figure out how to update the mounting points. I never assembly a gearbox by it's mounting holes. I worry about the equipment functioning and can move things around easily based on functionality. I let the CAD handle the bracketing details. This, to me, is in-context.

I'm thinking you're wanting to break your project up to control it, yet you want to see everything. Try the double click and compare to the in-context. I think you'll like the double click method. Use part studios to control the relationship between parts that need to be related. In-context may be over kill. 

billyzelsnack

Up until very recently I have avoided assemblies entirely and instead used complicated configured derived chains of part studios that allowed me to gain performance back when building slowed down too much. Now I've kinda went the other way with simple part studios for each multi-part rigidbody and mates connecting them for articulation.

I am constantly changing my workflow and it's not unusual for me to restart a document just to try a new one. The double click method seems handy and I should give sub-assemblies another try now that I have a better handle on assemblies in general. I'm always playing this game between under and over organizing things. I can never make up my mind.

billy2

@billyzelsnack been there, done that.

After 4 years, I'm still changing up my work flow. 

One thing that I'm doing is starting the assembly and part studio at the same time.  I know I'm going to use them both eventually, so I just start that way. I use a lot of downloaded parts and deriving them into a part studio wasn't working for me. Double clicking between the 2 tabs is hard to explain, but it works and I'm not creating in-context relationships. I just want to see everything when designing parts.

If you come up with something new, please let me know

billyzelsnack

@billy2

I've made a lot of progress breaking things into sub-assemblies and my part studios are smaller and more manageable now. The workflow I'm using is to use in-context for adding related assemblies to the current part studio and one for referencing one link up the kinematic chain.

That said.. I have been running into an issue with the "Context assembly primary instance is not valid. Set primary instance of context before updating the assembly context." messages. Which is fine if you can find the instance with the correct context! For example.. In Part Studio "LowerLeg" I seem to have lost "Context 1 - UpperLeg" and can no longer "Update Context" with it. Looking in the Assembly "UpperLeg" I only have a context called "Context 2" under any of the Parts with context arrows.

https://cad.onshape.com/documents/b50f50d925044b399d06826d/v/96cf9fb4fe4ae99d396865b9/e/9d99153b214f0c63db81bf50

btw. When you say "When in an assembly, double click a part from the feature manager, this ghosts the assembly in the part studio." is this a short cut for choosing "Edit in context" from the right-click context menu?

billy2

Double clicking is a short cut. It behaves mildly different than the edit context in that the ghost is always relative to the part double clicked. It seems to work best without any contexts defined. Typically I'm adding 80% downloaded parts and a few make parts. This is my assembly. Defining an context isn't that important to me. I'm still figure out how many parts should be in a part studio. I tend to put a lot of parts inside a part studio to keep them organized, but I feel this messes up the context construct. I'm thinking of creating a lot of part studios. This might be the solution for you and me. Will let you know.


The set primary determines where the ghost will be placed. When editing many different parts, I was constantly changing the primary context to the part I wanted to edit. Instead, I began assigning a context to each part, therefore each part had one context and each part had a primary instance. The need to change primary context goes away. With this approach, there is no need to keep resetting primary context.

You know, if parts aren't related, they belong in their own part studio. With one part/ part studio you can have one context / part studio pointing to one part.

Confusing? yep

I'm still working it out looking for the perfect project structure, it's not 2nd nature to me yet, but I feel I'm converging on a workflow that understandable.

billyzelsnack

@billy2 Looks like we have opposite projects. Nearly 100% of the parts I use are parts I make.

Have you ever lost the ability to update a context? Maybe I am blind but I can't even set the primary instance so I can update the context. I guess maybe I modified/deleted a part and now that context is in limbo never to be updated again? If that can happen then maybe I need to start making special parts that are marked in some way to never be modified/deleted.

billy2

Yeah, I have a different problem.

Including everything in one context, seems like if the parts are stationary and planar, then one context should do it. The problem I have is when things in the assembly move, which they do, the in-context is correct, the ghosting is not what I expected. 

I have not dropped any context, they all updated. 

I you want to share your model, I'd like to take a look: billc@rndengineering.com

billyzelsnack

@billy2

Here's the latest where I'm at with a workflow. Built just enough to have some articulation.

https://cad.onshape.com/documents/255be450463faf2e3590ad39/v/d09414df5fd791660002c7c3/e/d353847a3b7a5e9f30d1a4e0

Essentially what I am doing is not using any of what I consider UI sugar features such as "Insert and go to assembly" or "Create Part Studio in context." Rather I create the part studios and assemblies directly.

So create a part studio. The very first part I create is a 10x10 box part at the origin and name it primary. I then manual go insert into its parent assembly if there is one. By parent I mean in the articulation. From that parent assembly I right click on that primary part and "edit in-context" which puts me back into the partstudio with a ghosted view of the parent assembly. I then build a part off of that ghost. So now I have a parent context.

I then create an assembly and insert that newly created part (built off the ghost) into it and attach some other assembly item I have like a bearing to it. Now I can "edit in-context" and and build something off that bearing ghost. So now I have the second context for the part studio I call "this."

This is all very confusing to describe in text. The link above is barebones and might be easier to follow.

billyzelsnack

I've had a few days now with the new context workflow and have not run into any problems so far. I also now think that my problem of parts not staying where I put them were due to an adhoc use of contexts without really being able to track all the regeneration relationships in my head. Even with the very simplistic and very intentional way I use them now I still can be surprised when a regen does not go exactly as planned but if do take a second and think about it it will make sense. That said, we will see if it stays that way as the document proceeds and all the specific details of how I created something are no longer fresh in my head.

As for disappearing contexts I think I have this issue resolved as well. Just "paying the price" of using a fake part that is instanced in the hierarchy's parent has just made this problem go away and if it does show up in the future I think it is something that I will be able to fix. I still need to come up with a better naming convention though. Currently I have been calling that part in the parent  the name of the Part Studio which is ok, but not great. However I am happy with naming the context of the assembly where I assemble a given Part Studio as "this."

https://cad.onshape.com/documents/255be450463faf2e3590ad39/v/2b050d56379c5fd6a4ec5d7c/e/d353847a3b7a5e9f30d1a4e0