Dezignstuff SolidWorks Blog

If you’re the kind of person who needs to have things perfectly nailed down and defined, you might possibly be better served by some other blog. I sometimes get involved in conjecture, which means that I’m looking for facts rather than presenting facts. It seems there are a few people out there who do not understand the difference, or don’t accept that conjecture is a valid pursuit.

Anyway, you’ve been warned.

We’re closing in on it. We’ve talked about several topics surrounding the Direct Editing craze that is making its way through the blogger, press and analyst circuit. Users are not silent on the issue, but what they have to say so far sounds relatively uninformed. More on that later. For now, on with the show.

From a previous post, history modeling brings advantages as well as disadvantages. There is both downside and upside when you separate history from the rest of the attributes that we normally associate with history modeling. I think we tolerate history modeling primarily because we don’t know anything else. It isn’t clear to me that history modeling is necessarily the best way of looking at all types CAD models. This is all I’ll have to say about history modeling for this post.

Parametrics, on the other hand, I think has clearly demonstrable advantages. The ability to make geometric relations, using equations, dimensions, etc. This is the kind of thing we use to establish “design intent” or an “intelligent model”.

What interests me today is if you can separate parametrics from history, and if you can, what would the result look like? What is parametrics? It’s just the use of “parameters”, right? We have come to think of “parameters” as dimensions, numbers (for patterns), equations, relationships, stuff like that. So what if you took that stuff and just attached it to the finished model? Is there any reason why you can’t attach dimensions and relations to the finished model instead of to sketches and in dialog boxes?

If you look at SolidWorks, you can put dimensions on the finished model, but they are driven dimensions, reference dimensions, they just measure, they don’t drive. I understand the interface for doing this doesn’t exist within SolidWorks, but let’s just say that you’re God for the moment, ok, maybe not God, but at least the head of a talented bunch of programmers, and you can do anything. Is there any logical reason that would prevent you from applying dimensions to a 3D model, and when the dimensions are changed, the part geometry changes to match? It’s such an obvious thing to do, why aren’t people doing this?

Let’s do a little homework. Just assume for the time being that you have a fully “intelligent” SolidWorks model in one window, and in another window, you have that same SolidWorks model, exported as a Parasolid and reimported. The reimported file is what is commonly known as a “dumb” solid. It is imported. It has no features or sketches. It is dumb because you can’t edit it. So right there, side by side, one imported and one native, the same geometry, but one is intelligent and the other is not.

The funny thing about this is that the final geometry, the Parasolid body, is described inside the SolidWorks file in exactly the same way. So the finished model is exactly the same, regardless if it is imported or native. Let that sink in. I believe it’s true, or close enough for our purposes.

SolidWorks currently has a feature called Move Face. It enables you to select a face or set of faces from a solid or surface model, regardless of how the face was created and translate, rotate or offset the faces. This tool has limitations, and the interface is comparatively primitive, but it works, and it works on both native models and imported models.

There are some aspects of the Move Face tool that are kind of funny. First of all, it is essentially a direct modeling tool being used inside a history-based modeling scheme. It creates a history-based feature which resides in the feature tree, and is rebuilt along with the rest of the features. I wrote about this contradiction over a year ago in a post called Stepping outside of the parametric feature-based paradigm with SolidWorks. (If you read that post, it might look like some of my ideas about this have evolved over the last year and a half, and there’s a reason for that – because they have.) There are all sorts of best practice concerns about mixing history-based paradigm and direct editing methods. I’ve heard some top users say bad things about using Move Face, calling it sloppy practice and worse. I don’t disagree. But the fact is that it works, and when it works, it typically saves you a lot of time when compared to the monkeying around that you would need to do in order to do the job “correctly”.

I used to spin my wheels a lot trying to follow arbitrary rules. It took me a while to realize that it is better to have rules you can live with than to just follow rules because they are there. I think the same applies to this Move Face functionality. History-based best practice rules declare that Move Face is an abombination, sloppy, hack-and-whack modeling. So try to imagine a set of rules where saving time and brain power is a good thing.

Just think that if the Move Face interface were improved, and instead of it working through a PropertyManager dialog box, instead you were just able to put a dimension on the model and make changes, think of how convenient that would be. You wouldn’t have to mess with the feature order, or the FeatureManager or parent/child relations. You wouldn’t have to worry about other features failing. This would just be the interface change because the inner workings of the software using the Parasolid kernel to calculate the geometry would still be the same.

So, do you still think that parametrics can’t exist without history? Here’s the kicker. I already knew the answer before I asked the question. The answer is yes, parametrics without history can and in fact does already exist. Check this out:

This model was created in SolidWorks, by the way, but it really doesn’t matter. This is just a teaser. And no, I didn’t use any demo jock voodoo on this. It is just what it looks like it is, putting dimensions on an imported model, and changing the imported model.

There I hope that puts that one to rest. For now you’ll have to trust me that you can do geometric relations as well as dimensions, but if you watch you can see the sides of the rib that are tangent to the top cylinder change when the outer cylinder gets bigger, so it is maintaining tangency, which is done in the Live Rules panel in the upper left. You really can’t see that, but it’s there, and can be either added to or disabled according to your needs. Really, the video just scratches the surface. You’ll see more of this from me in various places.

Thanks to the  comment from Dale Dunn from the previous post for pointing out that the main problems with history modeling are really with the implementation. It is possible that other implementations of history modeling don’t have the same problems.

With new modeling paradigms (or old paradigms with new interest) out there, history modeling is going to have to prove that it is up to the challenges of the 21st century. In order to do that, it is the old “evolve or perish” mantra. History modeling has value, but does it have more value than other ways of doing things?

Let’s assume that the history-based idea as implemented in SolidWorks causes some inefficiencies. Let’s say that we don’t want to throw away the whole idea yet, we just want to update it so that it fits users needs rather than some developer’s fixed idea of what history-based modeling “should” be, or an industry tradition. How would you fix SolidWorks history modeling if you could?

Straighten the tree

The first thing that I’d do, and I’ve suggested this before, would be to completely straighten out the feature tree so that it can be shown as a straight history list without any of the counter-intuitive twists added by the reverse dependencies exhibited by how features vs sketches are shown (child on top, parent indented underneath). I’d also want to be able to manipulate the features in this state.

SolidMap-like display

For a while there was a product called SolidMap. I’m not sure what happened to it. I gave it a rather bad review here, but that post isn’t available anymore. Here’s a review from Jeff’s Blog. Again, a lame implementation of a great idea. It graphically showed relations between parts or features. In order for model history to be a useful tool rather than a millstone around your neck, you need to have options like this.

With these two ideas, straight tree and SolidMap, I would want them to be options in addition to the current scheme, not replacements.

Freeze features

The second thing I’d do would be one of the ideas suggested by commenter Kevin Quigley. You really need to be able to freeze all or a portion of the history. To some extent you can already do this by using inserted parts, which is a technique I’ve used to cut down on rebuild times by segmenting the rebuilds, but it is more than a little clumsy. It sounds like this is the same technique commenter Charles Culp is talking about. Let’s say you could just make a folder and freeze the features in that folder. SolidWorks uses Parasolid body data to represent the content of the frozen folders, and integrates the active parametric history-based data with the frozen bodies.

It may or may not be obvious, but SolidWorks data in the end is just dumb Parasolid body data. SolidWorks makes a dumb body intelligent by updating it using the parametric relations and feature definitions. It gives you detailed control over all the geometry, but it also implies the need for a feature order, which is where we get history from.

Manual rebuild

Similar to the freeze features idea is the idea that the user should be able to tell SolidWorks when to rebuild instead of automatically rebuilding whenever you twitch. And maybe the ability to rebuild only portions of the tree would be nice too. There might be some limitations, such as if you froze a child, it’s parent might need to be frozen as well. Anyway, some things in the current implementation of rebuilding just don’t make sense, like rebuilding when suppressed or failed features are deleted or reordered, or when features with no children are changed. The biggest case against history modeling is the rebuild times. There are a lot of low-hanging opportunities for SW to improve things in this area.

This would include suspending rebuilds when exiting edits to sketches and features. Maybe even allowing the user to go directly from the sketch to the feature PropMgr even for an existing feature (without the intermediate steps of exit sketch and enter feature).

Limit saved data

What kind of data is really in SolidWorks files? If you have configs, SW stores parasolid data for each config. Plus it stores display data, not just 2D thumbnails, but 3D tessellation as well. Some versions saved parasolid data for rollback states. 3rd party data can be put in, Cosmos, CAM, Photoworks, etc… All of this stuff is put in there for a reason, but is it really a reason that matters to you? Does something else matter more? I’m sure there is a lot of stuff in there that users don’t care about at all. Applications like Eco-Squeeze are officially panned by SolidWorks, but they strip out much of the unused or onwanted data. Why can’t SolidWorks allow users that type of control, instead of forcing on us one-size-fits-all data bloat?

It’s understandable that it is faster to read data than it is to recalculate it, and that hard drive space is cheap these days. Unfortunately, those ideas don’t completely represent the range of users concerns. Transmit time for people who work across vpn or ftp is a big consideration. Tons of people work remotely in this age, and when you don’t have unlimited bandwidth, file size, especially the file sizes we have grown to expect from SolidWorks, can become a problem.

=================================

I know these suggestions mean that users would have more control because they limit the automation of the software, which seems to be opposite to the current trends at SolidWorks, but hey, we’re dreaming, so we might as well go all out. Having a wider user base does not just mean that they have to dumb down the software and automate everything, I think if they are going to avoid alienating power users, they have to consider higher levels of functionality and user control.

In all of this, we need to keep in mind that Catia V6 is around the corner. Wikipedia points out that the V6 kernel is based on direct editing (in the Future Implementation section). Of course I don’t have any type of real information from DS on this, but I expect it to apply some lessons learned to the Synchronous Technology scheme. It remains to be seen what if any functions from V6 will be pushed down into SolidWorks, but I expect that to compete with Solid Edge, coupled with the newly chummy relationship between SW and DS, SolidWorks will shortly get a V6 make-over.

While assembly and drawing documents get faster by SolidWorks using clever tricks (lightweight, configurations, SpeedPak), the part documents just get slower due to automation bloat.

How would you update history modeling in SolidWorks? This is a collaborative effort, leave your ideas as comments.

As a prelude to comparing history-based systems to other types of modeling systems, I want to try to spend some time thinking about history-based systems on their own. Specifically, I want to see if without comparison to anything else, the idea of modeling something based on the software sequentially rebuilding geometry from a recipe has any gaping conceptual flaws.  Most of us have lived with this system for years now, whether it is SolidWorks, Solid Edge, Inventor, Pro/ENGINEER or one of several others. I find it is difficult to be objective about it because I’m admittedly too close to the topic to have much perspective. But unless you don’t use anything regularly or are switching regularly between radically different CAD packages, you’re in about the same boat as me.

If you think back to when you were first introduced to SolidWorks, can you still remember the new concepts and vocabulary you had to learn? You’ve got terms like history, feature-based, parametric, associative, solid and surface modeling, and so on. As I remember it, none of this was particularly intuitive. I thought it was cool once I understood the process, but that’s the first thing to be aware of: that history-based modeling involves a process.

Something that has been slightly mind bending for me is trying to separate history-based nature of contemporary CAD systems from those other buzzwords. For example, can you imagine a CAD scenario that uses parametrics, but not history modeling? How about using features without history? Those concepts may be difficult to imagine if you’ve lived in a history-based world for your whole professional life, but we will get around to having a look at those things. For now, I just want to extract the history part of it and look at that by itself if possible.

If you think about what part of the modeling workflow exists specifically because of the history-based nature of SolidWorks, you think of things like:

• FeatureManager
• reordering features
• rollback
• rebuilds, including waits and errors
• parent/child relations

If your experience was anything like mine, when you were first introduced to history-based modeling the topics above weren’t easy to learn. I know I’m constantly doing battle with each item on the list, even after studying history-based modeling for the past 14 years. I frequently refer to the conflict between draft, fillets and shell as “rock, paper, scissors” (the game where each option can either win or lose depending on what the other player chooses), which is primarily due to the effects of feature order, one of the by products of history modeling.

The main difficulty associated with history-based systems has to do with the fact that the process involved with modeling becomes very important. That’s why people say history-based CAD requires a specialist just to understand the modeling process. There is a lot of validity to this complaint. Getting the right process for different types of models is sometimes tricky. We have become familiar with the term “best practices”. What if there were no such need for best practice, because the only thing that mattered was the final product, not the process by which you arrived at the final product?

How about accepting the idea that the model you really want is the finished model, which is just a set of boundary representation (b-rep) faces created by the software. Do you really care how you got to the finished model, or do you just care about the model itself? Lists of features are one thing, but does (“should”) it really matter what order those features were created in?

If you have ever struggled with parent/child relations between features or feature order or broken relations due to features removed or added while in rollback, you have experienced some of the difficulties induced by the history-based nature of the software. Most of us just accept this as part of the price of waking up in the morning and using history-based 3D CAD software because we don’t know anything else.

To be fair, there are also some advantages of history-based modeling. For example, fillets. Whether or not a modeler remembers the order in which fillets are applied, the effects of applying them in a particular order can be seen in the resulting geometry. A history-based system enables you to deliberately alter that order. It turns out that fillets are simultaneously both a strength and weakness of both history and non-history modelers. This seems like a contradiction, but at the end of this series of blog posts, I hope you will agree with me on this point.

So, like the rest of life, history-based modeling has its pluses and minuses. It is a system that has served us well for a couple of decades, and most of us have been able to figure out how to use it profitably in our businesses. However, there are enough examples of painful experiences around working with history-based systems to consider if there might be some viable alternative out there. That’s what the next blog entry will be about – alternative modeling paradigms.

The name Relationship Counseling is of course playing off of the marriage counseling bit, and is doubly funny to me, thinking of my self as any sort of relationship counsellor. “What, she won’t let you spool your fishing reel in the living room or clean fish in the sink? Time to move on, buddy!” “No, you can’t come fishing with me, I’m trying to catch fish, not look at the flowers!” Yeah, I can see myself not being too successful in that field.

The other funny part of it for me is thinking about all of the double meaning stuff that we just ignore in the SolidWorks phraseology lexicon. You know, the stuff I wrote about in my “Stuff you can’t say in public” post. I can hardly keep a straight face ever since I wrote that one.

Anyway, relations in SolidWorks are almost as complex as they are in real life. In this post I’m talking mainly about sketch relations, although you can apply the same principles (and the same double entendre jokes) to assembly mates.

When you have to transgress the dogma

Sometimes you just can’t follow the rules. Think of Horizontal Modeling as a set of best practice suggestions. Best practice is typically a set of rules that you follow when you can, but the rules often contradict other requirements that you have to follow, so you have to make choices. Most of what I’m going to talk about in this part is what to do when you can’t make sketch or feature relations to layout sketches, or stable reference geometry. Sometimes you simply have to reference an edge at the intersection of two faces, and there’s no way around it.

The kind you can fix and the kind you can’t

There are two kinds of sketch relations in SolidWorks, the kind you can fix and the kind you can’t. When you are talking about durability through changes, the ability to repair relations is really key. Sketch relations that you can’t fix are:
- Pierce
- On Edge
- Offset
- At Intersection Between Two Faces
- Patterned

… along with maybe a few more. The idea is that if your model depends on relations like these, and you make a change such that the relation fails, you can’t repair it, you have to delete and recreate. When I used to teach SolidWorks to a lot of new users, I was fond of saying “Delete is not an editing option”. Again, a dogma you can sometimes afford and sometimes not.

The way you select something matters

If you select a face and convert entities or select edges individually and convert entities, you get different results. When a face is selected, it is really selecting a parametric outer loop around the face, so if something happens to change the boundary of the face, the loop selection updates. If you select individual edges and something happens to the boundary of the face, your selection loses an edge, and the feature may fail or get a warning. Remember loop selections can be done by selecting faces or by RMB on an edge. Each edge of a solid has 2 possible loops, you can use the little arrow to select which loop is selected.

Other stuff to remember

SolidWorks added the ability to use a sketch endpoint in the Up To Vertex end condition for extrudes a few releases ago (it used to be that you could only use a model vertex). This is very useful if you have created a sketch-based skeleton and are using a sketch to drive the length of a solid feature.

Remember also that starting a couple of releases ago you can specify the Start Condition as well as the End Condition of an extrude, so you can extrude starting 1″ from the sketch plane. This is handy if you want to avoid creating extra planes, but is kind of a hassle for editing because if you double click the feature, that offset value doesn’t display on the screen.

Up To Next and Up To Body are great ways to specify an extrude without using actual numbers, but remember also that this is the kind of relationship that can easily fail, while actual numbers fail less frequently.

One that burnt me just tonight is that when you have a sketch that was created way back in history, and a feature that was created at the end of the tree, editing the sketch is going to be a pain, because SW will roll the whole model back to edit the sketch. AND, and here’s the good part, you can’t reorder consumed features. Yippee!! So that’s delete and recreate time again.

Actually, if all you have is a sketch and that’s as bad as you have it, it’s not so bad. Absorbed curves can’t even be selected from the graphics window for creating sketch relations. Mature software? Ha! No way. At least not for non-block shapes. Remember the Rings Of Fire! You are ok in the center, but the farther out you go, the more likely you are to find uncharted territory. Unfortunately, robust sketch relations are way farther from the center than they should be.

Here’s what I want you all to do — run down to the SolidWorks Enhancement Request page and ask for a FeatureManager option that shows straight history, without absorbing sketches under features. And make sure they know to make it fully functional; if they try to put the steering wheel in the trunk again, well, simply tell them you believe that would be a mistake.

And for Part IV…

Part IV will be an example part driven by a Horizontal Modeling scheme using a sketch and reference geometry skeleton.

Why do SolidWorks users as a class of CAD users need more relationship counseling than, say, Pro/E users? The answer is going to sound sarcastic, but I honestly believe it is true. I think it boils down to an outdated modeling philosophy more closely related to ease-of-use marketing dogma than to best practice type suggestions. SolidWorks has always recommended a fast-and-loose approach in order to sell software, without regard for robustness through changes. SolidWorks has also become more and more error phobic, more intent on giving users ways to ignore or hide problems instead of ways to build models that don’t get the errors in the first place.

As usual, there is some history behind this story, and we hae to learn from history. Parametric Technology Corporation was the first to develop parametric solid modeling in a successful commercial product, known as Pro/ENGINEER. Parametrics was a new way of life back in the late 80s, and it was important for the company to deliver some modeling philosophy along with the tool. Pro/E has a reputation for being rather rigid in how it forces users to use the parametrics. Sometimes it is difficult to separate rigidity built into the software from the traditional usage or corporate dogma laid down through documentation and formal training. There was a reason for the rigidity, it was necessary to make models that held together through change.

Pro/E’s method was not called “horizontal modeling”, in fact, I don’t think it had any name at all. That name was a child of licensing wonks at Delphi eager to coin a phrase describing a technique already established by Pro/E users. Delphi used Unigraphics to develop their take on the process, and are clear to mention that it can be used with any parametric history based modeler.

Regardless of how or why, when you import a Pro/E part, you are sure to get a lot of what seem like unnecessary planes. This is because the Pro/E process includes making a “datum” or what we would call a Reference Plane for each sketch.

SolidWorks began winning out over Pro/E in the late 90s CAD wars by being easier to use (and cheaper). Pro/E imposed a lot of rules, but SolidWorks did not. Users predictably chose the path of less initial resistance. Pro users knew intuitively that there was a problem with the SolidWorks approach, but didn’t know how to articulate it. It turned out that Pro/E (the software) was like a good parent, raising good children by disciplining them. SolidWorks was a new age parent, and produced children who neither knew nor tolerated any discipline.

SolidWorks “best practice” ideas started to be spread at the grass roots level by users. SolidWorks corporate kept talking sales jive, and didn’t recognize the need for a change in the direction of the modeling philosophy that they asked people to buy into. When it came time to make changes to models, Pro/E models are better behaved because the model is constructed in a disciplined way that guarantees better success. SolidWorks models tend to fall apart when you start making changes beyond the simple, because the traditional SolidWorks technique taught to users through the corporate documentation and formal training advocates a “fast-and-loose” approach.

The real difference is that SolidWorks encourages you to sketch on faces, make references to solid and edge geometry, and build a chain of references. When you consider that each feature in SolidWorks is directly dependent upon the feature that comes before it, like the picture on the left. Unfortunately, when features are built this way, when one feature fails, all of the features dependent on the failed feature also fail. This is what the Delphi materials call “Vertical” modeling because the relationships are vertical.

By contrast, the horizontal modeling method looks like this when charted:

The “control data” here is either sketches or reference geometry (planes, axes, reference points). When a feature fails in this scenario, it doesn’t take other features with it. The references when charted tend to make a short, wide tree. I wrote a lengthy news group post about a year ago that descibes this a bit. Where I use the “wide tree” term, you could substitute “horizontal modeling”.

This concept can be applied at both the part and the assembly level, and is particularly useful for overcoming in-context difficulties. You can even use another part as the “control data”, with an inserted part in a part document or an envelope in an assembly.

The good news is that any parametric modeler can do this, Pro/E, Catia, Unigraphics, SolidWorks, Inventor, Alibre, whatever. You don’t have to model in a sloppy and lazy fashion, the way that SolidWorks teaches people to model.

The problem with this approach is that SolidWorks users are impatient. We are trained to think that modeling quickly is the ultimate good. You can’t do “wide tree” modeling as quickly as the “tall skinny tree”. It takes planning. It takes forethought. It requires discipline. It requires you to move your mouse and make more clicks. SolidWorks is trying to condition its users to be work-phobic, believing that you can not just model, but design with no effort, and that your work should be judged not by the quality of the final product, but rather by how much you moved your mouse and clicked. I think their modeling philosophy shines through in their software design. It is all getting that same plasticine sheen, the hallmark of a product banged out far too quickly without attention to details or quality. Think more Yugo than Pro/E’s Lexus. There is a price to pay for fast-and-loose.

You can’t just pick and choose with this method either, really. You need to implement it from the beginning with a part or an assembly. If you created a model using the “vertical” method, and then change your mind, it can be done, but depending on how many features you have it may be a load of work.

Ok, well, I’m going to have to extend this to a Part III. That will contain the techniques to use for selection of entities when you have to reference solid and edge geometry. This is the stuff I really wanted to post in the first place. All the rest of this is just a bit of fluff leading up to it. Interesting stuff. Come back tomorrow.

PS

In Part I I mentioned that someone at SolidWorks World this year is going to give a presentation on Horizontal Modeling. Matt Lorono (fcsuper) encouraged me to do a bit of research into who this was. This person turns out to be Elise Moss, the well known author of books on Autodesk products. Has Elise “changed teams”? She is asking a lot of beginner type questions on the SolidWorks Forums, so it looks like she is trying to learn the software. It’s not clear to me that someone with a few months experience on the software is going to be a valuable presenter of modeling techniques in SolidWorks, but with her writing background, maybe she has Inventor ideas she is bringing forward with her. Anyway, we shall see. Maybe someone could convince Elise to stop by and leave us a note here?