Task hängt sich in unregelmäßigen Zeiten auf.

bjoern3003

Level-1
Beiträge
13
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Kurz zu meiner Konfiguration:

Wago 750-881
mit diversen 8 Kanal Ein- und Ausgängen, sowie DMX512 und 1Wire
und 3 Tasks

MainTask:
Prio 3 - Zyklisch 30ms
Durchschnittliche Laufzeit: 4ms

DMX:
Prio 1 - Zyklisch 20ms
Durchschnittliche Laufzeit: 1ms

EinSekTimer:
Prio: 2 - Zyklisch 1s
Durchschnittliche Laufzeit: 3ms

Folgendes Problem: Der Task, welcher sich um den DMX Ablauf kümmert, stürzt in nicht absehbaren Abständen ab (hängt sich auf).

Teils ist zu dem Zeitpunkt auch niemand anwesend.

Die beiden anderen Tasks laufen total unproblematisch.

Es hilft dann nur noch, die WAGO Hart zu resetten. Manchmal ist dann für 2-3 Monate ruhe, manchmal aber auch nur für 2 Tage :confused:

Die DMX.lib habe ich mit dem entsprechenden Programm und Beispiel mal angehangen (ist ein original aus einem anderen Forum, von dort stammt auch die Entwicklung.
 

Anhänge

Hallo,
der erste Satz "Achtung: die Aktion "dmx_handling.ping" muss in einer eigenen Task mit geringer Priorität (>=20) aufgerufen werden, da sonst das System ausgebremst wird." ist wichtig,
alternativ kannst du die DMX-Task auch als Background-Task (11-31) auslegen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Rayk, danke für deine Hilfe. Ich meine zwar, dass ich das ursprünglich auch sogar schon mal so hatte, aber habe es eben auf Priorität 20 eingestellt, damit es bei der Fehlereingrenzung hilft 8)

Das Problem jetzt ist, dass es durchaus sein kann, dass ich erst wieder in 1-2 Monaten reporten kann, da das Problem wie ja bereits eingangs erwähnt, nicht regelmäßig auftritt. Nichts desto trotz, werde ich einen Status abgeben, damit es möglicherweise auch Nachzüglern helfen kann.
 
Guten Abend,
musste gar nicht so lange warten. Kamen heute aus dem Kurzurlaub zurück. DMX Task aufgehangen. Mittwoch Mittag ging noch alles.
 
Guten Morgen, vielleicht hat ja jemand Zeit und Lust, mir bei dem Problem zu helfen oder hat eine Idee, wie ich der Sache näher zur Leibe rücken kann. Mittlerweile ist das Problem wieder 3x aufgetreten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen, vielleicht hat ja jemand Zeit und Lust, mir bei dem Problem zu helfen oder hat eine Idee, wie ich der Sache näher zur Leibe rücken kann. Mittlerweile ist das Problem wieder 3x aufgetreten.

Um ehrlich zu sein, verstehe ich auf die schnelle deinen Code nicht. Was ich auf die Schnelle nicht gefunden habe ist die Stelle, wo dein Socket geschlossen wird. Wenn du immer wieder erneut einen Socket aufmachst, gibt es irgendwann keinen mehr und du kommst auch nicht mehr mit CODESYS drauf. Kenne aber leider deine Bibliotheken zu wenig.
 
Was ich auf die Schnelle nicht gefunden habe ist die Stelle, wo dein Socket geschlossen wird
Das wird durch den UDP Client erledigt.

Du könntest als erstes mal die Rückgabewerte vom UDT_Client (Socket_is_open und ErrorCode) sowie Sock_Ping auswerten.
Ein neuer Sendeauftrag sollte erst nach der Abarbeitung des letzten gestartet werden (start_senden auswerten)

Dein Ping hat eine TimeOut von 2s. Wenn connect = False (Warten auf Antwort) startest du in der Zeit 66 mal einen neuen Ping! Intervall PLC_PRG = 30ms.
Code:
anforderung_ping:=Freigabe AND NOT connect;
Der UDP Client wird wird in jedem Zyklus aufgerufen und nicht ausgewertet egal ob Ping erfolgreich oder nicht.

Fazit: Solange deine Gegenstelle innerhalb von 30ms antwortet funktioniert dein Programm. Sollte dies nicht der Fall sein (Netzwerkbelastung,....) kommt dein Programm böse ins stolpern.
Das Programm ist bestenfalls als grobes Demo geeignet.

Holger
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein ich meine während des Programmlaufes.
Ping > wenn erfolgreich > Socket öffnen -> wenn erfolgreich > Daten senden -> wenn abgeschlossen > nächsten Datensatz usw..
Bei Fehler entsprechend Fehlernummer auslesen und im Programm darauf reagieren.
Holger
 
Aber müsste es nicht dann nicht so sein, dass sich der main Task aufhängt?

Bei mir läuft dieser aber durch, und es hängt sich der ping Task auf. Ich glaub, so wenn ich mir das oben noch mal durchlese, habe ich die Situation falsch erklärt.
 

Anhänge

  • Bild-001.jpg
    Bild-001.jpg
    53,9 KB · Aufrufe: 13
kurz zur Funktion: da der DMX node keine Antwort sendet wird periodisch ein Ping ausgeführt um die Anwesenheit zu prüfen, wenn man Daten senden an den Ping koppelt, dauert der Farbwechsel lange
 
Zurück
Oben