---

TC_Dienste.png

Hallo,

Aus irgendeinem Grund funktioniert bei uns der TC Dispatcher nicht mehr.

Eigentlich wird dieser über einen Freigabeworkflow aktiviert, aber auch manuell über Übersetzung-Konvertieren-nxtopdf bekomm ich kein pdf erzeugt.

Jetzt habe ich mal folgendes geprüft:

- TC Dienste am Server laufen alle.
- NX Lizenz ist verfügbar.
- Die Dispatcher Dienst neu gestartet.

Hat jemand ein Idee woran das liegen könnte?

Vielen Dank!!

Schöne Grüße,

Thomas

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

---

nxtopdf ist ein custom Translator, nehm ich an ?
( zumindest in 8.3 gibts den nicht ).

Aber gegangen ist der schon einmal ?

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

---

Hi Thomas,

Dass das ein Custom Translator ist wäre mir neu.

Ja das hat einwandfrei funktioniert. Wie gesagt, normalerweise aus einem Workflow heraus. Aber manuell mit dieser Übersetzung-nxtopdf hat es immer geklappt.

Danke!

Grüße,

Thomas

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

---

Unabhängig von custom oder nicht muss man als erstes schauen was aus dem Request geworden ist.

Entweder über die Admmin Konsole ( #Konvertierung ) auf einem RAC wo dieses Feature mitinstalliert wurde oder man macht sich eine Query für DispatcherRequests.

Dann geht die Sucherei in den Verzeichnissen los ....

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

---

Hallo Thomas

Ist es ein generelles Problem oder nur bei einzelnen Dataset's?

Ich kenne folgende Probleme:
- Mehrere Blätter in der Drawing
- Leerschlag im Dataset- Name

Hast du schon in den Logfiles geschaut ob du da was findest?

Gruss hausi

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

---

Hallo Thomas, Hallo Hausi,

zuerst mal Danke für eure Hilfe!

Das Problem tritt im Moment bei allen UGPART Datasets ein.

An mehreren Blättern und Leerzeichen im Dataset Namen kann es eigentlich nicht liegen.

Und der TC-Syslog gibt leider auch nix her.

Was aber etwas komisch ist, ich habe mir gerade den Dienst am Server angeschaut (Teamcenter DispatcherClient V9000.1.0.23_20130426.00) der befindet sich im Status Stopping.
Das war letzte Woche auch schon so, dann hab ich den Prozess gekillt und wieder gestartet.

Vielleicht brauchts ja mal ein Neustart des Servers?

Grüße,

Thomas

[Diese Nachricht wurde von tom-nx am 19. Mai. 2014 editiert.]

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

---

Hallo Thomas

Das Problem, dass der Client- Dienst nicht sauber neu gestartet werden konnte hatten wir auch schon mal. Reboot oder den fehlerhaften Service mit  z.B. Process- Explorer killen.

Viel Glück 
hausi

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

---

Zitat:

---

Original erstellt von hausi:
...Das Problem, dass der Client- Dienst nicht sauber neu gestartet werden konnte hatten wir auch schon mal. Reboot oder den fehlerhaften Service mit  z.B. Process- Explorer killen....

---

Dazu findet man auch Beiträge im uganswer.

Aus meiner Sicht als Nicht-reboot Option in diesem Fall am besten:
ProcessExplorer in der TreeView betreiben, den DispatcherClientService mit KillProcessTree beenden.
Eventuell verwaiste Translators ( sind in der TreeView dann weiter unten als TopNode zu sehen ) auch abwürgen.

Dann starte ich Scheduler / Module / Client neu.
( die ersten 2 natürlich auch zuerst beenden ... ).

Ich hab mir inzwischen auch einen ScheduledTask dafür angelegt ...

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

---

Hallo,

das mit dem Killen des entsprechenden Prozesses hab ich auch schon verucht.

Ich habe auch heute den Server komplett durchgestartet, aber der Dispatcher tut nix mehr.

Da muss ich wohl bei Siemens nachfragen.

Danke!

Grüße,

Thomas

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

---

Kannst du dich in Tc mit infodba einloggen?

Stoppe die Services in folgender Reihenfolge:

1 Client
2. Module
3. Scheduler

und Starte nachher in umgekehrter Reihenfolge.

CU

------------------
“Vision without action is a daydream. Action without vision is a nightmare.”

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

---

Hallo Big King,

ja die Services für den Dispatcher hab ich schon mehrmals gestoppt und wieder gestartet, auch ein Server Neustart hat nichts gebracht.

Was mich etwas wundert ist, dass normalerweise der DispatcherClientService.exe einen tcserver.exe als Unterprozess haben sollte, das ist bei uns (im Moment) nicht der Fall.

Grüße,

Thomas

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

---

Zitat:

---

Original erstellt von tom-nx:
...
Was mich etwas wundert ist, dass normalerweise der DispatcherClientService.exe einen tcserver.exe als Unterprozess haben sollte, das ist bei uns (im Moment) nicht der Fall....

---

D.h. das mindestens der DispatcherClient einen Patschen hat.
Schau mal ins Logfile ob da was drinsteht mit dem man was anfangen kann, bei mir ist das in <TC_DispatcherRoot>\Logs\Dispatcher\process.
Bei uns hat der DispatcherClient auch ein eigenes TEMP ( + Derivate ) damit man seine(n) TC Syslog leichter findet, das ist bei einem globalen TEMP recht mühsam.

Deine Requests werden dann alle noch auf INITIAL stehen, oder ?

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

---

DispatcherClient_172.18.2.23_2099.txt

Hi Thomas,

Der Logfile kommt mir etwas komisch vor, siehe Anhang.

Das klingt ein wenig nach Anmeldeproblem des dcproxy users, kann das sein?

Könnte mich aber nicht erinnern dass da mal etwas verändert wurde.

Zitat:

---

Deine Requests werden dann alle noch auf INITIAL stehen, oder ?

---

Richtig, die stehen alle auf INITIAL.

Danke!

Grüße,

Thomas

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

---

Zitat:

---

Kannst du dich in Tc mit infodba einloggen?

---

???

- PW abgelaufen > TC -- aktiv
- infodba in DB gesperrt
- AD Account ?

------------------
“Vision without action is a daydream. Action without vision is a nightmare.”

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

---

Ja mit dem infodba kann ich mich einloggen, aber ich denke das hat damit nix zu tun.

Da dürfte es wirklich mit dem Dispatcher selber etwas haben.

Grüße,

Thomas

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

---

Hallo Thomas

hast du für dein problem eine Lösung?

komischer weisse habe ich nun das gleiche nur mit Tiff... laufen alle in TERMINAL...

CU
Big King

------------------
“Vision without action is a daydream. Action without vision is a nightmare.”

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

---

tcserver.PNG

Hallo Big King

ja inzwischen weiß ich was damlas war.

Hat dein DispatcherClientService.exe einen tcserver.exe als Unterprozess wenn Du dir das im process Explorer anschaust?

Grüße,

Thomas

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

---

ScreenShot2042.jpg

sieht bei mir andes aus, aber ist vorhanden

------------------
“Vision without action is a daydream. Action without vision is a nightmare.”

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

---

und da wo dieser tcserver.exe dran hängt macht das was bei uns der DispatcherClientService.exe macht?

Was sagt denn der DispatcherClient*.log? Der ist bei uns in D:\Siemens\TC91\DispatcherRoot\Logs\Dispatcher\process

Bei uns war damas das Problem dass der DispatcherClientService.exe seinen tcserver.exe verlorgen hatte.

Grüße,

Thomas

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

---

Servus

wir vermuten das letzte Woche die Server Truppe einige MS Security Patches eingespielt haben und nun irgendwas schief geht.
Es läuft in der zwischenzeit wieder.

Haben auch noch ein paar Sachen am Virenscanner Exluded: *.prt ; *.tif ; Folder: *\Stage\* ; *\Logs\*

haben in der nxtotiff.bat ein  -wait=60 gesetzt.

mfg

------------------
“Vision without action is a daydream. Action without vision is a nightmare.”

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

---

Ju Hu

naja, da es mal wieder nicht funzzt.....

Habe im Dispatcher Server Modul folgende Meldung: „Cannot calculate CpuUsage. CpuUsage is -1“

Kann mir ev. mal jemand seine Einstellungen vom VMServer übermitteln, ev. ist da noch was Faul 

1. Einstellungen bearbeiten
2. Optionen
  > alles mit CPU
3. Ressourcen
  > alles mit CPU

Komisch dass dies immer nach den Security Patches auftritt....

Und wir sind natürlich wieder die einzigen 

grüsse und Danke
Big King

------------------
“Vision without action is a daydream. Action without vision is a nightmare.”

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

---

Hallo

nachdem wir Anfang November die Lösung bei uns gefunden hatten und
der Dispatcher so zuverlässig wie noch nie die Jobs abgearbeitet hatte,
war es Anfang dieser Woche mal wieder soweit......
MS Security Patches wurden auf dem Server eingespielt,
der Server Neu gestartet und ....... PENG .... nur noch Terminal vom Dispatcher.....

November 2016
-------------
Wir hatten unseren Virenscanner unter verdacht -->> McAfee
Nachdem wir folgende Einstellungen getätigt hätten lief es wie geschmiert.

Virus Scan-Konsole > Task > Eigenschaften unter Zugriffsscanner

> Standard-vorgänge > Ausschlüsse > hier die Dateiendungen und Pfade zur Installation angeben
Bsp:
-*.prt
-*.jt
-c:\CAD\ (Pfad zu TC/NX Installation - Unterordner auch einschliessen)

dies war aber McAfee nicht genug, es gibt eine weitere Einstellung....

> Vorgänge mit geringem Risiko > Vorgänge > hier alle *.exe die kein Risiko darstellen einfügen...
Bsp:
- tao_imr_activator.exe
- tao_imr_locater.exe
- tcserver.exe
- Teamcenter.exe
- ugraf.exe
- etc.

Diese Einstellungen für Server und Clients..... ich habe sogar die Exe zum BMIDE hier angegeben, läuft seither auch ein weniger flüssiger.....

So danach war für 2 monate ruhe und es gab keinerlei Probleme......

Januar 2017
-----------
wie gesagt erneut Probleme, erster verdacht war natürlich der geliebte McAffe.... das wars aber nicht....
irgendwie hatte es diesmal mit den Berechtigungen auf C:\Temp zu tun..... in diesen will da so definiert der Dispatcher schreiben...

Folgende Variabeln haben wir nun auf einen anderen Folder geändert --> c:\CAD\temp (dieser ist auch im McAfee excluded)

UGII_SDI_OVERRIDE_HOME=c:\temp
UGII_SDI_BPS_JOBS_DIR=c:\temp
UGII_SDI_OUTPUT_DIR=c:\temp

danach lief der Dispatcher wieder wie zuvor...... mal schauen wie lang ;-)

Vielleicht hilft die obige Beschreibung irgendwem.....

Best Regards
Big King

------------------
“Vision without action is a daydream. Action without vision is a nightmare.”

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