Bug Report: negative distance constraints accepted, but work wrongly (abs())

[OceanHydroAU]

Ideally - negative horizontal and vertical constraints should just work the same as positive ones, just "going the other way"

Presently, this is accepted without an error:

rh=d.addDistanceDimension(nose, sp, myHorizontalDimensionOrientation, sp.geometry)
rh.parameter.expression='{} cm'.format(splinex[i]*scale) # This is negative

but the resulting constraint is being treated as an absolute value (dropping the negative sign), which obviously messes things up...

e.g. these look OK at first glance (except for the glaring fact that it's not supposed to have a dimple in it):-

The problem is revealed if you click on the one that's not supposed to be dimpled:

 

It's being treated like 0.087 when it's supposed to be -0.087

I notice it turns red if I try to change it.  It might be better to fix the code dealing with negative constraints, rather than try to hide that issue by trying to prevent users from entering them?

Interestingly, this seems to only be a problem with Horizontal Dimensions.  Vertical ones work fine (even though, when clicked, they come up as red/invalid - they are actually working OK)

[OceanHydroAU]

My work-around was to first move the point where it needs to be, then add the abs(distance) constraint on the X axis.

I did not have to change Y, because that already "works" (see below - it shows "red" for invalid in the UI, but the API already let me put it in, and it's working OK for Vertical constraints. - the "nose" is the point *above* the negative Y constraint ).

[OceanHydroAU]

Correction... all the negative Vertical constraints "break" (turn positive) as soon as it does a re-calc unfortunately...

Before:

After:-

This looks like a very minor original bug, that somehow got fixed "philosophically" (ban negative) instead of "programatically" (fix the code mistake) - which I humbly recommend you take the "more difficult" path to fix - first, find and fix the code bug, then, find and remove all the "philosophical patches" (banning of negatives, using abs(), etc) that have piled up to try and overcome it, and finally check that the locational switcheroos involved all still work.

The future benefits of having a bug-free and robust constraint-handling engine will almost certainly reward you later (I've been "maintenance programming" for 35 years - I've got a good feel for "minor things" that turn up later causing "big problems"... this smells like one of those to me...)

[kandennti]

Hi @OceanHydroAU .

I have some experience with macros in other CADs (CATIA), but other CADs do not accept negative values for sketch constraints.

Probably because it is for expressing distance, I think that it will only accept natural numbers.

Therefore, I feel that it cannot be called a Fusion360 bug.

I thought that it would be a problem as it is, so I made a sample as one idea.
https://github.com/kantoku-code/Fusion360_ChangeSketchDimensionValue 

Please allow it though an error may appear because it has not been tested so much.

1. Make a sketch and make a constraint.
   Type should be "SketchLinearDimension".
2. Execute the linked script.
3. A dialog will appear. Please enter a number other than 0.
   Of course, you can use negative values.

It is a difficult process to understand, but it is done in this way.

I made the constraint non-driven, created points and constraints temporarily, moved them, and then brought them back in again.

[OceanHydroAU]

Yes, I "solved" the issue similarly, but this is definitely a bug.

Constraints can be parametric.  Neither you nor I get the opportunity to run any code whatsoever IN FUTURE when a user makes an adjustment that causes a distance constraint to go negative.

Almost everything is in fact working fine with negative constraints - except for one minor bug with the handling of horizontal ones upon creation, and another minor bug on the handing of negative ones during re-calc.

The concept of "positive distance only" is a totally "anti-parametric" decision - I'm hoping that the Fusion team will understand that, and swat those 2 minor bugs to get this all working right for future users!

[OceanHydroAU]

P.S. Be aware of a "trap" you can fall into with this - if you create a point (or probably other script object) that is coincident with another, Fusion seems to "collapse' the two into one, so you end up inheriting possibly unexpected constraints from the existing sketch [which then causes over-constrained errors when you try to add yours, and you can't just delete the one you inherited because that's the users decision already], and/or with object lists that are shorter than you might expect (if one of the points that got discarded is on the end).

That means, when you need coincident points, that you need to create them in some other place (so they don't collapse) and then move them.  That also means that the new temporary non-coincident place you chose could possibly be the "other direction" of a constraint you need to add, so the full-blown solution that you suggested actually ends up as a huge pile of unnecessary and fragile code when you take into account all the edge cases...

[BrianEkins]

@kandennti is correct.  This is not a bug but a reflection of how the sketch constraint system works.  When you add a  constraint you're defining some type of relationship between entities (parallel, equal, etc.) or a position relative to something else.  A linear dimension constraint is defining a distance between two entities.  A distance between two entities is always a positive number.  It doesn't matter to which side one entity is from the other, but just the distance between them.  

[OceanHydroAU]

OK @BrianEkins - explain how your understanding works in a parameterized environment.

Points A, B and C.  C is constrained to the right of B by 1 meter less than A is to the left of B.

Now how exactly do you resolve the conundrum that you have artificially introduced by trying incorrectly to dispense with the sign on distances?

A and B might be 2 meters, or half a meter, apart.

There is simply no possible way to parametrically "encode" the concept of a distance that must always be positive as well as supporting parameters too, at least short of the ridiculous idea that you give every distance an event handler and let the designer write a chunk of python to catch negative distances, erase them, then re-create them in the opposite orientation. 

A distance is a distance.  A parameter can change.  You can't have the second idea if you want to eschew negatives from the first.

Yes this is a bug.