[EibParser] cycle(1,0) ungleich 1 Minute ?

[Jambala]

Hallo Zusammen,

um zu sehen wie lange die Bewässerungskreise den Garten bewässern, schreibe ich mit folgendem Code die Minuten seit Einschaltung in den Button:

[highlight=epc]
Counter_Rasen = AUS
Minutes_Rasen_On = 0u32
Button_Rasen_Refresh = AUS
if Init == EIN \\
and "Bewaesserung Rasen Ein/Aus-5/5/12" == EIN then \\
Counter_Rasen = EIN; \\
Minutes_Rasen_On = 0u32; \\
Button_Rasen_Refresh = EIN \\
else \\
Counter_Rasen = AUS \\
endif
if Counter_Rasen == EIN \\
and cycle(1,0) then \\
Minutes_Rasen_On = Minutes_Rasen_On + 1u32 \\
endif
if Init == EIN \\
and (Button_Rasen_Refresh or change(Minutes_Rasen_On)) then \\
pdisplay(ID_Zentral_Bewaesserung_Rasen,$An seit $+convert(Minutes_Rasen_On,$$)+$ Min.$,SWITCH,ACTIVE,GREY,PageID_Zentralfunktionen) ; \\
Button_Rasen_Refresh = AUS \\
endif
[/highlight]

Die auf cycle(1,0) basierende Zeitanzeige weicht jedoch stark von der Realität ab. 32 Minuten reale Bewässerungszeit werden im Button mit 20 Minuten angezeigt.

Entspricht cycle(1,0) nicht immer genau einer Minute oder enthält der Code einen Fehler, den ich nicht sehe?

Viele Grüße

Michael

[enertegus]

Entspricht cycle(1,0) nicht immer genau einer Minute?

An sich sollte cycle gehen. Bei mir hier im Haus habe ich einen cycle(2,02) der ziemlich exakt (ca. 1 Sekunde) den Zyklus auch schaltet.
Zur Not mal im then Zweig einfach einen write-Befehl ausgeben.
Stimmt die Uhrzeit des EibPC denn?

[Jambala]

Stimmt die Uhrzeit des EibPC denn?

Ist Cycle(1,0) von der Uhrzeit abhängig?

1 Minute ist doch hoffentlich für den EibPC immer 1 Minute unabhängig von der Uhrzeit.

Ich baue an dieser Stelle einmal Bernds UDP Reporting ein, dann sehe ich ja ganz genau bei welcher Uhrzeit Cycle immer schaltet.

Viele Grüße

Michael

[enertegus]

Ist Cycle(1,0) von der Uhrzeit abhängig?

Alle Timer hängen von dem Systemtimer ab, daher auch die Uhrzeit sowie der cycle Timer.

[anlo007]

gelöscht, da Beitrag doppelt übertragen

[anlo007]

Hallo,
versuch es doch mal alternativ mit:

1. and stime(0) then

1. weil sich dann Ungenauigkeiten nicht aufaddieren können.

Du hast dann max. 1 Minute Differenz, aber die hast du bei cycle(1,0) auch.

[Jambala]

Hallo Zusammen,

jetzt bin ich endlich dazu gekommen das Zeitverhalten detailliert zu analysieren.

Ich habe auf Basis des u.g. Codes einmal ca. 30 Minuten mit cycle(1,0) und ca. 30 Minuten mit stime(0) getestet.

Die Zeit habe ich über den Button im Webserver und über UDP Nachrichten verfolgt.

Das Ergebnis ist äußerst verwunderlich:

Bei Durchlaufen von 20 x cycle(1,0) stehen dem ca. 32 echte Minuten gegenüber. Der EibPC "verschluckt" hier also ca. 1/3 der Zeit.

Bei Durchlaufen von 20 x stime(0) stehen dem ca. 28 echte Minuten gegenüber. Der EibPC "verschluckt" hier also auch fast ca. 1/3 der Zeit.

Die genauen Einzeldaten sind im Excel Screenshot im Anhang zu sehen.

Damit sind meine bisher "gefühlten" Zeitabweichungen belegt.

Hat jemand eine Idee woher diese deutlichen Zeitabweichungen bei cycle und stime kommen?

Ich verwende Patch 2.304 und meine Speicherauslastung ist 30,8%.

Dies ist der genutzt Code:

[highlight=epc]
// Test
Counter_Test = AUS
Minutes_Test_On = 0u32
Button_Test_Refresh = AUS
if Init == EIN \\
and "EibPC Test-5/4/1" == EIN then \\
Counter_Test = EIN; \\
Minutes_Test_On = 0u32; \\
Button_Test_Refresh = EIN \\
else \\
Counter_Test = AUS \\
endif
if Counter_Test == EIN \\
and cycle(1,0) then \\
Minutes_Test_On = Minutes_Test_On + 1u32 \\
endif
if Init == EIN \\
and (Button_Test_Refresh == EIN or change(Minutes_Test_On)) then \\
pdisplay(ID_System_Test,$An seit $+convert(Minutes_Test_On,$$)+$ Min.$,SWITCH,ACTIVE,GREY,PageID_System); \\
Button_Test_Refresh = AUS \\
endif
CurrentTime = $@ $+convert(hour(),$$) + $:$+convert(minute(),$$) + $:$+convert(second(),$$) + $, Message: $
DebugBewaesserung = EIN
DebugPort = 5050u16
DebugIP = 192.168.0.2
DebugCount=0u32
if DebugBewaesserung == EIN \\
and change(Minutes_Test_On) then \\
sendudp(DebugPort,DebugIP, CurrentTime, $Rasen wird seit $ + convert(Minutes_Test_On, $$) + $ Minuten bewaessert$,13,10) \\
endif
[/highlight]

[highlight=epc]
// Test
Counter_Test = AUS
Minutes_Test_On = 0u32
Button_Test_Refresh = AUS
if Init == EIN \\
and "EibPC Test-5/4/1" == EIN then \\
Counter_Test = EIN; \\
Minutes_Test_On = 0u32; \\
Button_Test_Refresh = EIN \\
else \\
Counter_Test = AUS \\
endif
if Counter_Test == EIN \\
and stime(0) then \\
Minutes_Test_On = Minutes_Test_On + 1u32 \\
endif
if Init == EIN \\
and (Button_Test_Refresh == EIN or change(Minutes_Test_On)) then \\
pdisplay(ID_System_Test,$An seit $+convert(Minutes_Test_On,$$)+$ Min.$,SWITCH,ACTIVE,GREY,PageID_System); \\
Button_Test_Refresh = AUS \\
endif
CurrentTime = $@ $+convert(hour(),$$) + $:$+convert(minute(),$$) + $:$+convert(second(),$$) + $, Message: $
DebugBewaesserung = EIN
DebugPort = 5050u16
DebugIP = 192.168.0.2
DebugCount=0u32
if DebugBewaesserung == EIN \\
and change(Minutes_Test_On) then \\
sendudp(DebugPort,DebugIP, CurrentTime, $Rasen wird seit $ + convert(Minutes_Test_On, $$) + $ Minuten bewaessert$,13,10) \\
endif
[/highlight]

Viele Grüße

Michael

[Uwe!]

sehr interessant und sehr merkwürdig! Klingt eigentlich nach Firmware-Fehler.
stime(): Die Zeit passt eigentlich seh exakt, aber es wird immer mal wieder eine Runde komplett verschluckt!

cyle(): noch viel komischer! 1 Minute dauert immer so zwischen 1:30 und 1:45???

[salixer]

Hast du die Uhrzeit im EibPC auch schon überprüft?

[Jambala]

Falls Du die normale Systemuhrzeit meinst, die steht bei mir auf NTP Synchronisation und zeigt exakt das Datum und die Uhrzeit an, was auch mein iMac und meine Uhr anzeigt.

Viele Grüße

Michael

[salixer]

OK, das passt dann schon mal.

[anlo007]

Das ganze erinnert mich an ein Problem, welches ich vor ca. 25 Jahren mit den ersten Siemens SPSen (100-101) hatte.

Wenn man eine Zeit genau vergleichen ließ, führte sie den Befehl nicht aus, da durch die damals langen scan-Zeiten, diese sec. evtl nicht genau getroffen wurde. Mit einem Zeit>=x war das behoben.

Ich weiß, das der eibPc bedeutend schneller ist, als die alte Siemens SPS, aber bei den Zeit-Angaben arbeitet ihr aber heute auch im 1/1000sec Bereich, kann dort nicht etwas ähnliches passieren, das genau in diese 1/1000 sec, dieser Teil der Anweisung gerade nicht bearbeitet wird?

Letzte Woche sind an einem Tag meine Rolläden nicht hochgefahren, im Busmonitor fehlte diese GA ebenfalls, das könnte eigendlich ähnlich gewesen sein. Das Programm läuft seit ca 1 Jahr 24/7 ohne Unterbrechung und Änderung und auch ohne Fehler, die aufgefallen wären.

Nur mal so als Idee aus den Erfahrungen der Vergangenheit.

[Jambala]

Hallo Zusammen,

um das Fehlverhalten weiter einzugrenzen, werde ich den Test heute Abend noch einmal ohne jegliche andere Last wiederholen.

Den gestrigen Test Code habe ich in mein vorhandenes Programm eingebettet, also u.A. inkl. HA7E Makro, Wärmepumpen Gateway Makro und GoogleWetter Makro.

Heute werde ich dann ausschließlich den Test Code nutzen.

Viele Grüße

Michael

[Jambala]

Hallo Zusammen,

nachdem ich den Test nur mit dem zuvor genannten Test Code ausgeführt habe, also mein normales Programm mit allen Makros vorher aus dem Code entfernt habe, laufen cycle und stime zeitlich korrekt ab.

Es handelt sich hier also um ein lastabhängiges Problem.

Bei meiner Speicherauslastung von 30,8% habe ich dem Thema Last bisher keine Aufmerksamkeit geschenkt.

Ich habe nun jedoch festgestellt, dass die durchschnittliche Last bei mir aktuell bis zu 4.20, 2.86, 1.61 erreicht.

Das HA7E Makro scheint bei mir einen Großteil der Ressourcen zu benötigen. Ohne dieses Makro sinkt die Speicherauslastung auf 11% und die durchschnittliche Last ist: 0.22, 0.18, 0.45.

Ab welcher Last wird es kritisch, so dass Funktionen wie cycle nicht mehr korrekt ausgeführt werden?

Viele Grüße

Michael

[enertegus]

Es handelt sich hier also um ein lastabhängiges Problem.
Ab welcher Last wird es kritisch, so dass Funktionen wie cycle nicht mehr korrekt ausgeführt werden?

Das ist bisher noch nicht so aufgetreten und auch bei 50% Last nicht bemerkbar geworden.
Wen ich mich recht erinnere, hat der Timer gewisse Latenzzeiten. Wenn ein Timer-Event nicht z.B. in 500ms verarbeitet werden kann, wird es verworfen.
Wir werden das mal genauer analysieren, ich werde am Montag da mal intern nachhaken, was wir da machen können.

Du kannst die Situation vermutlich verbessern, indem Du im EibStudio die Performance runter nimmst : Optionen-Performance-Zyluszeit auf z:B. 50 ms erhöhen. Dann sollten die Systemprozesse etwas mehr Zeit bekommen.

Wie ist das denn jetzt ohne das Makro? Vermutlich ist es das HA7E Makro vom bmx (?). Deaktiviere doch da mal die zahlreichen Debugsachen, das kann die Sache extrem lahm machen.