10. Parent Child Interaction
10.1. These statements are based on simple testing. If you are modeling with both parent and child move parts, please add validation measures to verify the moves are working as expected.
10.2. If a child part is moved, and then a move applied to the parent part over-constrains the model, then the second move will override the first. Joint Wizard shows both parent and child as under-constrained.
10.3. If a parent part is moved, and then a move applied to the child part over-constrains the model, then the second move will override the first. Joint Wizard shows both parent and child as under-constrained.
10.4. Therefore, “cross-branch” moves to both a parent and child are not supported. In the example tree below, moves can be created between Part C and SubAsm 1 or between SubAsm 2 and Sub Asm 1, but both types of moves should not be in the same model. No warning is given for this case.
10.5. The expected move order is that child parts will be constrained within their parents, and then their parents will be moved to each other. In the example tree, first Part A and Part B will be attached, and then Part C and Part D will be attached, and then either the SubAsm 1 and SubAsm 2 will be attached, or the parts will continue to be attached (e.g. Part A will be attached to Part C.) Either option is supported.
10.5.1. The first moves can be at their SubAsm levels or the Root level as long as the Move Parts tabs are correct. If these moves are made at the sub-asm level, the Move parts tabs will be less likely to cause move errors. Also, then the modeler can use Branch Tree (3DCS MC) or only open the sub-asm CATProduct (3DCS V5) when working on a particular sub-asm.
10.6. If a part (parent or child) is moved, and then a move applied to the same part over-constrains the model, then either the model will fail or DoFs will be dropped to solve the model. The Joint Wizard will show a “?” to indicate solver failures or an “F” to show the part with dropped DoFs is fully constrained.