Can't change angle constrint in sketch

[Joel_graff]

So I have a sketch that I've created which contains thre lines. Two share an endpoint, are parallel with each other, and each has it's own length constraint. The third is vertically oriented and serves as a bearing reference for the other two, so I constrained them with an angle constraint. I managed to get it working, but encountered the error "Invalid constrinat index: 7". The angle constraint is the eight constraint (which means it's index would be 7, of course).

Ive always had this issue with angle constraints and could never really sort it out.

Thoughts?

culvert_sketch_error.fcstd

(6.72 KiB) Downloaded 40 times

Screenshot from 2019-06-06 05-42-19.png (74.53 KiB) Viewed 1495 times

Code: Select all

OS: Ubuntu 19.04 (ubuntu:GNOME/ubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.
Build type: Release
Python version: 3.7.3
Qt version: 5.12.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

[meme2704]

Hi
I do not understand the objective of drawing the vertical segment, for a constraint of angles of the first 2, that can be done compared to axes XY

[NCCALCADA]

Hi,
I've played a bit with your file, and the behaviour is really strange.
If you make a small increment of the angle (< 3°) the change work, but if it's to much it don't.

Also you don't have to create a vertical line for the reference, you can direclty use the Y axis as a reference.
(it don't change the way your sketch react though...)

When i create a new file and new sketch, i don't have any issue of changing angles.



OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16110 (Git)
Build type: Release
Branch: (HEAD detached at upstream/releases/FreeCAD-0-18)
Hash: f7dccfaa909e5b9da26bf50c4a22ccca9bb10c40
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: French/Switzerland (fr_CH)

[meme2704]

I push further the tests, I see that after the constraint 7, he refuses the 6, then the 5 so the constraints of position are banized by this newcomer, and as soon as he is placed, I can take again the constraints elimed
I think that there is a bug

[kisolre]

When meme2704 mentioned that the constraints start to be reported in reverse order I remembered that I reported something similar https://forum.freecadweb.org/viewtopic. ... constraint Might be related. In recent builds there should be more info in the Report view to identify the culprit.
When I open your file I get "File was not written with this version of the topology" in the report view. Since I am also using 0.19 I dont know why is that. I then have no problem changing the 15deg to 89 (or any other) in one go in sketch editing mode. When I try to change that from the Data tab it failed once then succeeded.

Code: Select all

OS: Windows 8.1
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.16687 (Git)
Build type: Release
Branch: master
Hash: ff1fb11af15a7c5f7f0ba3ef79588e128f397c2c
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Bulgarian/Bulgaria (bg_BG)

[un1corn]

Don't know if this helps, I had a little play with your sketch and found the same issues you have, however if you remove the parallel constraint, change the angle then reapply the parallel constraint it works.

[Joel_graff]

Wow. Surprised at the number of responses. Also kind of nice to see a reproducible bug, for once

To the previous comments:

1. I know I can constrain to the vertical axis, but this is one of several cases where that may not always be true (the angle's reference axis may not always be vertical)

2. Good to know I can work around it by releasing the parallel constraint and reapplying. Nevertheless, it shouldn't be necessary...

I'm thinking this is a bug for @abdullah to examine. If nothing else, there's certainly some inconsistent behavior going on.

[un1corn]

I have found several instances where a constraint cannot be placed or changed unless another local constraint is removed, not sure if they have to be in a specified order to be compatible with each other.

[Joel_graff]

I can see how removing one constraint to change another might be necessary at times - intuition suggests changing the value of one constraint in a substantial stack of them might create an unsolvable condition...

Nevertheless, this case is simple enough the sketcher should be able to handle it. I'm guessing that whatever is causing the failure is either a bug or an exception that should be tested for.

[openBrain]

This is kind of bug I often see here when the dimensions are quite big.
If you keep the same sketch dividing all dimensions by 1000, the bug doesn't exist anymore.
I guess there is a solution to prevent it by playing with advanced solver settings, but here ends my knowledge.