Problems with revolute joint
I thought we have firmly established in the other thread that revolute joints should not be used for such an assembly ?
I'll create a screencast on how to fix this later today using your components, but with explicit joint origins and an assemble-as-you-go method.
No screencast but I fixed your design.
Go carefully through the Timeline and ask if you don't know how I used your model to create this.
Hint: I created a group per component and then dragged that group to the point in the timeline where it was first needed for assembly. Keeps things neat and tidy.
Of course not a single revolute joint.
It is tolerable if you can get away with it. However he isn't. So time to change course 😉
Also, it's generally better to start with a solid foundation of how to do things correctly and then based on that foundation to start experimenting what one can get way with. In that case you can always fas back to the more robust solution if things break.
There are a number of things you did right in the design, which made grouping a lot easier or even possible.
All your fittings were designed properly in a component and then they were also designed consecutively, so all timeline features belonging to one component were listed consecutively in the timeline.
Then when you turn on component color cycling you can see exactly what belongs to one component. Then you can select all these features, including the leading "new component" feature and can create a group for that component.
This would be a nice timeline re-organization feature ( I've got ides for a umber of them ). Consolidate component features and group.
Once you have the components grouped, it makes it a lot easier to change their order in the timeline.
@lemelman, you are correct. It should be possible to construct almost all of this assembly with revolute joints. Whether this is the best method to construct it or not doesn't matter to me. It should be possible to use Revolve, and if there is a bug in Joints, it's worth looking into.
I think that there is something wrong with how the joints in the model that you shared were created, and, as I went through the exercise I think I figured out what the problem is. Sometimes, when I open that model, and Compute All, I get lots of failures and the assembly goes all wonky:
So, I deleted all the joints and Capture Position features, and re-assembled it using Revolute joints. First, I positioned the components relatively near where they should be. I do this as a practice, because I've found that it is easier to create the joints this way, and also because I've found that the solver is more tolerant if the components are close to their final positions. I have no idea if this is a real thing or not, but I do it anyway:
Then, I created the Revolve joints, taking great care to pick consistent geometry on the pipes and connectors. I used the inner edge of the connector, and the outer edge of the pipe. Again, I've found that if you are consistent, it helps:
When constructing the base, I found that creating the last Revolute caused an error:
I now understand why this is - all those Revolute joints cannot be free to rotate in a closed loop like this. In fact, now that I think about it, I suspect that is the root of the problem in your original model. Though it seemed (even to me) that it should be possible, once I started thinking about it from the solver point of view, I understand why this is hard. The solver wants all those pipes to be free to rotate, but that last one in the loop will make it so that none of them can really rotate. So, for that joint, I would use an As-Built Rigid joint.
Then, I added the revolve joints for the "curve" components, and now it all functions well. I attached the model, just for your reference.
Hope this helps, and I apologize for the overly-long answer - I kind of wrote it as I was doing the experiment, so I discovered things along the way.
Jeff
Jeff Strater
Engineering Director
My opinion on the question of why revolute joints are not ideal for this is really just that you should use the simplest joint possible for the job. The question of whether a revolute uses significantly more CPU power than a rigid joint is probably debatable, especially in a smaller assembly such as yours. But, there is an effect in larger designs. In the case of that base frame, the result of 8 revolute joints is a rigid frame, so it makes some sense to use rigid joints to achieve that. It's interesting to me, from a solver point of view, that Fusion can't actually build that set of revolute joints, but I do see why this would confuse the solver.
Another thing I have seen in the past is a newer user will try to use a cylindrical joint for a bolt/nut/threaded hole relationship (including even adding Motion Links between the rotation and translation axes of that joint), because that is the real-life physical relationship between those two components. But, if you think about it, the whole point of the bolt is to eventually create a rigid relationship, so the cylindrical joint is overkill.
Your frame is kind of a similar situation: Yes, as you are assembling such a frame out of tubing and elbow pieces, unless you glue/solder/weld the pieces in place, they are really free to turn until that final connection is made, but in the end, the goal is rigidity, so it's worth going there straightaway.
There is often no right/wrong way to do things in a CAD tool, and a lot of ways to achieve the same goal. You happened to hit one of the cases where one way to that goal actually causes a solver problem, and the alternative (in this case also more efficient) way would avoid this.
Jeff Strater
Engineering Director
@jeff_strater wrote: I now understand why this is - all those Revolute joints cannot be free to rotate in a closed loop like this...The solver wants all those pipes to be free to rotate, but that last one in the loop will make it so that none of them can really rotate.
Why is that a problem, Jeff? Circular dependencies and constraint sets that have only a single, fixed solution are common in F360 models. For example, why is a loop of revolute joints any different in concept from this set of 2D constraints?
F360 handles this sketch just fine. I know I'm conflating the 2D sketch solver with the 3D joint solver here, but aren't these two modules based on similar operational principles?
it's not just that it's a cycle, @GRSnyder, it's that it's a cycle with degrees of freedom, and where the cycle will end up creating a rigid relationship between those items. I can't think of a sketch analogy, but there may be one.
This is one of those things that should be theoretically possible, but in the implementation, is actually quite difficult. The solver wants to be able rotate all those components, but the total constraint system prevents that. This is why the original design sort of works, sometimes. If you are very careful, you might be able to get it to assemble, but then you will see bad effects like the original issue, or what I saw where sometimes Compute All works, and sometimes it does not.
hope this helps at least a little...
Hope this helps a bit...
Jeff Strater
Engineering Director
