Wago MobusTCP Feldbuskoppler hängt sich auf

[WagoSPS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe folgendes Problem bei der Automatisierung meines Hauses. Ich habe im Keller eine Wago SPS 750-880 für alle Aktoren und Sensoren im Keller und EG. Für OG und Dach habe ich eine Feldbuskoppler 750-352. Als Protokoll verwende ich Modbus TCP. Beide Komponenten sind aktuell ohne weitere Teilnehmer mit einem Ethernetkabel verbunden. Zur Programmierung verwende ich die OSCAT-Building-Bibliothek. Im ersten Schritt habe ich alle Sensoren auf einem Stockwerk programmtechnisch verbunden. Also Eingang SPS = Ausgang und Eingang Feldbuskopller = Ausgang Feldbuskoppler. Das = steht hierbei für einen "SWITCH_I"-Baustein, einen Baustein mit Setzen, Rücksetzen und Entprellen. Soweit hat alles gut funktioniert. Nun will ich natürlich an einem Taster im Flur EG das Licht im Flur OG schalten (Eingang SPS = Ausgang Feldbuskopller).

Hierbei tritt der Fehler. Wenn ich das Programm einspiele funktioniert alles wunderbar für ein paar Stunden. Ich habe gestern das Programm eingespielt und heute morgen hat dann kein Licht mehr funktioniert. Ein- und Ausschalten von SPS und Feldbuskoppler hat nichts gebracht. Kurz bevor der Absturz kommt werden noch Licht im FLur OG und Licht im Bad (Ausgänge Feldbuskoppler) kurz ein und wieder ausgeschaltet, obwohl kein Taster betätigt wurde.

Wo liegt hier der Fehler?

Zur Konfiguration des Modbuses hab ich den Modbus-Master-Konfigurator verwendet. Dort habe ich eine Verzögerung von 25ms eingestellt, um den Bus nicht unnötig zu belasten. Das war ein Tipp vom Wago-Support.
Die Tasks sind wie folgt konfiguriert:
MainTask: Zyklisch 10ms
MB_ETH_MASTER_TASK: Zyklisch 5ms

Gruß

 

[santacrews]

Hallo WagoSPS,

ich habe genau die selbe Konfiguration. Habe auch im Keller eine 750-880 und in der Garage einen 750-352.

Mich wundert bei deiner Konfiguration, dass Du Modbus TCP hast. Wenn ich meinen 750-352 in den MODBUS Master Konfigurator einfüge wird automatisch als Protokoll Modbus UDP gewählt. Daher die Frage: Warum hast Du Modbus TCP ausgewählt?
Die Verzögerung von 25ms halte ich für gefährlich. Das passt absolut nicht. Weder zu der Main Task mit dem 10ms Aufruf, noch zu den 5ms vom Modbus Task.
Dann frage ich mich, wofür Du einen OSCAT Baustein benötigst. Wago liefert mit dem Modbus Master Konfigurator absolut alles, was man zur Kommunikation braucht. Oder dient der rein zur verwurstung von Ein- und Ausgängen innerhalb deines Programms?

Hast Du Dir die Task automatisch mit dem Konfigurator erstellen lassen?
Die Main Task erscheint mir auf den ersten Blick etwas flott (hängt natürlich vom Programm ab) aber da rate ich mal ins blaue hinein, dass Du den Aufruf der Main Task etwas langsamer machen solltest. Einfach mal online rein schauen und den Aufruf der Task ca. 2,5 x Zykluszeit nehmen.
MB_ETH_MASTER_TASK ist mit seinen 5ms ordentlich in Ordnung.

Ich denke, dass hier irgendein Buffer gewaltig voll läuft, da die Daten nicht abgearbeitet werden können aufgrund der Verzögerung. Das mag bei UDP funktionieren (weil es hier keinerlei Kontrollen gibt), jedoch nicht bei TCP.

 

[WagoSPS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo santacrews,

bei mir ist Modbus UDP im Einsatz. War ein Schreibfehler von mir. Sorry.

Die OSCAT-Bausteine verwende ich nur zur Verwurstung der Ein- und Ausgänge.

Die Konfiguration habe ich mit dem Modbus Master Konfigurator erstellt. Die Zykluszeiten und die Verzögerung habe ich auf Anraten vom Wago Support eingestellt. Anfänglich hatte ich bei der Verzögerung den Standard von 0ms eingestellt. Der Herr vom Wago Support hat dies mir als erstes auf den Weg gegeben, da sonst nach jeder gestellten Anfrage sofort eine neue Anfrage an den Feldbuscontroller gesendet wird. Die 5ms beim Modbus Task sind Standard. Die 10ms Sekunden beim MainTask brauche ich ja um einen Tastendruck mitzubekommen.

Gruß

 

[WagoSPS]

Was mich aktuell noch wundert ist, dass die NS-Led bei 750-880 und bei 750-352 immer noch blinken, obwohl der Modbus läuft. Per Wago Ethernet Settings wird mir auch angezeigt, dass der Feldbus nicht aktiv ist.

 

[santacrews]

Hallo WagoSPS,

die NS LED Blinkt auch bei mir weiterhin fröhlich vor sich hin. Das liegt laut Wago daran, dass keine Ethernet/TCP und keine Modbus/TCP Verbindung existiert. Insofern nicht weiter tragisch.
Vielleicht verrenne ich mich, aber ich würde wirklich mal mit den 10ms für den PLC_PRG Task "spielen".
Am einfachsten wäre es da, wenn du den Task einfach mal entfernst. Dann führt er ja automatisch den PLC_PRG aus, sobald der vorhergehende abgearbeitet ist.
Wenn Du das gemacht hast, kontrolliere mal mit dem Befehl TSK im PLC-Browser deine aktuelle Zykluszeit. Diese muss deutlich unter 10ms liegen, damit Deine Taskkonfiguration funktioniert.

Stell Dir vor, dein Chef legt dir morgens Arbeit auf den Tisch für einen Tag. Und gegen Mittag kommt er wieder mit Arbeit für einen Tag. Und kurz vor Feierabend nochmal. Da wirst Du am Ende der Woche kündigen ;-)

Was das "mitbekommen" des Tastendrucks angeht, da brauchst Du Dir keine Sorgen machen. 10ms ist sowas von schnell... Mein PLC_PRG ist auf 30ms eingestellt und ich habe es noch nicht geschafft, dass meine Wago einen Tastendruck nicht mitbekommen hat.
Ich werde wahrscheinlich noch auf 50ms hochgehen, damit die Visu etwas flüssiger läuft.

Man darf nicht vergessen, dass wir hier keine 1500er CPU von Siemens im Keller haben, sondern nur einen Feldbuskoppler, dem wir etwas intelligenz einhauchen können.

 

[WagoSPS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hab am Wochenende nochmal alles von der Verkabelung her durchgeprüft. Mir ist dabei aufgefallen, dass ein Patchkabel einen Drahtbruch hatte. Aufgefallen ist mir ist dies, in dem ich am am Kabel gewackelt habe und dabei die LINK-LED komplett aus war. Kabel habe ich gegen ein komplett neues getauscht. Seit dem hängt sich der Koppler auch nicht mehr auf. Das Phänomen das nachts und tagsüber Lichter an und aus gehen habe ich immer noch. Warum dies geschieht habe ich keine Ahnung.

 

[santacrews]

Ich verstehe nicht, wieso Du so konsequent meine Empfehlungen ignorierst.
Stelle doch keine Fragen in einem Forum, wenn Du die Ratschläge, Lösungsvorschläge und Tipps zur Fehlereingrenzung nicht annimmst.
Dafür ist mir meine Zeit zu schade.

Letzter Tipp von mir:
NACHDEM Du den PLC_PRG Task kontrolliert hast, pack vor jeden Setzbefehl an deinen Switch_I ein SR Flip Flop ohne das Rücksetzen zu beschalten.
Damit kannst Du kontrollieren, wer dir das Licht eingeschaltet hat wenn Du online bist.

Und nochwas: Das Entprellen würde ich auch sein lassen. Die Eingangskarten haben ohnehin schon einen Filter von regulär 3ms und das Prellen eines Tasters liegt deutlich darunter. Außerdem wird Dein PLC_PRG zum jetztigen Zeitpunkt alle 10ms aufgerufen und 10ms prellt definitiv KEIN Taster.

 

[WagoSPS]

Hallo Santacrews,

ich bin froh um deine Hilfe. Ich kann die Tests mit der Zykluszeit erst heute Abend ausprobieren und es dauert immer eine Weile (ca. 8-12 Stunden) bis der Fehler wieder auftritt.

Ich teste heute Abend mal und gebe dir Rückmeldung.

Danke für den Tipp mit dem SR-FlipFlop. Ich hab mir aufgrund deines Vorschlags jetzt mal einen FB geschrieben, der mir bei Eingang = 1 und Ausgang=1 Datum und Uhrzeit speichert. Damit möchte ich parallel zur Sache mit dem Taskaufruf versuchen, herauszufinden, ob der Eingang bzw. Ausgang wirklich kommt oder der Koppler einfach spinnt.

 

[WagoSPS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hab jetzt mal die Zykluszeiten ausgelesen:

tsk
Number of Tasks: 2
Task 0: MainTask, ID: 3
Cycle count: 5906
Cycletime: 3 ms
Cycletime (min): 2 ms
Cycletime (max): 74 ms
Cycletime (avg): 3 ms
Status: RUN
Mode: UNHANDLED
----
Priority: 12
Intervall: 10 ms
Event: NONE
----
Function pointer: 16#28C8EBD8
Function index: 926




Task 1: MB_ETH_MASTER_TASK, ID: 4
Cycle count: 11989
Cycletime: 1 ms
Cycletime (min): 1 ms
Cycletime (max): 1 ms
Cycletime (avg): 1 ms
Status: RUN
Mode: UNHANDLED
----
Priority: 1
Intervall: 5 ms
Event: NONE
----
Function pointer: 16#28C8EC24
Function index: 927

Was mir hier komisch vorkommt ist die Cycletime (max): 74 ms. Scheint mir doch etwas lange zu sein.

Das Mitloggen der Ein- und Ausgänge hat auch nichts auffälliges ergeben.