HS/FS - √ - Netzwerkkarte für 30 Minuten außer Gefecht

[schmiddi998]

Moin moin,

hatte gestern ein traumatisches Erlebnis mit dem HS3. Folgendes Problem:
Ich steuere mittels eines Ethernet/DMX Gateways die Unterwasserbeleuchtung von Schwimmbädern. Bisher gab es das Gateway nur als RS232/DMX, so dass ich noch ein Ethernet/RS232 Gateway davor schalten musste. Letzeres habe ich per UDP angesteuert, weil ein Telegrammverlust keinerwegs tragisch wäre. Jetzt habe ich ein neues Ethernet/DMX Gateway, wo der Ethernet/RS232 wegfällt. Das neue Gateway lässt sich aber nur per TCP ansteuern...soweit kein Problem.

Aber... aus irgendeinem Grund meldete der HS unter den "Exceptions" einen Fehler in "DoSend" oder "ConnectSocket" oder so ähnlich (habs leider nicht notiert). Dann hatte ich plötzlich kompletten Verbindungsausfall, d.h. keine Verbindung mehr zum Touch-Panel (Client) und auch keine zum PC.
Selbst "pingen" ging nicht mehr (Zeitüberschreitung bzw. Host nicht erreichbar). Nach ca. 30 Minuten rätseln und mehreren vergeblichen Neustarts fing sich der Homeserver wieder selbst.

Das Ganze hatte ich aber 3 Mal an dem Tag, bis ich die Verbindung per TCP zu dem DMX-Gateway rausgenommen habe. An dem Gateway kann es nicht liegen, weil der Homeserver selbst dann nicht mehr reagiert hat, wenn ich nur meinen PC und den Homeserver am Switch hatte. Das Problem löste sich wirklich nur von selbst, allerdings erst nach 30 Minuten. Unter den "Exceptions" war dann was von "TimeOut" die Rede.

Wirlich zu dumm, dass ich mir die Fehleranzeige nicht kopiert habe...
Beim nächsten HS3, der "über" ist, werde ich versuchen, den Fehler zu reproduzieren.

Was Gateway von Ethernet/DMX angeht ist die Hersteller-Firma glücklicherweise bereit, die Firmware um UDP zu erweitern. Mit UDP sind Fehler ala "Socket" und "TimeOut" Gott sei Dank nicht möglich.


Hat jemand ähnliche Erfahrungen gemacht, was Verbindungen per TCP über den HS angehen ?? Ich habe Dacom auch schon vorgeschlagen eine Option einzufügen, dass die TCP-Verbindung nicht beendet wird. Somit steigen die Chancen den HS an eine SPS zu koppeln. Bisher geht das nur per Ethernet/RS485.

Vielleicht nimmt Dacom den Vorschlag mit auf die Wunschliste ;-)

MfG
schmiddi998

[makki]

Obs am HS selbst liegen kann sollen die Experten beurteilen, kann ich mir aber ehrlichgesagt nicht vorstellen.
Ich würde nach Deiner Beschreibung eher auf andere Netzwerk-Probleme als Ursache tippen, die das beschriebene Phänomen als Wirkung haben.
Ich knattere auch im Sekundentakt die TCP-Verbindungen zu Moxa etc. raus, bisher keinerlei Probleme..

Ohne Details zu anderen Komponenten (DMX-GW, Switches, Router) ist das aber stochern im Nebel..

Makki

[meudenbach]

Wäre mal interessant zu wissen, mit welchen Parametern Du die TCP Verbindung eingerichtet hast. Eine TCP Verbindung permanent offen zu halten ist auch nicht grad der Weisheit letzter Schluss... Eine Timeout Einstellung würde ausreichen. Senden/Empfangen über nur einen Port ist aber auch nicht ideal, da eben dann das Timeout zu unerwünschten Verzögerungen beitragen kann...

Ideal ist immer ein Port zum senden und ein Port für den Empfang...

Bei der Verwendung eines DMX Gateway's (welches setzt Du denn da ein ??) stellt sich mir die Frage, was Du da empfangen willst ??? Der HS "spielt" doch Master somit ist Dein Gateway auch "Master" DMX arbeitet grundsätzlich in nur eine Richtung oder Du benötigst ein 2. Gateway als Slave...

Ergo, ist das Verhalten des HS von Vorteil, da er nach dem Senden die Verbindung sofort schließt ohne auf ein Feedback zu warten... UDP finde ich generell auch idealer...

Nun stellt sich die Frage nach dem Gateway. Iich gehe ja stark davon aus, dass das Gateway "aktiv" arbeitet und den DMX Bus selbständig refresht und Du nur einmal einen "Channel" mit einem "Value" über TCP beschreiben mußt. Ähnlich sollte es mit "Einblendfunktionen" sein. Gute Gateway's können das selbständig... Wenn Du Einblendfunktionen über den HS Wert für Wert sendest könnte ich mir vorstellen, dass es knallen kann ...

LG

[schmiddi998]

@meudenbach
Naja, Parameter gibt ja nicht viele bei einer TCP-Verbindung: Die IP-Adresse und einen Port. Also falsch machen kann man da nicht viel.

Ich verwende das Gateway von www.cinetix.de. Das Teil nennt sich DMX-Generator. Meiner Meinung nach und nach deine Aussage ist das ein sehr gutes Gateway.

Iich gehe ja stark davon aus, dass das Gateway "aktiv" arbeitet und den DMX Bus selbständig refresht und Du nur einmal einen "Channel" mit einem "Value" über TCP beschreiben mußt. Ähnlich sollte es mit "Einblendfunktionen" sein. Gute Gateway's können das selbständig...

Und das kann es. Faden usw. macht es auf Kommando. Die Befehlsstruktur ist sehr simpel. Hab mir für meinen Anwendungsfall einfach einen Logik-Baustein gebastelt. Der Baustein kann Farben durchlaufen, die aktuelle Farbe anzeigen usw. Er "baut" den nötigen Befehl zusammen und gibt einen Sende-Befehl, wenn der Befehl auf den DMX-Bus gesendet werden soll bzw. an das Gateway. Der Baustein arbeitet wirklich einwandfrei und verursacht auch keine Überflutung mit Telegrammen, weil er nur am Senden ist oder so.



Aber zum Problem: Das Gateway ist natürlich der Master und hat eigentlich "nichts zu melden". Aber gerade weil es recht "intelligent" ist, sendet es Status-Meldungen zurück. Standardmäßig tut es das auf dem gleichen Port, auf dem man es auch anspricht. Es sendet dann z.B. ein OK oder eine Fehlermeldung zurück, sobald man einen Befehl entsendet. Diese Meldungen werte ich nicht aus, der HS soll diese Antworten nicht empfangen (vielleicht später mal für eine evtl. FEhlersuche)

Jetzt kann es natürlich sein, dass der HS einen Befehl abschickt und danach sofort die Tür zuknallt, obwohl das Gateway gerade den Mund zum Antworten aufgemacht hat. Und in diesem Augenblick ist wahrscheinlich einer von beiden für gewisse Zeit bockig. Vielleicht erst das Gateway und danach der HS, weil:



Mit TCP-Einstellung, frisch gestartetem HS und frisch gestartetem Gateway kann ich ca. 3 erfolgreiche Befehle an das Gateway senden (zu sehen an diversen Leuchtdioden, am Router und in der DEBUG-List des HS) Dann sendet der HS nichts mehr. Mit "nichts mehr" meine ich wirklich NICHTS ! Nebenbei tausche ich per UDP nämlich Daten mit einer SPS aus. Ebenfalls über das Netzwerk. Und selbst dieser Datenaustausch findet dann nicht mehr statt. Zu sehen ist das auf der DEBUG-Seite des HS, an den LED usw. Das sonst sekündlich abgesetzte Telegramm an die SPS wird nun für unbestimmte Zeit nicht mehr gesendet. Sage ich dem HS, er soll das Gateway nicht mehr anfunken, dann dauert es irgendwas zwischen 30 Sekunden und mehreren Minuten, bis der Datenaustausch selbstständig wieder stattfindet. Irgendwo ist halt ein TimeOut drin.

Das ist mir aufgefallen, bevor das Problem mit TOTALEN Verbindungsverlust zum HS auftrat. Ich hab keine Ahnung woran das liegt, aber ich habe panische Angst, TCP mit dem HS zu benutzen, seit das aufgetreten ist. Vielleicht ist das auch Linux-Problem oder eine Sicherheitsmaßnahme, ein Pufferüberlauf, eine Begrenzung der Queue bzw. Warteschlange für Telegramme oder sonst was.

Hoffentlich hat die Firma Cenetix die Firmware des Gateways schnell um UDP erweitert, dann wird alles gut.

MfG
schmiddi998

[meudenbach]

mhhh könnte evtl. auch am Gateway liegen, evtl. hat dies das "Timeout", weil es ja eine feedback Message absetzen will und wartet eben auf Empfang...

Aber wenn Du nun UDP bekommst ...

Mich würde aber denoch interessieren, wenn Du anstelle von TCP eine WEB Abfrage benutzt...

LG

[schmiddi998]

mmmhhh... das mit der Webabfrage ist keine schlechte Idee. Das werde ich mal probieren. Wieso bin ich da nicht drauf gekommen ??

Danke für den Tipp !

[schmiddi998]

Hallo,

ich habs übrigens wieder bei einem Kunden gehabt, dass der HS sich nicht mehr ansprechen ließ. Evtl. habe ich aber die Lösung gefunden:
Da sich der HS mit einer S7-300 unterhält und ich die SPS auch Fernwarten möchte, setzte ich ein LANcom Router ein, in den man sich per ISDN einwählen kann. So kann ich HS und SPS programmieren und brauch nur eine Telefonnummer. Anscheinend ist aber der Router genau das Problem. Manchmal gehts und manchmal nicht. Als der HS mal wieder nicht ansprechbar war, habe ich einen "dummen" Switch benutzt und siehe da, es ging.

Vielleicht hat sich der HS gerade in dem Augenblick beruhigt oder lag wirklich an dem Router. Komischerweise konnte ich den HS im Augenblick der Stille wenigstens pingen. Nur Zugriff per Client, Web und Experte war nicht möglich.

MfG
schmiddi998

[makki]

Schau mal während nur Pingen geht in die ARP-Tabelle des Rechner von dem der Ping gemacht wird (cmd->"arp -a"); ich möchte fast wetten da steht zum Fehlerzeitpunkt nicht die Mac-Adresse des HS drin (ggfs. diese vorher mal rausschreiben).

Makki

[schmiddi998]

Fehler gefunden. Die S7-314 hängt zwecks Fernprogrammierung auch am Netzwerk und hatte die gleiche IP wie der HS. Schöne Sche**** !! Auf die einfachsten Dinge muss man erstmal kommen....

MfG
schmiddi998

[klaus407]

Moin moin,

.....
Ich steuere mittels eines Ethernet/DMX Gateways die Unterwasserbeleuchtung von Schwimmbädern. ..
schmiddi998

Freut mich, dass Du den Fehler gefunden hast. Mich würde ja mal brennend interessieren welche Leuchten Du benutzt, da ich bislang nur 60 W RGB Led's mit eingebautem "Controller" bekomme. Da kann man zwischen 8 Farben durch Schaltimpulse wechseln, das ist natürlich nicht so dolle.