Copied References to a New Directory Problem

Hi,

I copied an assembly to a new directory, using File | Find References -->
CopyFiles...

The reason for the copy is that the working assembly is the most recent
correct version. I want to copy that assembly to a directory (say current),
and put all of the old parts and sub assemblies in a directory named
reference only, for example. That way I have all of the current working
files in the "Current" directory. I have not noticed this behavior in the
past???

I went in to add a new part from the Toolbox (a 6-32 PEM Stud) and it asks:
A document named "Flush_Stud_PMI" is already opened. Do you want to show
this already-opened document?
(Yes) (No)

Yes - mates the part to a position different than I want (backwards) - and
it gives no opportunity to change it in the dialog - I have to do it
manually for each fastener, and
No - says "Drag and drop failed" (OK)

What is going on and how do I fix this Please?

Aron
SW2006, sp5.0

 

Aron,

Did you use "Smart (really dumb) Mates" for the fasteners on the original
file ???



Mark

 

Well,

If you mean smart like... I found the part I needed in the tool box, then
drag it to the part and it orients itself then yes. However, no it does not
do that now (after the part was copied) it is a "Dumb" mate, or I am dumb,
at this point the answer is all I really seek, it is a mystery to me...

Aron

 

I've got to find a way to make a living at this.

You've been Toolbox'd.

When you copied the files, you copied some files out of Toolbox. Then
you opened the assembly from the new directory, and it got the copied
files. Naturally. It's probably even what you intended to do.

When you try to use Toolbox to place a screw, it goes to open the screw,
but realizes there is another file with exactly the same name which is
already open (the copied file). A single session of SW can't open two
files with the same name at the same time. So everything is FUBARed.

Its just a damned library, but it tries to be intelligent. That's what
gets it in trouble every time. A real damned library never has problems
like this.

The only way to really fix it is to get rid of toolbox. That's the only
way to guarantee stuff like this doesn't continue to happen.

Another way to fix it would be to close down the assembly and SW and
delete (or just move to a newly created folder or rename) the copied
toolbox parts, and the assembly will revert to using the real toolbox
parts. If it doesn't work, try opening a toolbox part and then reopening
the assembly. Eventually it will find the toolbox library.

They keep trying to fix it, but they are solving a simple problem with
mounds and mounds of complexity, which of course makes everything worse.

Library = static parts.

Non-static parts + quirky application = file management problems = Toolbox.

 

Yes I guess I have been toolbox'd...

I used find references from the SolidWorks menu and it produced these
results... If I would have known how to do it I would have done it the
correct way, but again I just used the tools given to me to use in SW
itself.

I totally agree, the tool box should be a static library that gets
referenced only and does not actually make copies of itself which is what it
seems happen or at least SW thinks it happens. Sometimes software does try
to be too smart no doubt about it.

I will try your suggestions, thank you.

Well I hope 2008, gets this handled...

Aron

 

The problem is that you *did* do it the right way. That's exactly how
you're supposed to copy an assembly with its parts. Somehow the rest of
your parts didn't get messed up, only Toolbox.

I don't believe this will ever get "fixed". SolidWorks has bought into
this "configurator" method for creating a library on the fly even though
it has been proven for several years to be a huge source of headaches
for users and administrators. A problem like yours can't be fixed with
one of their typical "bandaid" fixes.

One thing you could do to minimize problems would be to switch to using
the Save Parts option, but you'd have to start from a clean Toolbox
library to do it, and replace all of the existing toolbox parts in
existing assemblies. Bummer.

Maybe write your congressman...

Best of luck

 

One thing you could do to minimize problems would be to switch to using

I like the general concept of what SW tried to accomplish with Toolbox,
ie. to create configurations with dimensional data from a database.
However, when it comes to custom properties and setting some custom
"standards" for library parts it seems like having individual parts in
a library with multiple configurations is at the very least more
straight forward.

Towards that end, there are some tricks that can be useful for
transposing toolbox parts into individual parts, (with configurations):
1) Open a toolbox part, (or any other part) and save it with the
appropriate name.
2) Open a Excel spreadsheet and populate it automatically.
3) Update everything per your company standards for Library parts,
(including smart mates).
4) Open other similar parts of different sizes and then create a
spreadsheet for each of them.
5) Go into the spreadsheet for each of the parts and copy the row of
data for that size
6) Go to the first part file spreadsheet and paste the data into new
rowes.
7) Add columns for custom properties, (like Description etc that can
be used for BOM later).
8) Save the first file and discard all of the others.

There will now be a nice "relatively" small file with several
configurations.

For things like fasteners, (ie. screws and bolts etc.) a little Excel
creativity can product large numbers of similar size parts but of
different lengths etc.

Hope these ideas help.

EdT

 

I'm not sure it's a Toolbox problem.
I think you correctly identified it as being due to SWX not being able to
open 2 parts of the same name but which are in different folders.
That particular limitation is a complete PITA. Also, the warning message
that comes is particularly oblique, and if you proceed you can end up
substituting parts unintentionally.

The warning message should be:-
"If you proceed with this command, Solidworks will **** up your design
intent".

Regards,
John H

 

That is a Windows "limitation", if you want to call it that. All other
Windows programs have the same limitation. Any program that seems to not
have a problem with it is getting around it by running two separate
sessions. You can do the same with SolidWorks (run a second session, and
you can open cover.SLDPRT from two different locations).

Having multiple files with the same name is sloppy file management.

My point is not to blindly bash SolidWorks, but to point out problems
that exist.

 

Aron,

What I do, to minimize problems, is set the toolbox save directory to where
my project is. In this way you aren't using it as a library (like it was
intended), and yes you do end up with multiple identical fasteners in
different folders, but I can't model a screw or bolt as fast as I can
generate one with toolbox.

Some day, when I have some free time (yea,, right) I'm going to create a
static hardware library from all the pieces I've made over the years. This
kind of stuff doesn't change.

Mark

 

Thanks everybody,

I will make it through, but I really hope this toolbox dilemma does get
"cleaner" in the future...

Best Wishes,

Aron

 

I agree in general. However, I've recently had cause to deal with a lot of
imported assemblies (from SAT files), where SWX generates part names of
"imported1", "imported2" etc.

The next imported assembly ends up with parts of the same name, and so I
can't have both assemblies open at the same time. It would be nice if SWX
knew that if I have one such assembly open whilst I'm importing another,
that it couldn't duplicate the part filenames.

I could use SWX Explorer to rename all the parts, but that's a
time-consuming job.

Regards,
John H

 

Not if you just tell it to copy the assembly and all the children and
use a prefix or suffix. That should be pretty quick.

 

Thanks for the tip.
It'd be nice if you could similarly specify a prefix during the import.... I
feel an enhancement request coming on...

John H