Changing Dimension in Master Sketch Breaks Sketches with Associated Shape Binder Dependencies

[topher217]

I'm trying to make a part in Part Design based on a master sketch workflow (i.e. I have multiple bodies that depend on the dimensions set within some master sketch).

An idealized model tree would look something like:
Document
MasterPart
Master Sketch
Body1
Body2
...
BodyN

where Bodies 1-N have some sketch that depends on a Shape Binder build using the Master Sketch.

First off, is this a legitimate workflow in FreeCAD or advised against for some reason?

Whenever I change the dimensions of something in the master sketch I would assume the Shape Binders and Bodies in turn would all update to reflect these changes. For some reason when I modify these dimensions the Shape Binder seems to update, but the sketches in the Bodies break. By "break" I mean the following is produced in the report view:

14:55:28 Updating geometry: Error build geometry(5): Both points are equal
14:55:28 Invalid solution from DogLeg solver.
14:55:28 Updating geometry: Error build geometry(5): Both points are equal
14:55:28 Invalid solution from BFGS solver.
14:55:28 Updating geometry: Error build geometry(5): Both points are equal
14:55:28 Invalid solution from SQP(augmented system) solver.

and the sketch in the Body shows an error icon with tooltip stating "Solving the sketch failed". If I open the sketch I see "Undefined degrees of freedom. Unsolved (0s)."

I originally encountered this in a more complex part file, but I made a copy and reduced it down to just a single body, master sketch, and spreadsheet in which I can recreate the issue with the following steps:

1.) Open test.FCStd
2.) Open the Spreadsheet and change the PuckRadius value (cell B10) from 70 to 60 and press enter/return

You should now see the errors I quoted above. Now note, that in the more complex part this sample test came from, a LOT more things break, and when I tried to manually fix them all it didn't really make sense to me what was the root for all this breakage. I'm hoping someone here can enlighten me as to what is causing this to break, and how to avoid it with either a different workflow, or by some other fix to my existing workflow.

I've also attached the dependency graph both before and after the breakage in hopes someone can reference an object that is being renamed or something along these lines before/after the dimension update. I'm not seeing any difference though.

Also if it matters, I am making coincidence constrains between end points in the "Sketch004" to the endpoints of the lines defined by the ShapeBinder. If other types of constraints work better for this workflow, please let me know.

System Details:
OS: Ubuntu 20.04.2 LTS (ubuntu:GNOME/ubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24291 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 0.19.2)
Hash: 7b5e18a0759de778b74d3a5c17eba9cb815035ac
Python version: 3.8.8
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)

[topher217]

After messing with several other ways of constraining things I noticed in this video at time 9:39, he mentions that one should not reference lines, but points (vertices):

https://www.youtube.com/watch?v=2Yee1pSqTLg

So I tried that, and didn't resolve my issue, but it did help me locate what seems to be the core issue.

See the two screenshots attached. I'm changing the dimension of the horizontal line, but highlighting the bottom right vertex before and after this change. Note the name of the green highlighted vertex in the master sketch in the python console in the bottom right. The name can be seen to be Vertex2 in the unbroken state, and Vertex4 in the broken state. So it seems redimensioning a sketch changes the names of each vertex?? Wouldn't this break anything using a Shape Binder based on a sketch? With this in mind, does anyone have a proper work-around or how to use a master sketch workflow?

[topher217]

It seems I have found a workaround, but I'm still not certain if this is intentional behavior or a bug.

I simply replaced the Shape Binder with a SubShapeBinder and the model does not break when changing the dimension of the bottom horizontal line. I note that the names of the vertices in the master sketch still change every time I change the dimension, but somehow this does not affect the Body Sketches ability to resolve the coincidence constraints with said vertices. Not sure why this works, so eager to hear why and if this is just my hacky workaround or if this is intentional, and if so why.

[topher217]

Just tested one more thing. If I make a sub-object shape binder of the original binder, it works. Attached model with this configuration. Maybe this enlightens someone more familiar with the inner workings of FreeCAD than myself.

[chrisb]

After messing with several other ways of constraining things I noticed in this video at time 9:39, he mentions that one should not reference lines, but points (vertices):

Sounds like another video that the world didn't need. There may be a tiny size advantage when only a point and not a line has to be stored, but that's all I can imagine.

[Roy_043]

The name can be seen to be Vertex2 in the unbroken state, and Vertex4 in the broken state.

We have seen this before. IMO it is a major issue. I'd really like to know why this happens.
See:
https://forum.freecadweb.org/viewtopic.php?t=58221

[Shalmeneser]

This video is not so bad, but I would select lines instead of vertex (really easier).

[GeneFC]

The master sketch should not be changed except in really essential cases. The master sketch is subject to TN issues in the same manner as any other predecessor element.

The "master" of master sketches, at least as shown on the forum, is user ppemawm. See his detailed explanations at https://forum.freecadweb.org/viewtopic.php?f=24&t=48473.

Gene

[Roy_043]

The master sketch should not be changed except in really essential cases

That sort of defies the purpose of a master sketch IMO. I thought the often advised master sketch workflow would NOT suffer from the TNP. I am surprised that it does.

[chrisb]

I thought the often advised master sketch workflow would NOT suffer from the TNP.

And indeed it works well in most cases, when nothing is deleted in the sketch. But "most" is worth nothing, if we cannot clearly identify the cases where it doesn't.