What is best practice for reference points on a face?

[esr]

Ruing 0.18.4 under PopOS 20.0.

I've had several problems recently specifying dimensions in a parametric design, one of which led to an expensively botched 3D print and all of which traced to the following problem...

When you start a sketch on a face of an existing 3D part, you don't automatically get reference points at the places on the sketch that coincide with the face corners. The only reference point available is the part origin, which often won't be coplanar with the sketch.

Instead, such local reference points on the face have to be constructed with tricky sets of constraints, which are difficult to write in a way that doesn't break if the dimensions of the underlying pad change. This bit me hard when I was trying to carve a lap joint near the end of a beam and changed the length of the beam.

Is there some way I am missing to define points at these face corners that will move with the corners if the face's substrate changes size? What is best practice in this situation?

[drmacro]

Sketch external geometry:

Part Design Shapebinder:

to name two...

[chrisb]

Hard to say without more details (file, images, FreeCAD infos). But you should definitely invest some time to get a current version running.

[ifohancroft]

I know this is probably not what you want to hear and it's not the solution you are looking for, but:

FreeCAD has the so called Topological Naming Problem.

Instead of creating a sketch on the face of a body/pad, create a datum plane that sits the origin plane, offset in the direction you want, using variables, then create the sketch on that datum plane. Then the sketch would also change when changing the parameters.

I.e. Let's say you create a 1 by 1 meter square as a Sketch on the XY plane, then you pad it, to make a 1 by 1 by 1 meter cube, that is symmetric to plane (i.e. sticks half a meter on top and half a meter on the bottom).

You'd set a variable (using a Spreadsheet for example) where height is set to 1m or 1000mm. So when padding the sketch, you'd use formula for the height, and set it to equal Variables.height.

Then, when creating the datum plane on the XY face, you'd offset it in Z direction by Variables.height / 2. Then create the sketch on the datum plane.

As for the reference points themselves, use the Create an edge linked to external geometry in the Sketcher.

[esr]

Sketch external geometry:

Part Design Shapebinder:

to name two...

Thank you, Sketch External Geometry appears to be eactly what I need to write more natural constraints.

[esr]

FreeCAD has the so called Topological Naming Problem.

I'm aware of this. I have read a lot of the documentation and watched at least a dozen tutorial videos, including one specifically on the TNP

I think in this particular case I am unlikely to fall into the renaming trap. All I'm doing is making a couple of pockets in a beam so that two copies of it can mate end-to-end via...it doesn't seem to have a standard name, but I think of it as a "handshake joint". It's a variant of a lap joint that is better against pulling stress - I invented it after watching some videos about Japanese carpentry.

Anyway, it's very simple. I understand why I may need to use the datum-plane technique in the future, but I don't think today is that day.

Since you mention it, I am a bit puzzled by the descriptions of the TNP I've seen. If I understand it correctly, it should be trivially solvable in this way:

1. Give every element a unique internal name that is never allowed to change and will never be re-used; make links using those.

2. Associate an external name with these, generated however you like. Users see only these.

3. When elements are inserted or deleted, regenerate external names but don't touch the true ones.

But perhaps I don't actually understand it.

[ifohancroft]

I'm aware of this. I have read a lot of the documentation and watched at least a dozen tutorial videos, including one specifically on the TNP

I think in this particular case I am unlikely to fall into the renaming trap.

Ah! I thought it may have been because of it that your Sketch wasn't changing with the change of the parameters but it seems I misunderstood.

All I'm doing is making a couple of pockets in a beam so that two copies of it can mate end-to-end via...it doesn't seem to have a standard name, but I think of it as a "handshake joint". It's a variant of a lap joint that is better against pulling stress - I invented it after watching some videos about Japanese carpentry.

It would be cool to see it in the FEM workbench to see how it behaves under different stress conditions.

Since you mention it, I am a bit puzzled by the descriptions of the TNP I've seen. If I understand it correctly, it should be trivially solvable in this way:

1. Give every element a unique internal name that is never allowed to change and will never be re-used; make links using those.

2. Associate an external name with these, generated however you like. Users see only these.

3. When elements are inserted or deleted, regenerate external names but don't touch the true ones.

But perhaps I don't actually understand it.

I thought the same thing. Unless we are indeed not understanding it, the solution does seem that simple. Especially considering that some names never change internally in some cases.

I can't remember whether it was for constraints or shape binders, but if you create a new sketch and it gets named Sketch027 for example, then you rename it to SketchWhatever, then do something with/to it, there are certain places where you can notice it is still being referred to as Sketch027.

[drmacro]

...

Since you mention it, I am a bit puzzled by the descriptions of the TNP I've seen. If I understand it correctly, it should be trivially solvable in this way:

1. Give every element a unique internal name that is never allowed to change and will never be re-used; make links using those.

2. Associate an external name with these, generated however you like. Users see only these.

3. When elements are inserted or deleted, regenerate external names but don't touch the true ones.

But perhaps I don't actually understand it.

I thought the same thing. Unless we are indeed not understanding it, the solution does seem that simple. Especially considering that some names never change internally in some cases.

I can't remember whether it was for constraints or shape binders, but if you create a new sketch and it gets named Sketch027 for example, then you rename it to SketchWhatever, then do something with/to it, there are certain places where you can notice it is still being referred to as Sketch027.

Clearly, if it was this simple, the issue would not have survived for years...

FreeCAD receives the internal names from OCC. OCC names them essentially sequentially. If, for example, an edge is deleted in a sketch the recompute of the model receives names again from OCC. OCC essentially starts the sequential naming over and previously generated geometry edge/s (etc.) may or may not reuse the same name (or even use a previous name for a new edge). So, later things in the model that are attached to the old name are now either not attached to anything or attached to the old name which represents new/different generated geometry.

[esr]

Hmmm. So I tried importing external geometry to make writing my constraints more natural, and everything seemed to go fine...until the pocket operation failed to pocket.

CAD file enclosed. Over at the left-hand end of the beam you can see the rectangle where I tries to puckewt it to make a lap joint, but the pocket operation doesn't actually carve anything out of the beam.

The screwy part is I've placed and executed this pocket before, when not using External Sketcher Geometry. Have I missed something stupid obvious here?

[esr]

FreeCAD receives the internal names from OCC. OCC names them essentially sequentially. If, for example, an edge is deleted in a sketch the recompute of the model receives names again from OCC. OCC essentially starts the sequential naming over and previously generated geometry edge/s (etc.) may or may not reuse the same name (or even use a previous name for a new edge). So, later things in the model that are attached to the old name are now either not attached to anything or attached to the old name which represents new/different generated geometry.

OK, then, this looks like a serious design error in OCC (whatever OCC is) that FreeCAD is trying to cope with and failing.

It's a very, very bad idea to destabilize and reuse reference names in situations like this. Which is not to say I haven't seen this kind of anti-pattern before, sadly. And I won't be surprised if I see it again...