Community Tip - Your Friends List is a way to easily have access to the community members that you interact with the most! X
Hi All
I am trying to simulate a gear mechanism. But I get this error :
The highlighted connections are not defined from two bodies, if you continue they will be suppressed
I have figured it out that the second axis of the rotation should belong to the assembly, and not the parts. is that right?
caus this creates a difficulty that you have to relocate your Assembly axis after defining your parts location. Is there another way around ?
and how could I resolve this suppression ?
Thank you very much
Hello Farzad,
If I understand correctly, then you face this problem when you are switching from Parametric to Simulate. isn't it?
May be you can try this:
This issue occurs when the model is over constrained or some assembly references are lost (see video below)
and refer this video
And if this does not help, then will you elaborate more about the model?
Best regards,
Jignesh
Hi Torabi,
When defining a mechanism connection all references / constraints need to be between two parts only.
example:
rotation constraint: between hole or axis in part A and in part B
Vertical Translation constraint: between flat surface or plane in part A and in Part B
Rotation orientation constraint: between flat surface or plane in part A and in Part B
Adding in a third component into the constraint set will lockup the mechanism.
Hope this help,
Don Anderson
Thank you so much.
So if the part A is connected to the motor, and the part B is the follower, the part A should be inserted in the assembly tree , in a higher point regarding to part B ?
cause when I start defining positioning of one of the parts, I do not see the rest of the assembly and some of the planes and axes that I have created. so I am not sure how I can define the three indicated parameters between two parts
Hi Farzad,
Yes.
When assembling and defining the mechanism constraints for part B, Part B can only reference one other component. So all of the references would all have to be to Part A or all to Part B. You are not allow to split the references between 2 components. (except you can use a rotational dimension reference like in a pin joint to a datum of another part or datum feature for the Zero degree reference)
Hope this helps,
Don Anderson
This isn't always true. If you look at the classic 4-bar linkage, 2 of the bars (parts A and B) will be pinned to the ground, while a 3rd (part C) is pinned to the first two. In that case, the floating bar (part C) would reference both of the other two bars (A and B). You just need to make sure that you leave the proper number of degrees of freedom open.
Most of the time I see this issue is because of unintentional references that lock up the mechanism and make everything behave as Ground. Look at the mechanism tree and see if the bodies are arranged like you expect. Or try dragging the assembly and you will likely get an error that you can't drag the Ground body. There is some constraint that is locking up your mechanism. I suggest stripping it down to the bare minimum and add/resume one component at a time, checking to make sure that it drags/moves as expected after each component.
Hi Roger,
My reference was related to one joint constraint set. In what you described above, while defining the placement of component C you would define 2 joint sets and the references for each joint set need to be pointed to only one part. Set 1 (pin joint 1) in part C to part A and set 2 (pin Joint 2) in part C to Part B.
Hope this clears my statement up a little more.
Don
I will offer that I was creating a pin constraint between Part A and Part B and somehow got Part C involved by accident (not hard to do when turning datum planes on and all 100 datum planes in an assembly are the same color). I then removed the constraints with Part C, leaving all constraints between A and B only, and still had the issue described in this thread. It was only when I deleted Part B from the assembly, then re-assembled it using the pin constraints that the mechanism behaved. This is what I describe as a "jiggle the handle" operation in CREO, where it is an operation that seems totally unnecessary (and it should be unnecessary), but is required to slap CREO out of it. I would consider this to be one of many bugs that is so obscure that it will never get resolved. There are simpler issues with CREO that have still yet to be resolved in a decade.