Implementing SW Toolbox in multi-user environment, best practice?

You mean other than the obvious "don't" recommendation? In order to have Toolbox data that is not guaranteed to blow up on you someday, you have to use the "copy parts" setting. This is unfortunate, since configurations are great for other things. That or you could just create all configs of everything you use, and then make sure any time you share data, they use YOUR toolbox data.

Toolbox is a timebomb for your designs. If you use it, you will get burned eventually.

Matt:

I'm a litlle scared. Are you saying that if bolts, nuts & what not from the Toolbox are all pulled from a single machine, sooner or later things will go south? But that I can breathe a sigh of relief if I copy the parts to my local machine (or at least from the Toolbox directory structure to the director structure of my assembly)?

That would make sense, and since I'm now orking with a *copy* of the hardware, I can spcify material, activate the weight calc, etc. so tha it all comes out in my BOM.

Thanks,

Tom

My best advice is not to use toobox. It's a nightmare of a product and poorly designed. It will cost you countless hours of wasted time and effort.

Create your own component library using tables and it will work much better. You can add all your part numbers and descriptions at the same time.

What I'm saying is that if you use configurations and share data with somone not linked to your Toolbox, there will be trouble. Specifically you won't have all the same configs created, so you'll get the "huge screws" syndrome, common to toolbox users.

Even if you solve that problem by using "copy parts" instead of configurations, you then have the problem of custom property info like material or custom part numbers, which is a very manual process for Toolbox users. Funny thing for such an automated product.

Oh, and if you start using a TB library with configs, don't switch to copy parts. Also be careful of custom standards. I've seen some bad bugs and speed issues when you start doing that.

Read the 11 page tirade on my website about Toolbox.

You're better off buying some non-intelligent library using design tables which at least gives you some control.

Thanks, Matt & abc.

Ya see, the problem is, we're deep into SW, having jumped from AutoCAD last year. Two of our young guys had used it quite a bit in college. Trouble is, there's a huge, huge difference between what you'd do in college and what you'd do in a real manufacturing effort. In college, the big issue is to get things ready for ComosWorks, or create realtively simple assemblies and drawings; revision control is not an issue.

So we have this huge assembly that uses all Toolbox fasteners and such; most of the BOM is filled in "By hand," and all these guys are worried about is that, at the end of it all, the paper looks okay. Proper use of the software, data structure, recoverability and revison control are "crushed in the rush."

So here I am, the senior guy, training myself, and trying to figure out how to get a set of part and assembly files that will maintain it's integrity. I must admit, the Toolbox had me suspcious.

What SHOULD be done- if you insert a fastener or other Toolbox component, that part SHOULD BE copied into the file structure of the assembly. That way, if you have to do anything to it, you can. Further, it would help with general portability.

At least I think. I don't like the idea of an assembly pulling parts from all God-knows-where. It's neater & easier for me if every part in an assembly in in the directory tree beneath the top-level assembly. That's my 2 cents.

Matt, where's your web site?

Tom

Depends on what your goal is, but in general, I think parts that are not project-specific "should" be kept in a library folder on a network or in a PDM system. Common shared parts without making duplicates.

Thanks, Matt, I'll check it out.

Ok, my only real gripe about "pulling parts from all God-knows-where" is that, for the fledgling BOM system I'm setting up, you can't enter a "Description" for the toolbox parts (normally - you know the drill) - and thus my nice automatic BOM system doesn't have a decription for the toolbox parts. Why couldn't they have just put (For ex.) "HEX NUT" in the description field of these parts? I could set up traceability for our own parts - and enter descriptions as well.

Just when I think I've got a system, you know?

But now to read about the Toolbox at Matt's site...

Thanks

Tom,

Check out Chapter 13, page 38 in the SW 2005 What's New Guide.

SolidWorks added the ability to assign Toolbox part numbers, descriptions and comments using Excel.

Hope this helps.

CG

Tom,

You might want to check out a new feature that was added in SW2005. It allows you to edit the Toolbox part numbers, descriptions and comments in Excel, then import back into Toolbox.

Here is an excerpt from the SW help file:

"You can add part numbers, part descriptions, and comments for each configuration. You can edit the cells in the dialog box or click Export to export the data to Microsoft Excel and edit the data in Excel. When you are done in Excel and have saved the spreadsheet, click Import to import the data into the database of Hole Wizard holes and Toolbox documents."

Do a search of "Edit Data" in SolidWorks Help.

It is also written up in the 2005 What's New pdf file. See chapter 13, page

2. Hope this helps.

CG

Sorry for the double post!

My newsreader said that my connection was broken before this message could be posted. It lied!!

CG

I strongly advise you not to use toolbox, in a multi-user environment, or anywhere else. Even using copied parts is a real pain. design your own parts and store them in the design lib, on a shared server.

Do not use configurations anywhere, they will really mess up your assemblies after time.

Many assemblies, with toolbox parts in, that I started in sw2003, now fall apart with sw2005. Removing the toolbox parts, now allows the assemblies, to open without errors.

We had a case this week of an assembly refusing to be re-checked into Pdmworks, even crashing the user PC, many times. This was due to a toolbox bolt, that has been in the assembly since Jan 2004!, even more amazing, is that the assembly has also been in Pdmworks, since that time. Deleting the said bolt, allowed the assembly to re-check-in, with no errors.

Toolbox is like a pair of smelly pants, with no way of washing them, throw it away for good.

OT, why do we say a "pair" of pants, there is only one? lol

Another Toolbox fix, they've got a jugular open, and address it with a bandaid. This is just manipulating the database. It is the database that is the root of the problem. That information needs to be in the part file, not some remote db. When you open an assembly and the configurations don't exist, this DB doesn't do you a lick of good.

Library means Library. Toolbox is not a Library. It is a configurator. It doesn't have what you want unless you tell it to build it. The configurator is worthless. What value is it to wait until you need it to tell it to make a size? Why don't all the sizes exist right up front? The solution is WAY simpler than anything they have done already. No one I know (including reseller techs) understands all the obscure functions in Toolbox well enough to make it work the way a library of parts works. Every time they add a fix, it is just another obscure switch which should have been turned on when you first started using your "library", but wasn't, so it's worthless or screws things up worse.

Anyway, Toolbox is a design danger until they dumb it down. They keep resisting doing something that will just create all of the sizes AS INSTALLED for beginning users, rather than some complex combination of obscure switches. Default settings should NEVER be the most dangerous things you can do, but that's how Toolbox does it.

Remember that we're talking about a library, not multi-variable integral calculus.

The main problem with getting it fixed is that they won't take away programming resources from developing some politically motivated but otherwise disfunctional MOLD CREATION feature, or one of a dozen other pointless line items in a given release's "over 150 enhancements".

/rant

Matt,

Very well said. Your comments are spot on. I've worked at three different company's that tried to implement toolbox using company standards and it bombed out for all of them. Issue after issue. it's just a mess of a concept to work with.

Best to bite the bullet now and create a library from scratch. It's too bad it has to be that way.

Good one!

I've always wondered we it is: A pair of panties, yet it is one bra?!?!?! Seems a little backwards to me...

Matt,

I agree with your assessment about Toolbox being overly complex for the task it is designed for. I was merely attempting to provide some useful information for users that are using Toolbox.

A part library based on families of parts driven by design tables, or standard configurations is my first choice as well.

Perhaps one of the API gurus that visit this group could write a macro that would build a standalone (design table or config based) part library from the Toolbox master parts and database tables. Beyond my API capabilities unfortunately.

Best regards,

CG

descriptions

At one time pants were two separate pieces. Leg coverings only, worn in addition to something like a loin cloth.

Joe Dunfee

I disagree here. Converting that db to a library should be a trivial exercise. The real problem is that the content won't be locked in the db so that you have to buy TB to get it. If it was a simple library, offices wouldn't have to buy a copy for every seat. Licensing for a simple library would be unenforceable. Death of a cash cow.

In my opinion (based on my usage), the weakest parts of SW are all derived from CimLogic.

I think the best argument against toolbox is economic. If you will need more than a certain number of seats (say 0.9), the cost of TB is better spent on the time to develop your own library, or purchase a real one. The other aspects of TB don't make it worthwhile. Smart Fasteners are not, and the calculators can be had from other sources.

Thanks, all. I've got some investigating to do. And some Execdrin to take...

THIS WAS SUPPOSED TO BE EASY!

Okay, I'll stop shouting now...of course, I never believed it, but I hoped...