Race condition between Asm3 and Ext. Geo. constraints may lead incorrect solutions

[ceremcem]

Reproduction and an example will be added soon.

There is a situation I guess caused by indirectly redundant constraints. Currently not harmful, I'm handling them.

1. Create a part (A)
2. Create part with part design (B) whose sketch is drawn by external geometry constraints (EX) which belongs to the Binder (BN) which is a sub-shape binder of A
3. Create a constraint (PlaneAlignment, for example) between top surface of B and top surface of A, which the EX constraint is also in this plane (indirectly)
4. After things are moved and BN needs to be updated by double-clicking on it, there starts a race condition.

At step 4, the B's top surface is in a different location than top surface of A, I think because:

• Asm3 wants to make them equal with top surface of A
• PartDesign external geometry redraws the sketch according to BN, which is in a different location.

Note to myself:

• indirectly-redundant-constraints
• redundant-solution

Current Workaround

Delete/disable Asm3 constraint and let the PartDesign's EX handle the relocation.

[realthunder]

I don't think that is a problem of the program. This is the binder update cycle I talked about. For a correctly constrained system, the binder will eventually stop moving. What's your expected behavior?

[ceremcem]

the binder will eventually stop moving

Will that happen when "the" calculated difference is below the float precision? If that's the case, this is something that impacts the performance if sub-shape binders are heavily used (like in my case) since it has a lot of re-computations.

What's your expected behavior

I'm thinking on this now.

[ceremcem]

IMPORTANT Note to myself (and further users): Removing Asm3 constraints might (will) lead to incorrect solutions which will ruin your design (I remember @realthunder said something like that before, but I can't remember on which topic that was)

[realthunder]

Really? I didn't remember either? Ruin your design, how? I am sorry, I am busy investigate some other bug, so didn't follow the binder issue, yet.

[ceremcem]

"Ruining" will depend if you spot the issue or not. If you can't realize that some parts are moved without your intention, it will lead a ruined model. In my case, a part is moved too much so that I could spot the change immediately and enabled those asm3 constraints, now everything is back to normal.

[realthunder]

Ah, I see. Yes, as long as there is DOF left, it is possible and in fact legal for the solver to move your parts. Even if there is no DOF left, there may be multiple solutions, such as different orientation of the part that all fit the constraints. You may want to freeze an assembly whenever possible.

[ceremcem]

Another note to further readers (and myself): If sub-shape binder jumps whatever you do (i.e. update it with its source, recreate, etc.) check the race condition between external geometry and asm3 constraints.

If external geometry wants to draw an object in a position and asm3 (solvespace) wants to move the part, asm3 moves the part and the subshape binders.

In other words, when sub-shape binder is used for external geometry constraints source and resulting object's placement is changed by asm3 constraints, this possibly creates a race condition.

Example

In the picture below, the Body001/Pad001/Sketch001 depends on the Binder which is bound to Body. There is a conflict created on purpose (for this example):

1. The Body001's upper face (lets call it A) touches the binder
2. and a PlaneAlignment is set between Body001's lower face (B) and Body's lower face (C).
3. Asm3 constraint wants to put the B to C into the same plane (naturally)
4. but since A is actually the same face as C according to the binder
5. the regarding to the operation in step 3, if B to C and A to C => B to C, which is impossible because B and C are the opposite faces of Body001. This creates the conflict in practice:

[ceremcem]

Closing as this is an old issue and things have been changed dramatically in the newer version, which makes the issue impossible to reproduce.