Autor
|
Thema: Umgang mit Umgebungsgeometrien? (761 mal gelesen)
|
trainman Mitglied CAD/PDM Supporter
Beiträge: 89 Registriert: 19.11.2004 CATIAV5 R16/SmarTeam R16/AutoCAD 2006/WinXPPRO
|
erstellt am: 03. Mrz. 2006 14:12 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen Ich habe noch folgende Frage: Ich frage mich wie wir in unserem Hause mit Umgebungsgeometrien umgehen sollen. Bsp. Ich habe eine Zeichnung von einem Einbau eines Stossdämpfers erstellt auf dieser Zeichnung ist der Stossdämpfer an sich und Umgebungsgeometrien (Carosserieteile, Aufhängung, Felge usw...) abgebildet im Produkt sowie im Drawing. Wenn ich jetzt die Einbauzeichnung freigeben würde, so würde mir SmarTeam nicht nur die Einbauzeichnung und den Stossdämpfer sonder auch die ganze Umgebungsgeometrie freigeben, dies ist aber nicht Sinn und Zweck, die Umgebungsgeometrien, müssen weiterhin für die weitere Bearbeitung zur Verfügung stehen!! Wie habt ihr das in eurem Betrieb gelöst? Was ich mir vorstellen könnte ist eine eigene Klasse (Umgebungsgeometrien) welche z.Bsp. bei der Freigabe Ignoriert werden? oder liege ich hier falsch? Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Nino Stuber Mitglied PLM-Analyst
Beiträge: 22 Registriert: 05.12.2005 Software: Catia V5R14SP8 SmarTeam V5R14SP8<P>Hardware: IBM Intellistation M-Pro
|
erstellt am: 15. Mrz. 2006 14:26 <-- editieren / zitieren --> Unities abgeben: Nur für trainman
Da liegst du falsch. Es ist nicht möglich in SmarTeam, einen hirarchischen Link von der Freigabe aus zuklammern. Das einzige was funktionieren würde, ist eine Klasse, die nicht revisioniert wird. Leider hast du aber diese Daten dann nicht im Vault, sondern auf dem Netzwerkpfad, von wo du diese gespeichert hast. Wir haben diese Problem seit Einführung von Catia und leider noch keine gute Lösung gefunden. Im Moment brauchen wir entweder 2D-Geometrien in der Zeichnung oder die funktion "Convert Product to CATPart". Leider ist dann die Geometrie nicht mehr verlinkt. Gruss Nino Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
hugin66 Mitglied
Beiträge: 106 Registriert: 06.10.2005 Win XP, ST R16SP7
|
erstellt am: 16. Mrz. 2006 18:21 <-- editieren / zitieren --> Unities abgeben: Nur für trainman
Man kann SMARTEAM schon so verbiegen, dass nur das Elternobjekt freigegeben wird, die Kindobjekte aber nicht - LCR machts möglich (siehe Bild). Aber vorsicht! Das ist äußerst kritisch. Der User muss dann nämlich selbst darauf achten, dass seine Konstruktion konsistent bleibt. ------------------
mfg, hugin66 Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
freddyfrisch Mitglied Appication Engineer PLM
Beiträge: 2 Registriert: 28.06.2005
|
erstellt am: 17. Mrz. 2006 09:09 <-- editieren / zitieren --> Unities abgeben: Nur für trainman
|
hugin66 Mitglied
Beiträge: 106 Registriert: 06.10.2005 Win XP, ST R16SP7
|
erstellt am: 17. Mrz. 2006 09:20 <-- editieren / zitieren --> Unities abgeben: Nur für trainman
Wir arbeiten mit R14SP7, sollte aber egal sein. Es gibt im LCR für jede Check-In/Release Regel den Schalter "Check Destination Object Status". Der Schalter legt fest, ob SMARTEAM den Status der Kindobjekte prüft oder nicht. Aber wie gesagt: Vorsicht! In den meisten Fällen ist das nicht sinnvoll! ------------------
mfg, hugin66 Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
hugin66 Mitglied
Beiträge: 106 Registriert: 06.10.2005 Win XP, ST R16SP7
|
erstellt am: 17. Mrz. 2006 09:29 <-- editieren / zitieren --> Unities abgeben: Nur für trainman
Das hab ich vergessen: Für den Documents Tree muss natürlich die Vererbung der LC-Operation abgeschaltet sein, zum Beispiel: Orginaloperation: Release --> Zieloperation: No Operation ------------------
mfg, hugin66 Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |