Fehler bei 750-889

guwen

Level-2
Beiträge
66
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,
gestern Abend ist meine 750-889 ausgestiegen.
Folgende Fehler haben sich eingestellt:
Auf dem IP_Master: KNX_DEVICE_KBUS_ERROR
Auf der KNX_Module-Klemme: KNX_POWER_FAILURE
Leider bin ich nicht zuhause. Über den Remote-Zugang habe ich sie auch mit einem Reset in jeglicher Form nicht wieder beleben können.
Einen Stromausfall hat es (nach Aussage meines Nachbarn) nicht gegeben. Und auch nach einem Stromausfall sollte die 750-889 doch wieder normal starten.
Das Webinterface der 889 ist normal erreichbar. Hier wird der Error Code: 1 mit dem Error Argument 6 angezeigt (Beschreibung ist "terminal Changed")

Wo kann der Fehler liegen? Gibt es eine Möglichkeit von Ferne die 889 wieder zum Leben zu bewegen?

Danke Euch
 
Liest sich so, als wäre die Busspannungsversorgung ausgefallen - entweder Sicherung oder Netzteil.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Liest sich so, als wäre die Busspannungsversorgung ausgefallen - entweder Sicherung oder Netzteil.
Ja. War auch meine erste Vermutung. Daher die Frage nach einem Stromausfall durch Starkregen. Das ist aber nicht der Fall. Und da die 889 via Webinterface erreichbar ist, dürfte es zumindest aktuell kein Problem mit der Spannungsversorgung geben.
Kann es sein, dass etwas am Netzteil kaputt geht, die Spannung kurz weg ist, dann wiederkommt und dadurch der Fehler entsteht?
 
Hallo, ich denke GLT meint den Ausfall der KNX Busspannungsversorgung. Die 24 V Versorgungsspannung für den Controller ist damit nicht gemeint sondern die KNX Spannungsversorgung. Wenn der Controller 889 via Webinterface erreichbar ist, dann sagt das nichts über den Zustand der KNX Spannungsversorgung aus. Du solltest das einmal prüfen. Ist per Remotezugang leider relativ schwer denke ich.
 
Hallo, ich denke GLT meint den Ausfall der KNX Busspannungsversorgung. Die 24 V Versorgungsspannung für den Controller ist damit nicht gemeint sondern die KNX Spannungsversorgung. Wenn der Controller 889 via Webinterface erreichbar ist, dann sagt das nichts über den Zustand der KNX Spannungsversorgung aus. Du solltest das einmal prüfen. Ist per Remotezugang leider relativ schwer denke ich.
OK.
Hoffe das ich morgen Nacht wieder zuhause bin. Werde ich dann direkt prüfen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,
habe am vergangenen Wochenende nachgesehen.
Die Busspannung auf dem KNX ist OK. (wobei ich ja nicht zu 100% ausschließen kann, dass es einen kurzen Ausfall der Busspannung gegeben haben könnte). Ansonsten läuft der KNX störungsfrei. Zumindest lief die Uhr am Herd noch, was zumindest bedeutet, dass es keinen Spannungsausfall vom Netz her gab.
Zur Behebung des Fehlers habe ich an der SPS die Spannungsversorgung Aus-/Eingeschaltet. Beim Neustart der SPS gab es dann den Fehler über den Blinkcode, dass mit der 4. Karte etwas nicht passt. Also: Spannungsversorgung aus, Karte ein stück rausgezogen, sodass kein Kontakt mehr besteht. SPS gestartet (natürlich mit Fehler, weil ja nix mehr passt). Dann wieder Spannung aus, Karte rein, Spannung drauf. Und dann wieder alles OK.

Noch was merkwürdiges: in derselben Nacht ist noch einmal die SPS neu gestartet. Wodurch auch immer eingeleitet. Danach blinkte die USR-LED rot. Wenn ich mich recht erinnere ist das im WAGO-KNX Beispielprojekt ein Problem mit der Übertragung vom KNX. Aber verstehen tue ich das nicht wirklich. Kann es sein, dass die KNX-Karte einen weg hat? Aber warum wird dann eine Störung auf der 4. Karte 750-403 angezeigt?
 

Anhänge

  • 750-889.png
    750-889.png
    119,9 KB · Aufrufe: 16
Update: Nach dem Neustart der 889 hat das KNX Modul diesen Fehler gemeldet: KNX_TimeOutSYNC

Und hier die rot Blinkende USR LED (Code aus einem Wago Beispielprojekt)
(*Blink sequence of RED USR_LED in case of KNX communication error*)

IF DeviceStatus = KNX_DEVICE_OK OR DeviceStatus = KNX_DEVICE_ETHERNET_ERROR THEN
;
ELSE
TON1(IN:=TRUE , PT:=t#2s);
IF TON1.Q AND NOT M1 THEN
M1:=TRUE;
Blinkfrequenz[2].Colour := RED;
Blinkfrequenz[2].Frequency:= 5;
Blinkfrequenz[2].Relation:=128;
Blinkfrequenz[2].Duration:=t#3s;
Blinkfrequenz[2].NextIndex:=2;

PointerToBlinkfrequenz:=ADR(Blinkfrequenz);
SET_FLASHING_SEQUENCE(1, ADR(PointerToBlinkfrequenz));
START_FLASHING_SEQUENCE(EN:=TRUE);

SET_FLASHING_SEQUENCE_INDEX(EN:=TRUE, IMMEDIATE:=TRUE, INDEX:=2);
END_IF
END_IF
 
Läuft dein Task auch mit einem Intervall von nur maximal 50ms und wie hoch ist die tatsächliche Cycletime?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Läuft dein Task auch mit einem Intervall von nur maximal 50ms und wie hoch ist die tatsächliche Cycletime?
Moin,
in Summe habe ich 8 Tasks laufen:

tsk
Number of Tasks: 8
Task 0: MB_ETH_MASTER_TASK, ID: 3
Cycle count: 37203349
Cycletime: 11 ms
Cycletime (min): 8 ms
Cycletime (max): 103 ms
Cycletime (avg): 11 ms
Status: RUN
Mode: UNHANDLED
----
Priority: 1
Intervall: 5 ms
Event: NONE
----
Function pointer: 16#28CB4F8C
Function index: 515


Task 1: MainProg, ID: 4
Cycle count: 7737140
Cycletime: 34 ms
Cycletime (min): 15 ms
Cycletime (max): 89 ms
Cycletime (avg): 34 ms
Status: RUN
Mode: UNHANDLED
----
Priority: 3
Intervall: 60 ms
Event: NONE
----
Function pointer: 16#28CB4F38
Function index: 514


Task 2: Steuerung5s, ID: 5
Cycle count: 93209
Cycletime: 7 ms
Cycletime (min): 3 ms
Cycletime (max): 1642 ms
Cycletime (avg): 14 ms
Status: RUN
Mode: UNHANDLED
----
Priority: 25
Intervall: 5000 ms
Event: NONE
----
Function pointer: 16#28CB50BC
Function index: 518


Task 3: Haustueren, ID: 6
Cycle count: 9320921
Cycletime: 1 ms
Cycletime (min): 1 ms
Cycletime (max): 5 ms
Cycletime (avg): 1 ms
Status: RUN
Mode: UNHANDLED
----
Priority: 4
Intervall: 50 ms
Event: NONE
----
Function pointer: 16#28CB4E08
Function index: 510


Task 4: Steuerung10s, ID: 7
Cycle count: 46604
Cycletime: 1 ms
Cycletime (min): 1 ms
Cycletime (max): 52 ms
Cycletime (avg): 1 ms
Status: RUN
Mode: UNHANDLED
----
Priority: 22
Intervall: 10000 ms
Event: NONE
----
Function pointer: 16#28CB5014
Function index: 516


Task 5: IP_Symcon, ID: 8
Cycle count: 466046
Cycletime: 89 ms
Cycletime (min): 28 ms
Cycletime (max): 129 ms
Cycletime (avg): 98 ms
Status: RUN
Mode: UNHANDLED
----
Priority: 6
Intervall: 1000 ms
Event: NONE
----
Function pointer: 16#28CB4EE4
Function index: 512


Task 6: Heizkreispumpen, ID: 9
Cycle count: 7759993
Cycletime: 38 ms
Cycletime (min): 10 ms
Cycletime (max): 83 ms
Cycletime (avg): 28 ms
Status: RUN
Mode: UNHANDLED
----
Priority: 5
Intervall: 60 ms
Event: NONE
----
Function pointer: 16#28CB4E5C
Function index: 511


Task 7: Steuerung30s, ID: 10
Cycle count: 15534
Cycletime: 3 ms
Cycletime (min): 2 ms
Cycletime (max): 486 ms
Cycletime (avg): 13 ms
Status: RUN
Mode: UNHANDLED
----
Priority: 26
Intervall: 30000 ms
Event: NONE
----
Function pointer: 16#28CB5068
Function index: 517

1685890555080.png
 
Dein PLC ist ja aktuell schon mit dem ersten Task überfordert. Du musst unbedingt deine Zykluszeiten optimieren.

Ich hatte mit meiner 750-889 auch immer wieder sporadisch die unterschiedlichsten Fehler bei der Initialisierung der KNX-Klemmen. Anfangs konnte ich meinen Code noch optimieren (besondere wichtig während der Initialisierung) Inzwischen bin ich auf die 750-8202 gewechselt.
 
Dein PLC ist ja aktuell schon mit dem ersten Task überfordert. Du musst unbedingt deine Zykluszeiten optimieren.

Ich hatte mit meiner 750-889 auch immer wieder sporadisch die unterschiedlichsten Fehler bei der Initialisierung der KNX-Klemmen. Anfangs konnte ich meinen Code noch optimieren (besondere wichtig während der Initialisierung) Inzwischen bin ich auf die 750-8202 gewechselt.
Ja. An den Zykuszeiten habe ich schon gearbeitet.
Habe "unnötigen" Ballast abgeworfen, und mit dem Wago Support an den Zeiten und den Prioritäten gespielt. Das hat aber alles nicht wirklich geholfen. Wobei Ausschlaggebend für diese Aktion war, dass ich ab und an einen "Buffer Overflow" auf der KNX Routerklemme bekommen habe. Der Buffer Overflow kommt sporadisch immer noch, jedoch seltener als vorher. Das merkt man immer daran, dass z.B. im Bad das Licht und/oder das Radio nicht automatisch ausgeschaltet werden. Der Buffer Overflow kommt immer nur bei Code, der auf der KNX Modulklemme liegt, nie bei dem auf der SPS. Auch komisch. Wago wusste irgendwann auch nicht weiter.
Um den 889 weiter zu entlasten habe ich mir vor einiger Zeit schon einen 885 zugelegt. Mit dem wollte ich Heizung, Kaminofen, Solar steuern (wobei der ganze Code auf der Steuerung liegt), was schon einen Batzen ausmacht. Die Kommunikation sollte zwischen 889 und 885 via ModBus laufen. Durch einen spontanen Jobwechsel hat sich das Projekt (vorerst) zerschlagen, da das Wohnhaus zum Ferienhaus geworden ist.
Aber die neue Herausforderung ist schon deutlich schlimmer als der Buffer Overflow. Das ist total doof wenn die Steuerung ausfällt. Und wenn ich dann nur noch am Wochenende zuhause bin ist das doppelt doof.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Warum benötigst du 8 Task. Ich kann mir nicht vorstellen, dass das erforderlich ist.
Ich würde das auf eine oder maximal 2 bis 3 Task aufteilen. Zunächst würde ich das gesamte Programm auf eine Task mit 60ms Prio1 einstellen.
Schau dir dann bitte einmal an, wie die tatsächliche Zykluszeit aussieht. Die 5s und 30s Task könnte ggf. so bleiben, wenn das benötigt wird.
Die Leistung des 889 Controllers sollte aus meiner Sicht für die normalen Aufgaben einer Haussteuerung völlig ausreichend sein.
 
Es ist schon erstaunlich, dass es Leute gibt, die ganze Industriemaschinen in einer Task verarbeiten.
Aber so ein EFH ist natürlich viel anspruchsvoller.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja. ich weiß. Nur nicht warum.
Die Tasks sind entstanden mit dem Support von Wago aufgrund des Buffer Overflow.
Ich hatte alles in einer Task. Und das hat auch gut gelaufen, bis, warum auch immer, der Buffer Overflow kam. Leider kann ich auch nicht nachvollziehen seit wann. Habe seinerzeit alte Projektstände eingespielt, aber der Fehler war nicht wegzubekommen. Und so sind die Anzahl Tasks entstanden.
 
Die Task 0 läuft im Mittel doppelt so lange wie projektiert.
Kann es sein, dass der Puffer nicht rechtzeitig abgeholt wird? Die Task raubt auch den anderen die Zeit. Hast Du da Schleifen drin? Z.b beim warten auf Done. Das macht man mit Schrittketten.
 
Die Task 0 läuft im Mittel doppelt so lange wie projektiert.
Kann es sein, dass der Puffer nicht rechtzeitig abgeholt wird? Die Task raubt auch den anderen die Zeit. Hast Du da Schleifen drin? Z.b beim warten auf Done. Das macht man mit Schrittketten.
Danke Dir für den Tipp. Bin im Moment wieder unterwegs. Werde ich direkt prüfen wenn ich zuhause bin.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo nochmal,
ist schon lange her, dass ich mich dazu gemeldet habe.
In der Zwischenzeit habe ich
... das Programm geprüft, aber keine Schleifen gefunden. Wobei ich auch nicht wüsste wozu ich die benötigen könnte.
... Die Netzteile aufgeteilt. 1x für Versorgungsspannung Feld (MeanWell SDR 480-24) und 1x für Versorgungsspannung System (MeanWell SDR 240-24)
... Die Spannungsversorgungen habe ich zentralisiert. Da die SPS über 750-627/628 2x weitergeleitet wird, bekommen nun alle Spannungsversorgungen (750-889, 750-613, ...) ihren Saft von den beiden o.g. Spannungsquellen.
... 2 KNX Netzteile habe ich durchgetauscht um auch hier einen Fehler auszuschließen.

Damit hatte ich nun gut 1/4 Jahr Ruhe.
Bis vergangene Woche. Seit dem habe ich bis jetzt 8x diese Neustarts gehabt.

1x war ich dabei.
Die Meldung war KNX_POWER_FAILURE auf dem FbKNX_Master Baustein
Die Spannungsversorgung der SPS habe ich mit dem Benning MM12 geprüft. Steht auf 24,5V
Komisch ist, dass ich nie ein Problem auf der KNX Seite hatte und die Spannungsversorgung auch nicht >max. anzeigt. Aber KNX_POWER_FAILURE angezeigt wird.
 
Es Ist schon sehr eigenartig, dass jetzt nach 1/4 Jahr wieder die Probleme auftreten.

Hast du im Programm immer noch die 8 Task laufen? Kann es sein, dass du in der Taskkonfiguration unter "System-Ereignisse" einen Neustart bei Auslösen eines Watchdogs konfiguriert hast? Das würde zumindest die Neustarts erklären.
Ich bin davon überzeugt, dass die vielen Task nicht benötigt werden und eine sinnvolle Aufteilung auf 2 bis 3 Task ausreichend sind und das System stabiler machen können.
 
Ja. Auch ich dachte das Problem wäre weg.
Aber. Komisch ist schon, dass seit Dienstag wieder alles ruhig ist. Als wäre nichts gewesen.
Die 8 Tasks laufen nach wie vor, so wie seinerzeit mit Wago zusammen eingerichtet. An der gesamten Elektrik und der Automation ist seit dem nichts mehr geändert worden.
Ein Versuch ist es auf jeden Fall wert die Anzahl zu reduzieren. Werde ich ausprobieren.
Neustart bei Auslösen eines Watchdog ist nicht angeklickt:
1705003684040.png
 
Zurück
Oben