Contact set issue: Part A drives Part B, but not reverse

[ea425019]

Hi,

This tool is supposed to work by turning the green plate up or down to detent, while the grey bellcranks and other elements follow the green plate.  However only the opposite occurs: Moving the bellcranks moves the green plate. I am using a contact set. There is a small clearance in the gliding region. The red objects are bearings, simplified as just cylinders for this CAD.

Any ideas?

I realize contact sets are pesky, however motion linking a rotational movement along a slot wasn't really convenient, so I went contact set.

[ea425019]

Hi,

This tool is supposed to work by turning the green plate up or down to detent, while the grey bellcranks and other elements follow the green plate.  However only the opposite occurs: Moving the bellcranks moves the green plate. I am using a contact set. There is a small clearance in the gliding region. The red objects are bearings, simplified as just cylinders for this CAD.

Any ideas?

I realize contact sets are pesky, however motion linking a rotational movement along a slot wasn't really convenient, so I went contact set.

[ea425019]

Anyone want to try this one?

[ea425019]

Anyone want to try this one?

[laughingcreek · Accepted solution]

don't have time to dig through this ATM, but my suggestions are-

-get rid of all the position captures.  you all ready know that contact sets are a computational hog.  so are position captures.  if they aren't absolutely necessary (and they won't be if you used good modeling practices) they should be removed. they can really bog down a design.

-some joint situations just can't be solved by fusion.  but i would try disconnected and simplifying the joint connections to just the motion of the plate and arm, and get that working, then start adding things to it.

-is it possible to use a pin-slider there instead of contact sets?

-I think you did this, but use as few motion joints as possible, and ridged joint things that move together.

[laughingcreek · Accepted solution]

don't have time to dig through this ATM, but my suggestions are-

-get rid of all the position captures.  you all ready know that contact sets are a computational hog.  so are position captures.  if they aren't absolutely necessary (and they won't be if you used good modeling practices) they should be removed. they can really bog down a design.

-some joint situations just can't be solved by fusion.  but i would try disconnected and simplifying the joint connections to just the motion of the plate and arm, and get that working, then start adding things to it.

-is it possible to use a pin-slider there instead of contact sets?

-I think you did this, but use as few motion joints as possible, and ridged joint things that move together.

[ea425019]

Switching to pin slot joint fixed it with one caveat: I had to change the joint for the green lever from revolute to cylinder, as clearances led to no common plane between the two elements to allow 'pin-slot' to initially function. It is good now 🙂  Attached is the remedy file for reference.

Position captures need to go away, I often clear them, but I 'capture position' so often they pile up. Is there a way to not capture just position captures? Is the logic behind capturing them in timeline useful to us? I do not see use in their capture.

I am learning that Contact Sets are pretty intense on the computing side even on a simple design such as this.

Thanks for the help!

[ea425019]

Switching to pin slot joint fixed it with one caveat: I had to change the joint for the green lever from revolute to cylinder, as clearances led to no common plane between the two elements to allow 'pin-slot' to initially function. It is good now 🙂  Attached is the remedy file for reference.

Position captures need to go away, I often clear them, but I 'capture position' so often they pile up. Is there a way to not capture just position captures? Is the logic behind capturing them in timeline useful to us? I do not see use in their capture.

I am learning that Contact Sets are pretty intense on the computing side even on a simple design such as this.

Thanks for the help!

[jeff_strater]

Capture Position cannot "go away".  Some operations are position-dependent.  Imagine you have two components, with a joint between them.  You activate one component, and create a sketch.  You want to project a face from the other component into this sketch.  The geometry created by that projection is dependent on the position of the second component.  You need that Capture Position to assure that, during compute, the second component is in the correct position to correctly update the projected geometry.  So, some commands in Fusion are tagged as "position dependent".  If you start one of those commands when components are in a moved state, you will be prompted to either capture the position ("this position is important") or revert ("this position is not important").  Today, that check is admittedly overly aggressive, and sometimes captures positions at times when it is not strictly necessary (mostly because Fusion cannot know what you might do next).  We are working to narrow that check as much as possible, but there will still be cases where gratuitous Captures are in there.  I tend to immediately go back and delete any Captures that I think are unnecessary, at the time they are created.  If that introduces an error, then I was wrong, that Capture was necessary, so undo...

[jeff_strater]

Capture Position cannot "go away".  Some operations are position-dependent.  Imagine you have two components, with a joint between them.  You activate one component, and create a sketch.  You want to project a face from the other component into this sketch.  The geometry created by that projection is dependent on the position of the second component.  You need that Capture Position to assure that, during compute, the second component is in the correct position to correctly update the projected geometry.  So, some commands in Fusion are tagged as "position dependent".  If you start one of those commands when components are in a moved state, you will be prompted to either capture the position ("this position is important") or revert ("this position is not important").  Today, that check is admittedly overly aggressive, and sometimes captures positions at times when it is not strictly necessary (mostly because Fusion cannot know what you might do next).  We are working to narrow that check as much as possible, but there will still be cases where gratuitous Captures are in there.  I tend to immediately go back and delete any Captures that I think are unnecessary, at the time they are created.  If that introduces an error, then I was wrong, that Capture was necessary, so undo...