has anyone ever created a default toolbox dataset (solidworks files w/ configurations) that contain every possible nut bolt & washer? The reason I ask is that when a company wishes to use toolbox in a shared environment (one data set) & there are different employees with different data sets then when the company moves to a shared environment then most assemblies error out because the shared data set does not include all the configurations. So I was wondering if someone has already created a data set that includes every possible configuration of a nut bolt & washer, as this way (according to my local tests) no assembly will error out. If someone cannot help me here could there be a macro written that would simply create a dummy assembly & have it drag & drop every possible size & length of a nut bolt & washer? Which after executing this macro we could then save this database to the central location. If anyone could help me out or point me in the right direction I would be very happy. Otherwise I will start the long drawn out process of manually doing this *yuck*. Thanks Steve Tietz
Can we assume that by data set, you mean database file? Or a group of SW files? Do you want (3) seperate files, one for bolts, one for nuts, and one for washers? If you have different employees, creating their own "datasets" of standard components like nuts and bolts, I think this is the start of a bigger issue there...?
Steve: If I had a nickel for every time I have asked that question myself or someone else has asked me, I wouldn't need to work. I have made this case several times to SW over the last 2-3 years, and I think they may be getting ready to do something. The selection process of what gets development time up there sounds extremely political, and I don't have any illusions that my complaining has actually changed anything, but someone understands what a problem this is and is trying hard to fix it. Lost configs of toolbox parts is a huge drain on tech support and worse, customer productivity and the much bantered "collaboration". The suggested fixes I have heard that sound promising have been things like an install routine that auto creates all configs on install, when a toolbox part can't find the right config, it creates it instead of just replacing it with the least appropriate size it can find, hyper-compact config data embedded in the part (probably text only) that enables all the data to fit on the installation disks, a toolbox configurator utility and maybe a couple others. No one knows what's going to happen or when, but I would guess that it won't be the kind of thing that shows up in a SW04 service pack. So, if anyone has some homegrown solution, it isn't too late. Short of that, you might want to hire yourself an intern. ....also, out of curiosity, have you set up and tested your multi-user Toolbox yet? Have you tested the read-write status of multiple users creating configs of the same parts? (I guess if you pre-create everything, you wouldn't need to worry about this). I got a piece of info from the toolbox product manager that she got from the programmer who had been hiding it under a rock. I haven't taken the time to test this yet, but they assure me its true. They say that you *must* make the Windows folder permissions of the Toolbox Parts directory "read only". This is in addition to the "insert as read only" and "change read only status" switches in the Configure Browser menu dialog. This isn't documented anywhere. Also, there was a bug fixed in one of the SW03 service packs (I think sp2 or3) which corrects the way these settings work. So at a minimum to do multi-user toolbox, you should be using at least sw03 sp3.1. Toolbox is much too convoluted a product to make it work right, and the biggest problem is that not everybody using it knows that they are doing things wrong and causing themselves problems. The capability is there for the software to be set up right, but SW I think knows that they have to do a better job of getting the word out with better documentation or easier to administer software. whew. end of rant. matt.
by data set I am talking about the group of SW files inside of the C:\Toolbox Parts folder -- these are the ones that Toolbox uses & creates configurations in. They all end in "*_AI.sldprt"... there are actually many files that encompass each type of bolt, nut & washer & the configurations inside them control the sizes. what I am saying is that if there are 3 standalone installs of Toolbox then each user has 3 different configurations in the toolbox files. However the solution is to have Toolbox to create every possible configuration in every fastener file it has ("*_AI.sldprt") -- then once that is done we could use that as our shared 'data set' on a network drive . This way there is NO downtime when opening other peoples assemblies & having to fix fasteners just because Toolbox does not know to automatically create configurations in the dataset upon open -- it only does it upon drag & drop. If someone could write a macro to get toolbox to create all configs it would save me & many other companies much time! Otherwise I will have to this the manual way of drag & drop for hours on end.
We don't use Toolbox here, so instead we have all the fasteners read-only on a network drive, and they are always referenced there. They are organized in folders by categories and all use configs & design tables as much as possible. Example: we have a part file for GR5 capscrews, a part file for flat washers, a part file for knurled-point setscrews, etc. The decision was made some time ago to have separate files for GR5 vs. GR8, knurled-point vs. cone point, etc. Don't really know why for sure, but there comes a point where a little more simplification outweighs the advantage of the single file approach. I won't say that we have "every" possible piece of hardware, but we also will never use some particular pieces. So it seems a waste of time to try to keep up for stuff that may never get used. Example: we did create all the "standard" capscrews, etc. that the local hardware house says are available. However, we did not create all the special washers out there - only the standard ones. Then as new hardware comes up that is required, we just add it to the tables. This overall scheme greatly reduces the likelihood that configs will change, as once we put it in the "library" it's essentially locked in. Works pretty well for us. WT
