Common Misconceptions

There are as many urban legends and crazy misconceptions surrounding the SolidWorks software as anything out there. There is a lot of apocryphal information which isn’t verified and is often simply wrong, or mostly wrong. I’m sure this is in part due to the lamentable state of the Help, and the astounding lack of any real definitive documentation about how the software is supposed to work. There is even some misinformation which SolidWorks Corp itself is responsible for disseminating.

I’ve always believed that technical content and details matter. It isn’t just who you are and how eloquently or forcibly you state your case that matters, it really does matter that the facts are correct. Is this silly and sentimental of me? Probably. The world has become so relative, it’s hard to tell if there is anything that is absolutely true anymore. My belief in facts is likely outdated and old fashioned.

Anyway, if you follow any of the major SolidWorks forums out there, you probably already know what I mean. Someone starts a rant, and that rant is based on what we in the business call a “PEBCAK” error (problem exists between chair and keyboard) – essentially a training issue, or more bluntly for anyone who still isn’t catching on, someone who simply didn’t know what he was talking about. And then of course anyone who points out the fact that he missed is just a shill, an apologist, a brainless corporate monkey, etc. The same scene plays itself out regularly in the wild wild west of comp.cad.solidworks, where it’s always open mic amateur night.

#1: Break Relations is better than Lock Relations

The first thing I want to mention directly that I see used or recommended again and again that is simply a really bad idea is the Break References option. I wish that option were not in the software. So many times you see recommendations from people who spell out their travails in the software in such a way that you are supposed to sympathize with their self-inflicted tale of woe and consider them an expert  because they have been there. Like the guy who made a 1500 part assembly where 40% of the parts were modeled in context shortly after buying the software. He went to “training”, which means the first Essentials class, not the one that covers in-context modeling, so he’s not just a dummy. Anyway, now that he has laid out his credentials and claims the respect of all readers, he says unequivocally that the best thing he ever did was to use the Break References option in those 40% parts. After doing that his assembly stopped rebuilding every change and the rebuild time went from 25 minutes to 15 seconds.

If your foot hurts, it stops hurting if you shoot yourself in the head. It’s the same brilliant logic, and just as useful.

Our hero here has other problems which were accidentally cured by actually making his problem worse. Now when he does an edit that the in-context would have updated, he has to go through and manually delete a bunch of relations, redefine features and recreate others. If he had simply used Lock instead of Break, he could have preserved some of the parametrics built into the model, at least preserving him long enough so that he could go to the Advanced Assemblies class and learn to use in-context sparingly.

Think of Lock as something you can undo. Break cannot be undone. Don’t do that.

#2: SolidWorks is So Slow: must be this &^%$# latest service pack

I used to do implementation and advanced troubleshooting for a reseller. My main equipment for this was my laptop and a whole stack of paper lunch bags. The laptop was just to give me look important, it was the top of the line Etch-a-Sketch model I think. Anyway, between the two, the lunch bags were by far the more useful. First because if so inclined, I could carry my lunch in them, or I could take notes on them because I forgot my notebook again, but more to the point it was to have the IT, or engineering manager breathe into to calm him down when I first arrived. People whip themselves into a frenzy and begin hyperventilating. If the manager passes out, who’s going to buy me lunch? Priorities are priorities after all.

So people are angry, hyperventilating, turning red, getting sarcastic, calling the software names, and directing it all at me. I didn’t write the software. I didn’t cause their problems. I’m just there to fix it, so they should be nicer to me or I might just agree with them that they bought a useless pile of shit and go home myself. I listen to what they have to say like it’s the first time I’ve ever heard it, and like they have discovered something profound which I must run and tell the king, as if the sky were falling or something. Essentially in this situation, I’m just letting them talk themselves out, trying to act sympathetic, and hopefully they will calm down after about 45 minutes of this. It’s more child psychology than CAD implementation. All this time I’m trying to gauge how this fellow is going to be able to handle all of the crow he’s going to have to eat in a couple of hours.

So eventually, we take a look at the problem. An assembly drawing. The first thing I notice is that the files are all opening over the network, and to their credit, it is slow. Then we see the drawing with 20 sheets. And then section and detail and cropped views like crazy. The assembly tree has more -> symbols than you can shake a stick of RAM at. And then the real tell-tale sign is the Symantec symbol in the system tray.

At times like this when it comes to the moment of truth, sometimes there is this tinge of self-doubt. “Should I really go out on that limb? Should I really stir this hornets nest more than what’s absolutely necessary? How much revenge do I need to exact from these people for subjecting me to that 45 minute rant earlier?” Usually before I’m done thinking this through, I hear myself saying something like “If I can’t fix your problem, you don’t owe me anything.” These people are already thinking I’m a dolt because I seem fairly unimpressed with their tale of woe, yet I’m not defensive, I’m almost bored, maybe even a little impatient.

The first thing we do is move files locally, and this improves the open time by about 50%. While doing that I discover a Toolbox installation on the network, with a database that must have a lot of custom standard data in it because its about 250 Mb, so I copy Toolbox files locally too. That gives us another 15%. Then I start messing with the Symantec icon and looking for the IT guy. “Can you turn this off?” I say, handing him another paper bag. “Is this scanning all files that move on the network?” By now we’ve got the open down from 25 minutes to about 5. I take a look at the file references, and with all the in-context going on, there has to be some circular or at least convoluted relations causing the assembly to rebuild multiple times. Sure enough, there are in-context relations to patterned components, an in-context features to other parts with in-context relations… I don’t have to look at this in detail to know that I could easily get the open time to under a minute.

I admit to them frankly that there are shortcomings in the software, but we haven’t even addressed those yet, and we have removed 96% of the original time to open the assembly. We hadn’t addressed local hardware configuration either, which gave another big boost. We never did analyze network problems, but I’m sure some benefits could have been had there as well.

Is this a true story? Yes. I’ve done this several times, as have other folks. It’s not anything special that I did that fixed the problems, it’s just that you have to stop assuming that the software is the problem, and don’t get wedded to a particular solution until all the facts are in. The fact is that SolidWorks taxes your network and your system more than surfing eBay or that Paper Pilot game. So nothing goes slow until you start SolidWorks. Must be SolidWorks fault.

#3: Geometry Pattern Speeds Up Large Patterns.

The thing that gets me about this one is that SolidWorks even in the Help file announces this. Quote from the Geometry Pattern entry in the Help: “The Geometry Pattern option speeds up the creation and rebuilding of a pattern. ” If you call tech support when trying to make a 100×100 pattern of hex holes in a sheet metal part, they will tell you to turn on GP. Fortunately, it takes so long to do that they can’t stay on the phone with you to see how it goes.

Here’s a little chart taken from the Patterns chapter of the SolidWorks 2007 Bible:

Pattern Type                         default   GP           VOR

20×20 sketch circle               1.75        na           10.5

20×20 sketch square           10.8        na           143

20×20 sketch hex                 19.4        na           294

20×20 feature circle            .19          .28          .19

20×20 feature square         .34          .55          .33

20×20 feature hex               .48          .70          .48

Figure 8-1 shows one of the parts used for this simple test.

GP = Geometry Pattern. VOR = verification on rebuild. Numbers given are rebuild times from the Feature Statistics.

The part is simple. The results are straight forward and repeatable. SolidWorks, please fix the Help, and stop telling people that GP speeds up large patterns.

Here is what GP really does: it makes a pattern of the faces of the parent feature, and it does not pattern the intelligence (end conditions) of features, such as an extrude with an Up To Surface. It often fails if any patterned face has to merge with another model face, but not always.

There is actually one situation when it really is faster. If you are patterning a feature with an Up To Surface end condition, a pattern will rebuild more quickly with GP on than with it off. Unfortunately, the resulting geometry is also different (because the end condition is not patterned), so this cannot be used to support the claim that GP speeds up patterns.

Anyway. That’s enough for now. What misconceptions have you come across?