Is it expected that a C2 sketch relation has no affect on an arc?

[ryan-feeley]

Hi everyone,

I run across this periodically. Does anyone know if there is an open SPR on this that I can vote on?

The illustrated sketch has a "generic spline" converted entity (black) that was originally a conic in the parent sketch. I'm trying to use that to drive the curvature of an adjacent arc (to the right of the converted entity). It doesn't work, which I forgot yet again. The relation is added, but it has no impact on the curvature (equivalently the radius) of the arc.

It does work fine for controlling the end-point curvature of the degree-two style spline to the left of the converted entity.

Generally when the sketch solver fails, you can work around it by just deleting the failing one and re-creating it, structuring the order of relations in the sketch across multiple sketches, or dragging the geometry to be "close" to give the solver a better initial condition. For example, see Updating equation receives error 'A Solution cannot be determined for this sketch'.

Spline to control an arc isn't explicitly called out as a supported feature in the help, so not allowing the relation would be ok. However in this case, rather than the solver failing the sketch, the relation is added and then simply ignored.

This example was created in Swx2022.

For my purposes, I don't actually need a circular arc. A quadratic bezier curve is fine, so I'll use that. But I prefer the software remind me that it doesn't work with arcs so I don't have to catch it manually.

[matt]

I don't think it's reasonable to expect the curvature of an uncontrolled spline to drive the curvature of an arc. There is no curvature control on the spline. Plus, the arc length dimension just complicates things. Even if someone did write an SPR on this, I don't think it's a reasonable expectation for software like SW. It would be reasonable for the arc to drive the spline, and I'd be willing to bet that's what's going on. There's no way to drive any sort of hierarchy within the sketch that I know of.

If there's some specific reason for taking this path, it might be better to come at it a different way.

[ryan-feeley]

Thanks Matt,

The (driving) spline is a converted entity. So it isn't really an "uncontrolled spline". It is fully defined -- it arises as a converted entity from a fully defined conic in an upstream sketch on the same sketch plane. Solidworks just converts conics into splines for whatever reason.

I'm not really arguing that this use-case be supported. I can go either way. But I don't think the software should provide the C2 relation as an option, allow me to apply it, and then ignore it.

Solidworks does allow the curvature of that converted entity to control the end-point curvature of the style spline in the left of this sketch. So they are ok with the concept of using parent splines to drive curvature of other entities.

This was just created as an example to illustrate something that surprises me periodically. I explored a little further, and the following cases work as I expect:

• Applying a C2 relation to control the curvature of an arc directly using the conic in the parent sketch
• Applying a C2 relation to control the curvature of an arc using a style spline in a parent sketch
• [EDITED] Applying a C2 relation to control the curvature of an arc using a generic spline (non-rational) that comes from convert entity on a style spline in a parent sketch. This doesn't work either. When you create the relation, the arc curvature changes to match that of the generic spline end-point. However, the relation isn't maintained. You can separately define a different arc radius, and the solver is happy to again ignore the C2 relation.

So it appears that you cannot use a converted entity or intersect curve (both which produce a generic spline) to control the curvature of an arc if the converted entity results in a generic spline and is in the same sketch. You can apply the relation, but it doesn't do anything.

If you actually what do to this (and I don't disagree with Matt that there might be a better approach), you can do it by splitting across two sketches. Do the convert entity / intersect curve in a separate sketch, and then apply the C2 relation to the arc in a new sketch.

[gristle]

Splitting it across two sketches is something you need to do sometimes when using 3D sketches as SW will add a G2 constraint to a style spline, however no constraint exists as you can drag the 3rd CV around at will, which is the CV which is constrained via G2. Instead, the reference geometry needs to be defined in a sketch prior to the 3d sketch with the style spline, in which case the constraint works as expected.

Predefining tangent references (normally use a perpindicular line) in a sketch prior to a sketch with a style spline is something I have to do quite a bit. Like when you have a sketch that always fails when changing something above it in the tree and all that is needed to fix the sketch is deleting and reinstating a tangent constraint.

[Arthur NY]

There's a difference between a work around and functionality that should work as intended. This seems to fall in the latter category even if it does fall into the barely used case.

I know the 2D and 3D solvers are licensed for use in Solidworks but I do often wonder if either the programmers at Siemens or Solidworks ever actually make more just squares and boxes. I get it, the roots are in engineering, but there's just been next to nothing that's evolved at all in this area. Even when G3 was added for a sketch constraint it was so finicky the conditions that it could hold without either not working or blowing up later.

That the limitations in the 3D Sketcher that existed 15+ years ago are still not available functionality is just sad. And over the years trying to report this as a "bug" they'd tuck it away and put it on the back shelf and collect dust. It's just not a priority to push forward and bring much new.