I’m curious if anyone has suggestions for how to baby the Solidworks 2D sketch solver.
I have a sketch with a few style splines, some tangency and equal curvature relations, etc. Not the easiest sketch for the solver, but I bet we’re still talking well under 100 constraints. If I make the dimension circled in this image “driven”, the sketch goes from Solved to Overdefined.
We all know mathematically this is impossible. Removing a constraint doesn’t shrink the solution space. But it does change the numerical equations presented to the solver, and in the later case it fails to find a solution. It’s a weak solver and doesn’t appear to have improved since I was a child, but it’s the one we have. (I know D-cubed is actively maintained and has had almost 100 releases over the past 35 years, but it seems unlikely that Solidworks licenses anything remotely current – or has it actually improved without my noticing?)
I believe the best approach here is to break this sketch up into as many individual sketches as possible, so the solver gets smaller matrices each time. Does anyone else have any suggestions? I believe Arthur NY and gristle have opined on this topic before. I’m on Solidworks 2020.
Curvature, and even tangent, relations have always been a thorn in my side with solidworks. Randomly breaking on rebuilds, etc. I’m half tempted to come up with some syntax that describes the relations I want that the solver can’t consistently give me, leave them out, and write a macro that parses the syntax and positions spline handles where they need to be to achieve my design intent. I’m sure it’s harder than it looks, but computers are fast. I’ve had unreliable sketches that consist of a single style-spline bridging two entities which are fully defined upstream. So the boundary conditions are known a-priori and I just need to smoothly connect them. How hard can it be?
Have you tried Ctrl Q to force a regeneration? Removing a constraint should obviously not cause an overdefined state, so SWX is getting confused, as you’ve shown. I find I hit Ctrl Q a lot and it helps. Just maybe it will for your situation as well.
In this case it will not I believe, the overdefinement is caused by the geometry’s boundaries exceeding the model’s limits. The dimension ‘solves’ it for SolidWorks because it removes the need for the solver to go and analyze the extents of the boundaries.
When I get these kind of results, I try turning other dimensions that are linked to ‘driven’, to see how SolidWorks reacts. Sometimes it solves it and then you can analyze and see what was the cause.
Thanks Dennis, but unfortunately it does not help this time. I think CTRL+Q can help if a sketch involves converted entities or intersections (perhaps it dithers the numerics), but this sketch is just pure sketch entities and relations among them and relations to entities in prior sketches.
Maybe the first macro I write should just delete all tangent and equal-curvature relations in the selected sketch and reapply them. That’s something I find myself doing manually a fair bit. I’d prefer a workflow that avoids the problem, but the delete-relation-and-reapply process does work 90% of the time.
Thanks AlexLachance. That is a good diagnostic technique. I’ve discovered that if I make two of the lengths driven, the sketch again solves. However nothing “jumps” or blows up in the geometry. In all cases the values of these two dimensions are the same out to 10 nanometers.
If you go into display/delete relations in the sketch you can use the drop down box to show the dangling or over defined relations in the sketch. Usually I will delete these and then re add them. Most times I get these issues when an automatic relation is added that I wasn’t aware of.
This can be a real pain in the arse. As mentioned, a Ctrl Q can sometimes fix things, however I have found some dimensions changing (style spline length dimensions to CVs) by a small amount when using Ctrl Q.
I have found style spline failures when using the CC constraint are pretty much always caused by the tangent constraint that is automatically added. Delete the tangent, then reinstate and most of the time that works. If not, try adding the tangent constraint between the first style spline control polygon segment and the reference geometry instead. More reliably, add a line perpendicular to the end of the reference geometry, then make the first style spline control polygon segment perpendicular to the line (90+90 = tangent). By far the most robust method is to ‘pre compose’ the perpendicular reference in a sketch prior to the one that contains the style spline.
Thank you! That might just do it. Maybe the tangent relation gets confused (basically flipped and wanting the spline to go tangent in the opposite direction), while perpendicularity is numerically more robust for some reason. I’ll try for this case and report back.
I just had another look at your sketch. I normally pre-compose this type of sketch, where you have CC constraints on style splines that reference geometry within the same sketch, where the reference geometry has dimensions that move the end points of the style spline.
Another thing, the style spline on the left looks to be deg3 with 4cvs, plus CC constraints on each end. CC constraint needs three CVs per end to have each end being independent of the constraint on the other end, so I’d try changing these to deg5 bezier style splines, with 6cvs.
Yes, I expect this is part of what the solver is struggling with. I actually don’t want each end to be independent of the constraint on the other end. Effectively I’m driving the y-dimension of the location of the left spline endpoint via the location, tangency, CC relation on the right end point, plus a sort of arbitrary constraint that all three chains have the same length.
I’m intentionally reducing the solution space to a single solution (because I want this to parametrically update in a way I can predict). The solver can find that single solution (at least most of the time), but as soon as I make the solution set a “line”, rather than a point, by making one of the dimensions driven, the solver can’t find any solution. Making the solution set a “plane” with two driven dimensions, using AlexLachance’s exploratory approach, again allows the solver to find a solution.
I wish they’d give us a few more knobs to turn. Or just change the defaults. When John Owen originally published on this stuff in 1991 (so almost 35 years ago), it was understood that a “competent” graph-based 2D constraint solver (i.e., one that can always solve what is solvable) is gonna be slow in the worst case. It’s just math and there’s no free lunch. But we’ve had a 1000x improvement in single core processing since then. Just maybe could solidworks (or Siemens?) bias the settings a little more towards “competency” over “efficiency”? Or at least allow us to opt-in to a competent solver on sketches we as intelligent people know have solutions.
I haven’t tested the perpendicularity approach yet. I hope it is the magic bullet I’m looking for! A few hours after my initial post I broke the sketch into three sketches, one for each spline, and that has been working thus far.
This excerpt from John’s paper might actually be relevant here. Looks like I need to stare at the math of these constraints a bit and see if what I’m doing is “formally overconstrained but none-the-less consistent and solvable”. I think that refers to having redundant constraints (say adding both a tangent and perpendicular), but I’m not sure.
Maybe it’s time to discard or at least augment these graph-based solvers. They won in the 90s for being more efficient than iterative Newton-Raphson techniques and for failing in more graceful ways, but we have way more computational horsepower today. It seems that once a sketch has solved once, the solver should be able to cache the topology and enforce it going forward to avoid entities flipping and similar. But I guess that’s a lot of work, and probably no money in it. D-cubed has the monopoly.
From Owen 1991.jpg
I’ve never gotten into this computation-and-solver stuff, but splines in sketches in SWX have invariably proved unreliable (and often unpredictably unreliable).
It’s a typical issue to have a constraint or dimension that flags as overdefining or unsolvable, but when the “offending” item is deleted and recreated, everything is suddenly fine… until the next rebuild, then it’s rinse-and-repeat.
Building reference “steering helpers” as below will often reduce the agony, but usually doesn’t turn out to be a cure-all.
Any chance of seeing a curvature graph of the arcs and spline, when SW has solved the sketch? I have a feeling that trying to achieve a G2 connection on each end of a deg3 spline with 4 cvs, to arcs (of different radius) means the spline will have to drive the arc radius? Not near SW at present, so only a gut feeling…
that should be the case. Definitively nailing down all the CVs will also define the curvature, and the G2s will force the arc radii to follow.
I’ve had this sort of case before, and it worked better to have each piece in its own sketch. It wasn’t parametric paradise perfection, but it threw noticeably fewer wobblers on rebuilding (i.e. as compared to trying to have the whole chain in one sketch.)
We work with large radiuses to define the arch of our trailers and those large radiuses exceed the SolidWorks boundaries. Any changes to the geometry often throws an unexisting error if the geometry has not been defined in a specific way. Sometimes a relation can be replaced by something else to work around an “unexisting error”.
