Der "Fingerabdruck" einer Inventordatei

Woher weiß der Inventor, dass eine gleichnamige Datei nicht dieselbe Datei ist, wie die, die ursprünglich in einer Baugruppe verbaut war? Klare Frage oder :)? OK, hier ein Beispiel: In der Baugruppe INV Datei Finger Print.iam ist das Bauteil INV Datei Finger Print_A.ipt enthalten. Die Baugruppe lässt sich ohne Probleme öffnen.

Jetzt schließen wir die Baugruppe und benennen das Bauteil INV Datei Finger Print_A.ipt um in INV Datei Finger Print_A - Original.ipt und ein völlig anderes Bauteil bekommt statt dessen den Namen INV Datei Finger Print_A.ipt.

Das bedeutet wiederrum, das die Baugruppe nun das andere Teil laden muss (den Zylinder), da das ja namenstechnisch an die Stelle des Originalteiles (Platte) getreten ist. Die Baugruppe findet das Bauteil auch, bringt aber eine Meldung, das sich das gefundene Bauteil vom ursprünglich verbauten Bauteil unterscheidet.

C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print.iam hat eine Referenz zu
C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print_A.ipt.
Dies wurde aufgelöst in C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print_A.ipt.
Dies ist nicht die ursprünglich referenzierte Datei. Wahrscheinlich wird eine Verbindung aller Dokumentrelationen fehlschlagen. Möchten Sie das aufgelöste Dokument wirklich verwenden?

Stellt sich die Frage, woher weiß der Inventor, das das Bauteil, das er jetzt laden soll, sich vom ursprünglichen Bauteil unterscheidet? Der Dateiname ist gleich, der kann es also nicht sein.

Inventor legt für jede Datei intern einen eindeutigen "Schlüssel" an, den "InternalName" der eine GUID (Globally Unique Identifier) ist. Die Baugruppe speichert also nicht nur den Speicherort einer Datei ab sondern auch deren "Fingerabdruck", den InternalName und prüft beim Öffnen, ob der gespeicherte InternalName mit dem InternalName des zu ladenden Bauteiles übereinstimmt. Ist dies der Fall, dann wird das Bauteil in die Baugruppe geladen. Ist das nicht der Fall, kommt die Meldung oben.

Noch ein Beispiel: Es werden alle Dateien umbenannt, was dazu führt, das der Inventor beim Öffnen der Baugruppe das gesuchte Bauteil INV Datei Finger Print_A.ipt nicht findet. Er will also, das wir die Referenz auflösen, ihm also sagen, welches Bauteil er laden soll. Geben wir das korrekte Bauteil an, wird dies verwendet da der InternalName des Teiles mit der gespeicherten GUID übereinstimmt.

Geben wir ein anderes Bauteil an, dessen InternalName sich unterscheidet, bekommen wir wieder die Meldung, das sich das angegeben vom erwartetet Bauteil unterscheidet.

Wenn wir ein Bauteil kopieren, kopieren wir auch dessen InternalName. Nun ist dieser "Globally Unique Identifier" plötzlich gar nicht mehr so eindeutig (Unique), was man an diesem Beispiel sieht.

Hier der FileName und der InternalName der Baugruppe und der beiden Bauteil ausgelesen mittels VBA. Man sieht, das der InternalName bei Original und Kopie gleich ist.

C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print.iam
{46E4484B-48A8-F7A6-91A0-C88A8C9D510E}
C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print_A - Original.ipt
{CC57360B-4BE8-F4BF-BCDB-52B9423E01D2}
C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print_A - Original - Kopie.ipt
{CC57360B-4BE8-F4BF-BCDB-52B9423E01D2}

Wird ein Bauteil davon geändert, dann bleibt der InternalName trotzdem gleich, wie man hier sieht.

C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print.iam
{46E4484B-48A8-F7A6-91A0-C88A8C9D510E}
C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print_A - Original.ipt
{CC57360B-4BE8-F4BF-BCDB-52B9423E01D2}
C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print_A - Original - Kopie.ipt
{CC57360B-4BE8-F4BF-BCDB-52B9423E01D2}

Was sich allerdings nun ändert ist die RevisionId der Datei der sich somit zwischen den Daten unterscheidet:

C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print.iam
InternalName:{46E4484B-48A8-F7A6-91A0-C88A8C9D510E}
RevisionID:{30846EEA-CEFE-484A-A17A-7677CD008750}

C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print_A - Original.ipt
InternalName:{CC57360B-4BE8-F4BF-BCDB-52B9423E01D2}
RevisionID:{9DBE7296-4170-91F8-BDC4-F09DE70A1CC6}

C:\Users\jwagner.MUMDRESSLER\Desktop\_\INV Datei Finger Print\INV Datei Finger Print_A - Original - Kopie.ipt
InternalName:{CC57360B-4BE8-F4BF-BCDB-52B9423E01D2}
RevisionID:{23FD747F-E419-D2F5-000B-522AD3208500}

Als ich also ein bisschen rumspiele fällt mir folgendes auf: Wenn sich die RevisionID eines Bauteiles ändert, weil es z.B. (außerhalb der Baugruppe) bearbeitet wurde, scheint die Baugruppe die bekannte Meldung zu bringen, das Änderungen an Komponenten vorgenommen wurde und ob die Baugruppe aktualisiert werden soll?

Seit der letzten Speicherung wurden Änderungen an einigen Baugruppenkomponenten vorgenommen, was sich auf die Komponentengröße und -position auswirken kann. Um diese Änderungen beim Speichern zu berücksichtigen, passen Sie die Aufforderungsoptionen für überarbeitbare Updates in den Anwendungsoptionen an. Soll die Baugruppe jetzt aktualisiert werden?

Wird die Frage mit "Ja" beantwortet muss die Baugruppe anschließend gespeichert werden, weil Sie sonst nicht den neuen Status ihrer Komponenten speichert.

Nach meinen "Forschungen" gibt es folgenden Eigenschaften, die irgendwelche Änderungen speichern: 

• DatabaseRevisionId
• RevisionId
• ModelGeometryVersion
• InternalName

Wann welche Eigenschaften greifen, kann ich leider nicht exakt sagen. Ihr könnt selbst ein bisschen probieren und spielen, indem ihr mit diesem VBA Programm aus einer IAM die Werte auslest:

Public Sub AssemblySample()

    ' Get the active assembly.

    Dim oAsmDoc As AssemblyDocument

    Set oAsmDoc = ThisApplication.ActiveDocument

    Debug.Print oAsmDoc.DisplayName

    ' Call the function that does the recursion.

    Call Assembly(oAsmDoc.ComponentDefinition.Occurrences, 1)

End Sub

Private Sub Assembly(Occurrences As ComponentOccurrences, _

                             Level As Integer)

    ' Iterate through all of the occurrence in this collection.  This

    ' represents the occurrences at the top level of an assembly.

    Dim oOcc As ComponentOccurrence

    For Each oOcc In Occurrences

        ' Print the name of the current occurrence.

        Debug.Print Space(Level * 3) & oOcc.Name

        Debug.Print Space(Level * 3) & "InternalName:" & oOcc.Definition.Document.InternalName

        Debug.Print Space(Level * 3) & "RevisionID:" & oOcc.Definition.Document.RevisionId

        Debug.Print Space(Level * 3) & "DatabaseRevisionID:" & oOcc.Definition.Document.DatabaseRevisionId

        Debug.Print Space(Level * 3) & "ModelGeometryVersion:" & oOcc.Definition.ModelGeometryVersion

        Debug.Print "=============================================================================================="

        ' Check to see if this occurrence represents a subassembly

        ' and recursively call this function to traverse through it.

        If oOcc.DefinitionDocumentType = kAssemblyDocumentObject Then

            Call Assembly(oOcc.SubOccurrences, Level + 1)

        End If

    Next

End Sub

Die Beispielbaugruppe, die ich genutzt habe gibt's hier zum Download. Dort ist auch das VBA Programm enthalten!

OK, das soll's mal dazu gewesen sein. Wenn einer mehr/bessere Infos und Ergänzungen dazu hat, rein damit in den Kommentar!