Step 7 S7-400 Online Verbindung nur sporadisch möglich

[Spleanify]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

Ich beobachte seid geraumer Zeit ein Merkwürdiges Verhalten auf einigen S7-400 CPUs und habe noch nirgends einen passenden Hinweis auf meine Beobachtungen gefunden:

Ausgangslage:
- in einem Subnetz befinden sich 3 Stück S7-400 CPUs mit jeweils einem CP443-1 angebunden an ein LAN Subnetz
- mit einem VersionDog Server wird täglich ein Backup des Datenstands von der Steuerung gezogen
- alle 3 CPUs sind im gleichen Subnetz, und per Ping erreichbar
- alle 3 CPUs sind im Dauerbetrieb und laufen 24/7 (produktiv)
- Verbindungsressourcen der CPUs nicht ausgeschöpft / kein Webserver an der CPU in Betrieb
- Server befindet sich in einem anderen Subnetz

Verhalten:
- Verbindung zwischen Server und 2 CPU's schlägt sporadisch fehl --> Backup kann nicht erzeugt werden
- zur dritten CPU funktioniert die CPU ohne Probleme
- Es ist keine Regelmässigkeit erkennbar (mal gehts einige Tage am Stück, dann wieder nicht)
- Das Problem taucht auf verschiedenen Zugriffsgeräten auf (Server + mehrere PG/PC)

Massnahmen:
- Ich habe auf einem Monitoring Server für jede CPU ein Ping Sensor und ein TCP Port 102 Sensor in Betrieb genommen welche die Verfügbarkeit der CPU minütlich prüfen --> sowohl Ping als auch TCP Port 102 sind dauerhaft erreichbar
- Wenn ich aus dem Simatic Manager Step 7 (V5.6 SP2) eine Online Verbindung zu einer Steuerung aufbauen will, so ist das Resultat dasselbe: 2 Steuerungen sind nicht erreichbar, 1 Steuerung ohne Probleme (jedoch auch nur sporadisch)
- Das Seltsame an der ganzen Sache ist folgendes: Habe ich zu der einen Steuerung, welche immer erreichbar ist, eine Online Verbindung aufgebaut (zB. Baustein beobachten) und öffne parallel dazu eine Online Verbindung zu den anderen Steuerungen, welche sonst nicht erreichbar sind, erreiche ich diese ohne Probleme

Daher meine Frage:
- Konnte jemand von euch schon einmal was ähnliches beobachten? Gibt es eine bekannte Ursache für dieses Verhalten?
- Gibt es nebst dem TCP Port 102 noch weitere Ports die für Online Verbindungen an eine S7-400 offen sein müssen?

 

[thomass5]

Welche Firmwarestände haben die CPUs + CPs? Da gab es mal vor einiger Zeit Probleme mit nicht abgebauten Verbindungen...

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja, vielleicht gibts die IP Adressen sporadisch mehrfach im Netz....

 

[Spleanify]

Welche Firmwarestände haben die CPUs + CPs? Da gab es mal vor einiger Zeit Probleme mit nicht abgebauten Verbindungen...

• CPU 01: 6ES7 416-2XP07-0AB0 FW: 7.0.0
• CP 01: 6GK7 443-1EX30-0XE0 FW: 3.2.17

• CPU 02: 6ES7 416-2XK04-0AB0 FW: 4.0
• CP 02: 6GK7 443-1GX11 FW: 2.0

• CPU 03: 6ES7 416-2XN05-0AB0 FW: 5.1
• CP 03: 6GK7 443-1EX11-0XE0 FW: 2.6

Nicht mehr die neusten Komponenten, und natürlich sind die Firmwarestände ähnlich "aktuell". Gibt es eine Möglichkeit die nicht abgebauten Verbindungen zu diagnostizieren / sichtbar zu machen?

 

[Spleanify]

Naja, vielleicht gibts die IP Adressen sporadisch mehrfach im Netz....

Das haben wir schon geprüft, die IPs werden immer nur mit derselben MAC (die der CPs) in Verbindung gebracht. Es handelt sich hierbei um ein "managed" Netzwerk ohne offene Zugänge/Steckdosen wo sich einfach mal jemand einklinken kann.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schau dir doch mal die eingestellten MAC-Adressen bei den CPs an, nicht dass es da doppelt vergebene gibt. Wobei dann die Kommunikation eigentlich so gut wie nie funktionieren sollte, je nach dem wie viele Netzübergänge noch dazwischen sind.

Es wäre interessant, ob von Versiondog bei Fehler überhaupt keine TCP-Verbindung aufgebaut werden konnte, oder TCP-Verbindung erfolgreich war, und die Verbindung dann aber auf S7-Kommunikationsebene abgelehnt wurde. Dann kann sollte sich der Fehler schon eingrenzen lassen.

 

[thomass5]

Produktmitteilung: CP 443-1 Firmwareupdate V2.7 und uneingeschränkte Verwendung auf jedem Hardwareausgabestand (6GK7443-1EX10-0XE0 und 6GK7443-1EX11-0XE0)

SIOS

support.industry.siemens.com

 

[DeltaMikeAir]

Produktmitteilung: CP 443-1 Firmwareupdate V2.7 und uneingeschränkte Verwendung auf jedem Hardwareausgabestand (6GK7443-1EX10-0XE0 und 6GK7443-1EX11-0XE0)

Klingt interessant:

Produktverbesserungen:

1.) Bei einem Verbindungsabbau von einem bestimmten Windows XP TCP/IP Stack beendete dieser die Verbindung auf dem LAN nicht korrekt. Dadurch kam es zu einer permanenten Belegung von Verbindungsressourcen auf dem CP, was zu einer Nichterreichbarkeit des CPs führte. Durch einen Workaround sorgt der CP nun dafür, dass die permanente Belegung der Verbindungsresourcen durch Windows XP wieder aufgehoben wird und es damit nicht mehr zu einem Verbindungsengpass kommen kann.
2.) Bei schnellen Verbindungsauf- und abbauszenarien über das TCP/IP-Protokoll konnte es zu dauerhaft belegten TCP/IP-Sockets kommen. Dadurch konnten bestimmte Kommunikationsverbindungen nicht mehr aufgebaut werden. Dieses Verhalten tritt nun nicht mehr auf.
3.) Die Problematik beim Lesen der SZL 0x119 (LED Statusanzeige der Baugruppe) wurde behoben.
4.) Das Deaktivieren der Uhrzeitsynchronisation durch Urlöschen oder Rücksetzen auf Werkseinstellungen wir nun auch ohne Aus- und Einschalten der Versorgungsspannung übernommen.

 

[rar-101]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ähnliches verhalten ist mir bekannt, wir setzen MAC - Filter ein und da kommt (kam) das auch häufig vor. Wir haben herausgefunden, dass sich die CP´s zeitweise mit einer anderen MAC Adresse melden, immer die direkt danach kommende z.B.: 00:12:34:56:78:0A danach 00:12:34:56:78:0B

Hat scheinbar mit dem LLDAP zu tun, ist meines wissens nach nur dann der Fall wenn zwei Ethernet / PN Schnittstellen verbaut sind. Kam bei uns auch bei HMI´s, CPU´s und CP´s vor...

Seither tragen wir in den MAC - Filter standartmäßig beide MAC Adressen ein.

 

[Thomas_v2.1]

Ähnliches verhalten ist mir bekannt, wir setzen MAC - Filter ein und da kommt (kam) das auch häufig vor. Wir haben herausgefunden, dass sich die CP´s zeitweise mit einer anderen MAC Adresse melden, immer die direkt danach kommende z.B.: 00:12:34:56:78:0A danach 00:12:34:56:78:0B

Hat scheinbar mit dem LLDAP zu tun, ist meines wissens nach nur dann der Fall wenn zwei Ethernet / PN Schnittstellen verbaut sind. Kam bei uns auch bei HMI´s, CPU´s und CP´s vor...

Seither tragen wir in den MAC - Filter standartmäßig beide MAC Adressen ein.

Das liegt an Profinet, dort besitzt auch jeder Switch-Port eine eigene Port-MAC-Adresse. Eine ET200S CPU mit einem 3-Port besitzt somit insgesamt vier. Aber nur mit der aufgedruckten MAC-Adresse wird von der SPS auf ARP-Anfragen zur IP-Adresse geantwortet.

 

[rar-101]

Das liegt an Profinet, dort besitzt auch jeder Switch-Port eine eigene Port-MAC-Adresse. Eine ET200S CPU mit einem 3-Port besitzt somit insgesamt vier. Aber nur mit der aufgedruckten MAC-Adresse wird von der SPS auf ARP-Anfragen zur IP-Adresse geantwortet.

Das ist ziemlich genau das was uns Siemens geantwortet hat, auch mit dem Vermerk dass PN nicht ins Firmennetz gehört.
Wir können das aber nicht ganz so einfach trennen, da das leider so vorgegeben wird. Aber mit dem Eintrag von beiden MAC Adressen klappt das ganz gut.

 

[Spleanify]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schau dir doch mal die eingestellten MAC-Adressen bei den CPs an, nicht dass es da doppelt vergebene gibt. Wobei dann die Kommunikation eigentlich so gut wie nie funktionieren sollte, je nach dem wie viele Netzübergänge noch dazwischen sind.

Es wäre interessant, ob von Versiondog bei Fehler überhaupt keine TCP-Verbindung aufgebaut werden konnte, oder TCP-Verbindung erfolgreich war, und die Verbindung dann aber auf S7-Kommunikationsebene abgelehnt wurde. Dann kann sollte sich der Fehler schon eingrenzen lassen.

Sorry, was ein wenig "busy"
Hab eben mal unsere address-tables abgefragt: der CP meldet sich nur mit einer IP und einer MAC. Weder die IP noch die MAC lassen sich ein zweites mal auffinden im Netz. Der Ereigniseintrag im VersionDog zeigt folgendes:


Eine Erläuterung zu diesem Code habe ich noch nicht gefunden. Da ich mit dem Monitoring aber den TCP-Port 102 zyklisch prüfe vermute ich schon eher ein Fehler auf S7-Kommunikationsebene.

Ich hab das FW-Upgrade mal als Task aufgenommen

 

[Thomas_v2.1]

Fehler 10054 scheint direkt der Meldetext von den Windows Sockets zu sein:

Windows Sockets-Fehlercodes (Winsock2.h) - Win32 apps

Windows Sockets (Winsock) Fehlercodes, die von der WSAGetLastError-Funktion zurückgegeben werden.

docs.microsoft.com

Aber ob die Verbindung nach TCP Verbindungsanfrage abgelehnt wird, oder erst wenn sich versucht wird auf S7-Verbindung zu verbinden, geht mir daraus nicht hervor. Aber "Init Slot" hört sich sehr danach an.