---

220720_Item-Profile.jpg 220720_Struktur.jpg

Hallo zusammen,

aktuell benutzen wir für die Stahlbaukonstruktion das Routing Steelwork, heute versuche ich mich mal am NX Structure Designer, der hat eigentlich recht vielversprechend ausgesehen.

Die Konfiguration eigener Profile und die Einbindung in die Bibliothek war im Routing schon ein Krampf, aber immerhin noch einigermaßen logisch nachvollziehbar. Im Structure Designer ist's gefühlt nochmal ne Spur schlimmer, aber ich hab's hingekriegt, eigene Item-Profile da reinzukriegen (siehe ersten Screenshot) und in einer Struktur zu verbauen (siehe zweiten Screenshot).

Meine drängendste Frage ist im Moment, ob ich die Profile wahlweise detailliert oder auch vereinfacht darstellen kann. Das hab ich noch nicht geschafft.

Darüber hinaus bin ich auch an einem generellen Erfahrungsaustausch interessiert. Setzt das Zeug einer von euch schon ein? Ich find den Ansatz ja nicht schlecht (insbesondere das Ausformen der Ecken und Stöße funktioniert dramatisch besser als im Routing Steelwork), hab aber doch einiges an Kritik, die hoffentlich nicht nur auf Unwissenheit meinerseits basiert:

(1) Es entsteht immer eine Baugruppenstruktur, selbst Gleichteile bekommen unterschiedliche Nummern / Dateinamen. Mir wäre ein Multibody-Teil ehrlich gesagt wesentlich lieber.
(2) Vom Gitterteil (also der Skizze für die neutralen Fasern der Profile) werden in die Einzelteile immer Wave-Links (linked Composite Curves) gezogen. Von der Technik her irgendwie logisch, aber ich will mir gar nicht ausmalen, was passiert, wenn die Leute anfangen zu Revisionieren und zu ändern. Bedingt durch die Laderegeln kann ich mir gut vorstellen, dass solche Wave-Links gerne mal kaputt gehen (passiert ja am laufenden Band, wenn man nicht aufpasst).
(3) Vernünftige Funktionen für Konsolen (z. B. für Konsolenbleche mit Löchern für Verschraubungen) fehlen
(4) Verschraubungsfunktionen fehlen
(5) Die End Cap Funktion (Abschlussdeckel für Profile) ist auch recht.... sagen wir mal "seltsam"

Soll keine Werbung sein, aber bei meiner Suche im Internet bin ich da drüber gestolpert:
https://www.youtube.com/watch?v=f4FRXlSfQwk
Da wurde ein bisschen weiter gedacht als beim Structure Designer (klar, das Plugin gibt's ja auch schon ein wenig länger, da muss man fair sein). Ich möcht mir aber nach Möglichkeit mit NX Basismitteln behelfen - geht ja auch irgendwie aber ich komm da mit dem Struktur Designer irgendwie schnell an Grenzen, wo ich dann doch manuell anfangen muss zu modellieren.

Wie sind eure Erfahrungen?

------------------
Gruß 

Markus

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

---

Hallo Markus,

das Modul wird schon verwendet. Die Administration ist sehr stark an die Ship Structure App angelehnt. So wird es in Zukunft, in der 2206 ist schon ein großer Schritt gemacht, möglich sein, alle Komponenten, die mit dem Structure Designer erstellt worden sind, mit der Ship Structure Manufacturing zu nutzen. Also automatisiert Profillisten, Profilskizzen, Brennteile etc. zu erstellen.
Wie du dich wahrscheinlich noch erinnerst, war die NXship basiert auf Multi Body Teilen. Das ist mit der Ship Structure App weggefallen. Kann man sehen wie man will, die einen sehen Vorteile im Multibody, die anderen Nachteile. Der Weg von Siemens ist aber Komponenten basiert, also keine Multibody Teile mehr.
Eine BG wird aufgebaut, das sehe ich als Vorteil. Gleiche Teile bekommen eine andere Nummer/Namen, was auch vollkommen richtig ist. Denn auch wenn es ein geometrisch gleiches Teil ist, liegt es im Raum doch anders. Mit der anderen ID kann es also eindeutig zugewiesen werden. Das hat ja auch nichts mit der Positionsnummer zu tun. Denn die wird, zumindest in der Ship Structure, dann doch gleich sein sofern das Teil auch echt gleich ist. Sobald aber Markierlinien drauf sind, die anders sind als bei einem anderen geometrisch gleichen Teil, wird auch die Positionsnummer anders sein. Also nach meiner Logik vollkommen richtig. Diese Diskussion wird immer wieder geführt und deswegen verstehe ich deinen Einwand.
Ohne Wave Links wird es nicht gehen, das Ganze muss ja Komponentenübergreifend assoziativ bleiben. Da bietet NX nun mal nur die Wave Links an. Probleme mit Wave Links hört man immer wieder, ich kann das nur teilweise verstehen, habe selbst keine Probleme damit obwohl ich bedingt durch das Produkt Schiff mit tausenden Wave Links arbeite.
Auch das Revisionieren im TC ist eigentlich kein Problem, zumindest habe ich noch keine Klagen von Kunden, die damit arbeiten, gehört. Ändern bedingt natürlich das Verständnis für Wave Links ist aber beim Einhalten der Regeln (da hapert es manchmal  ) auch kein Problem.
Das Modul wird weiter ausgebaut, ist also noch lange nicht fertig. Deswegen mag für manchen noch was fehlen wie du schon angemerkt hast.

Viele Grüße
Felix

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

---

Hallo Felix,

danke für die Antwort - versteh ich alles (glaub' ich zumindest  ).

Zitat:

---

Original erstellt von FelixM:

Wie du dich wahrscheinlich noch erinnerst, war die NXship basiert auf Multi Body Teilen.

---

Naja, ich bin kein Schiffbauer und hab mit NXShip noch nie was gemacht. Deshalb muss ich leider gestehen, dass ich da keine Ahnung von habe.

Zitat:

---

Original erstellt von FelixM:

Eine BG wird aufgebaut, das sehe ich als Vorteil.

---

Erstaunlich.... Ich seh' das als einen der größten Nachteile. Früher hatte ich ein Multibody-Teil und konnte das gesamte Gestell mit einem Parametersatz ohne Wave-Abhängigkeiten steuern. Das war für mich immer sehr angenehm.

Zitat:

---

Original erstellt von FelixM:

Ohne Wave Links wird es nicht gehen, das Ganze muss ja Komponentenübergreifend assoziativ bleiben.

---

Gar keine Frage. Deshalb hab ich ja geschrieben: "Von der Technik her irgendwie logisch" 

Dass das bei dir klappt, glaub ich sofort. Wenn ich das richtig im Kopf habe, bist du ja selbständig und sozusagen eine "One-Man-Show", außerdem halte ich dich für ein pfiffiges Kerlchen (das ist aus meinem Munde schon fast so etwas wie das höchstmögliche Lob  ). Bei mir ist's so: Große Firma, Standort- und Länder-übergreifendes gemeinsames Arbeiten und jeder macht's irgendwie anders (obwohl wir mit Check-Mate immerhin schon vieles abfangen und wir natürlich auch eine Konstruktionsrichtlinie haben).

Zu Wave: Ich seh da teilweise Baugruppen, die nicht mehr aufgehen, weil zyklische Wave-Referenzen drin sind. Ich bekomm's zwar bisher immer noch hin, dass ich das Problem finde und ich die Baugruppen wieder zum Öffnen überreden kann. Aber bei einigen Baugruppen-Bereinigungen konnte ich die Wave-Referenzen schon gar nicht mehr nachvollziehen, so komplex war das aufgebaut. Und ich bin jetzt mal ganz arrogant und sage über mich selber, dass ich halbwegs was davon verstehe. Ich denk mir die Problematik also nicht aus, die ist wirklich vorhanden - da bestätigt mich die Praxis. Deshalb hab ich auch etwas Angst, wenn Wave in der breiten Masse genutzt wird.

Hast du beim Structure Designer eigentlich vereinfachte Querschnitte in Verwendung? Ich hab's bisher nur geschafft, einen Querschnitt anzugeben und habe beim Einfügen der Profile keine Wahlmöglichkeit "Vereinfacht" vs. "Detailliert" gefunden.

------------------
Gruß 

Markus

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

---

Hallo Markus,

ich kenne zwar den NX Structure Designer nicht, aber bei "vereinfacht" und "detailiert" handelt es sich stets um Ref. Sets, die man "intelligent" selbst anlegen muss. D.h., NX kann nicht entscheiden was bei "vereinfacht" wegfallen soll. Man könnte höchstens die Min-Max-Box (Hilfsquader erzeugen, Create Box) benutzen. Das passiert aber nicht automatisch und trifft auch nicht immer, z.B. bei Leitungen quer durch den Raum.

Für Querschnitte sollte das Gleiche gelten.

Gruß

------------------
Walter Hogger

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

---

Hallo Markus,

Multibody vs Single Body:
Ich verstehe dich vollkommen. Aber was ist mit den Anderen? Die können von deinem Multibody Teil keine Metadaten der einzelnen Profile ablesen. Es können keine Sequenz Zeichnungen abgeleitet werden (zumindest nicht ohne zusätzliche Tools). Es kann kein Lebenszyklus der einzelnen Bauteile abgebildet werden. Auch im Viewer können die Metadaten der einzelnen Bauteile nicht abgerufen werden (ohne einen speziellen Viewer zu haben). Das alles funktioniert doch erst, wenn man Single Solid Components hat. Wenn das natürlich alles nicht wichtig ist, gebe ich dir vollkommen Recht.

Wave:
Schwieriges Thema. Häufig bekomme ich von Usern zu hören, "Wave ist Mist, das funktioniert nicht". Dann wird es schwierig, sie vom Gegenteil zu überzeugen. Das sitzt meist sehr tief drin. Dabei ist die Wave Technologie ein Segen, um überhaupt assoziativ Baugruppenübergreifend arbeiten zu können. Natürlich ist dabei nicht alles super, aber es kommt dem schon sehr nahe, wenn die Regeln eingehalten werden und die Wave Architektur begriffen ist. Dazu gehört eine entsprechende BG Struktur. Wenn dann noch im TC gearbeitet wird, kann eigentlich nicht mehr so viel passieren. Das gilt auch für große Firmen, die Länder übergreifend arbeiten.
Denn genau das mache ich ja. Ich bin zwar eine One Man Show, arbeite aber auch anderen Firmen zu, auf deren TC Datenbank, also als Teil des Teams, womit ich alle Regeln der entsprechenden Firma einhalten muss. Da sehe ich, das die Regeln in Bezug auf Wave peinlich genau eingehalten werden. Es wird aber auch jedem Mitarbeiter direkt mitgegeben, worauf er zu achten hat und vor allen Dingen warum. Stelle sich mal jemand vor ein Spant an der Außenhaut würde nicht passen, weil der Wave Link zur Außenhaut gebrochen war. Ganz schön teuer. Wave Links brechen nicht einfach so auf. Dazu gehört schon was. Aber okay, ich bin auch ein Wave Junkie, gebe ich zu.

Vereinfachte Darstellung:
Das ist mir ehrlich gesagt gar nicht bekannt, dass das möglich wäre. Dazu wäre es ja nötig, einen zweiten Querschnitt zu definieren, der ein entsprechendes RefSet mitbekommt. Wenn du dafür eine Lösung hast, wäre ich dir dankbar, das eben zu teilen. In der Ship Structure Application haben wir eine Möglichkeit, Profile einfach nur als Linien darzustellen. Aber das ist nicht das was du meinst.

Viele Grüße
Felix

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

---

Man kann auch im Mix arbeiten. Im Multi-Solid-Part konstruieren und die Baugruppe per Programm erzeugen lassen. Objekt-Attribute werden zu Part-Attributen (Metadaten). Leider ist diese Technik nicht in den "normalen" NX-Köpfen zu finden, aber Firmen die diese Top-Down-Technik nutzen sind extrem schnell und haben ganz saubere Strukturen auch in Bezug auf WAVE-Links.

URL=Video 1 dazu:
URL=Video 2 dazu:

Gruß

------------------
Walter Hogger

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

---

220722_Querschnitt.jpg 220722_Profile.jpg

Hallo zusammen,

danke für euren Input. Wegen der vereinfachten Darstellung: Doch, das geht auch ohne Referenz-Sets. Im Routing Steelwork z. B. kann man das Profil so qualifizieren, dass man zwei Querschnitte vergibt (einen vereinfachten und einen detaillierten). Siehe erstes Bild im Anhang.

Beim Einbau kann ich dann entscheiden, ob der Querschnitt vereinfacht oder detailliert verwendet werden soll. Siehe zweites Bild im Anhang. Ich hatte auf eine ähnliche Funktionalität beim Structure Designer gehofft.

PS: Im Routing stimmt sogar das Gewicht (bzw. die Masse), da in den Config-files das Gewicht pro Meter angegeben wird - unabhängig vom Detailgrad des Querschnitts, der ja in jeweils unterschiedlichen Volumen resultiert.

------------------
Gruß  

Markus

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

---

Hallo nochmal,

hatte jetzt nochmal etwas Zeit, mich damit zu beschäftigen... Irgendwie wirft das Ding immer mehr Fragen auf.

@ Felix: Hast du den Structure Designer im Teamcenter am Laufen? Ich krieg's nicht hin. Wahrscheinlich muss man die Config-Files in Tc-Items importieren, die dann die Datasets mit bestimmtem Namen und Relation an den Revisionen hängen haben. Und dann natürlich noch per Customer Default angeben, welches das Item ist, das die Config Files enthält.

Hast du da eine Beschreibung? Oder geht's auch im Teamcenter mit den Config-Files im %NX_STRUCTUREDESIGN_DIR% ?

Im NX-Installationsordner (%UGII_BASE_DIR%\NXSTRUCTUREDESIGN\InstallationTool) gibt's zwar eine kleine Installationsroutine, die die Templates und Config-files ins Tc holt, die will ich jetzt aber nicht ausführen, ohne dass ich weiß, was dabei genau passiert.

Zitat:

---

Original erstellt von FelixM:
Die können von deinem Multibody Teil keine Metadaten der einzelnen Profile ablesen.

---

Doch, das macht Routing Steelwork doch auch. Da hängen die Attribute halt an den Volumenkörpern (Stocks bzw. Aufmaße) dran.

Zitat:

---

Original erstellt von FelixM:
Häufig bekomme ich von Usern zu hören, "Wave ist Mist, das funktioniert nicht".

---

Naja, wenn man mit so einer Einstellung an die Sache rangeht, dann arbeitet man ja unbewusst schon drauf hin, dass es nicht geht. Bei mir ist's irgendwie genau andersrum: Die User finden Wave richtig geil. Leider fallen die aber meistens früher oder später auf die Nase, weil sie ihre eigenen Abhängigkeiten irgendwann nicht mehr verstehen.

------------------
Gruß   

Markus

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

---

Hallo Markus,

ohne die Installationsroutine wird es wohl nicht klappen mit TC. Du benötigst die Daten echt im TC. Es wird eine Library im TC angelegt, im Wesentlichen Items, die dann das Part, Excel und Bitmap beinhalten, steht so halbwegs in der Doku drin. Zudem Items für das Registration Sheet und die Configs.
Eine Testumgebung wäre natürlich besser um so etwas zu machen.
Kleiner Tip von mir: Es ist einfacher, die Library native zu unterhalten und zu ändern. Deswegen achte darauf, beim Import der Lib ins TC die Naming Rule so einzustellen ,dass auch Nummern vergeben werden. So kannst du ohne Probleme eine neue Lib importieren und brauchst dann nur die Nummern in den CD bzw. Reg Sheets auszutauschen.

Ja, im Routing stehen die Metadaten auf den Multibodies drauf wenn du nicht mit "Stock as components arbeitest". Aber versuch mal, die Metadaten mit dem TC Viewer darzustellen, wenn du eine Lösung dafür hast, her damit  . Zudem kannst du schlecht den Lebenszyklus eines Rohrbogens oder eines Flansches deines Multibodies darstellen. Das geht dann ja nur für das ganze Multibody Part oder sehe ich das verkehrt?

Dann hast du Glück, dass deine User Wave gut finden. Da sollte eine deutliche Arbeitsanweisung das Problem doch lösen können.

Viele Grüße
Felix

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

---

Hallo Felix,

Zitat:

---

Original erstellt von FelixM:
ohne die Installationsroutine wird es wohl nicht klappen mit TC. Du benötigst die Daten echt im TC.

---

Versteh ich - aber ich wollt die nötigen Items eigentlich gern von Hand anlegen, ohne magische Skripte von PL, bei denen ich nicht weiß, was im Hintergrund alles passiert. Ich hab mir bei solchen Aktionen schon mal was kaputt geschossen, deshalb bin ich da mittlerweile übelst vorsichtig geworden.

Zitat:

---

Original erstellt von FelixM:
Es ist einfacher, die Library native zu unterhalten und zu ändern.

---

Ähm... steht das nicht im Widerspruch zu dem, was du oben geschrieben hast? Ich hatte es so verstanden, dass das Zeug zwingend im TC vorhanden sein muss. Kann ich denn die Konfig native haben und "nur" die Profilquerschnitte ins Tc importieren?

Zitat:

---

Original erstellt von FelixM:

Aber versuch mal, die Metadaten mit dem TC Viewer darzustellen, wenn du eine Lösung dafür hast, her damit   . Zudem kannst du schlecht den Lebenszyklus eines Rohrbogens oder eines Flansches deines Multibodies darstellen. Das geht dann ja nur für das ganze Multibody Part oder sehe ich das verkehrt?

---

Stimmt alles, war bei uns aber nie ein Thema. Wir brauchen eigentlich nur das Gestell an sich und die Zuschnittsliste. Die einzelnen Zuschnitte an sich haben keinen eigenen Lebenszyklus, nur das Gestell an sich hat einen.

Zitat:

---

Original erstellt von FelixM:

Dann hast du Glück, dass deine User Wave gut finden. Da sollte eine deutliche Arbeitsanweisung das Problem doch lösen können.

---

Wenn's nur so einfach wäre...

------------------
Gruß 

Markus

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

---

Hallo Markus,

Deswegen ist eine Testumgebung ja so wertvoll. Gehen tut es natürlich auch ohne das Skript. Ist halt Arbeit. Für jedes Profil muss ein Item angelegt werden und die entsprechenden Datasets angelegt werden und gefüllt werden. Dann noch die Regs und Configs. Da wäre es doch gut, das einmal in eine Testumgebung zu importieren, um zu wissen, was alles nötig ist. Ich nutze halt einfach das Script.

Ja, das Zeug muss im TC vorhanden sein. Native deshalb, weil es da viel einfacher ist, die Daten schnell mal zu ändern für einen neuen Kunden z.B.. Danach wieder mit dem Script importieren und die CD anpassen. So kannst du verschiedene Libs im TC für verschiedene Kunden aufbauen falls nötig. Kannst du natürlich auch im TC machen, ist aber aus Erfahrung weitaus mehr Arbeit. Kann aber natürlich nicht einschätzen wie viele Änderungen du so machen musst. Bei uns besteht im Prinzip für jeden Kunden eine eigene Library. Kommt ein neuer Kunde dazu, wird native die Library gebaut und dann nach TC per Script importiert.

Wenn der Lebenszyklus für Euch nicht interessant ist auf dieser Ebene, verstehe ich natürlich dein Vorgehen. Für uns ist es halt wichtig zu wissen, ob z.B. ein bestimmter Flansch, Spant etc. schon im Boot eingebaut ist bzw. in welcher Phase er ist bzw. welchen Status er hat.

Wenn's nur so einfach wäre? Stimmt, ist es nicht. Es gibt auch sicherlich nicht das allgemein passende Rezept für dieses Problem...

Viele Grüße

Felix

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