Troubleshooting Inventor Errors from Duplicate Files29 Nov, 2016 By: Mark Flayler
IMAGINiT Tricks Tutorial: Learn about the “Duplicate Files” and “Different Than Expected” dialog boxes in Autodesk Inventor, and how to correct the issues that cause them to appear.
Editor's note: This tutorial courtesy of IMAGINiT Technologies.
As Autodesk Inventor users, we sometimes find ourselves scratching our heads at certain error dialog boxes that pop up. This usually is more common when we have multiple users wreaking havoc in an unconstrained environment. One such dialog I see when users have poor file management or design practices is the dreaded "Different Than Expected" error message upon opening a file.
Much like encountering a smaller-than-expected tax return or a bad blind date, we are usually shocked by the affront to our eyes, and we feel betrayed — the assembly should have opened cleanly, our new swimming pool depends on the larger tax return, and the blind date should have looked like our friend said they would. Now I can't explain away the latter two, but let's take a crack at the Inventor issue.
We could have a very lengthy discussion about why this happens, but let's keep it short and sweet instead with these facts:
- This almost never happens with Vault users (unless you have a really messy local workspace).
- This almost never happens when you have good file naming practices.
- This usually happens when you have a shared network workspace that others can access and freely copy to and modify.
- This has been found to usually affect Libraries where no control is enabled over server write access.
The issue that Inventor has is that the file the assembly is looking for does not match the file that Inventor found in the project workspace. What? They have the same name, so what's the deal? Well, you have found yourself a name duplicate, but the file is technically different.
Let’s look at the two files and see what is actually different, shall we? As you can see below, the files are geometrically the same, but their modeling is different. One was converted from a non-native Inventor file through a translation; the other was modeled with an Extrusion. So in this case, not only is the name the same, but the mass properties and sizing are identical — so what’s the problem?
Well, Inventor has different internal file IDs that really determine which file is the correct file. If an assembly is opened and the internal file ID is not returned to be the same, then the dialog box will appear and you will have to investigate the problem. Your best bet is to stop what you are doing and compare the files to see what is going on. You may not have the right file in your workspace, you might have two really different files on your hands, or maybe this is the only file you have and the other was lost due to being overwritten.
If you find yourself in this predicament, where the name and the sizing match but the error still results from the mismatch in file IDs, then you can accept the error and move on — with the understanding that all heck may break loose when you get to your assembly.
Now this is the moment when your palm will smack your forehead, because you thought you were good with the file name and the actual geometry. After all, it looked the same, right? Well, the internal file ID is not the only problem. When you choose references for relationships, whether they are joints or constraints, they have their own unique identifier in Inventor, and therefore are no longer valid in the assembly!
With this realization, I hope a ray of light has just illuminated your cubicle (and not just the fluorescent kind). This is why a lot of issues arise in this type of workspace, and without proper file security or tracking.
This is also why assembly relationships fail when modeling changes in parts are done that delete and recreate features. In just this one case, I have to fix 17 relationships because something happened outside of our procedures, or because of a lack thereof. Now imagine that this file was used in 10, 20, or 30 more assemblies, and how I will have this problem compounded for all of those designs.
So here is the exact culprit in this particular case: A user downloaded a STEP file and simply decided at some point to model it in Inventor as a normal part, and replaced it in the library that everyone uses. So there is no old version of this file anymore, there is no easy recovery method to get it back — in short, there is no “easy button” to fix this problem.
I have also seen this happen when users have iPart factories stored locally and they overwrite others on a server as they put designs back. Anytime a new file is generated from a template, it will create a new internal file ID. The only time an internal file ID does not change is if you perform a Save Copy As or a Save As. That is why files that are derivative of others have fewer issues with relationships (commands like Save As and Replace).
To sum up: Keep track of your files and of what your team is allowed to do. This could easily be a couple of pages in a CAD manual.
Want to see this internal file ID for yourself? Try out the iLogic code below. (Tech Tip: I use it as an external rule so I can run it whenever I want.)
SyntaxEditor Code Snippet
'code to check for File ID
oDocDisplayName = ThisDoc.Document.DisplayName
oDocName = ThisDoc.FileName(True)
oDocFullFileName = ThisDoc.Document.FullFileName
oDocInternalName = ThisDoc.Document.InternalName
oMessage = "Display/Browser Name: " & oDocDisplayName & vbLf & _
"File Name: " & oDocName & vbLf & _
"Full File Name: " & oDocFullFileName & vbLf & _
"Internal Name: " & oDocInternalName & vbLf & _" "
MessageBox.Show(oMessage, "File ID Tech Check")