The Conceptual Beauty of Toolbox

Conceptually, SolidWorks Toolbox is beautiful. No, really, I mean this without any sarcasm this time. Conceptually, it is beautiful.

The idea of delivering thousands of fastener parts in a very small file size is extremely attractive.

The idea of driving parts and matching holes through a database appeals to the side of an engineer that loves efficiency and centralized control.

The concept of linking the Toolbox fasteners to the Hole Wizard is beautiful, so that the fastener and the hole update together.

The idea of using “Smart Fasteners” where a hole through multiple parts is created in-context and at the same time the fastener is automatically sized, created and placed along with top and bottom stack washers and nuts is just unbelievably powerful.

The idea of telling the other “Smart Fastener” functionality to populate all of the holes in an assembly with the proper fastener also seems too ideal to be true.\n\nWhen companies hire me to come in and do some implementation consultation, sometimes I just glow with satisfaction at the beauty of the concept of how Toolbox is supposed to work. How it is ideally integrated with all of the aspects of the model and in concept works flawlessly with the file management software, and is so easy to use. What could be easier than placing a few sketch points in an assembly and allowing SW to drill all of the holes in a stack of plates and put the screws in?

But then I learn that the company uses several different materials of each screw type, black oxide, stainless, nylock, plated, etc.

…or that they want to use individual part numbers assigned by them rather than the software…

…or that they want to use individual parts rather than configurations…

…or that they use a PDM system…

…or want to use custom parts…

…or run multiple versions of the software simultaneously…

…or that they have customers who want fastener files with different formats…

…or that they have multiple locations that cannot share the same libraries, but often trade assemblies…

…or that they want to share a Toolbox among several users across a network…

Technically, there are workarounds for almost all of these issues, and each workaround is a research project, assuming you know you’ve got a problem in the first place. But the fact that so many common situations cause problems with Toolbox is cause for alarm. These aren’t simple bugs, they are architectural problems in the very structure of how the software is conceptually mean to work.

Toolbox is not a library. A library is a collection of things, and you can go and get an individual thing that you want. Think of a library of parts as a buffet line. You get what you want and go. You can’t just do that in Toolbox. Toolbox is a configurator, which you can think of as a restaurant. You go in and order something off of the menu, and they make it for you. The next day you go back and order something different, and they make that for you. They will keep making things for you until you have ordered everything on the menu.

The menu is the database that holds all of the numbers for all of the sizes and options and standards and various parts and hole types.

There is another reason why you can’t call Toolbox a library. Libraries of parts are just that: a bunch of parts. Toolbox consists of 3 elements: the parts, the database with all of the size data and the application – the executable software program that brings together the database and the parts. So Toolbox is really just software.

When Toolbox is installed, Toolbox has only the default size of every part, which is usually either the largest or the smallest part on the menu. By default, when you ask for a part, Toolbox gets the data from the database and puts it into the part as a new configuration, although you can ask it to make a copy of the part instead. Just beware that if you start using your library in default mode (making configurations) and then switch to the “copy parts” mode, it is going to copy parts with the existing configurations. This is probably not good if you are trying to avoid configs for whatever reason.

One of the most common problems is that you open an assembly built by someone else, or even built by you before a reinstall, and you get Huge Screws. This happens when you don’t have the same configurations in your library that the person who made the assembly had. Assemblies created in SolidWorks 2007 or later are supposed to have a tool for rebuilding the missing configurations, but in assemblies made before that, there is no remedy, regardless of which version you open the assembly in. Repairing things is a long manual process.

You could have a discussion like this on any angle you might try with Toolbox. There is always some sort of caveat with a complex solution that solves about 80% of the problem. It seems like you can never really fully solve a problem, and you can’t get exactly what you want. The real problem with this is that most users are completely unaware that Toolbox is such a time bomb in your assembly data. In order to make these settings most effective, you have to make them before you start using the parts. Most people have to make the mistakes first, then discover the problems and then try to undo the mess. I’ve often said that even if SW were trying to be malicious about things, they could not come up with a worse set of default settings than the way the software installs out of the box.

So while the concept of Toolbox is beautiful, the implementation is honestly a full on nightmare. Many CAD admins I know do not allow Toolbox to be used in their departments except to create parts which are immediately divorced from Toolbox by changing their names and saving them to a non-Toolbox folder.

Again, not to just throw stones at such an old issue, but if I were responsible for the Toolbox product, here are some things I would want to examine:

– Deliver a static library of existing part files, or at least an application that would make all of the sizes based on an admin’s input, using either a formula or list of numbers to produce custom file names and custom properties. (Something that really works, not the poor excuse for a “make all configs” button that currently exists.) This would be a one-time thing per company. The end product would be a finished library of parts. The company could then distribute their library or settings for making a library. The settings could be saved so if they needed to do it again later, it could be exactly replicated.

– Make the Toolbox parts version independent. Let me say that again for emphasis. MAKE THE TOOLBOX PARTS VERSION INDEPENDENT. This nonsense about you can’t make parts reverse version compatible is bull shit. SolidWorks shows great disrespect for their customers every time they foist this one on an unsuspecting users. Anyway, Toolbox parts being dependent upon versions is a maintenance nightmare and a file management nightmare for users. SolidWorks is so capable when it comes to clever ways to get data from any other software package into SolidWorks, but so completely hamstrung when it comes to dealing with reverse compatibility SW or any type of Catia data. Coincidence? No way.

– Be really up front about the potential for problems and ways to avoid problems. This is the practical side of what’s lacking at SW. Very rarely do you find real practical advice or anything concretely useful in the documentation.

– Still offer integration with Hole Wizard and Smart Fasteners, but pare the functionality down to the stuff that works reliably. About 30% of SF functionaly is actually worth keeping.

So how do you feel about Toolbox? How do you use it or not use it? Got a “perfect” solution for your situation? Got any nightmare stories? Please share!