Autodesk recommend the use of the single project file method, this is an excerpt from their white paper on the subject:
The first point is valid if you work on a large number of short duration projects but it’s the third point which will determine if you should consider using a single project file or not.
That is; if you regularly reuse CAD models from old or existing projects in new ones then using a single project file is likely the way forward for you.
However, if like SMI, each product you design is completely unique 99% of the time and the materials etc. vary constantly from project to project then you should consider using multiple project files, albeit following some strict guidelines.
The Root of the Issue…
We work on the concept of having a master project file to use in Vault and a new project file for each new contract we have in the design office for use within Inventor.
With Inventor Project Libraries
Place all the project files in the ($) root directory, along with the library folders and a single ‘Projects’ folder which contains all the project workspace folders. The diagram below shows how the workspaces for each project file are setup in relation to the folder structure.
Without Inventor Project Libraries
using lifecycle controlled ‘library’ folders:
For Multiple Projects to work there are a few things you need to understand if you don’t already:
- Assemblies saved in the project workspace have searchable links to their children. The assembly file contains a path to its children, but its not fixed. This means when you use an Inventor project file set to use unique file names, you can move any of those child files anywhere within the workspace. Conveniently, when you open the Assembly the child links get resolved automatically when Inventor searches the project workspace for a file of that name.
- Assemblies in a project library have fixed or hard coded file path links to their children. This improves performance when opening the assembly since Inventor doesn’t have to perform any kind of search. However, it means you can’t move any of the child files since it will break the file links within the assembly. Its also important to note library paths are relative and not full paths.
This behaviour isn’t restricted to just assemblies, but to any file relationship; derived parts, iParts & iAssemblies etc.
Considering these traits, there are some rules you must adhere towhen creating your project files:
- Always make sure project libraries have the same name from one project to the next, including the Vault Master Project
- Always make sure the project libraries are pointing to exactly the same set of folders, so the relative path doesn’t change from one project file to the next
- If you are using Content Center, stick to the same Content Center definitions and folder structures
Now here’s the good bit, some freedom, you can changethe following aspects of a project file:
- The workspace. (This would have to be the same across all projects if you use the structure in the 2nd image)
- The Design Data folder
- The Templates folder
Having this flexibility means you can:
- Define a different set of templates for each project. This is helpful if you have project specific iLogic rule event triggers set on your template files
- Define project specific style libraries for all file types, this is useful when it comes to drawing styles
- My favourite benefit is the ability to focus your Materials & Appearances to just the ones you need for the project
- You can still use Vault’s Copy Design tool to copy designs from one project to the next utilising the Vault Master Project.