Sonstiges RT Advanced und Drittanbietersoftware greifen auf SPS Daten zu - plötzlich n.m. mögli

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das haben wir versucht manuell nachzustellen, sprich: Wenn wir den Service auf dem Rechner beenden und dann die Drittapplikation starten, dann läuft das Ganze. Starten wir danach irgendwann den Service und die WinCC Runtime, dann verliert die Drittanbierter-App die Verbindung (die SPS auch...). -> Sollte doch das von dir erwähnte Vorgehen wiederspiegeln?

Ja, eigentlich sollte es so funktionieren. So mache ich es auch bei Nettoplcsim um dem Siemens-Dienst den Port wegzunehmen:
- Siemens Dienst beenden
- Eigenen Server auf TCP Port 102 starten
- Siemens Dienst starten, dieser kann aber seinen Server auf Port 102 nicht mehr starten, Dienst läuft aber weiterhin. Port 102 ist anschließend frei für eigene Serveranwendung.

Der Siemens Dienst versucht auch anschließend nicht erneut ob der Port wieder freigeworden ist. Eigentlich solltest du auch nachdem der Dienst wieder läuft deine Drittaplikation beenden und neustarten können ohne dass es zu Problemen kommt.

Du kannst über eine Eingabeaufforderung und ein paar Befehle herausfinden wer gerade auf Port 102 lauscht.
Mit:
netstat -ano | find ":102 "

Erhältst du im Ergebnis in der letzten Spalte die Prozess-ID des Tasks der den Port 102 gerade verwendet, z.B. 1234

Den Namen erhältst du dann mit
tasklist | find "1234"

 

[ADS_0x1]

Ja, eigentlich sollte es so funktionieren. So mache ich es auch bei Nettoplcsim um dem Siemens-Dienst den Port wegzunehmen:
- Siemens Dienst beenden
- Eigenen Server auf TCP Port 102 starten
- Siemens Dienst starten, dieser kann aber seinen Server auf Port 102 nicht mehr starten, Dienst läuft aber weiterhin. Port 102 ist anschließend frei für eigene Serveranwendung.

Der Siemens Dienst versucht auch anschließend nicht erneut ob der Port wieder freigeworden ist. Eigentlich solltest du auch nachdem der Dienst wieder läuft deine Drittaplikation beenden und neustarten können ohne dass es zu Problemen kommt.

Du kannst über eine Eingabeaufforderung und ein paar Befehle herausfinden wer gerade auf Port 102 lauscht.
Mit:
netstat -ano | find ":102 "

Erhältst du im Ergebnis in der letzten Spalte die Prozess-ID des Tasks der den Port 102 gerade verwendet, z.B. 1234

Den Namen erhältst du dann mit
tasklist | find "1234"

Top! Danke Thomas! Wir haben auf unseren Systemen genau das Verhalten, was du aufgezeigt. Aber.... das !#@%&? System beim Kunden macht es genau anders...

Dort zwingt das erneute Starten des Service den bisherigen Server zum Stopp:



:sm17::sb6:

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann der "Drittanbieter" erklären, warum sein Dienst (unbedingt) auf dem Port 102 laufen "muß"?
Wenn die Drittanbieter-Software einfach auf einem anderen freien Port laufen würde, dann hättet Ihr keine Probleme und alles wäre gut...

Harald

 

[ADS_0x1]

Danke Harald für deine Antwort,

leider musste hier ISO on TCP genutzt werden.... und der kommuniziert nun mal auf dem Port.

Aber an alle die gute Nachricht:

Wir haben das Problem mittlerweile gelöst. Es ist aber eher ein Workaround, als eine Lösung. Bei der Kommunikation hat sich irgendetwas geändert, sodass neben den Daten, die der SEND Baustein geschickt hat, weitere Daten an das Drittprogramm gesendet wurden. Das hat das Drittprogramm komplett überfordert, da man hier keine Filterung oder Selektierung von (Teil-)Daten vornehmen konnte, bzw. im Programm vorgenommen hat. Damit ist im Programm, von außen komplett unbemerkbar, der Socketserver nach einer Zeit abgestürzt. Die Fehlermeldungen dazu wurden nicht ausgewertet und unterdrückt. Zwar hat das Programm versucht, den Server neuzustarten, aber das ist fehlgeschlagen, weil sich noch Reste davon in Verwendung gefunden haben.

Alles in allem lag es also, wie einige hier und der Siemenssupport gesagt haben, am Drittprogramm :sw18:

Dafür haben wir - insbesondere durch eure Hilfe - viel über ISO on TCP Verbindungen gelernt...

Danke noch einmal in die Runde!