Behavior Of Non-Rigid Joints in Linked Components - Possible Support Request

[ripberger]

So I'm relatively new to Fusion 360, but the behavior of non-rigid joints in linked components seems to have some issues.

So for example, I have a slider joint in a design that is an assembly of components. This design is upward linked into a hierarchy of several other assemblies. I have set DRIVE, LOCK, REST values on the design that created the joint.

Here's what I see of the behavior...

1) You can independently drive, lock, unlock, set limits, set rest position on the joint at each level of the hierarchy (I think this is necessary and is allowed).

2) When you add or update a linked component, the DRIVE, LOCK, and REST positions in the linked component are not carried forward. You have to set them all up again at each next level (but see #4). I think it would make sense and be desirable if the add/update of the linked component carried the current settings from the linked component into the linking component (especially given #3). I think it would make sense if you still allow the joint to be LOCKED/UNLOCKED/DRIVEN/LIMITED after the add/update at any given level, but the initial setting should come from the linked component.

3) If you set the DRIVE and LOCK  in a component that links a design with a non-rigid joint, the settings at this level go away if you update the component. This is probably necessary because the linked component update may have edited the joint to the point that these settings no longer make sense. However, this would make more sense if (2) worked the way I suggest.

4) If you create a Rigid Group in the design that created the joints, the joints become frozen and their positioning is carried up to the linking hierarchy on adds and updates. This is kind of a workaround for the behavior in (2), but it makes the joints rigid (un-drivable) which may or may be what is needed by the designer.

Assuming the above is correct, I would treat this as a support request for the modification described in (2) so that (4) is not needed to propagate joint settings from lower components.

[Phil.E]

Can you provide a sample design?

[ripberger]

OK - I'll try to make something simple to show the problem....

[jeff_strater]

@ripberger - I have done some simple tests, and found that things like limits and rest position are propagated to the top level.  However, I suspect that there are certainly cases where the behavior is what you describe, so I need to take some time to fully understand the mechanisms involved.

The balance between a joint being driven by the source sub-assembly vs being driven by the top-level assembly is tricky.  Once you override the joint settings in the referencing assembly, you probably want that setting to "win", and not have changes in the sub-assembly override those changes.  But, other times, you want the sub-assembly definition to "win".  Right now, there are not good controls for this kind of thing.

I'll try to find time in the next couple of days to post some simple examples

[ripberger]

I've attached a screen recording of the design "Slider Test" with two plates assembled with a slider joint. The design is linked into "Slider Parent". The video shows how setting the slider position in the linked component does not update in the parent when the component is updated.

At the very end, I ran "Compute All" in the parent and it reset the joint back to the initial position that the linked component was in when it was linked (not the one in the linked component now and not the one set in the parent component before the update).

Here are public links to the components. 

Slider Parent 

Slider Test 

[jeff_strater]

Yes, what you describe here is what I would expect.  I did some research myself, because I did not know the actual behaviors, and my findings correspond to what you find (with one exception).

The first thing to understand is that in Fusion, all sub-assemblies are inherently "flexible".  Meaning:  If you have more than one instance of a sub-assembly, each of those can be in different states.  The example I like to use is a sub-assembly which is a door + a door frame.  In your "room" assembly, you have two instances of this sub-assembly.  You want the position of each door to be independent - you want to have the ability to have one door open and the other closed.  For this to work, the top-level assembly (room in this case) must store some aspects of the joints from a sub-assembly.  At a minimum the position (the "drive" value).  This is how Fusion works - for each joint, it stores some attributes of each joint in an "override" that is owned by the assembly.  Once those overrides exist, those attributes are then driven by the top-level assembly.  So, any changes to the source of the sub-assembly, then are not incorporated into the top-level assembly, for those attributes.

I need to look this up to be absolutely certain I have the complete list, but based on experiments, I've found that position, suppression, and lock status are attributes that are overridden.  This is consistent with what your video shows.  However, I do not believe that other attributes, such as rest, and joint limits are part of this set of overridden attributes.  In my experiments, setting a limit on the child is always propagated to the parent.  

I understand that you are asking for different behavior, but I think you actually might not like the results if that were the case.  Think about the door example.  If editing the sub-assembly to close the door resulted in both doors in the top-level assembly being closed, regardless of their current position, some might consider that undesirable.

Jeff

[ripberger]

OK - so you are suggesting that the parent's settings should persist when the child is updated because there could be multiple instances of the child which have different states in the parent. I agree this makes sense. You're going to have to be rather cleaver about what happens if I modify or delete the joint. Delete is easier. Changing from Slider to Rotate presents a different challenge. 

However, if that's the desired behavior, then "Compute All" in the parent should not blow away the parent's previous settings. Which is what happened at the end of the video so this seems to be a bug. 

I think if you wanted to make me a happy camper, you would give a selection control in the parent's joint (it is different than a joint in a design that creates the link), that allows me to "reset to linked the component state when the component is updated"; or, perhaps more importantly, give me a control (a button) that I can request the joint be reset to the linked components state when activated. 

I understand this is my 'wish' item. Ideally, it might get into some release plan at some point when you don't have anything more important to play with.

Thanks for your attention and responses.

I had a post open before that was related to this that had a bunch of speakers positioned in the child and the user controls to adjust the positioning where in the child. I didn't want to to transport all those user definitions to the parent and use them to set the same joints in the parent (there were a lot of them).

[jeff_strater]

"However, if that's the desired behavior, then "Compute All" in the parent should not blow away the parent's previous settings. Which is what happened at the end of the video so this seems to be a bug."

This is a different effect.  This is the "Capture Position Pending" state.  Whenever a component is moved (doesn't matter how - drag, Move, Drive Joint), the design enters a "Capture Position Pending" state, indicated by this UI in the upper right side of the UI:

You can either capture or revert this position, but in general, this is considered transient state.  Some operations preserve this state, some do not.  Compute All does not.  Is that a bug?  Probably so.

"I think if you wanted to make me a happy camper, you would give a selection control in the parent's joint (it is different than a joint in a design that creates the link), that allows me to "reset to linked the component state when the component is updated"; or, perhaps more importantly, give me a control (a button) that I can request the joint be reset to the linked components state when activated. "

OK, understood,  There is also the option to declare an instance of a sub-assembly as "driven by source" (or "rigid"), which would mean:  My position is always driven by the sub-assembly source.  I'm not sure that would be all that useful, but it is indeed an option.

[kgrunawalt]

Rest and limits (set via edit limits) are part of a joint definition and are propagated to all occurrences of a joint including parent occurrences. Rest IMO is not very useful. I'd not bother with it unless you like to drag and see a joint bounce back after the drag. Often rest has to be ignored so it is not that predictable.

Lock is a property settable by every joint occurrence's degree of freedom. You can lock the rotation of a particular occurrence of a cylindrical joint, but other occurrences (paths through assembly) to same occurrence will not have that DOF locked. Suppress is a property of every joint occurrence. You can disable a specific occurrence of a joint. This is helpful to diagnose joint conflicts.

Joint degree of freedom values (rotation angle in revolute for example) are per occurrence values, allowing each joint occurrence to have different positioning. This lets an engine have piston subassemblies that have different states for example.

A parent assembly imposes joint DOF values on child subassembly joints per occurrence in the parent. This is necessary to allow flexibility in subassemblies at the parent level. This is done through the parent's timeline and also by "uncaptured" positioning done by dragging/moving components and driving joints.

Some good things to know:

• The parent timeline has joint and position features that cause child subassembly joint occurrences to change position. If you roll back the timeline to the feature that inserts the subassembly, you should see the subassembly joints positions as they are positioned by the child subassembly timeline (if it has one).

• If the child subassembly has uncaptured positions, those will not be used by the parent. This is intentional so that opening the child subassembly and dragging components around and saving will not affect the parent unless you want it too, in which case you should capture the positions in the child's timeline. You can tell if an assembly has uncaptured positions by looking at end of the toolbar. If there are uncaptured positions, there will buttons to either revert positions to as-computed in the timeline or capture them in a position feature.

• If the parent has uncaptured positions that include inserted child assembly parts, Fusion will try to remember these as you do various edits. This allows you to drag open the lid of a box and do modeling inside without the box lid snapping shut on you and without you having to capture the temporary open position.

• Uncaptured positions are discarded by some operations. This includes Compute All and timeline rolling back and forth (I think). There may be some other cases. Compute All should not really be necessary. It is kind of like turning your computer off and on to solve a problem. Normal operations will leave the model in a fully computed state. We do include it for exceptional cases. In this "reset" role, it blasts uncaptured positions.

Long story short

If you update a parent to a new version of a child subassembly and expect to see changes to child joint positions propagate to the parent but do not see this, there are two possible reasons:

1. The parent's timeline imposes positions on joint occurrences via features that affect positioning
2. The parent has retained uncaptured positions. You can revert those positions to see the computed positions.

You can always roll back to the point in the timeline where the subassembly is inserted and then step forward to see which features change the subassembly joint positions. Rolling like this will cause uncaptured positions to be lost

[kgrunawalt]

Regarding making a subassembly rigid, that might be a good option. We are considering ways to make Fusion's flexibility more managable.

The biggest problem we see is that modelers often don't know that their inserted subassembly has unconnected (floating) parts. Then they are surprised to see things left behind when the subassembly is moved in the parent. Fusion makes this easy with as-built top-down design. Parts look well-placed without being assembled by joints/constraints. But in reality, an as-built joint might be needed to connect a part to the assembly.

[ripberger]

I totally understand that each instance of a objects needs to have its own set of settable joint parameters. I think what lead me into this discussion is that in this particular parent assembly, I have two probably not typical cases.

1) I have 4 instances of a component where I wanted the joints to be set exactly the same. So in this specific case, I do want the child's settings to control all the 4 joints identically.

2) I have a child that contains 11 instances of one component. The 11 instances of joint settings were set up in this child using user parameters. So in the child, I did want all joints to have independent settings. Having set them all up, I wanted to then import this child and have its joint settings persist.

It's just a matter of where in the hierachy you want joints to have freedom or not. So, the issue is not that joints have per instance controls, its that I wanted some way to say use the settings that exist at this level of the hierarchy. For most point, I've been able to get around this by making the child that I want to have the control a rigid group. It's just that it might be handy to be able to temporarily override that child's setting to experiment on something, and then revert back to the child's settings.

Jeff Said:

"There is also the option to declare an instance of a sub-assembly as "driven by source" (or "rigid"), which would mean: My position is always driven by the sub-assembly source. I'm not sure that would be all that useful, but it is indeed an option."

This is probably pretty much what I was asking for. Where is it?

And more generally, is there a reference manual that describes the "GUI". I often see things and don't have a clue about what they do or how to use them. For instance, in the joint right click there is "Create Selection Set" - I think I know what this means but I'm not at sure how to use it - would be nice if there was some place to go to find out - and for give me if there is some help button somewhere that lets me some how get the info I'm looking for... I can always google and find out somewhere (usually), but if it's something I'm not looking to use, I usually don't do that and remain ignorant of some function that is probably exactly what I needed at some point. The more I use Fusion, the less this is a problem but for the clueless initiates it would be handy.

I need to read through kgrunawalt's post some more - thanks all again for the exchange.

[jeff_strater]

just to be clear:

"Jeff Said:

"There is also the option to declare an instance of a sub-assembly as "driven by source" (or "rigid"), which would mean: My position is always driven by the sub-assembly source. I'm not sure that would be all that useful, but it is indeed an option."

This is probably pretty much what I was asking for. Where is it?"

This was in reference to a possible future enhancement.  It is not available today.  We do not have an imminent plans to implement anything like this, in the interest of full honesty.

[ripberger]

kgrunawalt

Thanks for the detailed reply.

"Long story short

If you update a parent to a new version of a child subassembly and expect to see changes to child joint positions propagate to the parent but do not see this, there are two possible reasons:

The parent's timeline imposes positions on joint occurrences via features that affect positioning
The parent has retained uncaptured positions. You can revert those positions to see the computed positions.

You can always roll back to the point in the timeline where the subassembly is inserted and then step forward to see which features change the subassembly joint positions. Rolling like this will cause uncaptured positions to be lost"

Although it will be a bit hard do more than relate my recollections here, I believe what triggered my post here in the first place was that:

1) The joint positions in the child had be as desired and not changed for some time.

2) The joint positions in the parent were as desired and had not changed for some time. (possibly set in the parent because they were not correct either when child was imported or after some update).

3) There was some other change made to the child that prompted me to update the parent.

4) Updating the child caused the parent's joint positioning to jump away from the desired position.

So my experience is that a child update was causing the parent's positioning to change to something other than the latest positioning of the child or the parent. Running "Compute All" had a similar effect. So perhaps, the parent's positioning was updated but not persisted somehow and the update reverted to some prior setting.

Many of the controls you describe are news to me, my ignorance at least. Is there some place you would suggest I could look to better educate myself? Tutorial I didn't watch? Reference document?

P.S. - I really like Fusion. Still learning. Maybe tripping over some issues, but also could be that I'm tripping over some of the stuff I've generated that was implemented before I learned to do things in more appropriate ways. I appreciate how responsive this team is.