CAD Forum

This is inspired by the excellent youtube video @Alin posted last April about the Unexpected Villains (originally presented at Solidworks World 2020).

In Crime #6, he warns about mixing design tables and equations. Based on my experience, this is just one example of a more general case of equations plus ANY other source of configuration data. If you have a design table, a config table, or just a configured dimension, any of these can interact poorly with equations.

I've attached toy example (created with SW2020sp05) consisting of two sketches and two configurations. Sketch one has a configured dimension, and sketch two has a length set equal to the configured dimension in sketch one.

Every time you switch between configurations, the "checkmark" will disappear from the inactive configuration. I would expect that the rebuild order would be deterministic and noncircular. Sketch1 should solve first (using the configured value), and then sketch2 should solve using the value from sketch1. Maybe it works that way under the hood, or maybe not, but in any event, the "body data" of the inactive configuration is marked out-of-date, so if you use this sort of workflow in a bigger part or assembly, you're in for a world of pain.

Looking at this a little more, it appears that if I mark the equation "configured" (but use the same expression for both configurations), that will resolve the issue. Marking that equation as "configured" must alert the internal data model of Solidworks that "hey, the value calculated by this equation" may vary across configurations, so expect that, and don't invalidate the other config just because it changes.

That little adjustment fixed everything. It feels a little like embedded systems firmware development, or something, where you need to mark as "volatile" any data that can change in ways unrelated to the execution of the current code scope, to prevent the compiler from making too many assumptions about them.

So here, you need to mark as "configured", any equation who's calculated result can vary across configurations. It makes a certain kind of sense, so I wonder if that work-around it might have worked in the example in Alin's talk.

This also seems like something that could be built into automated model checkers, or something. Just activate all the configurations, and see if the values of any equations that aren't "configured" ever change across configurations. Any takers from macro authors?

Here's another trivial SW2020 part file that uses an different approach from the OP to generate the same symptoms.

I made a sketch of a square. There is a configured global variable. The side length of the square is made equal to the global variable. When I switch configs, the previous config goes "out-of-date" (grey horizontal line, rather than grey checkmark).

The root cause is an equation the software is treating as "nonvolatile" calculates a different result for each config. This apparent inconsistency causes the internal data in the inactive config to be marked out-of-date. Such a scenario will cause perpetual rebuild headaches if multiple configurations of the part are included in an assembly.

The workaround/fix is the same as it was for the part in my OP. Configure the equation to indirectly tell Solidworks that the calculated result is "volatile", so it's fine if the value in an inactive config differs from the current value".

You can of course do this using either the equation editor or the dropdowns of the modify dimension dialog when editing the sketch.

Made an account just to say thanks for this. This issue has been driving me insane.

technical-des wrote: ↑Fri Dec 01, 2023 6:25 pm Made an account just to say thanks for this. This issue has been driving me insane.

Glad it helped! It's driven me insane at times as well. Which version of Solidworks are you on? They appear to have restructured equations a bit in 2021 but I don't think they fixed any core issues. The newer versions seems a little more trigger happy on flagging potential circular references. Probably a good thing since even if they aren't circular, the designer should know that there might be a solver efficiency issue.

Equations seems like such a good idea, but the implementation leaves a lot to be desired. I've seen the sketcher environment slow to a crawl if you have more than 100 or so. Linked equation files also seem to cause a lot of spurious rebuild issues. Let me know you have other questions or observations. There's so many places where Solidworks just doesn't work how it seems like it should and the limitations just aren't worth fighting.