Toolbox Lameness

I've always disabled configurations for newly inserted
Toolbox parts, so that new parts are copies of the
master part with changed dimensions. I've also never
used "edit toolbox definition", but tried it today.

I expected Toolbox to create a new copied part with the
desired dimensions, but no, it wants to create a
*configuration* of the master part. This completely
defeats the decision to skip configurations in the first
place!

This may be old news to many of you, but it just became
my pet peeve of the day.

Art W

 

I use Toolbox with 'Always Create Copy'.
And i have used 'Add my Parts wizard' to create new parts that create
copies.
Exactly what is the "edit toolbox definition" you are refering to?

Aaron

 

It doesn't behave the way YOU expect it to so it's lame? When
redefining the toolbox definition it's creating a config within the
same part you started with, the copy. It's not inserting the master
part file. This shouldn't be a problem, the file is still a copy of the
master, so what if it has configs?

 

In this case create the new configuration and delete the old one. It is
a pet peeve.

 

Yes, it's lame, to answer your question. The problem comes in sharing
parts. If someone else on another system makes a part with the "copy
parts" setting, it should have the same name and same dimensions.
That's why people avoid using configurations in the first place, because
one person's part will have configs that another persons doesn't. If
you start adding configurations to an otherwise unconfigured part (saved
with a filename reflecting the size), then you have different sizes and
a name that doesn't reflect what the part really is. Totally FUBAR.
The problem is that you tell it NOT to use configs, but it still does.

It's ok if you don't share your data with anyone or expect filenames to
make sense.

Matt

 

@g49g2000cwa.googlegroups.com>,
says...

You'e right, it is creating a config of the copied part,
not of the master as I said. My point is that I don't
want configurations in purchased parts *ever*. It's an
invitation to disaster if someone downstream changes a
part config. What's worse, if you edit the Toolbox
definition and accept the new config, you get a part
with the same name and a new config. So, if I have an
M6x20SHCS and want to make it 25mm long, I get 25mm long
capscrew whose name is M6x20SHCS!

 

Thanks, Paul. Deleting the old config is
straightforward, but, as I replied to rockstarwally, the
part name doesn't change and needs to be edited.

I was looking for a simpler way to resize Toolbox
components in an assembly. But with copied parts I think
the only solution is to create a dummy assembly, drag
the "new" Toolbox part into it, save it, go back to the
original assembly and do a replace components on the
"old" part. There oughtta be a better way....mumble,
grumble.


Art

 

That's not the case at all Matt. If you need to select your assembly
and all of it's children you just include the copied part like you
would any other part or sub. I really don't see what the problem is.
I've been using SolidWorks for years and the only problem with sharing
toolbox files really comes up when using the master file.

If you're sharing files with another network just bundle up all of your
files and send them over, no prob. If you're sharing files on one
network just make sure you all map your toolbox to a network directory.

If you're on a network sharing files but mapping to a local folder for
toolbox you're doing it wrong.

 

The configs are no problem but you're right, the lack of name change
can pose a problem. It is irritating when the feature tree shows a part
that's a 1/2 inch and it's really 3/4 for example.

Is doing a replace part process actually easier than just living with
the limitation?

Another thing to consider is that if you need to have fasteners in your
assembly try to save it till the end, then you won't have to change
them quite as often.

 

Unless of course you're not doing that. Let's say that you're on the
same network with someone and you have local Toolbox installations. You
wouldn't copy your files, and they wouldn't see your version.

There are lots of reasons for doing a local Toolbox, mainly being
performance. Network toolbox is a total hog, especially if you have any
custom standards. Opening a 50-70 Mb database across the network isn't
fast.

Even if you have a network Toolbox, let's say that your admin has
already created all the sizes your company uses, and has made them read
only. What then?

Or lets say you use some sort of PDM.

There are a lot of valid scenarios that cause Toolbox to become a blunt
object even in the hands of someone who understand its foibles.

Matt

 

You can complain that SolidWorks doesn't work the way you wish it would
or you can work within it's limitations. It has limitations just like
any other software and I used to be right in there bashing it until I
realized that by modifying how I go about using it instead of simply
expecting it to work to match my needs perfectly I get a lot more out
of it and spend less time frustrated. The problems people complain
about are really implementation problems. If you have multiple users on
a network and you're using local toolboxes that's an incorrect
implementation. Don't sit there complaining about something because
you're not using it correctly. Yes a 70Mb database will be a hog. Use
PDM. For crying out loud it's included in SolidWorks Pro! I don't see
the problem with PDM, haven't experienced one yet.

So what if the Admin made all the sizes you use? I guess they're all
there then aren't they? Just do a replace instead of redefine.

You of all people should know that it's a heck of a lot easier to work
with your tools instead of against them. Is it reasonable to expect
SolidWorks to do everything just right for everybody?

 

I think you might get a chuckle out of your post if you knew who I am.
Not that I'm anyone important, but just that for the last few years I
have made a living doing SolidWorks, Toolbox and PDMWorks
implementations, and have seen many of the different things that go
wrong with toolbox. I'm the guy the local reseller calls for help when
their customers get themselves into a Toolbox nightmare. It's literally
a weekly thing that a company has some emergency due to the "huge
screws" fungus that grows on Toolbox parts. I love toolbox so much, I
have a few documents on my website dedicated to that lovely product.

My implementation advice to companies is typically to either use Toolbox
to make parts and then turn it off, or to buy or make their own
libraries. They usually come to this decision on their own as I am
describing how to make Toolbox work correctly in their particular work
environment, and the potential problems they could have (none of which
is provided with the SW documentation, and is especially lacking for new
users).

I had the opportunity to sit with the Toolbox product manager and a
product definition specialist for a couple hours to talk about the
future of the product. They agreed that configurations as currently
implemented are really a disaster. I think my phrase was "even if you
were malicious about it, you couldn't come up with worse default
settings". It's possible that in a future release TB will be completely
gutted and redone.

Is it possible to make Toolbox work correctly? Yes. The one way I can
guarantee TB will work well is for you to unplug your computer from any
network and don't share your files. Regardless of what implementation
scenario you select, there is a conceivable problem with Toolbox getting
your hardware wrong. Even with PDM.

Why are there such problems with a LIBRARY? The answer is because it's
not a library, it's a configurator program. A library is a semi-static
collection of existing parts, not a build-as-you-go time bomb. If it
were a library, the only problem would be wrong sizes or names, but
because it's a program, not a library, the problems are really
unlimited. Each release they find new, complex, inventive ways to
resolve previous difficulties, and usually in the mean time create new
and unexpected problems. There are layers of settings in TB that most
people - most ADMINS - don't have any clue about.

Anyway, thanks for the lecture.

Matt

 

I know who you are Matt it's just not important to me. I'm saying that
these kinds of complaints are pointless. If it's really a big deal
submit an enhancement request, that's all you can do.

Live with the limitations and you'll keep your sanity. Find ways to
implement the software the way it is and you'll get your work done. Try
to force the software to work another way and complain about this and
that and you'll get nothing done and just feel angry.

I had problems with Toolbox a few years ago but by using the network
folder and making copies I haven't had any problems. So what if it's a
configurator? So what if it doesn't work just the way you wished it
does. Why is the sky blue? I don't know or care. Maybe you'd prefer a
nice tangello colour, but in the end you've got a blue sky so live with
it.

 

Not everyone is so fatalistic about things. I participated in the
process of redefining a new incarnation of Toolbox, which means that
bending over and taking it is not *all* that we can do. The first step
in fixing problems is to recognize they exist.

Don't lose sight that you have the option to use it or not. If it
causes more trouble than another solution, there is no "til death do us
part" clause in the EULA.

When it comes to Toolbox, I'm not concerned about anything other than
the stability of the data. By that I mean that the size screw I put in
today will be the same when someone in manufacturing opens it or someone
across the globe. This is not a cosmetic concern.

New users by default get the worst settings imaginable unless you work
completely isolated from other Toolbox users. New users come here often
for advice. Telling them to just "live with it" is not likely the best
advice that they could be given, in my opinion.

 

Since when am I a fatalist? It's realism buddy. Work with the tools you
have instead of wishing.

I don't tell them to just live with it. I'm telling you to live with it
becaue you have your head rammed into the sand so hard that you're
clearly not interested in doing anything except complain.

I already stated how I feel it should be implemented properly. Your
response was to whine that that's not how you want to do it. There's
nothing more that can be said to you if all you want to do is whine.
I've got two little boys, I hear enough whining without having to hear
so called professionals do it too.

When I say live with it I'm not saying live with out of the box
settings, I'm saying configure it to work properly for your
application.

The TB setup is obviously setup by default for stand-alone licences. If
it was optimized for a network the stand-alone clients would complain.

And you're right, EULA doesn't bind you to anything. You're free to
switch to IV or ProE or whatever else if you really feel that will fix
all of your problems. Then we'll just see you on the IV group bitching
about something else.

 

You almost need a macro that can cleanup the part and save it with the
appropriate name when done finding the right length. After a while you
will have all the toolbox parts copied and won't need to worry about
this.

 

tsk, tsk....come on guys be nice to each other... or your uncle neil will
make you do 50 press-ups...

 

Yes please-- I want one.

 

If you're in the mood to write macros, it would be ideal to have one
that goes through the toolbox.mdb file and makes all the parts, either
with configs or as copy parts. This would solve many TB issues for
anyone who uses it. Then you just disable the interface and move the
parts to a library folder. You forego some things like Smart Fasteners
and the Edit Toolbox Definition, but you gain a lot more, like the
ability to use a spreadsheet to populate custom properties like part
numbers and descriptions.

 

Yeah, I'm sorry. I was getting worked up.