Back

Navigating the Library Assembly Minefield

Problem

Have you ever tried using assemblies in a library within Autodesk® Vault, then either gave up or put up with the annoying, persistent saves thrown up by Autodesk Inventor®? You know how it is—you finish working on an assembly and hit save, but when you close the document it asks if you want to save. This is usually followed by your mumbled profanities about how stupid Inventor is.

Prior to implementing Vault, the persistent saves were always something that annoyed me, but I could never work out where they came from.

Along came Vault. So I set about updating all of our libraries and standardized all the components. They were then loaded into Vault and released. It was around this time I discovered we couldn't check in any drawing or assembly that used an assembly residing in a Vault library. The Vault add-in requires that every referenced document is fully saved before it will check anything in.

Figure 1: Any files with changes pending are highlighted with an asterisk in the Vault Browser.

If you proceed to try and check in Assembly2.iam you will get the following message:

Figure 2: The Vault check-in “dependent files must be saved” warning.

Selecting 'Yes' will then result in the following dead-end message:

Figure 3: Unsuccessful check-in.

Side note: it would be nice if the Vault programmers provided a list of the problem files, since it turns into quite a task trying to find the troublesome file(s) in a large assembly.

There is a workaround to get the assembly or drawing checked in, but it only works if the file already resides in Vault and that's not the point of this post; nor does this fix the problem.

Thanks to the guys who contribute to the Cracking The Vault blog, I found these two posts:

Changes have been made to some assembly components

Why does my inventor assembly always need saving…

However, once I read the four suggestions at the end of the second post I was disappointed, specifically with points 1 and 2.

Figure 4: Taken from 'Cracking The Vault' Blog post.

It's imperative that we use assemblies and iAssemblies in our libraries and we also have to use a new project file for each new contract we setup in Vault. Neither of these posts gave me a solution, but they did allow me to understand the problem. Fortunately my path crossed with Madhanagopal Thiruvenkatachalam, from Autodesk Singapore. I showed him the problem and he promptly showed me a workaround to use with Assemblies, but we both were stumped when it came to iAssemblies.

Figure 5: Use Rebuild All prior to generating members.

The second potential cause for seemingly odd saves by Inventor is a little understood bug with iParts and iAssemblies. This requires the Rebuild All command to be used once an iFactory has been modified, but prior to the members being regenerated.

Forgetting to use the 'Rebuild All' command prior to regenerating can result in Inventor thinking there haven't been any changes to the members when clearly there has been, so don't forget to use it. I learnt this via a few threads on the Autodesk Discussion Forums, so a quick thank you to all the contributors of that resource.

Note: This is an Inventor problem, not a Vault issue. As a result, it's advisable the following techniques are used whether you use Autodesk Vault or not.

Solutions

By their nature, library paths can't be part of the workspace of any given project. Since library paths are read-only, then one commonly used solution to create, modify, and administer library components, is to create a 'Library' project file with its workspace pointing at the library folder path defined in your normal everyday projects. You could, of course, switch to the Default project, which out of the box doesn't have a workspace defined, but this will likely cause problems as well. As a result, creating 'library' projects is a bad idea that will ultimately cause you problems when it comes to Assemblies and iAssemblies or any parts containing links (derived parts, iParts, and so on).

To be clear, throughout this tutorial I am referring to Project file defined Libraries as opposed to a Vault Library Folder linked to via the project file. So far as Vault is concerned, the library folders referred to by the project file are the same as any other. I don't use Vault Library Folders for reasons I will explain later on.

Library Assemblies

Library Assemblies are simple compared to iAssemblies. Start by setting up your library assembly and its associated components (sub-assemblies or parts) within your normal workspace. You could set up a temp folder for this if you want. Then:

• Move (don't copy) all of the *.ipt files to the appropriate library location using Windows Explorer, because it is faster than saving them individually using Inventor.
• Make sure the assemblies can't find its child components in the workspace and will instead resolve the links to their new location in the library.

Note: You are taking advantage of an Inventor behavioral trait here. If Inventor can't find a file in the project’s workspace, it will then automatically search the other locations defined in the project file, starting with the libraries

• Now open up the sub-assemblies (if there are any), and save them into the library location using the Save As command.
• Open the Parent Assembly and once again use Save As to save it into the library.
• Finally, delete the newly redundant assembly files in the workspace.

If you need to retrospectively edit any part files contained in the library, open them up, save them to your workspace, make the changes, then save them back to the library, overwriting the original.

Figure 6: Save into Library Location warning.

Note: A word of warning. When carrying out form, fit and function changes to library components, you should consider how they are used by Parent files (e.g., modifying a face that has been used to constrain the component to another in an assembly could result in that Constraint failing).

If any of these steps aren't clear, then hopefully this video screen capture will clarify the process.

Library iAssemblies

The iAssembly could be made up of iParts and standard parts or standard parts and another iAssembly etc. There are a number of variations you could create from very simple to complex. For the sake of this tutorial I'm keeping it simple by using an iAssembly made up of one iPart and one standard part, they will take the form of a cabinet concealed hinge and hinge mount. The hinge itself is always the same, but you can clip on different size mounts depending on the configuration of the cabinet door relative to the cabinet side.

1. Start by creating the factories for all your iParts in your project workspace.
2. Once you have your factory set up exactly how you want it, use the 'Rebuild All' command to ensure that all of the factories configuration and properties have been written to the table members.
3. Save the factory into the correct library location and delete the workspace copy.
4. Open the library copy and generate the members. This will 'publish' the iPart members into a subfolder of the library location you chose when saving the factory.

Figure 7: Generate iAssembly members.

Once your iPart members have been generated you can build your iAssembly factory. In my case I have placed the hinge from my library first, since I want that to be grounded, then I have constrained the hinge mounting plate to the hinge.

1. Notice I stated above that I placed the iPart hinge mount from the library, so the file path within the iAssembly factory is a Library path and not a workspace path. Make sure you do the same thing no matter how complex your iAssembly is.
2. Create your iAssembly table for the factory as you normally would.
3. Save the factory into your project workspace.
4. Now you have the iAssembly factory set up and fully configured. Use the 'Rebuild All' command again.
5. Save it into the correct library location, remembering to delete the workspace copy.
6. Open the Library copy and generate the iAssembly members. Once again, this will 'publish' the members into a subfolder within the iAssembly library path.

You now have a library iAssembly and a series of members that are stable and contain the correct library paths instead of workspace paths.

Checking iAssemblies into Vault

1. Create a new assembly and place each version/member available via the iAssembly Factory into it. This ensures every member of each referenced iAssembly and iPart is a part of the newly created assembly.
2. Switch over to the Vault browser, highlight all of the files except the newly created assembly, and check them into Vault

Figure 8: Placing all the variations for check-in.

This approach ensures that every required file and its respective relationship is checked into Vault, as opposed to opening them up and checking them in individually. You can use 
Scheduler to check in the parent folder, especially if you have just created a complex series of iParts and iAssemblies. However, depending on the spread of components across the library subfolders, there are times when it's more convenient to check them in using the method I have just described. I have created a video to demonstrate this here.

You will then need to carry out any of the normal steps you use for your Library parts in Vault. For example, I will make sure they have been categorised correctly, are compliant, and then I release them.

At this point the versions on your local workspace would differ from those in Vault, so deleting or overwriting your local copies with the released Vault versions would be a good idea.

Figure 9: Changing the lifecycle state.

Modifying Vaulted Library iAssemblies and iParts

Whether you need to modify an iAssembly or an iPart, the process is the same, although depending on the change you may have to modify both at the same time.
If you need to, change the state to Work In Progress to gain 'modify' access then do so. Check out the factory and its members.

A technique I use to ensure all members are regenerated is to modify a property in the factory.  This ensures a change is pushed through to all the members. Adding a new member to the table would also require the following steps to successfully publish it and update the other members.

1. Save out the factory from the library to the workspace.
2. Make the modifications, then Rebuild All.
3. Save it back to the library, overwriting the existing copy.
4. Delete the workspace copy.
5. Delete the Old Versions folder.
6. Regenerate the members from the factory.

Figure 10: Deleting the members’ Old Versions folder.

I delete the Old Versions folder (if it exists) in the members' folder, so you can make sure each member has had a new version created when they are regenerated from the factory.

Sometimes, for whatever reason, not all of the members are regenerated; this can cause problems later. There is one very important thing to remember with iAssembly and iPart members: NEVER delete the members to force them into being regenerated. They have a unique identifier, and any dependent file referencing them will throw an error saying the located version of the file is different. Inventor will give you the option of using the new file; however, it breaks any existing constraints you have used. Whereas regenerating members over the top of old ones only modifies the existing file so it retains the unique identifier. As a result, dependent files update perfectly (assuming there hasn't been any dependent geometry removed in the iPart).

Finally, check the factory and its regenerated or new members back into Vault and release them again if necessary.

I have created a video showing this process, since it can be a handful until you have done it a few times.

Conclusion

Ultimately this is a Pig of a process. In future releases, I would like to see improvements in managing assemblies, particularly iAssemblies with respect to libraries.

In addition it would be nice if there was a slick way of checking the iComponent Factories and their members into Vault. It seems the intricate parent and child relationships with iComponents complicate the process. I didn't realise how complicated it was until Vault showed me the relationships via its 'Uses' tab.

The videos and more information about using libraries with Vault have been posted onto the Design & Motion website. You can browse to the specific page by using this address:
http://designandmotion.net/autodesk/mfg-pages/inventor/inventor-vault-library-videos/

I hope this has been a useful tutorial. I follow these steps every time and so far I have a reliable dataset in my library that I can update if needed.

Scott Moyse is the design manager for SMI Group, a super yacht interiors company in New Zealand. His background is in motorsport engineering nad CNC programming. He has been using various Autodesk software for nine years. He can be reached using Twitter @scottmoyse and scott_moyse1@hotmail.com.