Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sketcher doesn't report that a fully constrained sketch may have multiple (finite) solutions #5536

Closed
FreeCAD-Bug-Importer opened this issue Feb 7, 2022 · 0 comments

Comments

@FreeCAD-Bug-Importer
Copy link
Collaborator

Issue imported from https://tracker.freecad.org/view.php?id=754

  • Reporter: jmaustpc
  • Date submitted: 6/16/2012
  • FreeCAD version:
  • Category: General
  • Status: assigned
  • Tags: #pending, constraints, Solver

Original report text

This file is two lines on a circle. The way it is constrained, you can drag the "triangle" in circles around the circle, which partly works.

A vertical or horizontal constraint set on the apex of the triangle will cause it to think it is fully constrained, when it should have two possible locations.

The "triangle" also can be dragged with the mouse when the apex is not constrained, but after it has gone most of the way around the circle, the triangle suddenly flips to the other side of the circle.

Additional information

Version: 0.13.1157 (Git)
Branch: sketcher
Hash: cad41483eb5bd175f9755eb4e21b04043207e3e3

I am wondering if this is a problem with how "length along line constraint" works? I might well be talking complete crap, but I was wondering if the horizontal and vertical distant constraint is working of the x and y value of the length along the line constraint rather than truly working on its length. If so that could explain what is going on.

Steps to reproduce

  1. if you drag the "triangle" around the circle it goes most of the way around and then suddenly flips to the other side.... then if you keep the mouse pointer going around the circle, the triangle suddenly flips back again.
  2. If you select the apex of the "triangle" and then set either one horizontal distance or one vertical distance constraint it says the sketch is fully constrained, which it is not. If you look at the screen shots attached you will see the two valid possible out comes for a vertical distance constraint. The error is the same type of thing if you set horizontal distance constraint
  3. if you set lock constraint on the apex it complains of being over constrained ....which might or might not be the case.
  4. this point happened the first two times I tried to set vertical distance constraint but after closing and reopening the file, I have not yet managed to get it to repeat. I will test further on this point. When the apex was one the right hand position of the two possible outcomes for vertical constraint on the apex, it inserted the correct vertical value but flipped the triangle over to the lower left hand side (the second possible outcome for that vertical constraint value)

Other bug information

  • Priority: normal
  • Severity: minor
  • Category: General
  • OS: Kubuntu 12.04
  • Platform: 32 bit
  • Updated: 2/6/2021

Discussion from Mantis ticket

Comment by jmaustpc 2012-06-16 06:59

I managed to get the error 4), or something similar to be repeatable. I not sure if this is more of a problem with the undo system, hence maybe should be on a different ticket, for now it is just a note on the existing ticket in my last post above.

  1. move the apex of the triangle to point somewhere towards the lower right quadrant
    2)set a vertical distance constraint on the apex
  2. click "undo" on the tool bar to remove the last added vertical distance constraint
  3. move the apex of the triangle to point somewhere towards the lower left quadrant
  4. set a vertical distance constraint on the apex

rather than setting the then current correct default value for vertical distance constraint, ....FreeCAD will push the apex back to the position it had been in prior to the "undo", and set the what should have been a new value default vertical constraint value back to what it had previously been prior to the undo.


Comment by jmaustpc 2012-06-16 07:00

This is a link to the topic on the forum

http://forum.freecadweb.org/viewtopic.php?f=10&t=2706&p=20622#p20622


Comment by logari81 2012-06-17 09:42

this is a difficult one. Currently there is no mechanism in the solver for handling multiple solutions and I don't believe that we will have such a possibility soon. However, it is nice to have this test case as a reference when we decide to implement the handling of multiple solutions. Until then, users have to be a bit more clever in order to avoid ambiguous dimensioning.


Comment by jmaustpc 2012-06-18 00:26

I have added another example to the same topic in forum

http://forum.freecadweb.org/viewtopic.php?f=10&t=2706&p=20641#p20641

In this example I don't think its the same, I mean its not an multiple solution, I don't think.

It is an example where an extra superfluous "=" constraint can be added without causing an over constrained error.


Comment by jmaustpc 2012-06-18 00:34

To be clear, in case it is important, the three files posted to the forum, the first I noticed the superfluous "=" constraint and thought "that's not right", used "save as" to get the second file then deleted the "=" and noticed that it was still fully constrained and I got no error messages. So I "saved as" again to get the third file and then noticed that I could put the "=" back in there even though the file had been in a fully constrained state before I clicked on "=" and it still didn't give me an error message.


Comment by jmaustpc 2012-06-18 00:44

Here is another example of where there is a multiple solution with the tangent constraint in these two examples. The tangent can be in either direction, I have included some screen shots two illustrate this particular example. Of course in this file there are more possibilities when one considers the other tangent.

I've posted the files to the forum topic, at the above url.


Comment by jmaustpc 2012-06-18 01:02

This is the version data for the last three posts today.

version data
Kubuntu 12.04 32bit
Platform: Ubuntu 12.04 LTS (32-bit)
Version: 0.13.1162 (Git)
Branch: master
Hash: e05fcc7
Python version: 2.7.3
Qt version: 4.8.1
Coin version: 3.1.3
SoQt version: 1.5.0
OCC version: 6.5.1


Comment by abdullah 2017-12-08 15:52

kunda1
jmaustpc

I am not able to reproduce this with the current master. I am not sure if I am missing something.

May some power user check it up with a current version?


Comment by Kunda1 2017-12-09 01:36

chrisb do you mind checking ?


Comment by Kunda1 2017-12-11 06:26

jmaustpc please re-check ticket when you get a moment, thanks!


Comment by chrisb 2017-12-21 10:29

I can reproduce it - of course - because it's the well known behaviour. The current definition of solved is: There is no smooth transition to another solution.
So it works as designed and is definitely not a bug. abdullah may comment if there is a chance to get a solver where solved means: this is the one and only solution. If so this can be a feature request, if not it can be closed.


Comment by Kunda1 2018-01-25 16:58

abdullah please take a look at chrisb's response in ~10623


Comment by abdullah 2018-01-27 17:19

chrisb

Man! I cannot move that triangle. I have tried dragging all the three points and the two edges, in I would say any direction.

When you can reproduce it, what are you dragging?


Comment by abdullah 2018-06-15 16:49

Sorry, I mixed two different aspects of the bug. Yes, I can reproduce.

To me from this example what is pending is the "flipping", which still happens even with the improved dragging implemented at the end of last year.

Regarding the multiple solution, I do not forsee any change in behaviour. The solution is valid. It is somehow similar to x^2=4, x=2, x=-2, both solutions are valid.

@chennes chennes closed this as completed Feb 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants