less risky to use "Move + As-Built Joint" instead of "Joint"?

[maker9876]

In order to make assemblies of components more robust, am wondering whether, instead of assembling using joints (to move components into place) it might be better to assemble components using Move commands, and then afterwards to create As-Built Joints?

The speculated advantage would be that, if joints were to fail, components would nevertheless be correctly positioned. If there are sketches that contain projections of assembled items it’s particularly important that they don’t fly apart because of joint failure. (In particular am thinking of the error scenario where ALL joints suddenly FAIL because of the “Position calculation failed due to initialization “error. Have had this and it's terrifying.) 

One of the doubts I have stems from hearing people say that it’s best to avoid using Move commands! (Something to do with Copy/Paste like timeline clutter...) So if every time there’s an as-built joint there are 1-2 move commands in the file, this might be problematic? (Am thinking of using a point-point move command to move components into place, and perhaps a “free-move” command in order to rotate it, if necessary.)

Would anyone like to comment?

[sanket223.patil]

I have mostly used joints rather than as-build joints . Joint command is accurate .

[chrisplyler]

I don't think so.

Personally I would rather not have a bunch of Move and Capture Position features in my timeline. And I much prefer regular Joint over As-Built Joint.

[lichtzeichenanlage]

What I have read so in the forum, Fusion has a performance problem wit many move commands. And in my personal opinion it makes the timeline ugly. Sure, sometimes it's useful to move things (away) so a joint-command is easier. But than I clean up the timeline after the joint is established. 

I'm using as build joints if I e.g. draw something in place or it's created in place like a result of pattern- ore move commands.

[TrippyLighting]

Moving a component results in a position capture feature at latest when the as-built joint is created.

That is simply the wrong technique.

If a component is not created in place - there are valid reasons for it - then it should be joined using a regular joint.

If a component is created in place an as-built joint can be used. I say "can" because whether it still works as intended after parametric updates depends on how it was designed in place and requires an understanding of the function of origins in Fusion 360.

[maker9876]

Thanks everyone!

Would like to emphasise that, until now I've only used Joint commands to assemble. But recently had a problem where most of the joints in a project turned red with the "Position calculation failed due to initialization “error. I couldn't track it down and so lost a lot of time. What really was frightening was that there were components I'd created from sketches that depended on the correct positioning of other components (with joints). So am trying to think of "other ways".

You've pretty much put me off the "Move" command. But have just discovered that the "Free Move" that comes when one inserts a component contains all the options of a regular move, including "Point to Point" move which allows accurate positioning like a joint. However one can't do a "point to point" and also ROTATE, so if rotation is required that would then require a Timeline Unfriendly normal move command. Hmmm.

Maybe I was just unlucky getting the "Position calculation failed due to initialization “error (that spreads across many joints) and should just continue using joints as before?

[jeff_strater · Accepted solution]

This is actually a very good question.  I can comment a bit on this topic.  I've never really thought about it in terms of "risk" before, but it's a good way to frame the question.  I've always thought about it in terms of convenience.  As-built joints are more convenient to use, IMO, which is why I tend to use them.

In terms of model stability, I would say that the most stable approach is to build the components in place, and use as-built joints.  In this method, the components are guaranteed to be in the correct position in a stable way.  As-built joints are slightly more stable just because there are fewer geometry references involved.  Regular joints require two geometry references, while an as-built joint only requires one (or zero, for a rigid joint), so there is less that can fail to match.

To understand whether the Move + As-built Joint method is stable or not, you need to understand that there are two kinds of Move here:  Body Move and Component Move.  Body Move creates a parametric feature in your timeline.  But, if you are assembling components, Body Move is usually not the best approach, because that positions the body inside of the component, and a joint repositions the component.  So, you might think that Component Move is the way to go.  The problem with that is that a Component Move is not associative to the geometry you select.  You can insert a Capture Position that will capture the orientations of the components after Component Move, but if the component geometry changes, the Capture Position will not update to reflect the geometry change.  So, that approach is actually less stable, in terms of keeping the joints attached to the correct geometry.

So, my recommendation is either:

• build the components in place, in their correct position and orientation, and use as-built joints or
• use a regular joint

Regarding the “Position calculation failed due to initialization “ error - we'd like to understand that as well, to be honest.  If you have a way to re-create this error, it would be helpful to the dev team.  We have as yet not been able to reproduce this reliably.

Jeff

[maker9876]

Hi Jeff,

Thanks a LOT for the clarification.

Wrapped up in "risk" I'd distinguish 3 nuances:

1) the chances that a problem will occur (model stability);

2) the amount of chaos that a problem will create (everything falls apart?);

3) the chances of being able to recover from the problem afterwards / the costs of doing so (i.e. how much time/work lost);

Guess the as-built approach was postulated to tackle point "2" - and also to put a limit on point "3", that you have to go around recreating as-builts - but now you've highlighted that it's weaker on point "1".... well frankly of course I'm going with your recommendations!

If the archive associated with this link gives versions: https://a360.co/2pkZaRt

then version 89 shows more or less what it should look like and then progressively “Position calculation failed due to initialization “ type errors creep in. Happy to share copies of any data if it helps the devs.. 😉

[derekmcleod]

Sort of related to this. Moving components into position with the Move command seems to offer a drastically easier interface for positioning compared with Joints. Joint origins can take several clicks at least to establish a non axial orientation. Rigid joints only easily rotate on axis, and require the aforementioned joint origin to get around this. Makes it quite tempting to Move and then use As-built Joint. I really wish that rigid joints could allow the degrees of freedom for positioning that the Move command does. 

[jeff_strater]

@derekmcleod - be careful with this approach.  Agreed that it is sometimes easier to use Move + As-Built Joint to get the orientation that you want.  But, Move is not parametric.  Even if you use Capture Position, all that gets captured is the current position of that component, there is no associativity to the geometry that you may have picked during the Move.  Meaning that if your design changes, the As-Built Joint will successfully compute, but be in the "wrong" position.

One thing to look into:  Try explicitly creating Joint Origins for your components.  While a Joint Origin does not have quite the same UI as what you get in Move, it does have the advantage of being fully parametric, and can help in cases where a standard Joint does not offer the flexibility you need to get your components in the right spot.

Also, we are even now working on a project to give you more flexibility in placing joints, specifically in the geometry used to place the joint.  No estimate as to when this might be available to the world.  Hopefully not too long...

[Sungod3000]

I agree, normal moves + as build joints are the way for me. 

My issue is mainly that building the joints is so weird because you cannot move a part with one plane locked like in blender. Having e.g. a rotational joint that revolves around the X axis and not being able to lock the YZ plane while trying to set up the second component into the joint just feels weird. As build joint skip this whole issue.

[TrippyLighting]

I’ve used Blender for 15 years and use it frequently. Comparing Blender modeling workflows with Fusion 360 Workflows is nonsense in a lot of cases and certainly here.

Jeff has clearly explained that combining the move command with as built or rigid group joints is a bad idea and my

 own experience gained by by having fixed a few hundred users designs 100 % supports that.

[maker9876]

Did anyone notice the Release Notes for the July  3rd (2019) product update?

Anyone who had used joints to position their parts and then projected the resulting assemblies in order to continue developing the design would have been in deep trouble. (Extract below...)

from July 3rd 2019 product update: joint trouble!

[derekmcleod]

"Also, we are even now working on a project to give you more flexibility in placing joints, specifically in the geometry used to place the joint.  No estimate as to when this might be available to the world.  Hopefully not too long..."

This is encouraging. I would really appreciate the ability to manipulate the joint on all 3 axes, plus rotation for all 3 axes. I have been using joint origins and even they require a sketch to get the origin to align to an unusual axis. 

[coffeQWDCK]

Just like the creator of this thread, my technique has also been to create a component, move it into place using MOVE/ALIGN and then use an AS-BUILT JOINT. This method has so far given me less headache than moving the component into place with just JOINT. The issue I have with JOINT is that whenever the JOINT is removed the component flies back to where it was created. Often times I create the essential (functional) components first and tie them temporarily to a placeholder (which is usually sketch points in a sketch that is grounded). I tie the components to the placeholder by first moving them into place and then create an as-built joint. This way I can later design the actual structure that will hold the components in place (when I know where they need to be). I delete the joints to the placeholder, the components stay in place, and I can create new as-built joints to the structure that I just made.

Now I'm having some issues that might be related to this approach that I'm using.

I see that you (and others) are suggesting to "create components in place" instead of (after designing them) moving them into place. But how do you do that? Whenever I'm creating a new component, it gets placed at the origin of the assembly. So that's where I design it. The start of a new component usually results in creating a new sketch. And from what I've been taught, the sketch needs to be tied to the origin of its component (that happens to coincide with the origin of the assembly) to be fully constrained. Am I missing something here? 

[davebYYPCU]

Am I missing something here? No,

but we are - no idea what you are modelling.

Follow Rule #1, sounds like you got that bit,

Fusion is so flexible; both your methods are acceptable to those that use them.

Use normal Joints, because parametric changes and As built Joint, do not mix at all.

A good understanding of File and Component Origins and their uses will help.

Might help...

[TrippyLighting]

---

@davebYYPCU wrote:

Use normal Joints, because parametric changes and As built Joint, do not mix at all.

.

---

That could not be further from the truth! I use as-build joints all the time in complex assemblies.

I guess the key is to understand how to use them and in what cases 😉

[davebYYPCU]

All rules are meant to be broken, most new people don't understand As built Joint peculiarities.

[jeff_strater]

Since you replied to me, I will give my 2 cents on this topic.  The short answer is:  Using Move or Align Components + As-Built Joint is NOT recommended.  The simple reason is:  As-Built Joints are not associative to any geometry on the components.  If your components change, neither the Move/Align nor the As-Built Joint will react to those changes.  For example, create two 10x10x10 cubes apart from each other.  Use Align Component to place them next to each other, so faces are mated together, and create an As-Built Rigid Joint.  So far, so good.  Now, go back and change one of the cubes to be 20x20x20.  Observe what happens.  The faces are no longer mated together.  This is not good.

As-Built Joint is useful (that's why we put it in there).  The best usage is for, as mentioned, components that are built in place (in fact, that is where the name "As-Built" comes from).  Joints serve two purposes:  Positioning components, and defining their relative motion to other components.  As-Built Joints simply skip the positioning part (assuming that the components are already in the right position), and only specify the motion.  Which is why you do not need to pick geometry to align (and why they do not react to geometry changes).  The existence of the Move Components + As-Built Joint is kind of an unfortunate, and unforeseen, usage,   Fun fact:  Did you know that a Rigid Group is another kind of As-Built Joint?  It is only different in that the "motion" is pre-defined to be Rigid, and it allows more than two components.  An As-Built Rigid Joint is exactly the same as a Rigid Group, if you only pick two components.

You say:  "The issue I have with JOINT is that whenever the JOINT is removed the component flies back to where it was created."  Yes, this is true (and, IMO, exactly the correct expected behavior), but I have to ask:  Why are you removing Joints in the first place?  I cannot think of very many times where I have needed to delete a Joint.

[maker9876]

My experience has been that, in complex designs, occasionally "bugs" appear in the timeline. The general explanation for this is that some element of some sketch has not been fully locked down (black and not blue). Unfortunately, even if one is meticulous, that's very hard to avoid (I have sketches which, even after performing a "select all" followed by a "lock" still show as not being fully locked down). Anyway, for whatever reason, situations can occur where joints suddenly start showing up as yellow in the timeline and components fly apart. Sometimes recalculating the timeline will fix that. But sometimes not. It is because of such imperfect reliability - not necessarily the fault of anyone, just the nature of chaos in complex systems - that I was advised to first move components into position and then use "as built" joints. If the joint fails, at least the component is where it should be, the assembly looks as it should, the joint can be manually re-created and, if there were any contingencies (such as projections), there will not have been horrible downstream consequences.

Analogously I have the impression we are frequently advised against using "projections". Obviously they are useful, obviously they are there for a reason and when used in simple projects there are usually no problems. But in a large project it's easy for something to "happen" (user error, emergent chaos or perhaps an actual mini-bug). So my impression the recommendation has been to plan ahead and use base sketches (which in practice often means, go back and recreate what you have done but this time using a base sketch and some linked variables).

Afterthought: noting your example with the cubes, might it be OK to move them together (then As-built) if the Move is associated with a midpoint or corner of the face - some element that is unrelated to the dimension (whether that dimension was defined in the sketch or the extrusion)?