Assemblies or Multibodies?

Asking SolidWorks users, or anybody for that matter, for suggestions is always an interesting affair. I always enjoy reading the suggestions when SolidWorks opens up Brainstorm or whatever they call the Top 10 list this year. The main thing I find is that 10 different users will have 10 different opinions when asked a wide open question, like “what would you like SolidWorks to add to the software next year?” The diversity is actually a good thing. I mean, if everybody agreed on a single topic without prompting, then it would be clear that SolidWorks was really missing something basic an essential. Also, a variety of opinions means you’ll have more ideas to pick from, which can only be a good thing. Also, some ideas are better than others, so getting a wide range forces you to evaluate. And beyond that, some suggestions are downright contradictory, so it forces SolidWorks to identify a bit of a philosophy for the software, and filter ideas through that.

The second thing I find is that a lot of people don’t know what is already in the software. If you look through the lists of requests, a good portion of the original ideas are things that are already in the software. To me this means that SolidWorks has some low hanging fruit, and it is called educating customers. Imagine if half of the things you really wanted in the software were already there, and already paid for, you just didn’t know it? Wouldn’t that be Christmas?

For example, Mark Biasotti recently posted a question on the SolidWorks forum about how to improve multi-body modeling in SolidWorks. Great question, and it got a fair amount of traffic including some peripherally related topics like the dreaded zero-thickness question, moving bodies, sorting feature trees,  multi-threading for multi-bodies, and also the relevance of assembly files.

The zero-thickness question is a trap that makes the rounds every so often. In the above link I got caught up in it, and as usual, the conversation ends with someone losing their cool and calling names. It’s an issue that I’d like to treat here some day. But not today.

Today I want to look at the multi-bodies vs assemblies issue. Some of the people answering Mark’s post were questioning why we have assemblies at all. Right off the top, my gut feeling is that assemblies are needed, and I see more disadvantages than advantages in eliminating that file type. There are SolidWorks techniques that blur the lines already, such as the Mold Tools, and definitely Weldments.

Other CAD programs can exist without assemblies, but the ones I’m aware of are either very low on the capabilities scale, or very high. In the changing world of CAD, its probably useful to re-evaluate ideas now and then. I do not believe in change for the sake of change, and I do believe that some ideas have more value than others. But for the purpose of this blog post, and the discussion that hopefully comes with it, I would like to start out neutral, and maybe over the course of writing and discussing I’ll form a real reason to hold one opinion or the other.

First, I want to lay out what I believe are the reasons why some people think we would be better off without an assembly file type.

1. I think the primary issue here is that an “assembly” is an abstraction. It’s something that doesn’t exist in the real world, so why do we need to make it up in the CAD world?
2. On a more practical note, assemblies just lead to a lot of parts, and a lot of parts just lead to file management issues. In addition to regular file management issues, with assemblies, you get in-context external relations, which complicate file management significantly.
3. Using mates to locate bodies within the part environment.
4. Having a single model environment where you can use either mates or features.

These were the intelligible features I could distill from the discussion on the SW forum. I may have misunderstood some of the arguments, but these are the main points as I see them.

On the other side of the issue are the reasons why we need assemblies as a separate file type. All of these reasons are based on the current file-based system that we currently have, and the current tree management tools that we currently have. We all know that part of  the concept with Catia V6 is to do away with file-based CAD. So if SolidWorks does away with the file-based system, or they decide to add some advanced tree-management tools, all of these arguments in favor of the assembly file type would have to be re-evaluated.

1. With multi-body parts, the feature lists are intertwined – but the features can only be rebuilt in a linear list. This alone should help you organize your data. When parts have their own feature trees, you can segment the rebuild times better (rebuild smaller chunks when you want to rebuild it instead of rebuilding everything every time).
2. Troubleshooting a feature tree where part features are jumbled up is a nightmare. SolidWorks body management is not good enough to handle all the ambiguity.
3. Part reuse – you can’t reuse multi-bodies in other assemblies.
4. There is no such concept as a subassembly in multibody modeling, other than maybe just another inserted part.
5. Assemblies can be organized differently depending on the purpose of the assembly (bom, assembly instructions, QA, secondary operations, stock on hand, etc). There is no way to “structure” a multi-body part. It’s just the wrong tool for that job.
6. Drawings of multibody parts are ridiculous. I don’t think that needs to be fixed, I think it’s like that for a reason.
7. Downstream – I haven’t seen a machinist ask for multi-body stuff, they want the individual parts.

So I guess this is where I would like to start the discussion. My initial off-the-cuff view is that eliminating assemblies is a method for lazy people who haven’t thought through the consequences of what they ask for. But at the same time, I can see that in an environment where parts are actually collections of features stored in a database rather than a stand-alone file, some of the anti-assembly argument starts to make some sense, in fact, in that situation, it’s hard to see any other way to do things, than without an assembly. A subassembly just becomes an indentation in a tree, not an actual file.  But then how do you handle rebuilds? Using server farms in the cloud??

In short, I highly doubt that eliminating assemblies can be done in our current file-based system. But the current system may not be around for much longer. It’s not clear to me what advantages there are in the database system, since I think it is primarily aimed at the data reuse market, and SolidWorks users I don’t believe are the center of that market.