Sometimes as Inventor users we find ourselves scratching our heads at some dialog boxes. This usually is more prominent when we have multiple users wrecking havoc in an unconstrained environment. One such dialog I see with users with poor file management or design practices is the dreaded "Different Than Expected" error message when you open up a file. Much like a smaller tax return or a bad blind date, we are usually surprised with the upfront travesty to our eyes and we feel an immediate pit in our stomach because the assembly should have opened cleanly, the pool should be going in with 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.
Now we can have a very lengthy discussion about why this happens but let's keep it short and sweet 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 are the same name so what's the deal? Well you have found yourself a name duplicate but the file is technically different hence, the different than expected error. Well, lets 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 and the other was actually modeled with an Extrusion. So in this case, not only is the name the same, but the mass properties and sizing are identical, so still, what gives?
Well, Inventor has different internal file IDs that really determine what 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 actual 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.
Now if you find yourself in this predicament where the name and the sizing actually match but the error is still thrown due to 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 where your palm will hit your face because you thought you were good with the file name and the actual geometry. It looked the same after all 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 post I hope a ray of light has just enlightened your cubicle and not just the flashing florescent light kind. This is why a lot of issues happen in this type of workspace and without proper file security or tracking. This is 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 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 to get it back, there is no easy button around this issue. 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 less issues with relationships (commands like Save As and Replace).
To wrap it up, keep track of your files and what your team is allowed to do. This could easily be a of couple pages in a CAD manual.
Want to see this Internal File ID for yourself? Try out this iLogic code...
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")
Tech Tip: I run it as an external rule so I can run it whenever I want on any file.
About the Author
Follow on Linkedin More Content by Mark Flayler
