Mod the Machine: Understanding File References

Sun	Mon	Tue	Wed	Thu	Fri	Sat
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29

It's been a long time since my last post. I've been busy with Autodesk University preparation and the next release of Inventor.

I thought I would take some time to discuss something that is related to some questions I recently saw on the newsgroup and see come up frequently. The topic is file references.

Overview

To start let's look at a very simple case of creating an assembly. When you first create the assembly (Assembly.iam in this example) it is empty and doesn't have any references to other files. When you place a part into the assembly there are two things that Inventor creates. It creates the occurrence that you see in the graphics window and as a node in the browser, and it also creates a reference to the part file. The file reference isn't something you see in the user interface but is an internal action that takes place.

To make sense of the file reference concept, I visualize the references as a table in each Inventor document. The table is a list of all of the files that file references. The table doesn't know why the reference exists (in this example because of an occurrence being placed), but just that there is a reference to a certain file. Below is a picture that illustrates this. It's the assembly with a single instance of Part1.ipt. We see the part in the graphics window and in the browser. It also shows a representation of the internal table that contains a list of the referenced files, which in this case has a single file in the list.

Now I've added a second part to the assembly, Part2.ipt, with the result shown below. The result shouldn't be surprising; a new occurrence in the graphics window and browser and another file in the reference table.

Now I've added two more instances of Part1.ipt. You see the additional occurrences in the graphics window and the browser but the reference table hasn't changed. That's because there was already a reference to Part1.ipt. There's never more than one reference for a particular file.

When this assembly is opened, Inventor reads the referenced file table, finds the actual file on disk, and opens it. Inventor can then use the contents of that file for whatever the reference is used for; assembly occurrences, drawing views, derived parts, etc.

File References and Where Used

One important thing to highlight here is that the files being referenced, (Part1.ipt and Part2.ipt in this example) don't know they're referenced by another file. Referencing a file doesn't change it in any way. This is important because a part can be used in any number of assemblies or drawings. Also a file might be read-only because of being an approved part and not available for edit or because the file exists on a read-only media.

A couple of the recent questions on the newsgroup had to do with determining where a file is used. Given Part1.ipt they want to know where it is used. It's a reasonable question, but as you can see from the discussion above, it's not a question that Part1.ipt can answer because it doesn't know. Design Assistant supports where used functionality but it does this within the limitations we've just discussed. Design Assistant looks through all of the files in a specified set of directories and reads the referenced file list within each file to see if that file references the file you want the where used information for. This has the limitation that it's only reporting for the files in the searched directories. PDM applications will typically save file reference information in a database when files are checked in and use this data to determine where used information.

Projects

Another topic that's important to understand relative to file references is projects. In the previous example, I explained that when the assembly is opened Inventor reads the referenced file list and then finds and opens the referenced files. To find the files Inventor uses the project information. The easy way to visualize a project is that it defines a list of directories to search. When Inventor reads Part1.ipt from the referenced file list it looks through the directories specified by the project to find Part1.ipt. Because of the flexibility of defining where files are you can easily move files around and as long as the project points to the new location Inventor will find and open the file. The file reference stored is basically just the file name, not the path because the path is dynamically defined by the current project.

Changing References

A common task is to change a file reference. Here's a simple example to illustrate. It starts with the assembly from the previous example where it references two parts; Part1.ipt and Part2.ipt.

I want to make a revision to Part1.ipt so I make a copy to Part1_Rev1.ipt and make the required changes. The picture below illustrates the current situation. The assembly is unchanged but I have a new file, Part1_Rev1.ipt, sitting on my disk.

I want my assembly to use the Part1_Rev1.ipt instead of Part1.ipt, as shown below. There are a few ways to accomplish this but the result is that the reference in the assembly is changed to another file. The occurrences that use that reference automatically reflect the new file.

There are a few ways to get the result shown above. Within Inventor you do it using the Replace Component or Replace All command, which indirectly will edit the referenced file list. You can also accomplish this using Design Assistant. Finally Inventor's API lets you change the file references. In fact, from the API you have direct access to the reference file table, which is also what Design Assistant uses internally.

Limitation

There is one limitation to be aware when attempting to change a file reference. The general rule is that the new file must be a descendent of the original file. In the example above, Part1_Rev1.ipt is a descendent of Part1.ipt because it was created by copying Part.ipt and then subsequently edited. Because of this when the reference is changed, assembly constraints are able to compute correctly and the assembly behaves as expected.