Fehlende Struktur TC im NX / NX
Robse-Ponte 31. Mrz. 2021, 13:57


Default_CD.JPG


Fix_CD.JPG

 
Hallo zusammen,

wir arbeiten mit TC 11.6.0.5 und NX1946. Seit Umstieg auf das Continous-Release haben wir ein recht nerviges Problem mit unserem CAD-PLM System, das wir nicht gebacken bekommen.

Ältere Baugruppen werden bei uns trotz Schreibschutz teilweise ohne Struktur geladen. Die Baugruppen sind teilweise leer, manchmal fehlt ein Teil der Unterbaugruppe. Grund hierfür ist, dass irgendein Auslöser die Struktur im TC zerbröselt. Ich kann leider nicht eingrenzen, wo das Problem liegt.

Anbei unsere aktuellen NX Customer-Defaults der TC-Integration der Assemblies als Screenshot.

Workaround von Siemens liegt darin, die Bauteile As Saved (siehe Anhang Fix Customer Defaults + Load Options) siehe Screenshot zu laden. Dann sind die fehlenden Teile interessanterweise wieder vorhanden. Ein nicht unwesentlicher Teil der Zeit besteht jetzt darin, Baugruppen wieder auf Stand zu bringen, die einmal funktioniert haben und anscheinend auch mal richtig gespeichert worden sind...

Ich möchte deshalb fragen, ob dieses Problem auch bei jemandem von Euch hier auftaucht, oder ob wir wie von Siemens komuniziert das magische Einhorn sind, bei dem das passiert. Falls es weitere Leidensgenossen gibt, habt ihr einen vernünftigen Lösungsansatz?

Danke und freundliche Grüße

ThomasZwatz 01. Apr. 2021, 00:29

Wenn ichs richtig verstanden hab, ist das Problem, dass in TC empty BOMs vorhanden sind ( wo auch immer die herkommen ).

Dein CustomerDefault "Structure Update on Empty BOM" setzt das dann auch um (=Structure leeren).
Warum hast du den gesetzt, gibts dafür einen Grund ?

Wir hatten das Problem auch mal, das ist aber schon lange her, gefühlt pre TC8.
Darum ist das bei uns unchecked ...

Big King 01. Apr. 2021, 07:56


2021-04-0107_52_45.png

 

- unsere Einstellungen sie im Pic
- NX1899 und bin der Meinung seit mind. NX6 ist das so....
- NX1953 dito, gerade im Test

Robse-Ponte 01. Apr. 2021, 12:04

Hallo zusammen,

zuerst einmal danke für die Hilfe.

Drei User, drei Settings...

@BigKing

die Einstellung mit "Add component that have a position" habe ich heute morgen getestet und bringt leider keine Besserung.

@Thomas, ich habe das einmal ausprobiert. Im CAD ist die Struktur noch vorhanden. Nehme ich den Haken raus, dann verhebt das (Stand 50 verschiedene Baugruppen bis jetzt).
Das Problem ist natürlich nicht gelöst, da im TC immer noch madige Strukturen rumschwirren.

Was könnte denn der Auslöser dafür sein, dass die Struktur nicht aktuell ist? Wenn ich speichere aktualisiert es die View, das habe ich gerade getestet und dafür gibt es ja auch den Haken "Update Structure on Save". Kann die Struktur anderweitig schaden nehmen? Schreibschutz Workflow etc? Oder kann beim Update etwas schieflaufen, dass es nicht ganz fertig speichert? (Ich habe ja plötzlich auch manchmal ein paar Bauteile zu wenig)

Viele Grüße und vorab gleich frohe Feiertage

Big King 06. Apr. 2021, 08:59

Morgen

paar fragen:
- nutzt ihr ITAR oder sonstiges ? worauf ich hinaus will, hat ein User bewusst/unbewusst ein ITAR Flag gesetzt?
- habt ihr an den Einstellungen in TC rumgespielt?
- also betrifft es alle Baugruppen oder nur von einem User oder BGs ab einem bestimmten Zeitpunkt? Eingrenzung möglich ?
- in NX "Dient ausschliesslich als Referenz" Teile werden in der BOMview (Structure Manager) nicht dargestellt. Ist dir das bewusst ?

mfg
BK

Robse-Ponte 06. Apr. 2021, 10:39

Hallo Big King,

mit Thomas seiner Hilfe können wir zumindest die Baugruppen wieder sauber laden. Haken raus und ich hatte (bisher) keinen weiteren Fehler. Aber wie ich schon geschrieben habe, ganz sauber ist das nicht, da die Struktur im TC definitiv einen Schaden hat. Anbei die Antworten auf deine Fragen: 

- Wir verwenden kein ITAR.
- TC wird grossteils von unserem PLM-Anbieter erledigt. Wir machen dort nur kleine Änderungen, bei denen wir wissen, was wir machen.
- Set As Reference kennen und nutzen wir. Da liegt ja auch das Ziel darin, dass Teile nicht in der Struktur auftauchen.
- Es betrifft alle User. Meiner Meinung nach stimmt etwas nicht mehr seit wir auf NX-Continous vor einem Jahr umgestiegen sind.

Um es etwas einzugrenzen:

-Wir verwenden für NX-Continous das gleiche TC-Settings wie bei NX11/12.
-Interessant dabei ist, dass es vor allem grosse Baugruppen betrifft. Wie als ob es sich beim Speichern der Struktur verschlucken würde. Vereinzelt berichten auch User beim Speichern über einen PLM-XML Fehler. Dort wird die Struktur nicht gespeichert. Nochmaliges Darüberspeichern behebt den Fehler.
-Solange kein Schreibschutz auf den Teilen war, scheint die Struktur richtig zu sein (getestet mit 5 großen Baugruppen > 50.000 Teile). Darum auch die Frage bzgl. Schreibschutz-Workflow. Kann dieser die Struktur zerstören? Dort wird eigentlich nur das Teil gesperrt. User berichten, dass Teile, die beim Erstellen auch immer sauber waren beim Laden zu einem späteren Zeitpunkt mit Schreibschutz die Struktur nicht mehr haben. Ich habe deshalb bei den Tests auch Teile schreibgeschützt. Kein Fehler zu finden. Es ist wie verhext. Ich finde den Trigger nicht, der das auslöst. Ich bin kurz davor den Mondkalender rauszuholen und dort nach Gemeinsamkeiten beim Speicherzeitpunkt zu suchen...

Ich habe von einem User noch eine Nachricht bekommen, dass unsere Versionswahl von TC11 und NX19.. zwar von Siemens freigegeben ist, aber nicht empfohlen wird? 

Ich glaube der nächste Schritt bei uns wird sein auf eine neuere TC-Version zu wechseln und das Ganze noch einmal sauber zu testen. Das wäre echt eine ganz miese Nummer, wenns daran liegen würde.

MfG

Big King 06. Apr. 2021, 12:34


wenn ich das so in der Mittagspasue lese.... wir hatten mal ein Problem mit Sequences von ItemRevision.... irgendwie hat es bei einem Update die Preference reingehauen, danach hatten wir ähnliche Probleme

Guck mal:
TCSequenceIDVisisble
TCCheckoutReserveOnly

und was wir auch schon hatten.... im UGMaster im Named Referenced 2 bis X *.prt
NX läd dann irgendwas....

der mit dem Einhorn find ich gut ;-) dachte das sind wir ;-)

tom-nx 06. Apr. 2021, 14:08

Hallo Robse-Ponte,

ich hab leider keine Lösung und auch keine Idee was euch die BOMīs vermurkst.

Da wir aber vor nicht allzu langer Zeit mit Siemens über mögliche Kombinationen (NX & TC) gesprochen haben und auch bei uns die Idee herumkreiste NXCR mit TC11.6.x zu betreiben, kam von Siemens zwar ein "ja das ist supportet", aber uns wurde davon abgeraten.

NXCR mit 12.2 aufwärts kam als Vorschlag. Ob das eine allgemein gültige Aussage ist kann ich leider nicht sagen.

Die TC11.6 ist wenn ich das von Siemens richtig verstanden habe, ja eher schon eine TC12.irgendwas, aber heißt halt nicht so.
Was das im Detail heißt weiß ich leider nicht.

Ob das aktuelle Problem damit zu tun hat weiß ich freilich nicht.

Grüße,
Thomas

Sir-Nosferatu 06. Apr. 2021, 14:15

Zitat:
Original erstellt von Robse-Ponte:

Ich habe von einem User noch eine Nachricht bekommen, dass unsere Versionswahl von TC11 und NX19.. zwar von Siemens freigegeben ist, aber nicht empfohlen wird? 


Hallo,

hier gibt es eine Übersicht über die Produktkompatibilität, welche Release-Kombinationen (incl. Patches) unterstützt werden:

https://docs.sw.siemens.com/de-DE/product/209349590/doc/PL20200507135732916.xid1753866/html/xid1847202

Grüße,

Sir-Nosferatu

Big King 06. Apr. 2021, 15:12


TC-NX_Versionshinweise.jpg

 

Zitat:
kam von Siemens zwar ein "ja das ist supportet", aber uns wurde davon abgeraten.

keine Ahnung welcher Bim Batsch von Siemens diese Aussage wieder gemacht hat, schon fraglich....

siehe Versionshinweise....und diese sind Supportet

TC11.6 mind. Patch 4 und NX ab 1851
TC11.5 mind. Patch 10 ab 1872

wir sind seit einem jahr mit 11.6 Patch 12 und NX1899/1903 unterwegs. keine Probleme ausser die normalen Begleiterscheinungen

ThomasZwatz 07. Apr. 2021, 22:08

Zitat:
Original erstellt von Robse-Ponte:
...
-Interessant dabei ist, dass es vor allem grosse Baugruppen betrifft. Wie als ob es sich beim Speichern der Struktur verschlucken würde. Vereinzelt berichten auch User beim Speichern über einen PLM-XML Fehler. Dort wird die Struktur nicht gespeichert. Nochmaliges Darüberspeichern behebt den Fehler.
-Solange kein Schreibschutz auf den Teilen war, scheint die Struktur richtig zu sein (getestet mit 5 großen Baugruppen > 50.000 Teile). Darum auch die Frage bzgl. Schreibschutz-Workflow. Kann dieser die Struktur zerstören? Dort wird eigentlich nur das Teil gesperrt. User berichten, dass Teile, die beim Erstellen auch immer sauber waren beim Laden zu einem späteren Zeitpunkt mit Schreibschutz die Struktur nicht mehr haben. Ich habe deshalb bei den Tests auch Teile schreibgeschützt. Kein Fehler zu finden. Es ist wie verhext. Ich finde den Trigger nicht, der das auslöst. Ich bin kurz davor den Mondkalender rauszuholen und dort nach Gemeinsamkeiten beim Speicherzeitpunkt zu suchen...
...

Ich hab jetzt in dem Thread erst die ersten 2 anderen Unternehmen "erkannt" die ebenfalls NxAssemblyArrangements nach TC synchronisieren. Das machen wohl nur Einhörner ...
Der "PLM XML Fehler" bezieht sich auf die Arrangements ? --> sieht man im NX Syslog, der gibt das explizit aus.

Wie schon geschrieben, weiss ich nicht mehr wann genau wir dieses Problem in der Vergangenheit hatten und warum war auch ungeklärt. Es ist aber schon echt "lange" her ...
Und zu dem Zeitpunkt haben wir auch noch nicht NxAssemblyArrangements nach TC synchronisiert.

Zum anderen gibts auch einen anderen Grund für leere BOMs ( das dürfte aber im vorliegenden Fall nicht zutreffen, der Beschreibung nach ists unwahrscheinlich, denn NX kennt die Baugruppenstruktur ja noch inklusive der Komponenten ):
Der/die Anwender haben aus irgendeinem Grund wirklich alle Komponenten aus der Baugruppe entfernt und gespeichert. Das kann man produzieren wenn man ungeniert im Grafikfenster alles selektiert ( RectangleSelect ) und "Entf" drückt - je nach eingestellter Selektion haut man damit auch mitunter alle Komponenten raus ...
Und dann noch ein SpeichernAlles an beliebiger Stelle abdrückt.

"Schreibschutz Workflow":
Solange der nichts mit der Struktur macht, würde ich den nicht als Ursache in Betracht ziehen.
Meiner macht dabei ein Unprecise/Precise, der käme da schon in die Liste der Verdächtigen ...

Und noch was:
Ist vielleicht ein Zusammenhang DefaultArrangementActive / NotDefaultArrangementActive beim Speichern in NX zu beobachten ?

Big King 08. Apr. 2021, 07:14

Zitat:
Vereinzelt berichten auch User beim Speichern über einen PLM-XML Fehler.

kannst den Fehler hier reinstellen ?


vielleicht ist es was banales...
- NX Rolle Standard ?
- NX User Profile mal gelöscht ?
- ist nur eine side config vorhanden oder kann jeder machen was er will ?
- 2-tier oder 4-tier oder awc ? Multiside?
- Versionkontrolle von NX und TC auf den Clients gemacht, überall identisch  ?

Edit: hab das noch in der TC Readme gefunden
Tc11.6.0.11,9628735,Remove_Subassembly_in_StructureManager,STRUCTURE_MGR,USABILITY,PS_EDITING,SAVE
Tc11.6.0.9,9545757,CPA2: Design Assembly with promoted body is not displayed correctly in eBOM,MPP,USABILITY,ALIGN_ASSM,ALL

mfg
bk


Sir-Nosferatu 08. Apr. 2021, 08:44

Hallo zusammen,

den PLMXML-Fehler hatte ich mal in Kombination mit zugewiesenen Projekten.

Geholfen hat:
CAD Daten schliessen - Projekt im Tc abgehängen (speichern) - CAD erneut öffnen - speichern und Projekt dann wieder zuweisen...

Wenn das nicht hilft hatte ich im zweiten Schritt in den CD die  "Sychronize Assembly Arrangements" deaktiviert.

Grüße,

Sir-Nosferatu

ThomasZwatz 09. Apr. 2021, 16:33

Zitat:
Original erstellt von Sir-Nosferatu:

den PLMXML-Fehler hatte ich mal in Kombination mit zugewiesenen Projekten.

Geholfen hat:
CAD Daten schliessen - Projekt im Tc abgehängen (speichern) - CAD erneut öffnen - speichern und Projekt dann wieder zuweisen...

Wenn das nicht hilft hatte ich im zweiten Schritt in den CD die  "Sychronize Assembly Arrangements" deaktiviert.


Das bedeutet dass die Propagation Rules für Projekte die AssemblyArrangement(s) unter der PSBOMViewRevision nicht abdecken dürften ( wobei die sonst automatisch die Zugriffsberechtigungen der PSBOMViewRevision erben, wie z.B. MasterForms auch ).

Robse-Ponte 09. Apr. 2021, 17:41


PLMXML.JPG

 
Hallo Thomas & auch an alle anderen

Zuerst einmal danke für die vielen wertvollen Inputs und Drehschrauben, an denen man prüfen kann.

Ganz kurz zur Erklärung, ja wir verwenden Arrangements in drei Fällen:

-Positionen von Zylindern eingefahren/ausgefahren
-Bewegliche Teile bei denen dann auch teilweise die Position überschrieben wird bei Schwenktüren etc.
-Variantenmanagement -> im Teil sind 110% der Teile verbaut und werden je nach Anordnung ein- und ausgeschalten.

Es ist in der Tat zu beobachten, dass die PLM-XML-Fehler bei den Baugruppen durch Synchronize Assembly Arrangement passieren. Es ist etwas verzwickt, da es teilweise funktioniert und manchmal nicht. Ich habe gerade einen Haufen Baugruppen etwas verändert bzw. neu überspeichert und ich konnte bei 40 BGs den Fehler 4x "heraufbeschwören".  Ich habe auch versucht, den alten Stand wieder zu laden und das noch einmal versucht und es klappt dann plötzlich alles ohne Fehler. Lasse ich das Synchronize Assembly Arrangement weg, kann ich Baugruppen ändern und ändern und ändern ohne dass etwas schiefläuft.

Leider lässt sich das sehr schwer nachweisen, da ich es nicht gebacken bekomme einen vernünftigen Testfall zu erstellen.
@BK Der Screenshot im Anhang wird dir nicht sonderlich helfen? Dort sieht man die Fehlermeldung + aktuelle TC Struktur nach dem Fehler.

Zitat:
Original erstellt von ThomasZwatz:

Und noch was:
Ist vielleicht ein Zusammenhang DefaultArrangementActive / NotDefaultArrangementActive beim Speichern in NX zu beobachten ?


Ein direkter Zusammenhang von der Default-Anordnung zu einer anderen kann ich nicht kategorisch ausschliessen, aber bei meinen Tests gerade war nicht zu beobachten, dass es dort vermehrt zu Fehlern kommt. Bist du dort schon einen Schritt voraus?

Ich habe den Strukturfehler auch bei Teilen ohne Anordnung. Ich bin gerade am Durchforsten, da bei den ersten beiden Teilen mit Strukturfehler ohne Anordnung zumindest mal in einer früheren Version eine Anordnung vorhanden war. Das wird jetzt mühsam, das alles aufzudröseln und zu durchforsten. Aber eventuell könnte das der Trigger sein, nach dem ich seit einer Woche suche...

Den zweiten von dir beschriebenen Fall schliesse ich jetzt mal aus, so schlimm sind unsere User dann doch nicht...

Zitat:
Original erstellt von Big King:

vielleicht ist es was banales...
- NX Rolle Standard ?
- NX User Profile mal gelöscht ?
- ist nur eine side config vorhanden oder kann jeder machen was er will ?
- 2-tier oder 4-tier oder awc ? Multiside?
- Versionkontrolle von NX und TC auf den Clients gemacht, überall identisch  ?


-Mit Standardrolle kann ich den PLM-XML-Fehler auch herleiten. Scheint nicht an unserer Rolle zu liegen.
-Jup keine Besserung
-Sidecofiq vorhanden und CD mit Schreibschutz drauf
-4-tier
-Jeder hat exakt die gleiche Software

In den Named References sind keine mehrfachen Daten vorhanden

Ich muss noch kurz durch Nichtwissen glänzen, da wir mit TC zwar klarkommen, aber wie gesagt, die Feinheiten macht eine Fremdfirma.

-Bzgl. TCSequenceIDVisisble + TCCheckoutReserveOnly: Wo finde ich die Settings und was sollte dort bevorzugt gesetzt sein?

ThomasZwatz 09. Apr. 2021, 22:21

Wegen Default / NichtDefault Arrangement frag ich weil Siemens das Verhalten der Stücklisten in TC12.1 geändert hat ( ich weiss nicht ob das schon für dein 11.6 gilt ):
Der StructureManager öffnet per Default das AsSavedArrangement, nicht mehr das DefaultArrangement wie vorher in TC10.1.
( das gilt so gut wie für alle Zugriffe auf die Struktur, auch eine Strukturübertragung nach SAP greift sich das dann ... )
Dann wurde nach Eskalation die Preference BOM_prefer_default_arrangement (=true) bereitgestellt ( glaub 12.1.0.8 ).

Ich hab weiters auch die Preference TC_arrangement_error_when_used_anchor_not_found (=0) gesetzt.

PLMXML errors haben wir beim Speichern in NX hin und wieder auch mal (Ursache ungeklärt), aber da ist nie die Struktur leer.

>>Ich habe den Strukturfehler auch bei Teilen ohne Anordnung. Ich bin gerade am Durchforsten, da bei den ersten beiden Teilen mit Strukturfehler ohne Anordnung zumindest mal in einer früheren Version eine Anordnung vorhanden war.
Soweit ich das mitgekriegt hab, löscht NX ganz brav das Arrangement in TC wenn mans in NX gelöscht hat.