bambuko wrote: ↑
Mon Apr 05, 2021 11:32 am
So here are my comments.
In fact, your analysis of kinematic equivalence classes is wrong. Your "sub-assy_wheels (ref)" subassembly contains elements that should maintain relative mobility. However, by definition, the components of the same sub-assembly will behave in the upper-level assembly like a single block of material.
Your "reference" sub-assembly should therefore only contain the "axlebox" components.
Then the components "driving_wheel_RH; driving_wheel_LH; driving_crankpin_RH; driving_crankpin_LH; driving_axle" form the kinematic equivalence class (subassembly) "driving_wheels".
The components "coupling_wheel_RH; coupling_wheel_LH; coupling_crankpin_RH; coupling_crankpin_LH; coupling_axle" form the kinematic equivalence class (sub-assembly) "coupling_wheels".
Finally, as you have done, the "coupling_rod_LH" component alone forms the kinematic equivalence class (sub-assembly) "sub_assy_coupling_rods".
Some additional personal remarks:
You have already used the Placement properties of Part objects to preposition your components, probably because visually you already had the vision of your assembly, hence the use of Part containers and the mirroring of some components.
The Realthunder Assembly Workbench does not require the use of these containers, as they provide their own "Assembly" containers.
But above all, it does not require building clones or copies by symmetry, nor thinking about the positioning by numerical values of the different components.
If a component must be used several times, all you have to do is define the "Element count" parameter or create a "Link" object for this component.
On each component, it is useful (and even preferable) to define and name the "Elements" (geometric entities which will be used to define the constraints).
The final choice of the constraints to be applied must be made with the greatest care to ensure that the overabundant constraints (as few as possible) are manageable by the solver.