---

Radien.jpg

Hallo Leute aus der Fraktion des Datenaustausches

Ich habe in NX2 beim Einlesen eines aktuellen Teiles siehe Bildchen aus ProE als IGES File das die Radien nicht richtig übersetzt werden.

Löschen der Elemente funzt nicht hier fehlen dann die entsprechenden Flächen und vor allem sind es zu viele.

Gibt es eine Möglichkeit innerhalb der UG Schnittstelle einzugreifen, das gleiche hatte ich auch schon einmal bei Catiadaten.

Die einzige Lösung die seinerzeit etwas brachte war den File als STEP einzulesen.

Antwort von Kunden ist wie sollte es anders sein, bei anderen Systemen gehts auch ohne Schwierigkeiten.

Vielleicht kann mir jemand einen Tip geben.

------------------
ugsi

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

---

Hallo ugsi

wir haben das gleich Problem auch ab und zu.Lasse mir dann auch wenn möglich immer step Daten schicken.Diese klappen eigentlich wirklich problemlos.Habe auch schon versucht was rauszufinden aber leider nichts erfahren.

Gruß
ManniMu

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

---

öffne mal im installationsverzeichnis von UGnx das im iges unterverzeichnis das igesnullnx20_mm.prt, gehe in die Konstruktion über Voreinstellung Konstruktion,-> die Abstandstoleranz steht meist auf 0.0254 ändere dieses mal auf ( ~wie in ProE) 0.01 Abstandstoleranz speichere und schließe das igesnullnx20_mm.prt.
Starte dann deinen Import, .. i hope it helps
mfg
uwe.a

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

---

Hallo Uwe,
hab es ausprobiert, leider ohne Erfolg, hab auch noch die Winkeltoleranz zurückgesetzt auf 0,1
Sieht aus als komme es direkt aus ProE läuft wahrscheinlich doch auf STEP raus

------------------
ugsi

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

---

Hallo,

das sieht man auch oft bei Step Dateien die aus ProE kommen.
ProE kann (bitte verbessert mich) mit 2 verschiedenen Toleranz Modellen arbeiten, Absolute und Relative Toleranzen. Der Sender der Daten soll die ProE Daten mal mit Absoluter Toleranz abspeichern bevor er sie übersetzt, das kann man angeblich einfach umstellen, dann klappt es auch mit UG.
Das kommt nicht von mir, ProStep hatte immer eine gute BestPractice Seite auf ihrer Homepage, zwar bezogen auf Step, aber es hilft auch bei anderen Formaten. Man muß eingeben wer Sende System und wer Empfänger ist und bekommt eine Anleitung was man wie einstellen muss in beiden Systemen.

Gruß
Ralf

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

---

... richtig, einfach an der genauigkeit rumzufrickeln bringt nix. meistens jedenfalls. das waere ja auch zu einfach, dann haette der nicht native datenaustausch ja im endeffekt keine probleme mehr.

nein, wir bekommen auch haeufig daten (*.stp/*.igs) von ug/ideas und catia. man kann grundsaetzlich nicht sagen, das *.stp eine bessere qualitaet wiedergibt. leider ist dieses vorurteil sehr weit verbreitet, aber gerade *.igs hat im flaechenbereich und nurbs class a seine staerken. viel wichtiger ist, was mein vorredner schon angedeutet hat. beim datenaustausch werden haeufig zu wenig parameter beachtet. also eine baugruppe wird geladen und ein knopfdruck und fertig. --> dann hat man haeufig den schlamassel, weil die wildesten kurven, verbundflaeche, nicht unterstuetzte u. s. w. in der datei haengen

... deshalb sollte man dateien weitergeben, wo all diese nicht gewuenschten elemente draussen gelassen werden und sein system bei dem exportieren eben sinnig einstellen. genauigkeit ist natuerlich auch wichtig, aber die o. g. dinge auch. kurzum: ich kaempfe mit pro/e auch beim einlesen, aber um euch zu beruhigen: *.stp und *.igs werden mit pro/e nach der konformitaetsklasse abgespeichert, d. h. sie sind 'regelgerecht'... diese konformitaetsklassen kann man auch im header einer datei sehen, genauso wie die abgespeicherte genauigkeit... und hier ist natuerlich auch das einzulesende system wichtig (also ug). die schnittstelle kann natuerlich auch fehlerbehaftet programmiert sein oder die klasse wird nicht unterstuetzt.

... so long

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

---

Hallo ugsi,
wir hatten in meiner alten Firma irgendwann mal das gleiche Problem. Allerdings war damals, glaube ich, jeder Radius umgestülpt. Bei Dir sind es wohl nur manche. Das Problem war relativ einfach zu lösen. Im iges.def-file (UG-Installations-verzeichnis -> IGES) gibt es einige Schalterchen. Leider kann ich Dir jetzt nicht sagen welcher Schalter das war, weil ich ja seit letzter Woche nicht mehr dort arbeite, also keinen Zugriff mehr auf die Daten habe. Teste einfach mal verschiedene Schalter aus; setze sie von ON auf OFF (bzw. umgekehrt). Achte nur darauf, dass Du beim konvertieren auch das geänderte def-File durchläufst und nicht irgendein anderes. Vielleicht mal die Werte BSURFACE_MAP ; SURFOFREV_MAP umsetzen.
Gruß, Bärbel

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

---

Hallo Bärbel,
danke für alle Tipps, bin gerade dabei mit den Schaltern zu probieren, dauert etwas, die Übersetzung dauert jedesmal fast 25min.

Hab beide einmal auf OFF gesetzt ohne Erfolg probiers gerade mit anderen noch aus.

Hab im LogFile verschiedene Errors bekommen am häufigsten Error 13805 bekommen was mir allerdings nichts sagt.

------------------
ugsi

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

---

Hat schon jemand mit Erfolg irgendwelche Änderungen zum Orignal IGESimport/expot.def File vorgenommen.

------------------
ugsi

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

---

Hallo ugsi,
na logo; zum Beispiel das Flachklopfen von Baugruppen (flatten_assembly) habe ich schon gebraucht; oder wie oben erwähnt, das Problem mit den umgestülpten Radien. Auch den Parameter mit den Bemaßungen habe ich schon getestet. und automatic_sew, usw...
Zeigen die vorgenommen Änderungen bei Dir überhaupt keine Wirkung? Dann würde ich vermuten, dass Du im falschen def-file änderst, kann das sein? Startest Du den Translator aus UG oder startest Du ihn extern? In beiden Fällen kannst Du ja das def-File neu holen.
Es wurde hier übrigens mal eine ähnliche Geschichte behandelt:Iges-Thread. Da gehtŽs auch um ein paar erfolgreich umgesetzte Parameter.
Das was ich Dir in der PM geschickt hat, hat nichts genützt, oder? Sie ist nicht so oft im Forum, wahrscheinlich konntest Du sie nicht erreichen. (Aber sie hat ja ihre email-Adresse im Profil). Vielleicht schickt Dir auch sonst irgendjemand einige def-Files zu, die Du ausprobieren kannst. Blöd ist nur, dass Dein IGES-File so dermaßen groß ist, und Du jedesmal 20 min warten musst, bis Du das Ergebnis siehst. Da vergeht einem natürlich das testen und ausprobieren. Kannst Du kein kleines Test-Import-File bekommen, das das gleiche Problem aufweist?
Hast Du mal einen älteren IGES-Translator ausprobiert?
Im UG-Answer finden sich übrigens auch einige Einträge zu diesem Thema.
Gruß, Bärbel

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

---

iges.txt Dos.JPG

Hallo Bärbel,

habe alle möglichen Varianten sprich Änderungen an den Schaltern probiert aus UG und extern gestartet, durchlaufe die richtigen Files.

Hab mir auch schon den anderen Beitrag angesehen, hilft auch nicht weiter.
Im Anhang einmal der Logfile wie ich ihn bekomme. die 20 min einlesen kommen daher das bei 60% der erste Fehler kommt und UG versucht zu korrigieren.
Habe den IGES auch mit V18 und NX1 versucht immer das gleiche.

Übrigens habe den File bei einem Bekannten einmal in SolidEdge ohne Probleme eingelesen.

Die PM hat nichts genützt ist auch kein Profil vorhanden.

Ich warte nun auf einen neuen File vom Kunden die müssen an Ihrem Teil einiges ändern, vielleicht klappts dann. Bin froher Hoffnung!!!

Ach ja, nachdem es in anderen Systemen wie getestet funzt muss es an UG/Iges liegen.
Kann es sein das ich der einzige bin der die Probleme beim Einlesen hat, bzw wo ist der Hund begraben???

Ich geb die Hoffnung nicht auf

Besten Dank einstweilen

------------------
ugsi

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

---

Hi,

kannst du eventuell das IGES File mal hier hereinstellen?
Ich würd dann mal versuchen, das in I-DEAS, Poor/E oder Catia einzulesen. Ich habe ähnlich Probleme mit dem STEP und IGES Export aus Inventor, in Poor/E sind sofort Fehler im Teil, in Catia und I-DEAS nach den ersten Bearbeitungen.
Wenn das in I-DEAS funzt, kann ich dir das in Parasolid umwandeln.

So rein interessehalber.

Griass

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

---

Hallo Ugsi,
das hört sich ja wirklich nach bug an. Ich hab heute morgen mal das UGAnswer durchforstet und bin mehrmals auf ähnliche Schlagwörter gestoßen. Ich glaube mich zu erinnern, dass da jeweils dringestanden hat, dass es den Fehler halt gibt und in irgendeiner Version gefixt ist. Das ist wohl ein Fall für die Hotline.
Da können wir noch lang an den Parametern drehen; das wird wohl nix.
Es ist auf jeden Fall nicht das Symptom, das ich vermutet habe. Der Translator hat ja laut Logfile ein Problem mit gewissen SheetBodyŽs und kann diese nicht trimmen.
Vielleicht hast Du wirklich mit dem neuen File mehr Glück.
Gruß, Bärbel

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

---

Hi,
auch ich als Solidworks-Anwender kenne dieses Phänomen "umgestülpe Radien aus Pro/E".
Mich würde demnach auch interessieren wie die Pro/E Jungs und Mädels den Export vornehmen. Vieleicht sollten die mal versuchen die Dateien im Pro/E zu öffnen.

Ich mußte mir dann immer diesen Satz anhören: Ihr solltet euch Pro/E anschaffen!!!!

------------------
Gruß
Rainer A.

Kein Fleich, kein Fich, komich!

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

---

PoorE_1.jpg PoorE_2.jpg PoorE_3.jpg

Rainer,

so ganz kann man das nicht gelten lassen. Oft liegen die Probleme des Datenaustausches nicht auf Programm-, sondern Anwenderseite.
- unsaubere 3D Modelle
- falsch eingestellte Modelliertoleranzen
- falsche Konfiguration oder falsche Export- bzw. Importparamter

Und Pro/E hat schon ordentliche Schnittstellen.

Das Teil ugsi habe ich in Pro/E, Uralt-Studentenversion, innerhalb 3 Minuten eingelesen, eine Fläche erscheint mir etwas verbogen, das Teil ist aber als Solid eingelesen worden.
Beim Versuch, die gleiche Datei in den Inventor einzulesen, ging die CPU Anzeige für 10min auf Anschlag, dann was Ende im Gelände.

Die UG Probleme kenn ich auch, wobei die Qelldaten aus MDT (IGES und STEP). Die gleichen Daten waren ohne Fehler in I-DEAS einzulesen.
Und auch beim STEP Export gabs Probleme, die UG Dateien ließen sich nicht in Fluent einlesen, über Pro/E gefiltert gings dann.
Aber vielleicht wird das ja auch in UG besser, wenn I-DEAS und UG zusammenwachsen.

Grüße

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

---

SURFOFREV_MAP=Off.jpg SURFOFREV_MAP=On.jpg

Hallo Leute,

wird ja immer toller ich bin immer wieder über UG und seine Macken erstaunt.
Nicht einmal Daten (nur ein dummer Würfel mit Radien) welche aus UG als IGES ausgelesen wurden kommen ohne am defFile zu drehen als IGES in UG komplett zurück.

Wie solls dann erst bei Fremddaten funktionieren

Ich glaub das kann doch nicht wahr sein die wollen uns dumme User nur alle vera....

Erst Schrott programmieren oder einstellen dann Support verkaufen der dumme User zahlts ja!!!!

Ich glaub damit wollen die nur Ihren Support rechtfertigen.

Übrigens nochmals danke Bärbel, wenn du das nicht mit den Schaltern geschrieben hättest wäre ich nicht drauf gekommen an welchem zu drehen ist.

Das andere Problem ist dennoch nicht gelöst vielleicht wirds noch hab ja Zeit..... wenn ich dahinter gekommen bin, kann ich es ja UG schicken.

Schluss jetzt ich bin genervt

Grüsse an alle die sich bisher beteiligt haben und vielen Dank 

------------------
ugsi

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

---

Hallo Meinolf,

besten Dank, Step funzt ohne irgendein Problem bis auf die eine verb.Fläche

Übrigens der oder ähnlicher Fehler ist bei UG bekannt hab mal gesucht hierzu gibt es folgendes

The problem where the NX/UG part submitted containing a sphere can not be
roundtripped back into NX/UG via the NX/UG iges translator is fixed in NX
2.0.4.1 and 3.0.

Also irgendwann gibts was man muss nur warten können.

------------------
ugsi

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

---

Ihr solltet im Ursprungssystem mal prüfen, wie kompliziert die Flächen sind. Je höher der Polynomgrad, desto schwieriger wird das ganze. Flächen sollten vereinfacht werden. 

------------------
MfG
Konrad Wieclawski

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

---

Ich exportiere meine Daten immer per Step 214 aus Pro/E und importiere sie dann nach UGNX. Funktioniert einwandfrei. Eine andere Möglichkeit habe ich auch noch nicht gefunden.
Matthias

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