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

ADS_0x1

Level-2
Beiträge
343
Reaktionspunkte
89
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

wir stehen gerade in der Firma vor einem Rätsel:
Auf einem Kunden-PC läuft seit geraumer Zeit folgende Konfiguration:
- WinCC Runtime Advanced 13.0 SP1 Update 8
- Drittanbietersoftware (in C# geschrieben, Verbindung über ISO-on-TCP)

Beides hat erfolgreich auf die Daten einer S7-1500er Steuerung zugegriffen. Vor einigen Wochen ist eine Feldkomponenten (PN device) der Konfiguration hinzugefügt worden, danach lief die Anlage bis letzte Woche ohne Probleme weiter.

Nun können WinCC RT advanced und die Drittsoftware nicht mehr zeitgleich auf die SPS zugreifen; schlimmer noch:
  • Fährt der PC neu hoch, startet sich Runtime Advanced, Verbindung zur SPS erfolgreich. Verzögert durch ein Skript startet dann die Drittsoftware, kann aber keine Verbindung aufbauen.
  • Beenden wir die Runtime advanced und den Dienst S7oiehsx64 (S7DOS Helper Service), kann die Drittsoftware eine Verbindung aufbauen - nur halt WinCC nicht mehr, weil wir die S7online Verbindung gekillt haben)

Natürlich wurde sonst nichts an den Einstellungen geändert (Kundenaussage). Nach Rücksprache mit Siemens ist natürlich die Drittanbietersoftware schuld - die ist aber seit 2015 auf dem PC am laufen und funktionierte auch bis letzte Woche erfolgreich parallel zu WinCC RT advanced.

Jetzt stehen wir vor dem Rätsel, das Ganze wieder an's Rennen zu bekommen.

Irgendwelche Tipps / Vorschläge? Danke im Voraus!
 
Hört sich erst mal so an, als bestünde da ein Problem mit Verbindungsrecourcen ( mit der 1500ér habe ich
mich mit denen allerdings noch nicht beschäftigt )
 
Ich würde auch sagen, verbindungsrecourcen. Ich nehme an, einen Kaltstart der cpu habt ihr noch nicht versucht? Was sagen die verbindungsrecourcen der cpu? Was sagt der status des tcon der cpu und was die diagnostic?
 
Danke Mike,

ich habe schon von TIA aus auf die CPU online geschaut. Dort ändert sich bei den Verbindungsressourcen allerdings nichts, wenn ich die ISO-on-TCP Verbindung verbinde bzw. trenne (der Drittsoftware).

Liegt es vielleicht daran, dass eigentlich der S7Online Zugangsknoten die Verbindungen sammelt und dann über den ISO on TCP Port 102 gesammelt zur Kommunikation mit der SPS nutzt?

Was gerade noch aufgefallen ist, dass bei den Kommunikationseinstellungen von TIA kein Stationsname eingetragen war:

stationsname.jpg

Den haben wir nun eingetragen, müssen die Kiste aber noch neustarten. Dazu kommen wir derzeitig nicht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Ihr Beiden,

die Verbindungsressourcen ändern sich nicht, wenn die ISO on TCP Verbindung besteht oder nicht:

verbindungen_ISOONTCP_deaktiv.pngverbindungen_ISOONTCP_aktiv.png

Die Änderungen beim LLDP / DCP und der Neustart haben ebenfalls keinen Erfolg gebracht. Unser nächster Schritt ist das Installieren des Updates 9 (letztes Update für diese Version).

Viele Grüße
 
Wer ist der Aktive Part bei der ISo_On_TCP verbindung? Was sagt die Diagnose (diagnosebaustein) auf der CPU warum die Verbindung nicht aufgebaut wird?
Ich würde jetzt der Reihe nach Ports kontrollieren? Hat windows irgendwelche Securityeinstellungen geändert (vovon ich nicht ausgehe sonst würd es auch ohne laufenden S7oiehsx64 nicht funktionieren)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo ADS,

was ist unter der Pg Pc Schnittstelle in der Systemsteuerung eingestellt?
Stell mal einen Screenshot bitte ein.
Geh mal unter Sytemsteuerung Netzwerk und Klick dann deine Netzwerkkarte an dann auf Details und mach von da bitte mal einen Screenshot.


mfg Tia
 
Wer ist der Aktive Part bei der ISo_On_TCP verbindung? Was sagt die Diagnose (diagnosebaustein) auf der CPU warum die Verbindung nicht aufgebaut wird?
Ich würde jetzt der Reihe nach Ports kontrollieren? Hat windows irgendwelche Securityeinstellungen geändert (vovon ich nicht ausgehe sonst würd es auch ohne laufenden S7oiehsx64 nicht funktionieren)

Hallo Vollmi,

aktiver Part ist auf dem IPC, einmal die Runtime, die auf die SPS Daten zugreift und einmal das Drittanbieterprogramm, das ebenfalls aktiv eine Verbindung aufbaut.
Was wir festgestellt haben, als wir das Dritt-Programm debugged haben: Wenn bereits eine Verbindung zwischen Panel und SPS besteht (und somit auch der Service gestartet ist), dann steigt das Drittprogramm mit der exception "Port already in use by another program" oder sinngemäß soetwas.... warum hat es denn dann vorher funktioniert... gab es in irgendeinem Siemens Update oder gibt es in irgendeiner Siemens / TIA / WinCC Einstellung einen Haken, der Kommunikation von Drittsoftware unterbindet?

Hallo ADS,

was ist unter der Pg Pc Schnittstelle in der Systemsteuerung eingestellt?
Stell mal einen Screenshot bitte ein.
Geh mal unter Sytemsteuerung Netzwerk und Klick dann deine Netzwerkkarte an dann auf Details und mach von da bitte mal einen Screenshot.


mfg Tia

Hi Tia!

Die PG-PC Schnittstelle über die "klassische" Schnittstelleneinstellung von Step 7 ist auf den Netzwerkadapter 3 gestellt (der einzige, der auch verbunden ist). In den "neuen" Kommunikationseinstellungen von TIA ist dieser ebenfalls eingestellt, dort haben wir dann auch den LLDP / DCP anpassen müssen, weil er auf einmal leer war. Ist nun identisch mit dem DNS Namen des PCs - auch in der Iso on TCP Verbindung in TIA haben wir dort den Namen eingetragen.

Ich komme gerade nicht remote auf die Kiste drauf. Wir haben gestern Abend noch einen Post im Siemensforum gefunden, dort sagte jemand, dass wir alle Siemens-Protokolle mal deaktivieren sollen - das haben wir dann in allen möglichen Kombinationen gemacht, hatte aber auch keine Änderung herbeigeführt. Nun haben wir wieder den Status Quo hergestellt und die drei Siemens-Häkchen sind gesetzt. Wie gesagt - Screenshot folgt später, wenn wir die Freigabe für die Remote vom Verantwortlichen vor Ort haben.


Viele Grüße!
 
welchen port nutzt ihr denn? Könntet ihr testweise auf was unverfängliches jenseits der 4000 wechseln? Also sowohl ein wie auch ausgehenden ports.

Ihr habt da nicht zufällig noch irgendwelche geräteserver eingebunden (Serialports oder usb ports)?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
welchen port nutzt ihr denn? Könntet ihr testweise auf was unverfängliches jenseits der 4000 wechseln? Also sowohl ein wie auch ausgehenden ports.

Ihr habt da nicht zufällig noch irgendwelche geräteserver eingebunden (Serialports oder usb ports)?

Die Software kommuniziert via ISO-On-TCP mit Remote und lokalen TSAPs - das passiert über ein- und denselben Port (102). Bei Siemens steht folgendes dazu:
RFC1006102TCPRFC 1006 mit dem Titel "ISO Transport Service on top of the TCP" (ISO-on-TCP) ist eine Protokoll-Erweiterung für das TCP-Protokoll und erlaubt eine zuverlässige Verbindung zwischen zwei Systemen.
RFC 1006 wird für folgende Standardverbindungen im SIMATIC Umfeld verwendet.


  • STEP 7 Fernprogrammierung über LAN
  • ISO-on-TCP Verbindungen
  • S7-Verbindungen über Industrial Ethernet
Hinweis

  • Der Port 102 ist standardmäßig in Routern und Firewalls gesperrt.
  • Weitere Informationen zum Dienst RFC1006 finden Sie im Beitrag 15048962.


Firewall ist in Ordnung. Wie bereits geschrieben haben wir durch debuggen des "alten" .net Programms die Information erhalten, dass - sobald WinCC RT advanced läuft - die .net App nicht mehr auf den Port zugreifen kann, da dieser bereits von WinCC benutzt wird.
Das ist vollkommen logisch und macht auch Sinn.... aber warum hat der Kram dann vorher funktioniert? :cry:
 
Wenn diese PC-Anwendung die Verbindung aktiv zur SPS aufbaut, dann kann ihr es egal sein ob der Port 102 schon von jemand anderen verwendet wird.
Also entweder ist diese PC-Anwendung Server auf Port 102 und die SPS baut aktiv die Verbindung zum PC auf, oder diese Anwendung ist Client, lässt sich aber den eigenen Port nicht vom Betriebssystem zuweisen sondern möchte fix den TCP Port 102 verwenden. Das wird aber üblicherweise nie so gemacht, weil es wie hier zu sehen ist auf einem Betriebssystem immer zu Problemen führt.

Dass es irgendwann mal funktioniert hat, könnte daran liegen, dass diese Anwendung vor dem Siemens Dienst der den Port 102 verwendet gestartet wird. Wenn dann der Siemens Dienst startet, dann kann dieser den Port 102 nicht mehr verwenden, was aber nicht weiter stört. Ich habe bei Nettoplcsim das gleiche Problem mit dem Dienst, dort schnappe ich mir in dieser Weise dem Siemens-Dienst den Port 102 weg. Vor ein paar Jahren konnte dieser Dienst ohne weitere Auswirkungen beendet werden. Siemens hat aber aus welchem Grund auch immer, immer mehr Funktionen an diesen Dienst gehängt, sodass viele Dinge nicht mehr funktionieren wenn dieser beendet wird.
 
Könnte es sein, daß die Fremdsoftware gar keine ISO-On-TCP-Verbindung macht, sondern eine S7-Verbindung? Zum Port 102 kann man meines Wissens keine eigene ISO-On-TCP-Verbindung machen, zum Port 102 muß imho alles S7-Protokoll sein.
Verwendet die Fremdsoftware eine Bibliothek eines dritten Anbieters, wie z.B. Snap7 oder Libnodave?
Zu welchem Port, zu welcher Verbindungsressource bzw. TSAP will die Fremdsoftware die Verbindung aufbauen?
Gibt es bei der S7-1500 evtl. Begrenzungen der Anzahl (ggf. nicht projektierter) einseitiger S7-Verbindungen zum TSAP 03.xx?
Ist PUT/GET in der S7-1500 freigegeben?

Hat irgendjemand (z.B. beim Zufügen des PN-Device in der Gerätekonfig) TIA-Updates eingespielt und/oder das TIA-Projekt zu einer anderen TIA-Version hochgerüstet/migriert und/oder die Firmware-Version der CPU geändert?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was wir festgestellt haben, als wir das Dritt-Programm debugged haben: Wenn bereits eine Verbindung zwischen Panel und SPS besteht (und somit auch der Service gestartet ist), dann steigt das Drittprogramm mit der exception "Port already in use by another program" oder sinngemäß soetwas....
Das scheint tatsächlich darauf hinzuweisen, daß das Problem nicht die S7-1500 ist, sondern daß das Drittprogramm den Port 102 des PC als eigenen/Absender-Port verwenden will - und das wäre tatsächlich ein Fehler des Drittprogramms, wenn es kein Dienst/Server für eingehende Verbindungen mit S7-Protokoll ist, weil das nur funktioniert, solange auf dem PC-Port 102 kein (Siemens-)Dienst läuft (wie Thomas schon schrieb). Falls tatsächlich ein fixer Absender-Port für die Verbindung nötig ist, dann muß das Drittprogramm (und ggf. das SPS-Programm der S7-1500) auf einen anderen freien Port des PC umgestellt werden.

Harald
 
Es gibt ja auch noch die S7-SAPI-Schnittstelle über die eine PC-Anwendung die Siemens Schnittstelle S7Online und die Funktionen zum Variablen lesen und schreiben aus der S7SAPI verwendet um mit einer S7 zu kommunizieren, oder eine Anwendung die libnodave als Protokolltreiber verwendet könnte ebenso S7online verwenden. Dagegen spricht aber die Fehlermeldung der Anwendung bezügl. belegten Ports.
 
Hallo Thomas und Harald,

danke erst einmal. Meine Antwort geht in die Richtung von euch beiden, daher hier mal zusammengefast:

Ich hab jetzt nochmal mit unserem IT-Hochsprachen-Menschen geschaut:
Das .net Programm startet einen Socketserver auf dem Port 102 und zerlegt die empfangenen Bytes nach einem Schema, dabei wird lokale und remote TSAP ausgewertet.
Es scheint so, als wenn es selbst entwickelt ist, da keine Bibliothek eingebunden und auf keine dll verwiesen wird. Intern wird lediglich das Sockethandling der .net Umgebung genutzt.

Hier bin ich auch überzeugt, dass das Ganze funktioniert, denn wenn der S7DOS Helper Service nicht läuft, dann funktioniert die Verbindung und TIA zeigt mir in der Verbindungsdiangose auch an, dass erfolgreich die ISO on TCP Verbindung besteht (vgl. Post 6 in diesem Beitrag, das Icon ist grün). Der aktive Part kommt hierbei von der SPS, hier die Bilder aus dem TIA Portal:


sadfgaw4ertg2q3.pngfdesawfgqw3t1.png


Auf dem PC war im Autostart ein Skript angelegt, dass semantisch folgendes gemacht hat:
  • Drittsoftware starten
  • 30 s Pause
  • Service Starten (S7DOS Helper Service)
  • 90 s Pause
  • WinCC Runtime advanced starten

Latine loqui non iam possum...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Könntest Du auch ein Bild der "Adressdetails" der projektierten Verbindung zeigen?
(Von den 2 letzten Bildern ist lediglich informativ, daß die SPS der aktive Partner ist, und das es tatsächlich eine ISO-on-TCP-Verbindung ist.)
Sollte beim Partner der Port 102 projektiert sein, dann ist das der Fehler der Drittapplikation. Auf dem selben Port können nicht 2 (einander fremde) Dienste gleichzeitig auf Verbindungen warten. Und Siemens wird ganz sicher nicht für irgendeinen Drittanbieter den Port 102 freigeben...

Harald
 
Auf dem PC war im Autostart ein Skript angelegt, dass semantisch folgendes gemacht hat:
  • Drittsoftware starten
  • 30 s Pause
  • Service Starten (S7DOS Helper Service)
  • 90 s Pause
  • WinCC Runtime advanced starten

Das würde sogar funktionieren, dazu müsste aber der S7DOS Dienst in den Starteinstellungen von Auto auf Deaktiviert umgestellt werden.
Oder du musst in diesen Ablauf einen 1. Schritt zu Beginn einfügen, der den S7DOS Dienst beendet.
 
Das würde sogar funktionieren, dazu müsste aber der S7DOS Dienst in den Starteinstellungen von Auto auf Deaktiviert umgestellt werden.
Oder du musst in diesen Ablauf einen 1. Schritt zu Beginn einfügen, der den S7DOS Dienst beendet.

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?

@Harald: Ich kämpfe gerade damit das Projekt auf meinem Rechner zu öffnen, ich hab leider kein TIA v13 mehr drauf... sobald das funktioniert mache ich noch einen Screenshot, ansonsten - morgen.

Viele Grüße!
 
Zurück
Oben