Carbon copy of a sketch results in unresolvable sketch

[uwestoehr]

Please file bug in the tracker against the Sketcher project just put a title and link this thread.

Thanks for having a look. I opened now issue #3973.

[openBrain]

No it isn't, the screen shot looks like you made a mistake, please recreate the file and let us see exactly what you did and exactly what FreeCAD does.

I think you didn't neither read the text coming with the screenshot, nor try to get some context of the global discussion.
Abdullah's and uwestoehr's posts tend to prove that it was understandable as is.
I'll recreate the file (or use the one by uwestoehr) when I'll create the ticket. I know you're probably not at work now given your timezone, but here it's working rush.
Somewhat looks like you're going after me but I don't know why...

[chrisb]

It seems to happen when 2 curves are tangent by design but not by constraint.

Very good find. With this knowledge I could simplify it even a bit further, and perhaps this sheds some more light on the issue:

Bildschirmfoto 2019-05-15 um 17.34.59.png (13.01 KiB) Viewed 1777 times

You can constrain any of the two bottom lines or the radius with 40mm and the redundancy message will show. If you constrain the upper right with 40 it is ok.

[openBrain]

Ticket for the wrong redundant constraint bug => issue #3976

@moderators : feel free to split the discussion about this bug in another thread if it increase bug tracking readability

[chrisb]

No need to split, the ticket points to the post, not the thread.

[abdullah]

...

...

...

...

I need user input regard the Carbon Copy tool. Basically, I am asking what the user expectations/intended use/intended outcome are.

Historical note

One day I became intrigued about the use of a master sketch (I think ppemawm is to blame for that ), but I am rather lazy and I realised I could take advantage of copies. I was starting to use the new PDN and I had problems to understand attachments, mappings and placements. Because of this lack of understanding, sometimes I was choosing (parallel) planes, which had different origin, inverted normals, which led to different kinds of mirrors and so on. Because I did not know how to correct this, I added a mechanism to calculate the relative senses of the sketches. This senses were then used when applying directional constraints, such as horizontal distance, which is sign sensitive, changing the sign to make the sketch flip. It worked at least in some simple cases.

The tool evolved to another use case, lofting, enabling to have unaligned non-parallel sections. With this use case, the flipping correction mechanism makes no sense, so it is actually disable when copies to non-parallel planes.

Problem

Well, the correction mechanism, in its current implementation obviously fails, at least in some cases.

Misconceptions

It is important to note that carbon copy does not suffer from toponaming. Not at all. Carbon copy does not rely on the indexing of the edges of a sketch, or the edges of a feature 3D shape.

User input

After some consideration, I am starting to think that the "correction mechanism" might have been a mistake. The reasons are that: (a) no correction mechanism was needed in the first place, because the right way to correct orientation if/when needed, is to use the placement properties as openBrain suggested some posts ago, (b) forcing a sketch to flip by inverting the sign of the constraints, is an error prone method with a potential to end up in an unsolvable sketch, when the correction mechanism fails, the result cannot be corrected, not even by using the placement.

Now, I am only one of the users and certainly not the one that has used this tool the most. So, what I want to know is: Is anybody taking advantage of this "correction mechanism"? Is there a use case where it is necessary? Would you miss it if I disposed of it?

What do you think?

[openBrain]

What do you think?

You read right. I think trying to implement a correction mechanism was a mistake.
To be clear, I'm a GNU-style user. I prefer to chain several basic operations that works well (and whose the behavior is highly understandable) than running an all-in-one feature with unpredictable result.
Given that, what I expect from the CarbonCopy tool is just to get a simple carbon copy of a sketch reported as is in my new sketch referential (with geometrical constraints repeated, and dimensional constraints linked as of today).
If that lands in a strange position, this is my mistake. I just correct it with sketch placement.
Oppositely, stop preventing me to carbon copy a sketch that isn't in a parallel plane. I know what I'm doing !

The case I see where it can be boring is when you start creating your (2nd) sketch geometry, then carbon copy the primary sketch afterwards, and the CC will land not in the expected position regarding the existing items. But that's a suboptimal workflow, probably not a big deal to patch things, and you will learn from this. And in this case, the user is responsible for the mess, not the software.

My 2 cents
PS : no claim to represent PoV of all users, I'm just one.

[chrisb]

I'm not a friend of too much automatism either.

I have to confess that I hadn't realized the correction mechanism at all, so I will not miss it. I guess that quite some use cases which may benefit from the correction could be easily solved without by using the "map reversed" property of a sketch.

[abdullah]

Thanks folks!

I was mostly convinced. Now I am also reassured:
https://github.com/FreeCAD/FreeCAD/comm ... d2108cd096

[uwestoehr]

I was mostly convinced. Now I am also reassured:
https://github.com/FreeCAD/FreeCAD/comm ... d2108cd096

Many thanks! I tested it today and it works well.