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

Reply to
Aron (bacsdesign.com)
Loading thread data ...

Aron,

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

Mark

Reply to
MM

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

Reply to
Aron (bacsdesign.com)

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.

Reply to
matt

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

Reply to
Aron (bacsdesign.com)

...

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

Reply to
matt

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

Reply to
Ed

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 f*ck up your design intent".

Regards, John H

Reply to
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.

Reply to
matt

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

Reply to
MM

Thanks everybody,

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

Best Wishes,

Ar>> I'm not sure it's a Toolbox problem....

Reply to
Aron (bacsdesign.com)

"matt" wrote

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

Reply to
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.

Reply to
matt

"matt" wrote

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

Reply to
John H

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.