Carbon copy of a sketch results in unresolvable sketch

[openBrain]

I don't understand. I created Sketch-CC at the upper face of the pad, parallel to the initial sketch. This face is not a mirrored one but the result of the padding.
When I look in your patched file I see that you created the sketch "in the air" but this sketch must be at the face of the pad (connected to the pad face):

My mistake. Didn't pay attention that your pad was in the reverse direction. I edited my previously attached file so it is now correct.
chrisb also did the same thing in between my 2 posts. A picture so maybe its clearer :

sketch_expr.png (41.83 KiB) Viewed 1663 times

This is normal you get a redundant constraint when adding a radius to the top left corner as it over-constrains the sketch along the Y axis.

Was talking to chrisb.

[uwestoehr]

You should attach the new sketch to XY plane just as you did with the original one, and move it per expression in Z direction to -Pad.Length. That would make your model much more robust and CarbonCopy would work as well.

Many thanks this works!
Nevertheless I don't understand why the CCing resulted in an unresolvable state with my method. I understand now why the mirroring occurred but not the error with the unresolvable sketch result. I just want to assure that there is not a bug in the CCing code that might affect me or other users in other occasions.

Offtopic: Concerning toponaming, this is in my opinion THE only field where FC is not yet ready for a 1.0 version. That the numbering of edges and faces are random is a nightmare : For example I know that I should insert fillets at the very last but in real live I often have the case that I have to cut into fillets. Changing such parts is a nightmare because almost every change changes the edge numbers, then the fillet is either broken or at the wrong edge and then the cuts and evolves are all broken and I have to invest 5 minutes again and again to repair my model.
Besides toponaming I can say that FC 0.18 is absolutely ready for production use and I use it already at work for my daily design work.

[openBrain]

It can't be normal, because I can constrain it after pulling the arc. Please note that I had removed one DOF and the radius should add one again.

Took some more time and .. you're right. My mind goes wrong. Basic math applies and 1 DoF can replace another. Sorry for noise.
But there is indeed an interesting bug in the solver that falsely detects redundant constraints. It seems to happen when 2 curves are tangent by design but not by constraint.
To demonstrate, take the basic sketch below (notice arc and top line are not constrained tangent) :

sketcher_bug.png (13.79 KiB) Viewed 1653 times

Delete the 2.5 mm constraint and add a radius to the arc => Solver (falsely) finds a redundant constraint
Reset the sketch to initial state, change the 4 mm constraint to 3 mm, then do the same as previous step => Solver (correctly) finds a fully constrained sketch

Wait for a confirmation to open a ticket.

[abdullah]

Nevertheless I don't understand why the CCing resulted in an unresolvable state with my method.

You don't and for good reason. It is a bug.

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

[openBrain]

You don't and for good reason. It is a bug.

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

Do you think it's the same bug as the one I described just above your post, or should another ticket be filled ?

[abdullah]

You don't and for good reason. It is a bug.

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

Do you think it's the same bug as the one I described just above your post, or should another ticket be filled ?

No, it is another bug. Yes, please, file it. This one against the solver project (GCS project).

There are some files which are failing and it is good to have examples for two reasons: To help fix the problem and to make unit tests out of them, so that once the problem is fixed we avoid reintroducing the problem again with another "fix".

[jmaustpc]

To demonstrate, ta

If you post the file as well as the screen shot, we could get a better idea of what you are talking about.

[openBrain]

If you post the file as well as the screen shot, we could get a better idea of what you are talking about.

I know it Jim. But this time I inadvertently closes FC without saving. Given the sketch simplicity, I guessed the screenshot should be enough.

[jmaustpc]

If you post the file as well as the screen shot, we could get a better idea of what you are talking about.

I know it Jim. But this time I inadvertently closes FC without saving. Given the sketch simplicity, I guessed the screenshot should be enough.

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.

[uwestoehr]

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 can help out since I can reproduce the issue, see attached an example file:

Constraint-bug-test.FCStd

contraint test

(9.62 KiB) Downloaded 45 times