#6226 - Warning message during geometry creation

[edwilliams16]

I would start with the minimal constraints - the four tangent ones then successively add the remainder. It smells like an over-constraint issue to me.

[drmacro]

I would start with the minimal constraints - the four tangent ones then successively add the remainder. It smells like an over-constraint issue to me.

I developed this one constraint at a time. I would add one, success, add another, success, and the next, error, adjust order repeat.

Yet when it is complete there are no over, redundant, or partial constrain message displayed.

And, it only happens with certain data sets.

For example, radius = 45, width = 4, and Angle = 44 reports no error in the current version of the code, yet radius = 44, width = 4, and Angle = 44 reports the noted error. (and as noted no solver errors when complete.

[edwilliams16]

If you construct your shape in the sketcher (not with the script) with exactly the same constraints and construction lines, it works with both inputs?

When exactly is the warning message created when your script runs?

[drmacro]

The sequence I use in the code was developed by doing it by hand as you suggest...

And the message is thrown after all the other constraints are completed and the angle constraint is added.

[abdullah]

Sorry for the direct ping, but I'm interested if you have any insight on this since it is a solver meassage?

pinged by pinger macro

Sorry for the late response.

That error comes from OCC. My guess is that the solver is getting 0 during iteration for a radius of a circle. You get this from sketch.cpp function updateGeometry(). You need your break point in the part where the circle is created.

You may think of constraining the radii before solving.

Come back with more info if this answer is not what you expected.

[drmacro]

...
That error comes from OCC. My guess is that the solver is getting 0 during iteration for a radius of a circle. You get this from sketch.cpp function updateGeometry(). You need your break point in the part where the circle is created.

You may think of constraining the radii before solving.

Come back with more info if this answer is not what you expected.

The error is indeed during the solving stage (my break points are external to FC code and in my Python...).

But, It happens whether solving is turned off while adding constraints or with it on.
(Though I just select it off in the dialog before running the script. I have not figured out to turn it off/on from Python.)

[edwilliams16]

Perhaps this why constraints are accumulated in a list and added en masse rather than one by one, in, for instance:
https://github.com/FreeCAD/FreeCAD/blob ... Polygon.py

[abdullah]

The error is indeed during the solving stage (my break points are external to FC code and in my Python...).

But, It happens whether solving is turned off while adding constraints or with it on.
(Though I just select it off in the dialog before running the script. I have not figured out to turn it off/on from Python.)

I am not sure what you mean by "turning solving off". Every constraint addition triggers a solve(), so as to effect the constraint. This is done by c++. There is no way to avoid it.

I might not be understanding what you are trying to do...

Perhaps this why constraints are accumulated in a list and added en masse rather than one by one, in, for instance:
https://github.com/FreeCAD/FreeCAD/blob ... Polygon.py

If:
- The final result of the geometry is valid;
- You insert the geometry in the final position (or very close to the final position); and
- You do not need the solver to act between additions;

then, this is the way to do it for two reasons:
- The solver won't interfere with you insertions
- Your insertion time will be way lower, as you are only solving once.

Let us know if this works for you.

[drmacro]

...

I am not sure what you mean by "turning solving off". Every constraint addition triggers a solve(), so as to effect the constraint. This is done by c++. There is no way to avoid it.

I might not be understanding what you are trying to do...

I refer to the Auto Update checkbox in the Solver Messages panel.

I see, from your explanation, that it does not stop the solver from running when constraints are added.

If:
- The final result of the geometry is valid;
- You insert the geometry in the final position (or very close to the final position); and
- You do not need the solver to act between additions;

then, this is the way to do it for two reasons:
- The solver won't interfere with you insertions
- Your insertion time will be way lower, as you are only solving once.

Let us know if this works for you.

My initial code did the following:

1. create geometry near or close to final position.
2. create a constraint
3. add constraint
4. repeat 2 & 3 as needed

I graduated to:

1. create geometry near or close to final position.
2. create a constraint
3. add constraint to a list
4. repeat 2 & 3 as needed
5. add all constraints by passing list

Both:

• appear to create valid geometry and constraints (constrained as intended)
• display the warning/s as discussed with some values
• displays the warning/s but, not 100% repeatably, given identical values for radius, lengths, etc.
• for instance, sometimes the warning includes multiple solvers or sometimes a given set of values works without warning

I realize without 100% repeatable conditions it's hard to assess what is happening.

Not necessarily a big deal, since it does create valid geometry and constraints...

[onekk]

The main point of the recent discussion is that a "Warning message" is not an error, so if the final geometry is correct and is not marked as invalid, you have not to bother of "warnings".

When programming, there are many "debug level", so there are a bunch of warning level, as example:

So warnings in some interpreters and compilers could be "turned off" has they don't harm anything, the program is running and his producing his results, maybe they are wrong due to the hints given in the warning but if you know "what you are doing" the warning could be ignored.

Regards

Carlo D.