---

Gibt es eine Möglichkeit in einer komplexen Baugruppenstruktur (mehrere Ebenen von Unterbaugruppen ) alle Teile und Unterbaugruppen automatisch oder mit relativ geringen Aufwand auf die aktuellste Revision zu aktualisieren.
Danke
Bettina

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

---

hallo bettina,

also falls ich dich richtig verstehe, gibtŽs folgende möglichkeiten:
1. allgemeingültig
- in tools | admin options | lc options | out of vault tab | latest revisions button ... kann man die option " always checkout latest available revision" selektieren
2. user-dependant
- im lc-window gibtŽs eine option unter dem "actions" menü, die da heißt "switch to latest available. hier kann man ein multiple select machen ...

hoffe, das warŽs, was du meintest ...

gruß
voje

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

---

Hi VOJE!

Ich glaube das löst das Problem noch nicht ganz!
So kann man zwar alle Komponenten (BGŽs u. Teile) auf die neueste Version setzen, aber wenn man nicht sämtliche Baugruppen, die von einer solchen "Aktualisiering" ihrer Teile betroffen sind auscheckt, dann ist die Umstellung wieder verloren.

Genau hier liegt der Knackpunkt! Wie in einer komplizierten BG-Struktur möglicht das ganze automatisch abwickeln. Das heißt Smarteam müsste wenn ein Teil in eine neuere Version gesetzt wird, automatisch schauen was die nächstdarüberliegende Baugruppe ist, u. die für einen check out markieren u. dies müsste natürlich bis rauf zur obersten Baugruppe durchgezogen werden (außer man überschreibt dann die Unter-BG Revison, dann ist die nächsthöhere BG ja immer noch aktuell)!

Aber wie man das am besten hinbringt ist die Preisfrage!

lg
Bruno

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

---

hi bruno,

ich glaube hier rennen wir in eine allg. philosophiefrage von parametr. CAD- und PDM systemen...nämlich der allg. frage wie soll das baugruppenhandling v.a. beim modifizieren sein. einen einheitlichen standard gibt es hierfür wohl nicht, egal welches system man sich anschaut. ich denke, es ist wichtig die unternehmensspezifischen anforderungen zu kennen.

alle diskutierten möglichkeiten haben sicherlich ihre vorteile und nachteile. zu den aufgeführten möglichkeiten hast du bereits schon stellung genommen. aber auch die weiteren auführungen von dir bergen punkte in sich, die man für sich abwägen sollte, z.b.

- wenn ohne auschecken ein automatisches update der parts im assy erfolgt, kann die neue version des parts nicht mehr kompatibel mit dem assy sein (geom. änderung, v.a. wichtig bei teilen, die in mehreren assys eingebaut sind). damit fällt dann der aufruf des assys auf die nase....im design-prozeß nicht ganz so tragisch, aber wenn das objekt ungesehen released wird...
- man hat keinen "eingefrorenen" stand der baugruppe mehr. da immer der aktuelle stand von teilen ohne auschecken der baugruppe zugewiesen wird, ist keine nachvollziehbare historie mehr da und man kann nicht auf einen "alten" stand zurückspringen.

ich möchte hiermit einfach nur sagen, daß das thema baugruppen und deren handling in PDM-systemen ein thema ist, worüber man sich gedanken machen sollte. das ist weder SmarTeam noch CATIA spezifisch, sondern gilt eher allgemein...

lg
voje

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

---

Bild1.jpg

Hallo Brim,

die von Dir geforderte Funktionsweise läßt sich offenbar in der Tat realisieren, indem im Lifecycle Rules Setup zwei neue Regeln hinzugefügt werden. Für ein einzelnes Part in einer Baugruppe hat es bei mir zumindest funktioniert. Nur, ob das zielführend ist, wage ich zu bezweifeln.

Alternativ kann der Anwender während des Checkin-Vorgangs eines Objekts aber auch wählen, die Eltern der Vorgänger-Version auf diese neue Version umzulinken (im Actions menü). Das bietet den Vorteil, daß die Eltern-Baugruppen nicht ständig versioniert (und damit gesperrt) werden müssen. Nachteil: Wer weiß, welcher Schaden dadurch angerichtet wird.

Ich denke die von VOJE angeführte Administrator-Einstellung ist eine gute Lösung. Dadurch kann ich auf dem obersten Knoten einer Baugruppe einen checkout initiieren. Anschließend selektiert der Anwender im Lifecycle Fenster "Propagate Operation", wodurch
a) alle Objekte werden innerhalb der Struktur in deren neueste Version gesetzt werden
b) alle Unter-Elemente auf ausgechecheckt gesetzt werden (schadet nicht, da ich so eine konsolidierte Version erhalte)
Damit habe ich also ein update über die gesamte Struktur erreicht.

Grüße
KleinerMuck

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