# wago 750-881 stellt ethernetkommunikation ein



## Tiroler (27 November 2012)

Hallo, 
Ich habe folgende zwei Programabläufe:

task1 100ms
Ethernet Server öffnen
auf Clientverbindung warten
Daten von Client empfangen und in global input speichern
daten aus global output an Client senden
Verbindung schliessen

task 2 50ms

Daten aus global input lesen
 DO1-8 schreiben
DI1-8 einlesen
Daten in Global output schreiben
DO9=DI9


nach ein oder zwei Tagen bricht die Verbindung ab, Webvisu und Onlinepanel sind nicht erreichbar und auch Codesys kommt nicht mehr auf die Steuerung Pings werden aber beantwortet. 

die Logik DO9=DI9 wird aberweiterhin abgearbeitet. Heißt also zumindest ein Teil der Steuerung läuft noch

Nach einem Warmstart der Steuerung läuft alles wieder wie normal ohne Fehlermeldung (kein watchdog ausgelöst ect.)

im moment habe ich mehrere Steuerungen mit dem selben Programm aber vollkommen zufällige Ausfälle.

1. eine schnelle Lösung wäre über SysResetPlcProgram die Steuerung bei Kommunikationsabbruch für mehr als 10min zurückzusetzen, wie kann ich das einbinden, die Funktion ist im Bibliotheksverwalter grün und wird nicht unterstützt?

2. wie kann ich die Ursache finden? ich habe keine Speicherüberläufe, bei deaktivierten Watchdogs tut sich auch nichts und die Steuerung ist nicht ausgelastet.

sg und Danke
 Clemens


----------



## KingHelmer (27 November 2012)

> die Funktion ist im Bibliotheksverwalter grün und wird nicht unterstützt?



Grün bedeutet ja normalerweise nur, dass die Funktion nicht übersetzt wird.
D.h. du nutzt diese nicht und hast, entweder manuell, oder automatisch über die Übersetzungsoptionen, die ganze Bibliothek oder eben nur dieses Teil der Bibliothek vom Übersetzen ausgeschlossen.

Gehe also auf Projekt-Optionen-Übersetzungsoptionen-Objekte ausschließen.

Hier entfernst du den Haken bei "nicht übersetzen" unten links. Dann schreibst du dein Programm und am Ende übersetzt du alles, kannst danach wieder die unbenutzten Blöcke ausschließen und dein Programm funktioniert.

Mit dem Baustein selbst habe ich keine Erfahrung!

Grüße, 

Florian


----------



## Tiroler (27 November 2012)

DANKE!
Damit ist zumindest eine kurzfristige Lösung möglich.


----------



## dast (27 November 2012)

Hallo Clemens,

ich bin zwar nocht recht frisch auf dem Gebiet der SPS-Programmierung, dein beschriebenes Problem könnte aber auf "orphaned sockets" (verwaiste Sockets unter Linux) hindeuten:
"_An  "orphaned socket" is a record in most Unix-like kernels for a socket  that is no longer attached to a socket descriptor in any user processes,  but for which the kernel is still required to maintain state in order  to complete the transport protocol.  This typically shows up in TCP  sockets when a user process closes a socket while there is still  unacknowledged data to transmit to the remote peer, ..._"​
[Quelle: http://www.quora.com/Whats-orphaned-sockets-and-how-can-I-prevent-them]​

Speziell in deinem Fall wäre der Einsatz von UDP vielleicht besser geeignet (viele, recht kurze Verbindungen/Datenaustausch).
Auf die Schnelle könntest du auch versuchen ein "Delay" zwischen dem Senden der Daten und dem Schließen der Verbindung einfügen um zu Verifizieren ob das das Problem ist. Das Delay soll verhindern, dass die Verbindung beendet wird solange noch versendete Daten zu quittieren sind.
Oder du lässt dir den Empfang der Daten auf der Gegenstelle quittieren bzw. du vertauscht Senden und Empfangen der Daten auf der SPS und der Gegenstelle.

Vielleicht hilft dir das ja ...

LG Daniel.


----------



## Tiroler (28 November 2012)

Danke für den Tipp. 
ich habe jetzt probiert bewusst einen solchen fall auszulösen. ein paket von der steuerung an den client und dann verbindung schliessen, bevor ack kommt. das ist der steuerung eigentlich egal. ich werde versuchen morgen in paar weitere fälle die dazupassen durchzuspielen und sehen, ob ich sie damit abstechen kann. 

nein, UDP geht leider nicht. der client ist ein schlecht programmierte black box, an die komme ich nicht ran (leider). 

jetzt habe ich eine umfassende logging funktion gebaut und werd schaun, was passiert, wenn die wieder abschmiert. 

dank florian habe ich ja jetzt zumindest eine möglichkeit die station durchzustarten, wenn sie sich nicht mehr meldet. damit erspare ich mir den weg zum kunden und komme immer auf die steuerung. keine gute lösung, aber sollte zumindest eine woche halten, bis ich eine idee habe, woran es sonst liegen kann.

sg und danke


----------



## dast (28 November 2012)

Hallo Clemens,

magst du dein SPS-Programm nicht mal posten?! Würd das ganze gern mal testen ...
Die "schlecht programmierte Black Box" kann ich mir ja selber am PC zusammenbasteln.

Ach ja, hast du Zugriff auf die "Black Box"? Ist das ein normaler PC?
Falls ja, könntest du -- falls keiner der Hinweise fruchtet -- einen kleines Dispatcher-Programm schreiben, das über "localhost" per TCP die Daten vom "Black Box Programm" empfängt, per UDP an die SPS schickt, von der eine UDP Nachricht empfängt und dann per TCP weiter an das "Black Box Programm" schickt.
IP-Adresse und Port solltest du ja an dem "Black Box Programm" konfigurieren können, oder?
Vielleicht ein Versuch wert. Zwar etwas umständlich, aber wenns hilft ...

LG Daniel.


----------



## Tiroler (12 Dezember 2012)

so, nachdem ich mit dem Wago support telefoniert habe:
1. ethernet lib gegen neue version austauschen (warum steht das in der beschreibung der alten lib auf der wago homepage nicht groß rot drin?!)

2. das problem war wirklich nur die anzahl der offenen ports. da die arbeitszeit in der blackbox mal schneller und mal langsamer ist kommt es zufällig zu einem überlauf und die kommunikation hängt sich auf. wenn man jetzt mit codesys dran geht stirbt die steuerung ganz weg und braucht einen reset.

behebung: alles verschmeißen, was nicht in 10ms abgearbeitet werden kann. zudem einen zweiten task, der die funktion des ersten überwacht und im fehlerfall die steuerung zurücksetzt (ist bis jetzt aber nie vorgekommen, da das verwerfen ja funktioniert)

sg und danke für die hilfe


----------

