---

Moin!

Beim Öffnen älterer (Gesamt-)Baugruppen bekomme ich infolge von allfälligen Änderungen am genutzten Datenbestand viele Störungsmeldungen.

Nicht mehr auffindbaren Komponenten sind das eine, aber die lassen sich ja leicht neu zuweisen oder auch überspringen - sogar alle auf einmal, also kein Problem.

Mit den Abhängigkeiten ist es weniger leicht. Auch da bekomme ich viele Störungsmeldungen, weil irgendwelche Kanten oder Flächen an irgendwelchen Bauteilen durch irgendwelche Änderungen nicht mehr vorhanden sind oder eine neue Identität bekommen haben. Weil die betroffenen Komponenten aber trotzdem an ihrem Platz sind und auch da bleiben können, würde ich gern alle gestörten Abhängigkeiten in einem Rutsch über alle Ebenen kurzerhand ersatzlos löschen. Abhängigkeiten neu zu vergeben ist nämlich weniger Arbeit, als sie zu reparieren.

Ist so was aufwändig zu programmieren, oder reicht dafür ein mittlerer Zauberspruch?

------------------
Roland  
www.Das-Entwicklungsbuero.de

It's not the hammer - it's the way you hit!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin

Abhängigkeiten werden immer in der jeweiligen Baugruppe gespeichert. Von daher muss man nur alle referenzierten Baugruppen und die oberste Baugruppe einzeln absuchen. Ich habe eher Schwierigkeiten damit die einzelnen Fehlerstatus zu verstehen. Ich hab dir mal alle Optionen mit rein gepackt. Die Fehlerursache "fehlende Referenz" z.B. durch eine nicht mehr vorhandene Fläche ist aktiviert und würde gelöscht. Vielleicht erstmal einen Durchlauf so probieren und wenn noch welche übrig bleiben mal schauen, welcher Status zutreffen könnte und ggf. dort auch den "oCons.Delete" einfügen.

Code:

---

Option Explicit

Public Sub RecursiveDelSickConstraints()

Dim oApp As Inventor.Application
Set oApp = ThisApplication

Dim oAssDoc As AssemblyDocument
Set oAssDoc = oApp.ActiveDocument

Dim oDoc As Document
Dim oRefedAssDoc As AssemblyDocument

For Each oDoc In oAssDoc.AllReferencedDocuments
    If oDoc.DocumentType = kAssemblyDocumentObject Then
        Call DelSickConstraints(oDoc)
    End If
Next

Call DelSickConstraints(oAssDoc)

MsgBox ("Fertig")
End Sub

Private Sub DelSickConstraints(ByVal oAssDoc As AssemblyDocument)
       
    Dim oCons As AssemblyConstraint
    For Each oCons In oAssDoc.ComponentDefinition.Constraints
        Select Case oCons.HealthStatus
            Case kBeyondStopNodeHealth:            'Object is beyond stop node in the browser.
            Case kCannotComputeHealth:              'Object cannot be evaluated.
            Case kDeletedHealth:                    'Object has been destroyed. You may be holding on to an empty 'shell' of the Object.
            Case kDriverLostHealth: oCons.Delete    'Object is driven by data from other Object(s), and one or more of them have been disconnected.
            Case kInconsistentHealth:              'Object is inconsistent with another object.
            Case kInErrorHealth:                    'Object's internal state is in error.
            Case kInvalidLimitsHealth:              'Object has bad limits. e.g. max < min.
            Case kJointDOFLockedHealth:            'Object is locked Joint.
            Case kNewlyAddedHealth:                'Object is newly added or unsuppressed and has not been solved yet.
            Case kOutOfDateHealth:                  'Object needs to be recomputed with respect to its 'driver(s)'.
            Case kRedundantHealth:                  'Object's solution is redundant with another object.
            Case kSuppressedHealth:                'Object has been suppressed.
            Case kUnknownHealth:                    'Object's status is not known.
            Case kUpToDateHealth:                  'Object is up to date.
        End Select
    Next
End Sub

---

------------------
MfG
Ralf

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Vielen Dank!

Erster Test:
- Code in den Editor kopiert
- F5
- Inventor mit der geöffneten Gesamt-Baugruppe mit den kranken Abhängigkeiten stürzt ab.

Anmerkung:
Es war die Liste mit allen Störungsmeldungen vom Design-Doctor geöffnet.

------------------
Roland  
www.Das-Entwicklungsbuero.de

It's not the hammer - it's the way you hit!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Test2:
- Liste geschlossen, dann stürzt nicht ab. (Was nicht heißen soll, dass es daran lag. Vielleicht war es ja auch etwas ganz Anderes.) Vor allem: Die Fertig-Meldung kam auch beim ersten Test schon.

- Es werden viele Abhängigkeiten gelöscht, auch in den Unterbaugruppen, aber nicht alle. Die Unterbaugruppen werden auch zum Speichern gekennzeichnet.

-Die noch übrigen Abhängigkeiten werden von dem Makro auch dann nicht gelöscht, wenn die betroffene Baugruppe einzeln geöffnet ist, die Abhängigkeiten also auf der obersten Ebene sind.

Diese Abhängigkeiten haben die Spezifikation "Inconsistent Relationship".

------------------
Roland  
www.Das-Entwicklungsbuero.de

It's not the hammer - it's the way you hit!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin

Das mit dem Absturz könnte in der Tat daran liegen, dass mit dem Fenster ein Kommando aktiv war. Man könnte vorab noch schauen ob

Code:

---

oApp.ActiveCommand = Nothing

---

ist und ggf. mit

Code:

---

oApp.CommandManager.StopActiveCommand

---

dieses erst abbrechen.

Dann eränze mal bitte die Zeile zu

Code:

---

Case kInconsistentHealth: oCons.Delete

---

Ich habe wie gesagt erstmal nur eine Möglichkeit aktiviert, um schrittweise voran zu tasten. Leere Baugruppe geht schneller, ist aber nicht zielführend. :D

Weitere potentielle Kandidaten wären:

Code:

---

Case kCannotComputeHealth: oCons.Delete
Case kInErrorHealth: oCons.Delete
Case kInvalidLimitsHealth: oCons.Delete
Case kRedundantHealth: oCons.Delete

---

------------------
MfG
Ralf

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin!

In einem weiteren Versuch hat es nichts ausgemacht, ob die erwähnte Liste geöffnet war oder nicht. Vielleicht aber auch, weil dann keine Abhängigkeiten mehr gelöscht wurden und somit der Inhalt der Liste nicht zu verändern war. Ich werde das weiter beobachten.

Zu meinem Verständnis:
Es gibt im VBA keine generelle Kennung wie z. B. das gelbe Zeichen im iam-Browser, die anzeigt, dass eine Abhängigkeit gestört ist, sondern wir müssen jede Art von möglicher Störung individuell abfragen, und benötigen deswegen die case-Liste. Und in dieser Liste war bisher nur in dem einen Fall auch das Löschen aktiv, während die anderen Fälle noch leere Hülsen darstellen.

Sind das denn jetzt alle möglichen Störungsarten?

Ich sehe auch schon eine Anwendung für diese Unterscheidung:
Bei nicht aufgelösten Komponenten würde ich die dadurch ebenfalls unklaren Abhängigkeiten lieber zunächst behalten, weil sie ja wieder gesunden, wenn die Komponente später gefunden ist. (Die haben dann aber auch ein anderes Zeichen im iam-Browser.)

------------------
Roland  
www.Das-Entwicklungsbuero.de

It's not the hammer - it's the way you hit!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ich habe es jetzt (leider unabsichtlich und mit Verlust) verglichen:

Wenn das Makro Abhängigkeiten löscht, während das Design-Doctor-Fenster mit der Liste gestörter Abhängigkeiten angezeigt wird, kommt es anschließend (!) zum Absturz.

Es wäre schon besser, das abzufangen, denn wenn es gestörte Abhängigkeiten gibt und das rote Kreuz erscheint, ist es sehr naheliegend, diese Liste anzusehen.

Allerdings ist der Start über F5 im Editor ja nicht der Standard.

Ist es in der normalen Umgebung überhaupt möglich, eine andere Funktion zu starten, während das Design-Doctor-Fenster mit der Liste gestörter Abhängigkeiten angezeigt wird?

------------------
Roland  
www.Das-Entwicklungsbuero.de

It's not the hammer - it's the way you hit!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin

Jain, es gibt in dem Sinne keine einzelne Kennung. Man könnte es umdrehen und alle Abhängigkeiten nehmen deren Staus nicht "kUpToDateHealth" ist. Die wären dann in irgendeiner Weise krank.

Die Liste im Makro enthält alle möglichen Status. Mehr gibt es aktuell nicht.

Ich glaube die kaputten Abhängigkeiten durch nicht aufgelöste Teile fallen in den Status "kCannotComputeHealth". Ist aber mehr geraten als gewusst.

Man kann auch in der normalen Umgebung das Makro bei geöffnetem DesignDoctor starten. Ich hab mal eine Zeile zum Beenden des aktiven Kommandos hinzugefügt. Das sollte die Abstürze verhindern.

Code:

---

Option Explicit

Public Sub RecursiveDelSickConstraints()

Dim oApp As Inventor.Application
Set oApp = ThisApplication

If Not oApp.CommandManager.ActiveCommand = "AppSelectNorthwestArrowCmd" Then oApp.CommandManager.StopActiveCommand

Dim oAssDoc As AssemblyDocument
Set oAssDoc = oApp.ActiveDocument

Dim oDoc As Document
Dim oRefedAssDoc As AssemblyDocument

For Each oDoc In oAssDoc.AllReferencedDocuments
    If oDoc.DocumentType = kAssemblyDocumentObject Then
        Call DelSickConstraints(oDoc)
    End If
Next

Call DelSickConstraints(oAssDoc)

MsgBox ("Fertig")
End Sub

Private Sub DelSickConstraints(ByVal oAssDoc As AssemblyDocument)
       
    Dim oCons As AssemblyConstraint
    For Each oCons In oAssDoc.ComponentDefinition.Constraints
        Select Case oCons.HealthStatus
            Case kBeyondStopNodeHealth:            'Object is beyond stop node in the browser.
            Case kCannotComputeHealth:              'Object cannot be evaluated.
            Case kDeletedHealth:                    'Object has been destroyed. You may be holding on to an empty 'shell' of the Object.
            Case kDriverLostHealth: oCons.Delete    'Object is driven by data from other Object(s), and one or more of them have been disconnected.
            Case kInconsistentHealth: oCons.Delete  'Object is inconsistent with another object.
            Case kInErrorHealth: oCons.Delete      'Object's internal state is in error.
            Case kInvalidLimitsHealth:              'Object has bad limits. e.g. max < min.
            Case kJointDOFLockedHealth:            'Object is locked Joint.
            Case kNewlyAddedHealth:                'Object is newly added or unsuppressed and has not been solved yet.
            Case kOutOfDateHealth:                  'Object needs to be recomputed with respect to its 'driver(s)'.
            Case kRedundantHealth:                  'Object's solution is redundant with another object.
            Case kSuppressedHealth:                'Object has been suppressed.
            Case kUnknownHealth:                    'Object's status is not known.
            Case kUpToDateHealth:                  'Object is up to date.
        End Select
    Next
End Sub

---

------------------
MfG
Ralf

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP