I create two simple parts using Sketcher WB and PartWB:
1.jpg (208.26 KiB) Viewed 3416 times
The Extrude's sketch:
2.jpg (411.42 KiB) Viewed 3416 times
the Extrude001 is base on Extrude's Face, and have two external edges. The sketch like this:
3.jpg (414.44 KiB) Viewed 3416 times
Promblem occured when i change the distance constraints in Extrude's sketch(e.g. set Len2 to 800). The Exrude001's sketch solved fail. Could anyone tell me why? Thank you!
swat_01 wrote:But I just dont understand why the Tangent one fail.
Try to delete both tangent constraints and all coincident constraints involved. After add tangent constraints by selecting line end points instead of lines. After the tangent constraint are added add additional coincident constraint to constrain end points of the third line.
Hopefully that should sort it out if you want to use tangent constraints. As for why does it not work if you add tangent constraint by selecting 2 lines and after add additional coincident constraint? I am not sure but it does look like an issue worth reporting:
Issue.png (1.33 KiB) Viewed 3298 times
Add two lines
Select them and add tangent constraint
Add coincident constraint between end points and observe the result (try to move line)
triplus wrote:As for why does it not work if you add tangent constraint by selecting 2 lines and after add additional coincident constraint? I am not sure but it does look like an issue worth reporting:
It is because of redundant constraints. Assuming your lines are horizontal, tangent makes the enpoints to have equal Y. Coincident makes their Y's equal, too, and that's the redundancy.
If the line isn't forced horizontal, it doesn't look that trivial, but you will still get a redundancy.
This looks like being the root of all evil in swat_01's case.
triplus wrote:As for why does it not work if you add tangent constraint by selecting 2 lines and after add additional coincident constraint? I am not sure but it does look like an issue worth reporting:
It is because of redundant constraints. Assuming your lines are horizontal, tangent makes the enpoints to have equal Y. Coincident makes their Y's equal, too, and that's the redundancy.
If the line isn't forced horizontal, it doesn't look that trivial, but you will still get a redundancy.
This looks like being the root of all evil in swat_01's case.
Yes but in my simplified example the lines don't have horizontal constraints added?
As for redundancy from coincident + tangent constraint (equal Y). I guess hard to solve as user does need to add both to get the job done. Therefore i am not sure how to solve this without limiting the tangent constraint to less supported use cases? Anyway just some thoughts and hopefully redundancy in this use case could be ignored for the part that is causing issues.
The problem is with redundant constraint detection in QR decomposition. With the default 1E-13 pivot threshold, it results in the described behaviour. Parameters 8, constraints 4, rank=4. You can not move anything.
If the default threshold is changed to 1E-15, then the rank of the QR matrix is reported as 3 (the reality, as the coincidence only reduced one DoF, as the other is determined by the tangency). Then you can perfectly move the assembly (expected behaviour).
About the absence of error message, well there is none in this case. I mean the solver succeeded to an OCC valid solution. The problems start afterwards with the inability to move the valid solution. I makes a nice case for future solver development.
This ticket remains open and tagged with "solver", so as to further develop solvers (it would make a beautiful unit test).
EDIT:
Additional information:
Funny enough, without changing the threshold to 1E-15 (this is with the threshold at 1E-13), if you click "solve" in the advanced solver dialog to execute an additional solve, then the setupSketch reevaluates the redundancy to a correct rank=3 and then it can be moved.
abdullah wrote:Funny enough, without changing the threshold to 1E-15 (this is with the threshold at 1E-13), if you click "solve" in the advanced solver dialog to execute an additional solve, then the setupSketch reevaluates the redundancy to a correct rank=3 and then it can be moved.
Yes i noticed clicking solve button manually usually fixes the issue of non-movable sketcher geometry or different information is available under Solver messages. And lately i got quite a few use cases where adding constraint resulted in non-movable sketcher geometry. I can't confirm this ATM but it might be Box Select was used more often when the issue occurred.
Anyway i will keep an eye on this behavior and if in the future i find something new to report i will do that.
The problem arises because the geometry moved as a consequence of the solve after the initial solution was calculated. So the initial solution is no longer valid and generates problems when it is partially redundant.