parts not auto inserting at the right place - in context modeling

Yam_S

Hey,
I'm having trouble with the "sync" between the part studio and assembly when I try to auto insert parts I created through "Create part studio in context".
After I move the "in context" parts in the assembly and update the context, the parts auto insert in the "old" position (?!).
without further ado watch the 3 minute video on YouTube detailing the whole concept.

https://www.youtube.com/watch?v=8GMTnojEHF4

I contacted support, but they currently can't fix/explain it.
anyone figured it out already ?
if I ignore that and manually mate the parts, is there a chance for future movement/problems with this assembly?
that's my main concern, the comfort of auto part insertion only comes second.

Regards
Yam

nick_papageorge073

I didn’t watch your video yet. But the insert from the context only goes to the correct place on the very first insert. After that, they reference another origin and are in the wrong place. 

The fix is to use the mult-mate feature script in the context studio to give a MC to each context part. Then when mating to the assy, use that mate connector and the assy maté connector used to generate the context. It’s very robust and reliable, but takes a couple extra steps. 

Yam_S

Hey, thanks for the answer.

1. can you point me to the "multi mate" feature ?
I tried to search it but there are no results with these exact words.

2. Why is it like that ?
I mean the context update should re-orient the part's location relative to the assembly, that’s like….what the context updates are for.
moreover, in the "studio in context view" you can clearly see (watch the video it will clarify), that the software acknowledge that the part moved, and also that the added part are moving with it perfectly.
it's like the part studio image is spot on, but the assembly lost the orientation.
kind of weird, Isn’t it ?

that way the auto insertion of parts just fades away in the "in context" mode.

nick_papageorge073

I did end up watching your video after I posted my comment. What you experienced is what I was describing. I've actually put in a feature update request a year or so ago for the same thing. I don't know why it does it, it just does:) The way you ended up mating it in the end is very robust, however. If there is not convenient geometry to mate to like you did, mating to the origin always works. You don't need the FS below to do that, you can just make a mc at the origin of the part studio. However, mulitmateconnector makes it much easier when there are multiple parts.

Here is the mulitmateconnector fs. Its super handy for other assembly situations also.

https://cad.onshape.com/documents/5d8da63844bedebe5cff72b1/w/96a36142be717fc84a504e3f/e/11dcab8f665add80b9aced0a

nick_papageorge073

Also, the motion is not what caused the mis-match. Its the "second" insertion of the parts. Lets say your context has 4 parts. You design 3 and insert them at one time. Those will show up in the correct place. Then you design the 4th part later, and insert it when finished. It will be in the wrong place. Even if nothing moved in the assembly.

nick_papageorge073

I remember a bit more now... and experimented some on my own. The shift has to do with the origin of the top level assy, and the location of the mc you used to create the context. When they are not the same place, the "second" batch of parts that get inserted from the context will be offset by the distance between them. That's often what I do, and the second set never line up with the first set of parts. However, if the mc used for the context part studio "is" the assy origin, then I believe all future part insertions will be in the correct place.

In your case, I see you did choose the assy origin as the mate connector for the context. But, look at your default planes in the context. They move when you move the piston. And the error in your part placement seems to be the distance the planes moved. I wonder if it has to do with the way you assembled part 1 in your assembly it looks like it's fixed. I wonder if you assemble that part to the origin instead of fixing it, if it will keep the default planes from moving in the context.

I've grown to avoid using "fix" and "group" both in assemblies. For me, they've caused more trouble than they are worth.

Yam_S

nick_papageorge073 said:

 The way you ended up mating it in the end is very robust, however. If there is not convenient geometry to mate to like you did, mating to the origin always works.

which way i mated it ?
to the assy origin ?

didn't quite get what your were saying there, sorry.

nick_papageorge073 said:

Also, the motion is not what caused the mis-match. Its the "second" insertion of the parts. Lets say your context has 4 parts. You design 3 and insert them at one time. Those will show up in the correct place. Then you design the 4th part later, and insert it when finished. It will be in the wrong place. Even if nothing moved in the assembly.

actually no.
and I tried it again now to verify.
if the parts did not move from their exact coordinates, the insertion of the next part will be fine.
the motion doesn't have to be like the one in the rod, any placement change will do it, like lengthening of a part.

nick_papageorge073 said:

In your case, I see you did choose the assy origin as the mate connector for the context. But, look at your default planes in the context. They move when you move the piston. And the error in your part placement seems to be the distance the planes moved. I wonder if it has to do with the way you assembled part 1 in your assembly it looks like it's fixed. I wonder if you assemble that part to the origin instead of fixing it, if it will keep the default planes from moving in the context.

I've grown to avoid using "fix" and "group" both in assemblies. For me, they've caused more trouble than they are worth.

it was fixed (that's the way onshape instruct you to do in the learning center).
I unfixed it and fastened the part to the origin and.....the problem still exist.
the deviation of the planes clearly shows what I'm claiming, the PS origin and the assy origin lose their "anchoring" to one another.
but not entirely, the update context still "understands" the movement and follow it perfectly, as evident by the PS view being on the spot.
only auto insertion doesn't get it.

Yam_S

nick_papageorge073 said:

Also, the motion is not what caused the mis-match. Its the "second" insertion of the parts. Lets say your context has 4 parts. You design 3 and insert them at one time. Those will show up in the correct place. Then you design the 4th part later, and insert it when finished. It will be in the wrong place. Even if nothing moved in the assembly.

Well, just happend to me at the latest model, not sure why it happend now and not before.
but that too is defenetly a thing.

nick_papageorge073

Yam_S said:

nick_papageorge073 said:

Also, the motion is not what caused the mis-match. Its the "second" insertion of the parts. Lets say your context has 4 parts. You design 3 and insert them at one time. Those will show up in the correct place. Then you design the 4th part later, and insert it when finished. It will be in the wrong place. Even if nothing moved in the assembly.

Well, just happend to me at the latest model, not sure why it happend now and not before.
but that too is defenetly a thing.

Yeah.... that's why I was suggesting to mate to the coordinate system mate connector for non-moving assemblies. The group command is super fast and easy, but not the most robust compared to regular mates.

joakim_møller

I have 2 assemblies more or less the the same. If I insert a opart into the first it snap into place, insert same part into the other it doesnt. Why??

nick_papageorge073

joakim_møller said:

I have 2 assemblies more or less the the same. If I insert a opart into the first it snap into place, insert same part into the other it doesnt. Why??

It auto-snaps based on the origin of the asm. If the MC used to generate the context is not on the origin of the asm, the part will be offset the distance between the asm origin and the MC used.

The solution is in the part studio, add a MC at the origin of the part studio. Then in the asm, mate that MC to the MC used to generate the context.