| | |
 | Gut zu wissen: Hilfreiche Tipps und Tricks aus der Praxis prägnant, und auf den Punkt gebracht für Creo |
| | |
 | BOM Assistant für Stücklistenerstellung , eine App
|
|
Autor
|
Thema: Interner Bezug (901 mal gelesen)
|
Beingodik Mitglied
 
 Beiträge: 244 Registriert: 28.03.2002
|
erstellt am: 16. Mai. 2002 07:28 <-- editieren / zitieren --> Unities abgeben:         
Ahoi. Ich hab mal wieder ne Frage. Beim öffnen einer größeren Baugruppe bekomme ich die Fehlermeldung: WARNUNG: Bezug (interne ID = 1171) auf Baugruppen 0815_Fliwatüt_XYZ wurde eingefroren. 1. Was will mir ProE damit sagen? (Regenerieren Funktioniert - Die Baugruppe ist in Ordnung) 2. Wie Behebe ich diesen Fehler oder Warnung? Dank im Voraus. ------------------ Bis denne Die Antwort liegt irgendwo da draussen. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Sonja1 Mitglied Konstruktion/CAD-Betreuung
 
 Beiträge: 363 Registriert: 24.04.2002 HP Workstation XW4200 Windows XP SP2 NVidia Q FX3400 Treiber 8.1.6.7 Pro/E Wildfire4 M100 (sehnlichst auf M120 wartend) Intralink 3.4 M062
|
erstellt am: 16. Mai. 2002 07:33 <-- editieren / zitieren --> Unities abgeben:          Nur für Beingodik
Hi Beingodik Diese "Warnung" ist sehr häufig in Baugruppen anzutreffen. Ich habe die Erfahrung gemacht, das sie im Zusammenhang mit im Teil erzeugten Ebenen (nicht aber die Standard-Ebenen) und darauf referenzierten Teil-KE's steht. Sprich, wenn Du all Deine Teil-KE's auf Standard-Ebenen oder auf Andere KE's referenzieren würdest, käme diese Meldung nicht mehr. Da dies aber absolut null Sinn macht und vorallem auch in den allerseltensten Fällen machbar ist, habe ich mir angewöhnt, diese Meldung zu ignorieren, da das Ganze meines Wissen absolut keine Auswirkung auf die Baugruppe hat. So, hoffe, konnte Dir etwas weiterhelfen. Gruss Sonja  Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Szilli Mitglied
 
 Beiträge: 190 Registriert: 19.03.2002
|
erstellt am: 16. Mai. 2002 10:04 <-- editieren / zitieren --> Unities abgeben:          Nur für Beingodik
Hallo Beingodik! Bist du sicher, dass es ein interner Bezug ist? Klingt eher nach einer fehlenden Referenz. Der Status würde eingefroren werden, wenn in der config.sup oder *.pro "fail_ref_copy_when_missing_orig no" steht. Wenn dieses zutrifft, müsstest du zur Behebung die Komponenten neu referenzieren. In diesem Fall stimme ich Sonja zu: IGNORIEREN! Bis denne Szilli Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
ehlers Mitglied Ingenieur
   
 Beiträge: 1432 Registriert: 05.11.2001 Pro/E 14-2001 WF1-5
|
erstellt am: 16. Mai. 2002 17:42 <-- editieren / zitieren --> Unities abgeben:          Nur für Beingodik
So was sollte man nie ignorieren. Ich gebe mal ein Beispiel wo ich das erlebt habe. Ich habe eine Moldbaugruppe. Das Referenzteil hat ein Merge-Feature auf Artikel Fliwatüt. Der Artikel Fliwatüt kann aber nicht gefunden werden weil er in einem unbekannten Verzeichnis steht oder irgend ein Schluri ihn einfach umbenannt hat ohne die zugehörige Baugruppe in Sitzung zu bringen und mit zu speichern (Klingt sehr kompliziert und wird deshalb auch gerne falsch gemacht). Jetzt findet das arme Referenzteil mit dem Merge kein Artikel Fliwatüt. Um sich selbst zu helfen friert Pro/E die Referenzen ein. Das heißt die Geometrieinformation des Referenzteils bleibt erstmal unverändert. Das gilt auch für andere externe Referenzen. Man kann in Mold das auch als Trick anwenden. Ich verschiebe den Artikel Fliwatüt und schon friert er mir das Referenzteil ein. Effekt: Pro/E regeneriert schneller. Also wie meinte Sonja? Ignorieren? Ich sage nein, wenn ich die Ursache nicht kenne. Ja, wenn ich weiß was ich mache. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Sonja1 Mitglied Konstruktion/CAD-Betreuung
 
 Beiträge: 363 Registriert: 24.04.2002 HP Workstation XW4200 Windows XP SP2 NVidia Q FX3400 Treiber 8.1.6.7 Pro/E Wildfire4 M100 (sehnlichst auf M120 wartend) Intralink 3.4 M062
|
erstellt am: 17. Mai. 2002 07:26 <-- editieren / zitieren --> Unities abgeben:          Nur für Beingodik
Guten Morgen Ja, die Sonja meinte ignorieren (böse, böse Sonja ). Ich möchte das aber noch mal präzisieren: Auch ich ignoriere solche Meldungen normalerweise nicht, aber bei dieser ganz speziellen Meldung tu ich es. Und NUR bei dieser. Ich habe mir wirklich mal die Mühe gemacht, dem Phänomen auf die Spur zu kommen. Das ist mir sogar gelungen und ich brachte die Meldungen sogar weg. Nur: Dazu musste ich alle betroffenen Einzelteile aufrufen, alle auf erzeugte Ebenen referenzierten KE's umdefinieren und alle erzeugten Ebenen löschen. Erst danach konnte Pro/E die Baugruppe ohne diese Meldung aufrufen. Ich kenne diese Meldung unterdessen bald sechs Jahre, sie hat mir noch nie Schwierigkeiten gemacht, alle Teile waren immer sauber mit allen Einbaubedingungen vorhanden und der einzige Weg (den ich kenne) sie wegzubringen ist in den allermeisten Fällen nicht praktikabel. Bring mir für genau diese "Fehlermeldung" einen brauchbaren Lösungsansatz und ich werde Dir auf immer dankbar sein. Bei allem übrigen kann ich Dir nur zustimmen: Warnungen sollten (fast) nie ignoriert werden, aber es gibt (für mich) Ausnahmen. Liebe Grüsse Sonja  P.S.: Nicht denken, ich sei jetzt beleidigt, ich würde mich sogar über eine gute Lösung freuen... [Diese Nachricht wurde von Sonja1 am 17. Mai 2002 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Beingodik Mitglied
 
 Beiträge: 244 Registriert: 28.03.2002
|
erstellt am: 17. Mai. 2002 09:35 <-- editieren / zitieren --> Unities abgeben:         
Dank euch. Ich hab das bisher auch immer ignoriert. In meinen eigenen Baugruppen tritt das Phänomen ja auch nicht auf. Bei genauerer Betrachtung hab ich festgestellt, das die Kundenbaugruppe in sich schon diese Warnungen enthält. Ich selber habe nichts an dieser Baugruppe geändert, außer ca. 500 Ebenen Achsen und sonstiges auf Layern versteckt. Wenn ich die Layer wieder einblende kommt die Warnung immernoch, nur schreibt Pro/E dann noch, das es jetzt doch ein bischen regenerieren kann, aber nicht alles. An Kundenbaugruppen (auch aus eigenem Hause) bastel ich ohnehin nicht viel rum - da macht man nur mehr kaput als das es hilft. Ansonsten bei Fremdbaugruppen gilt: "Nicht ärgern, nur wundern" Bis denne und frohes Pfingstwochenende  ------------------ Bis denne Die Antwort liegt irgendwo da draussen. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
sadolf Mitglied VR-Projektleiter, IS-Berater, Konstrukteur
   
 Beiträge: 1440 Registriert: 27.11.2001 DeltaGen 12.1.1 VRED 2015 W7 64bit PrÖ, Katja Windchill TCE (nur unter Protest;)
|
erstellt am: 18. Mai. 2002 19:38 <-- editieren / zitieren --> Unities abgeben:          Nur für Beingodik
Hallo Beingodik, was mich bei den vielen hilfreichen Antworten ein wenig wundert, dass Dir niemand den Global Referenz Viewer empfohlen hat. Mit dem kann man solchen Ärgernissen ganz gut auf den Grund gehen. Die Meldung klingt danach, dass an einem Teil in der Baugruppe konstruiert wurde und jemand unbedacht Referenzen angeklickt hat, die jetzt nicht mehr Bestandteil der Baugruppe sind. Sonja1 hat recht, dass es eine Riesenaufwand ist, alle wieder zu fixen, zumal sie eingefroren sind und eigentlich nichts passieren kann. Es gibt aber so eine nette config.pro/sup Option die einen zum arbeiten zwingt, weil sie eingfrorene Referenzen verbietet und schon ist man im Resolve_Mode (siehe Szilli). Um den ganzen Ärger von vornherein zu vermeiden hilft auch ein config.pro/sup Option bzw. der Konstruktionsmanager im ASM-Mode, mit der/dem man externe Refernzen außer auf Skeleton.prt verbieten kann. Frohe Pfingsten und ... ------------------ freundlich grüßend Sven [Diese Nachricht wurde von sadolf am 18. Mai 2002 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |