Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations MintJulep on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Copying of assemblies

Status
Not open for further replies.

jonniesw

Computer
Dec 19, 2010
2
thread559-146826

Hi

As an ex Parasolid developer ( the modelling engine inside Solidworks ) all I would say here is be careful regarding copying assemblies for any other purpose than a backup or machine migration.

I have always been impressed by the way Solidworks strived to make the mind-numbing complexity of solid modelling look easy to the user - they were revolutionary in this respect.

Copies of assemblies that have 'new-copy' dependencies will in general be hard to re-combine if the assemblies should later merge again into one model. The potential for pointless duplication is huge. Duplication of parts that should otherwise have been the same part not only increases file size and memory demands but also may have implications for performance - a binary comparison of two part files is unlikely to be much use with all the kinds of data that can change and yet reflect the most trivial change to a part - just changing the colour of one face will see a divergence. I am not speaking for SW here - I didnt work on their code - I am speaking in general terms.

In general, if there is an alternative to copying (other than for backup) a different way of working and organising files then I would say consider it as an option.

The behaviour where a copied assembly has original references is actually the behaviour you want for a backup if it is your intention to restore the backup and all part files to the original working directory upon some failure.

Apart from the trivial case of backup I would always ask myself first "why do I want to copy?" - there will always be cases where there is a good answer but just asking this question and thinking it through may reveal the possibility of another working methodology - in short then - a copy that is anything other than a simple backup of your entire project working directory may lead to insane issues of duplication where sharing could/should have occurred - breaking shared links where they could have been preserved is often a bad idea.









 
Dan ... The linked thread is old and has been closed.
 
So I do not want to copy per se, just rename an assembly and the parts and drawings to meet our new numbering criteria. What do you suggest?

--
Hardie "Crashj" Johnson
SW 2010 SP 4.0
HP Pavillion Elite HPE
W7 Pro, Nvidia Quaddro FX580

 
Hi SnowCrash

>>So I do not want to copy per se, just rename an assembly >>and the parts and drawings to meet our new numbering >>criteria. What do you suggest?

I dont have much experience directly with drawings - its an aspect of SW I have never really needed so I will leave someone more familiar with drawings to answer that.

My point is high level general one - whatever principles someone tries to work to there will always be cases where you cant find another way. My point is really about forms of copying that break former sharing (with subsequent recombination failing to cull the items that originated form the same part). A simple and faithful copy of an entire assembly where names are consistently changed throughout shouldnt be a problem as I have described it.

Its interesting because a huge class of problems to do with performance and reliability in solid modelling could be put down to things that are every so nearly the same but not quite.

This manifests again and again at every level from the case of two surfaces which are supposed to be clones but show small physical differences up to assembly components that should have been instances of the same part but have for one reason or another been allowed to drift and diverge - perhaps for instance one clone passed through a surface clean up algorithm that made changes on the 1.0e-07 level but the clone surface didnt get cleaned up.

Dealing with two surfaces that are supposed to be identical but wobble with respect to one another to the tune of 1.0e-07 is computationally going to lead to nightmare performance.

Users obviously notice when they have made large shape changes - the devil changes are the ones that are so small as to be un-noticed but subsequently result in two surfaces ( curves ) that used to be identical now being deemed distinct.

If you want to see complex intersections that give solid modellers a bad stomach then take a bspline surface, copy it - wobble all the vertices by 1.e-07 and then ask a surface intersection algorithm to find you the intersection curves of the two surfaces.

Anyway I am rambling - all I am really saying is that copying beyond backup is one route whereby timelines that should have been identical diverge causing problems later on.


 
Status
Not open for further replies.

Part and Inventory Search

Sponsor