---

Hallo zusammen,

mir ist folgendes im Zusammenspiel zwischen Pro/I und Pro/E aufgefallen:

Ich rufe ein Modell aus dem WS auf , im Pro/E wird mit dem Bauteil NICHTS gemacht (weder gedreht, schattiert etc.), dann speichere ich das Modell.
Im WS wird das Objekt nach einem Refresh als geändert markiert!!

Warum 

Welche Einstellung im Pro/E kann das verhindern?

------------------
Bis dann
Hans Fröhlich

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

---

Hi fröhlich,

jaaaaaa, das hatten wir auch schon. 
Speziell bei einem Kunden ist das der Fall, weil dort mit Merge-Baugruppen gearbeitet wird. Zum Beispiel wenn in einer Komponente nur das Rohteil erstellt wird und in einer weiteren Komponente nur die mechanische Bearbeitung.
Eine Lösung ist uns dazu nicht eingefallen, außer der Information der Anwender.
Bitte prüfe einmal, bei welchen Baugruppen das auftritt. Vielleicht ist da auch sowas wie ein Mgerge drin...

Grüße

D. Bexkens

PS: Kleiner Nachtrag. Das Problem liegt IMHO nicht im Intralink sondern im Pro/E. Denn dort wird die Baugruppe mit einem "+" versehen.

[Diese Nachricht wurde von dbexkens am 27. Februar 2002 editiert.]

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

---

Hallo Fröhlich,

wie ist denn eigentlich eure config.pro eingestellt?

Sind da Typen wie "save_model..." oder "save_Objekt" drin?
Warum sind die da drin und wie sind sie gesetzt?
gruß
Andreas

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

---

Hallo,

also hier ist ein Auszug aus unserer config.pro:

                            override_store_back NO
                            save_object_in_current NO
                            save_display YES
                            STORE_DISPLAY YES
                            save_modified_draw_models_only YES
                            !STORE_DEPENDENT_OBJECTS CHANGED_ONLY
                            compress_output_files NO
                            rename_drawings_with_assem YES
                            save_objects CHANGED_AND_SPECIFIED
                            instance_search_exhaustive NO
                            !SAVE_MODEL_DISPLAY SHADING_LOD
                            !SAVE_DRAWING_PICTURE_FILE BOTH
                            save_instance_accelerator NONE
                            rename_drawings_with_object BOTH

------------------
Bis dann
Hans Fröhlich

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

---

Hallo Hans,

wenn ich mir das so anschaue, dann heißt das für mich, das durch das Speichern, (auch wenn keine änderungen vorgenommen worden sind) werden die "ÄNDERUNGEN" gespeichert.
entweder bleibt das so wie es ist?! 
oder Ihr löscht den Wert
save_object aus der Config Pro
oder Ihr stellt um auf changed

changed_and_specified — Speichert stets das Objekt der höchsten Ebene sowie die veränderten abhängigen

eine von den 3 Möglichkeiten hat bis jetzt immer geholfen.

Sonst kann es auch noch eine einstellung in den Preferences geben aber (ProI2.0?) das weiß ich nicht mehr so genau, da ich schon länger mit 3.0 arbeite. Da passieren solsche Dinge nicht.

Ich hoffe das hilf weiter.

Gruß
Andreas

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

---

Zitat:

---

Original erstellt von andschne:
...
oder Ihr löscht den Wert
save_object aus der Config Pro
oder Ihr stellt um auf changed

---

Hier noch mal die möglichen Values für save_object:
changed_and_specified=
-Ausgewähltes Objekt und geänderte Abhängige Speichern (IST DER STANDARD-WERT, gilt auch, wenn Save_object NICHT gesetzt ist!)
changed=
Speichert nur geänderte Objekte und sollte hier auch Abhilfe schaffen
All=
Speichert alle Objekte, egal ob geändert oder nicht!

Hoffe, das hilft weiter,

T. Vorschuetz

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

---

Hallo Hans,

wir hatten vor längerem das selbe Problem.
Folgende (undokumentierte) config.pro-Option verhindert dies:
relat_marks_obj_modified no

Siehe auch: http://www.ptc.com/cs/tpi/107361.htm

Giggel 

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

---

Hallo,

Nur noch mal so dumm nachgefragt 
warum speichert Ihr etwas was Ihr doch nicht verändert habt?

Der Üblische Weg ist doch Anschauen und wenn ich nicht geändert habe das Teil aus dem Speicher Herauslöchen oder etwa nicht?

Gruß
Andreas

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

---

Hallo,

so wie das Problem von fröhlich geschildert wurde, stellt sich auch mir die Frage nach dem Sinn des speicherns eines nicht geänderten Objekts.
Jedoch werden bei mir immer wieder in einer Baugruppe verbaute "nicht geänderte" Teile beim Speichern der BG mitgespeichert.
z.B. Scheiben DIN 125 mittels Ausrichten und gegengerichtet eingebaut.
Mit der config-option "relat_marks_obj_modified no" kann das doch nichts zu tun haben.

Wir haben das in Intralink 2.0 auf folgende Weise gelöst:
eingeloggt als "user" - Normteile bzw. freigegebene Zeichnungen, Teile sind schreibgeschützt.
eingeloggt als "Intralink" - ändern der schreibgeschützten Teile möglich.

Ist zwar ein Mehraufwand, aber es funktioniert.

Gruß
us 1

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

---

Hallo us,

So sehe ich das auch! alle Teile die ich nicht verändern darf bekommen den "Status" Freigegeben oder so und können damit nicht mehr im alltäglichen Arbeiten verändert werden.

Gruß

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

---

Hallo hier nochmal eine Info zu der config von us 1!
Genau dieses Problem wie von us 1 geschildert hatten wir auch. DINteile wurden gespeichert obwohl in der Baugruppe nicht geändert (hundertpro nicht). Mit er config relat_.. wird nur ein Bug gemildert. In der 2000i2 Version 2001500 sol das gefixt sein. Auch der Schreibschutz soll als Workarround helfen. Eigentlich unverständlich, den unsere Normteile dürfen nur vom Administrator geändert werden. Alle anderen haben sowieso keine Schreibrechte.

Es würde mich sehr interessieren ob der Bug in der 2001500 gelöst ist oder ob wieder alte Fehler drinnen sind.

Das mit den Mergeparts und dem Regenerieren kann man vielleicht so beheben.
Daten auschecken und das Mergeteil (also das Teil was in ein anderes verschmolzen wurde) gleich wieder löschen. Klingt blöd, das Verschmelzungs-KE wird dann eingefroren und zieht erst wieder nach wenn es das Referenzteil findet (sogar leicht bessere Performance).

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

---

Hallo,

zufälligerwiese über diesen Beitrag gestolpert

@ehlers Das mit dem geändert + soll nach meine Kentnisstand in der 2002080 bzw 2002060 gefixt sein

Für 2000i2 und intralink 2

Haben wir folgenden Workaround für irrtümlich geänderte Normteile, die nicht geändert werden dürfen (Problem Pro/E speichert nicht)
Die Normteile sind in der Commonspace schreibgeschützt.
In der Workspace Status ändern auf schreibgeschützt

Das mit den Config-Optionen werde ich im Ärgerfall mal testen.
Das mit dem Merge und Baugruppenschnitten  hatte ich auch schon.

Servus Alois

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

---

Hi anagl,

wenn die Objekte im WS auf "schreibgeschützt" stehen, wird doch im Pro/E gleich beim Aufruf für jedes Modell ein Fenster aufgemacht mit der Info dazu, wobei der geneigte Anwender dies zu bestätigen hat.
Bei großen Baugruppen mit vielen schreibgeschützten Modellen müssten deine Schutzbefohlenen doch ziemlich ins Fluchen kommen. Oder vertue ich mich da.... *grübel*

Grüße

D. Bexkens

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

---

Hallo D. Bexkens

Ich habe mich vielleicht nicht ganz klar ausgedrückt:

Das ist der "Notnagel" und nicht das Standardvorgehen für den Fall, dass Baugruppen nicht gespeichert werden können weil Familien-Tabellen-Teile irgendwie von Pro/E geändert werden. Das hilft über das aktuelle Problem des Nicht-Speichern-Könnens
(Pro/E sagt kann nicht gespeichert werden ->WS-Status auf schreibgeschützt ändern Speichern geht in Pro/E mit Konflikt)
-> Die Konfliktmeldung ist in diesem Fall vernachlässigbar

Scheinbar sieht es mit 2001510 bei 2000i2 besser aus

Alle User als Schutzbefohlene zu betrachten ist manchmal schon sehr schwierig
<IRONIE> Die Steigerung von "DAU" ist "DAA" (dümmster anzunehmender Administrator) <IRONIE>

Servus

Alois

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

---

@dbexkens
Diese Meldung erscheint nur für die Baugruppe, wenn sie schreibgeschütz ist.
Erst wenn die gesperrten Komponenten aufgerufen werden erscheint die Meldung.

Übrigens es war einmal ein Bug:
Wird die Baugruppe gesperrt ein Anwender hat für sein Teil, ich nenne es mal A, Berechtigungen und Teil B ist auf die Stirnfläche von A verbaut, so zieht beim Regenerieren Teil B nicht mit wenn A in der Länge verändert wird. Man somit auf einmal Durchdringung oder einen Spalt.
Würde mich mal interessieren ob das noch so ist?

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