Rigid groups and configurations

[ltomuta]

I have a group of components that have to stick together so I have them form a rigid group.
Now, depending on the selected configuration, the number of components in that group differ, but there are always at least two. I can imagine an extreme case when only one component is left in the group.

Now, as soon as one component is suppressed, the rigid group is suppressed as well and the remaining components no longer have the rigid group relationship.

To make the rigid relationship work I should create groups for all possible combinations of components? Any better solution?

Ideally the rigid group could have a more flexible option, one that says "apply to any of these components" vs "apply to all of these components or none"

[TrippyLighting]

---

@ltomuta wrote:

...
To make the rigid relationship work I should create groups for all possible combinations of components? Any better solution?
...

---

That is the current best practice. Remember that this is only the first release iteration of the Configurations functionality. I am sure there  will be more and your feedback is not ignored @karina.harper. 

I've discovered bugs during my trial of the Insider Version and just another one this weekend after the first release so there will certainly be updates for those fixes.   

[karina.harper]

Thanks for the tag @TrippyLighting -

@ltomuta I think this falls into one of the limitations of Configurations at the moment. I'm guessing in your design you're configuring the # of instances in a pattern, or something else that generates/destroys bodies when switching configs? Currently we don't have a great way of consuming these generated/destroyed bodies (or components) after they are created, since you can't configure Selection. I think that is the long term solution (and something that is being worked on).

In the meantime I do have a thought about rigid groups. One workaround might be to strategically put the parts into their own component, then in the rigid group select just the top level component. This will then react to whatever bodies are in that component. This could also be done with Components by using the "include children" checkbox.

Karina

[ltomuta]

Indeed, I was using patterns to generate copies of the components. I did meanwhile refactor the design and now all the components are jointed together, which works just fine. 

[cschofieldL2TXN]

I've been using this workflow for a while now but with parameters rather than configurations. I have several models with patterned components where the pattern quantity is driven by a parameter. Rigid grouping the top level component like you said works OK, but when you change the parameter, it either throws an error if you reduce the quantity (it is unable to locate previously included parts) or doesn't included added quantities if you increase.

I've started to use configurations to try and make switching those parameters more seamless by having different rigid groups for each configuration and suppressing groups from other configurations, but it still feels like a work-around.

I seems like the "include child components" option on rigid groups is really just a shortcut to selecting all of the subcomponents. When going to edit the group even just after creating it, the top level and all subcomponents will be selected, but the checkbox is unchecked.

[TrippyLighting]

---

@cschofieldL2TXN wrote:

... but it still feels like a work-around...

---

It is!

It is a recognized (by the Fusion 360 team) limitation. Hatefully that will result in better patten tools sooner rather than later!

[michaelBJE4U]

I was having this problem, I've just found the Ground To Parent tool. This seems like the fix you (or any one else who finds this thread) are looking for, definitely less cumbersome than multiple suppressed rigid groups. It's tied to the component rather than an item in the design history: So if a pattern has different numbers of components then there isn't a rigid group function looking for parts that aren't there (or ignoring parts that are!).

Mick

[TrippyLighting]

---

@michaelBJE4U wrote:

... I've just found the Ground To Parent tool. This seems like the fix...

---

That is indeed the fix for this particular pattern problem!

The Ground-to-parent attribute was added relatively recently, long after this thread was started.

[ltomuta]

Nope, not a fix for my scenario. If a component has n subcomponents, only the first one is grounded to the parent so (n-1) subcomponents are still floating around in space.

The fix for this problem is for RG to remember the "include all children" parameter and recalculate itself every time the timeline items that preceded it get updated.

[TrippyLighting]

---

@ltomuta wrote:

Nope, not a fix for my scenario. 

---

Can you share your scenario/model ?

[ltomuta]

Hmm, I stand corrected although something is odd. I thought only the firs subcomponent was supposed to be grounded but now I see this happening with parts created via a rectangular pattern. 

All parts are grounded !?

However, my reference structure is this one, created by API

Here the parts instantiated by the pattern are not automatically grounded (not even the first one, as I supposed it would do automatically, but I was not paying attention) and the rigid group only captures the parts that existed when the rigid group was created (:1, :2) and future changes of the parts no would lead to adding floating parts (:3).

But if the ground to parent is available via the API, it would seem I should be able to get rid of the rigid group and use the grounding instead.

[TrippyLighting]

The workflow is different for external components and internal components.

However, the "trick" in both cases is to ground-to-pattern the seed instance before patterning.

Then all patterned instances are also grounded to the parent.

For external components:

What I do when I need to create a pattern, I first create a component to collect all patterned instances in. that component is not yet assembled to anything or grounded to a parent, or pinned!  

Then I insert the external component into that first component, ground it to that parent and then create the pattern.

Then I can assemble the seed instance of the external component to it's location.

For internal components:

I create a component to collect the patterned instances in. I then assemble that component to the location where I want the pattern to start.

Then within that component I create the seed component for the pattern and ground it to the parent. then I design the seed component and then create the pattern.

This will keep patterns fully intact with not adjustments needed when the instance counter is changed!