1. Home
  2. Solidworks CAD Design software
  3. File References and Relations. - How does SolidWorks keep track?

File References and Relations. - How does SolidWorks keep track?

Regarding file references, mates, and in context relations:

How does SolidWorks keep track of these relations? I which file is the information recorded?

If a fastener is mated to a hole in a part, that would be an assembly. The mate relations must have to be stored in the data of the assembly model file.

Now I add a third part, called "widget" to the assembly and design some feature in the context of the assembly. Save everything and close all the files. Open widget alone, view the relations and find that some feature has an external reference pointing to the assembly. Ok, now close it out and open the assembly, make a change affecting the "widget", save and close. Open the widget and ta-da it is updated.

How does the "widget" know to change itself? Where is this information stored? In the Assembly model file? In the widget model file? In both files?

Anyone have a difinitive answer, I would greatly appreciate a response.

Thanks

Brian

Reply to
BWelch
Loading thread data ...

Both documents have knowledge of the other. If you have a part with in-context relations the part knows that it references another file. It also will know whether that file is loaded in memory. And it will know the assembly from which it came by some sort of internal ID in addition to the file name. This is the one exception to the rule that files loaded in memory are referenced by their names.

When certain things happen in SW notifications are sent out and the objects that are concerned with those notifications take notice. Bob Hanson would know more about that side of things. When an assembly opens it, pulls all the parts into memory silently. When you open a part in an open assembly SW doesn't look at the file on disk, it just wakes up the part that is already there. When you pull a part into memory with in-context relations it knows something about the parent file like where it is or was based on a complex search algorithm (which means incomprehensible). If you ask to edit in context it will attempt to open that file. If it can successfully open the correct file then you can make in-context changes.

Reply to
P.

Thanks for the quick resopnse.

"P." wrote in news: snipped-for-privacy@c13g2000cwb.googlegroups.com:

I thought so. I have see the reference directly to the parent in the "View References" dialog box. Even when the (child) file in question is isolated on a completely diffenent machine.

If you have a part with

This "Internal ID", would it happen to have anything to do with the so- called "File Header" I have seen (on rare occasion, in certian errors)? And does this header change when a file copy is made.

I have made copies (Save AS; Save As Copy; as well as using Solidworks Explorer and Windows Explorer) of part files, where the parts are similar and where configurations are not appropriate. So I'm wondering if this "cloning" method can lead to an assembly catastrophe?

Hoping Bob can chime in. I really need to wrap my head around this issue.

Thanks

Brian

Reply to
Locutus

"P." wrote in news: snipped-for-privacy@c13g2000cwb.googlegroups.com:

I thought so. I have see the reference directly to the parent in the "View References" dialog box. Even when the (child) file in question is isolated on a completely diffenent machine.

This "Internal ID", would it happen to have anything to do with the so- called "File Header" I have seen (on rare occasion, in certian errors)? And does this header change when a file copy is made.

I have made copies (Save AS; Save As Copy; as well as using Solidworks Explorer and Windows Explorer) of part files, where the parts are similar and where configurations are not appropriate. So I'm wondering if this "cloning" method can lead to an assembly catastrophe?

Hoping Bob can chime in. I really need to wrap my head around this issue.

Thanks

Brian

Reply to
BWelch

FYI, as much as SW Corp, Var's and people who like SW want to tell you this works... it does not work well. In my experience using SW, parts and assemblies do not handle updating of references well.

To this day, I am forced to "ctrl-q" (rebuild) my parts and assemblies because SW has problems with updating links (sketches, features, incontext relations,...).

So, get use to using "ctrl-q".

This is called, POOR PROGRAMMING and it continues to be this way.

..

" snipped-for-privacy@carrollhealthcare.com" wrote:

Reply to
Paul Salvador

Paul Salvador wrote in news: snipped-for-privacy@verizon.net:

I have noticed some flakey behaviour. For instance, If I replace a file, The assembly still points to the original and to it's original save folder. (so much for portability) Just use A decent text editor and search for the referenced file name.

Have you read the post by Sporkman? - "Seen this one? - Nov 09 Nice, Huh!

Thanks for the feedback Paul

Brian

Reply to
BWelch

Sometimes SW will just tell you something.

I have been working with Solid Edge and they seem to have a better handle on this side of things. For example equations update real time in sketches so that you can drag one part of a sketch and the other equation related parts follow along without a rebuild or any other user action.

I haven't played much with assemblies yet.

In SW assemblies, items in the feature tree seem to update in the order they appear. So first the parts are updated, then the mates, then any sketches that come after the mates, then the inplace holders. Somewhere in that sequence patterns and smart fasteners appear. One thing I have learned is that if I want a sketch to work well as a layout it has to go in before any components are added so it gets first position in the FMT.

Reply to
P.

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.