kisolre wrote: ↑
Thu Jul 18, 2019 5:46 pm
The problem is again some automation. When the trim is executed it automatically creates PointOnLine or Coincidence constraint (which was probably why trim was executed) depending on resulting number of edges left at that point. This is visible on a screenshot but not explained in the docs Sketcher_Trimming
Here existing PointOnLine constraints on both arc edges make the solver to produce confusing (but valid) result. Removing bottom PointOnLine constraint makes it work as expected.
Many thanks for the explanation. The question is if the solver can be improved in this respect or not. If yes, I will file a bug if not, then not.
bejant wrote: ↑
Thu Jul 18, 2019 9:09 pm
an improper method of making the Sketch
My aim was not to get a working sketch but to find a reproducible case for a strange thing I see frequently with trimming.
(The original sketch is the result of a DXF import, thus no autoconstraints.)
In my understanding the sketcher should work as expected no matter in which order the user set what constraint or not. I mean I performed a trimming action therefore it should not matter how other sketch parts are constrained or not. I want a line to be trimmed and FC should just do this. But I get the opposite - an extension. This is at the first look very confusion and it took me few minutes to get it right.
I stumble over these workflow-breakers every day since I started to do more work with FC. More work means collaboration and and this means DXF files to import and manage. The DXF import results gives you sketches in sometimes strange state. Therefore it would be very helpful if FC would be more tolerant and just performs the actions as can be expected by the user.