The Freeze Bar

I spent four years working for Solid Edge because I thought that the Synchronous Technology that they employ has a good chance of being able to replace history-based schemes. Sync has a lot of advantages compared to history, but for some reason, it just hasn’t caught on. Sync is simpler, gives you more control, eliminates parent/child stupidity in models, and doesn’t even have the concept of “rebuild time”. Moreover, the way ST is implemented in Solid Edge, you have the choice of mixing methods, so you can do part of your model in Sync and part of it in history. There are a few feature types that are still better in history.

It’s frustrating to me that Sync hasn’t caught on, even with a majority of SE users, even though its benefits are clear and have been well demonstrated.

The way you combine modes is that the software puts the Sync model first in the tree, then follows it with history-based (ordered) features. It’s similar to how SolidWorks puts an imported body at the top of the tree, and then you can add features to it.

Sync still has the concept of “features”, but they are really just a collection of faces instead of a sketch and some process. And that’s the part that’s interesting to me today. If you make an extrusion in Sync, the software assigns the faces created by that feature to an item it keeps in the tree. Because the feature is a collection of faces and not a sketch and a process, order doesn’t matter. The faces are all that matter. Process is order dependent. So from all of this, you can take the idea that Synchronous features are essentially collections of faces.

How does that tie in to the SolidWorks Freeze Bar? The Freeze Bar comes down from the top, so it creates a set of features at the top of the tree that theoretically becomes static, or frozen. Conceptually, stuff at the top of the SW tree should be the most stable – the least changed. So in this way, the Freeze Bar is starting to make SW work like Sync, because remember that the Sync features are kept at the top of the tree.

Maybe now would be a good time to describe why you might want to use the Freeze Bar in the first place. In history-based workflow, some features rebuild when you open a part. In some parts, this can take a long time and possibly lead to errors. Despite all the noise you hear from people, designs aren’t always well-planned. The design process itself can be chaotic, and full of change. The only way to really have a well-planned model is to reorganize it once it’s done, which is like doing a test run, and then finalizing it. This kind of thing is only viable when the model itself with all of its process-based planning is really what’s important, rather than the geometry. Like you make a practice model, and then the final model. Often people live with the imperfections of the originally designed model because it’s the geometry that counts, not how you got to the geometry. So the Freeze Bar can cover over a multitude of sins in that respect. You’re done with the parametric changes, and you just want what you have to stay the same.

To me, the Freeze Bar is an admission that the history-based scheme is only useful up to a certain point. After that point, change is actually a liability, and for some reason, you need an external tool to clamp the model down rather than being able to trust the process. The Freeze Bar is a manufacturer implemented work around for all of the accidental or unintended changes that you can get with history-based modeling. And I don’t think it’s an accident that it functionally looks and is supposed to act like the Synchronous section of the tree in Solid Edge. Even if users don’t recognize it, the developers at SW seem to recognize that the Synchronous/Ordered duality has some real merit.

In history-based modeling, the intelligence is in the model, and it can regenerate at any time. In Synchronous, the intelligence remains in the software, ironically the model is called “dumb”, which allows you to control the changes more deliberately (and also has the happy side effect that you can change imported data almost as efficiently as native data). This makes changing an imported dumb model easy, since you can’t add smarts to imported data without rebuilding it.

There are a couple of things to be aware of with the Freeze Bar. First is external references, and I’m just going to use the Insert Part feature as the example. There are other external reference types that work differently, but in this article I don’t have time or space to chase all of them down individually. You can insert a part lower in the tree, but usually an inserted part is the first feature, so if you use the Freeze Bar, an inserted part is often one of the first things that is frozen. If the parent part changes, it prompts a rebuild symbol (flag) in the inserted part, which is frustrating for a couple of reasons.

The first reason for frustration is that SolidWorks users are notoriously flag-phobic. You don’t want anything with yellow or red in the tree, because that tells people that you’re doing sloppy work, and have errors in the data.

The second reason for frustration is that the rebuild symbol is frozen in a section of the tree where you’ve used the Freeze Bar, and the data is supposed to be static. Rebuild symbolizes change and Freeze symbolizes not-change. Frustrating contradiction.

Anyway, the SolidWorks Freeze Bar is a tool that has been around for 5 years or so, and definitely has a place in helping users keep their models stable, but it is an officially sanctioned workaround for the conceptual miscalculations of the history-based method. If you have read this far, you’ve obviously got an interest. I recommend that you research the Synchronous Technology method further.