Sketch constraint violated when changing dimension parameter

[obalbousEAKDA]

Hi!

Please have a look at this very simple design : https://a360.co/3FD7rsh

If you change the "length" in "user parameter" to 280 mm (instead of 320 mm) the body length will not change as expected : If you edit the sketch you'll see that there's a "coincident" constraint that broke but the sketch is still displayed as fully constrained.

Other strange behaviour : if you change the "length" in "user parameter" to 100 mm, it'll work fine.

Thanks.

[TheCADWhisperer]

I would have used the Slot command to create this sketch - far fewer constraints needed.

I (mostly) avoid Symmetry constraints.

If you drag the point it does update, but I would not create a simple sketch like this with so many constraints to solve.  Centerpoint Slot is much more computationally efficient.

[obalbousEAKDA]

Thanks for your answer. I agree with that but I wanted to point out the fact that this is to me a bug in Fusion : the sketch should no longer be marked as "fully constrained". These kind of issues may lead to faulty designs and very hard to find the cause.

[jeff_strater · Accepted solution]

I know what is going on here:  the distance delta that you chose (40) translates in the dimension (/2) to exactly equal to the diameter of the end circle.  You can see this if you add in a construction arc that shows the rest of the circle:

So, when you change length to 280, the center construction line lies exactly on that phantom arc:

Internally, Fusion treats sketch constraints as if they are to the "infinite" version of the geometry.  So, coincident to an arc is really coincident to the full circle.  So, what I suspect is going on is that the sketch solver is seeing this as not having violated the coincident (actually midpoint) constraint, it just is confused about which half of the circle is visible.  If you go step-wise, in anything less than 40 increments, it works.  320 to 300 to 280 works fine.  It's just that delta of 40 that causes this problem.

Yes, it is a bug.  I will create a bug for it.  But, @TheCADWhisperer is also correct - you are working way too hard to create a slot shape.  Symmetry and midpoint are both constraints I tend to avoid, unless there is no alternative, just because they are more complex, and the solver can struggle with them.  There are many other ways to create that slot shape that does not have this problem.  Until that bug is fixed, I'd use another method.

[edit] the Fusion bug for this is FUS-116409

[mavigogun]

"Symmetry and midpoint are both constraints I tend to avoid"-

There's nothing like the designer of a tool saying they avoid using a tool they were part of designing!  If only there was some sort of designation for faithless tools in Fusion- say, rendered in hot-pink -then the hapless user would know it was a snake when they picked it up.   Instead, we (I) foolishly presume (my bad) structures are built on a solid foundation.   Fusion can be a lover that occasionally gives you reason to hate them.

[MichaelT_123]

Hi Mr Mavigogun, FFellows,

I am sympathetic to your statements,

The problem with how constraints/dimensioning sketches behave is not new .... and there is no sign of its resolution.

https://forums.autodesk.com/t5/fusion-360-design-validate/dimension-zero/m-p/5515950

The nature of it is elementary for people with primary basic algebra (or arithmetic) knowledge.

The constrained and unconstrained sketch can be viewed as an algebraic equation which the F360 kernel engine tries to solve. Without going too much in the details, typically, nonlinear optimization iterative procedures are utilized here.

They are not necessarily deterministic; they might also be heuristic in nature for some problems .. and this is unavoidable.

What is avoidable, though?

As many probably noticed, parameters and dimensions are two arguments types of constrainment objects/functions. While parameters occupy the whole ℝ domain, dimension values can be positive real number ℝ+ only. Zero (dimension) is also excluded.

This simple fact profoundly affects how the calculation/optimization of constrained objects is performed.

The solver will stumble while trying to pass on the other side of ℝ+ barrier (e.g. switch to the other side of a symmetry line).

Thus, the duality of dimensions and parameters domains is the main problem – the main pickle. How was such a basic design flaw has been allowed?

Are there any remedies? Yep, there are some.

• After encountering a pickle … shot of vodka
• Avoid situations when there is the potential of ‘flipping’ dimensions
• Rebuild solver introducing the datum concept and consequently allowance of negative dimension values.

Regards

MichaelT