Anlagenstatus einer Alpha Innotec Wärmepumpe (Luxtronik 1.0)

[saft6luck]

@Jambala, Matthias: Welche Zykluszeit setzt ihr im eibPC denn ein? Bei mir steht die auf 1ms.

Ich hatte das Makro auch laufen, der eibPC bedankt sich dann allerdings mit regelmäßigen Pausen. Es geht nichts mehr rein oder raus. Gleiches Verhalten bei V2 und V3.

Bei mir erkennbar am CommandFusion Interface.

An der RS232 liegt es nicht, da ich das Makro auf TCP umgestellt habe. Der Remanente Speicher könnte aber zusätzlich eine Rolle zu spielen. Ursache scheint aber die Verarbeitung im Makro zu sein, denn es wird alles in einem Zyklus durchlaufen.

Um das Problem zu lösen habe ich das Makro gestern auf Zeitscheibenverarbeitung umgestellt. Seither funktioniert der eibPC wieder ohne Hänger.

[enertegus]

@Jambala, Matthias: Welche Zykluszeit setzt ihr im eibPC denn ein? Bei mir steht die auf 1ms.

1ms generiert hohe Grundlast, da die Verarbeitung dann wirklich alle 1ms erneut angestoßen wird. Ich würde hier den Default (20) lassen oder sogar auf 50 hochgehen, wenn Webserver, FTP etc. aktiv sind.
Für den KNX Bus reicht das allemal...

[saft6luck]

1ms generiert hohe Grundlast, da die Verarbeitung dann wirklich alle 1ms erneut angestoßen wird. Ich würde hier den Default (20) lassen oder sogar auf 50 hochgehen, wenn Webserver, FTP etc. aktiv sind.
Für den KNX Bus reicht das allemal...

Bei 50ms hätte ich auch meinen ABB Logikbaustein lassen können.

Interessanter wäre eine Aussage, wie "ja, das könnte den Effekt erklären".

[enertegus]

Bei 50ms hätte ich auch meinen ABB Logikbaustein lassen können.

Hm, wieso?

Interessanter wäre eine Aussage, wie "ja, das könnte den Effekt erklären".

Ehrlich gesagt, versteh ich das Posting nicht wirklich. Außer, dass eben 1ms rel. unsinnig ist:
Am Bus kommen bestenfalls alle 40ms Nachrichten an. Wenn die Verarbeitung also eine 50ms Pause macht, nachdem sie die letzte Nachricht verarbeitet hat, ist das m.E. ausreichend.
Der Linuxkernel bzw. der Schnittstellentreiber im EibPC sorgen ja dafür, dass durchaus auch während der Pausenzeit Telegramme gepuffert werden.
Wenn die Verarbeitung "ruht", ist eben mehr Raum für die anderen Aufgaben.

[saft6luck]

Hm, wieso?

"Beim eibPC geht alles viel schneller. Gewöhnliche Logik-Module haben Latenzen von 100ms und mehr ... nicht so der eibPC, etc."
Das Handbuch sülzt einen voll mit "hoher Reaktionsgeschwindigkeit" und du propagierst grad 50ms Zykluszeit?

Ehrlich gesagt, versteh ich das Posting nicht wirklich.

Das hat 2 Zeilen. Da steht sogar schon die erwartete Antwort.

Außer, dass eben 1ms rel. unsinnig ist:
Am Bus kommen bestenfalls alle 40ms Nachrichten an. Wenn die Verarbeitung also eine 50ms Pause macht, nachdem sie die letzte Nachricht verarbeitet hat, ist das m.E. ausreichend.

Aha, unsinnig ... deines Erachtens? Willst du damit sagen, dass der Parameter demnächst im Wertebereich eingeschränkt wird, damit der Webserver mehr Rechenzeit bekommt?

Der Linuxkernel bzw. der Schnittstellentreiber im EibPC sorgen ja dafür, dass durchaus auch während der Pausenzeit Telegramme gepuffert werden.
Wenn die Verarbeitung "ruht", ist eben mehr Raum für die anderen Aufgaben.

Ist jetzt aber nicht so, dass der eibPC auch noch anderes macht, wofür 1ms durchaus Sinn macht?
Abgesehen von der "Event"-Bearbeitung im "nächsten Zyklus" oder der zeitlichen Auflösung von after().

Steht in der Anleitung auch, was after(1u64) bei einer Zykluszeit von 50ms macht? Wird da irgendwo drauf eingegangen, welche Auswirkungen das hat?
Da steht ein lustiger Absatz über State-Maschinen (ohne dass der eibPC die adäquaten Kommandos hierfür besitzt), die dann eine Zykluszeit von 50ms bekommen????

[saft6luck]

@Jambala, Matthias: Welche Zykluszeit setzt ihr im eibPC denn ein? Bei mir steht die auf 1ms.

Welche Zykluszeit verwendet Ihr denn? Evtl. könnte Matthias mit einer höheren Zykluszeit das Problem beseitigen?

[Matthias]

Welche Zykluszeit verwendet Ihr denn? Evtl. könnte Matthias mit einer höheren Zykluszeit das Problem beseitigen?

Hallo!

Aktuell steht sie auf 20.
Vor dieser Diskussion hatte ich schon mal probiert an der Zeit rumzuspielen. Jedoch hab ich mich wohl in die falsche Richtung bewegt (habe die Zahl immer kleiner werden lassen aus Unwissenheit über die Hintergründe. Dachte je kleiner desto mehr Durchläufe, desto schneller die Abarbeitung)
Ich werd mal bei Gelegenheit auf 50ms gehen.

@Enertegus: Ich nehme mal an SynOhr und Bugfixing raubt euch die Zeit dass meine Mail zum Thema noch keine Beachtung fand?
So aus dem Bauch raus sollten die paar Bytes kombiniert mit split und find ja nicht solche katastrophalen Auswirkungen haben...

Grüße
Matthias

[enertegus]

@Enertegus: Ich nehme mal an SynOhr und Bugfixing raubt euch die Zeit dass meine Mail zum Thema noch keine Beachtung fand?

Ich finde da von Dir keine Supportantfrage im System. Ggf. kannst Du da nochmal die Daten schicken.
Das Problem hier ist aber ganz allgemein:

Wir haben keine Innotec WP hier, Jamabala sagt, sein Makro läuft bei ihm seit Jahren stabil, sowie auch bei anderen Usern. Was soll ich da tun? Selbst wenn ich den Code hier teste, wird es ja wohl nicht das selbe sein, da ich nicht deine Anlage habe.

Du müsstest mal Stück für Stück Deinen Code reduzieren, bis es einfach nicht mehr auftritt, bzw. bis das Problem zu erkennen ist.

Ich hatte hier unlängst einen Fall, als ein User über 4000 Timer genutzt hatte, 1 Wire, Webserver, TCP/UDP und was sonst noch alles. Letztlich war es einfach möglich auf nur "400" Timer dessen Usermakros umzubauen, und das Problem ist mittlerweile behoben.

[Jambala]

Wie Michael schon sagt ist dies mit großer Sicherheit kein grundsätzliches EibPC Problem.

Bei mir läuft die Alpha Innotec WP Abfrage + Weather Underground + Rhein Pegelabfrage + RS232 1-Wire + umfangreiche Visu + sonstiger Code ohne jegliche Performance Probleme.

[NetFritz]

Hallo
Ich habe keinen eibPC sondern ein Wiregate
Aber auch eine AI WP mit der Luxtronic 1.0
Ich frage die WP alle 30sec. ab.
Ich würde nie auf die Idee kommen sie alle 2mS abzufragen.
Das macht die Luxtronic auch garnicht mit.

Versuch es einfach mal mit 30sec.

Gruß NetFritz

[saft6luck]

Bei mir läuft die Alpha Innotec WP Abfrage + Weather Underground + Rhein Pegelabfrage + RS232 1-Wire + umfangreiche Visu + sonstiger Code ohne jegliche Performance Probleme.

Das sagt halt nichts, bei mir fiel es auch sofort aus/auf (ich habe erst im Dez. 2013 auf die luxtronik 1.0 umgerüstet).

Und das auch bei 20ms Taskaufrufzeit. Insbesondere gab es auch regelmäßig Temperaturwerte mit 0°C (sichtbar, da ich die Temperaturen ins chart schreibe).

Vorstellbar ist hier auch ein Zusammenhang mit dem remanenten Speicher und/oder der Sonnenstandberechnung alle 5 min. Dummerweise hatte ich die Abfrage genau alle 5 min.

Wie schon geschrieben habe ich jetzt die Tasklaufzeit deutlich reduziert und das Problem ist weg, auch mit 1ms Taskaufrufzeit.

[saft6luck]

Ich werd mal bei Gelegenheit auf 50ms gehen.

Wäre sehr interessant

So aus dem Bauch raus sollten die paar Bytes kombiniert mit split und find ja nicht solche katastrophalen Auswirkungen haben...

Ein so umfangreiches Makro (und dafür gebührt Jambala Hochachtung, also keine Kritik!!!) hat schon was zu tun:
Ich hab es nicht exakt gezählt, aber es sind im worst case ca. 800 Zeilen Code mit ca. 600 Zuweisungen, 150 split(), 170 find(), 70 convert() mit vielen, vielen zugehörigen Berechnungen und "Kleinkram".

NB:
Worst case beschreibt die Möglichkeit, dass es auch Fälle gibt, in denen sich ein String inhaltlich nicht ändert (dies wird per change() abgefragt).
Ich befürchte allerdings, da dies alles "Teilstrings" sind, die sich aus dem gelesenen String durch find() und split() bilden, dass der eibPC diese "Gleichheit" nicht erkennt. D.h. diese Strings gelten immer als "changed" und es werden alle Teile abgearbeitet. -> der worst case trifft immer zu.
(Michael möge mich bitte korrigieren, geprüft habe ich es allerdings auch noch nicht.)

[enertegus]

D.h. diese Strings gelten immer als "changed" und es werden alle Teile abgearbeitet. -> der worst case trifft immer zu.

Hier wird bei Änderung von t nix rausgeschrieben:
[highlight=epc]
u=$abcd$
z=split($abcd$,2u16,4u16)
t=AUS
if t then z=split($oabcd$,3u16,5u16) endif
if change(z) then {
write( "TextFeldSynOhr-10/0/14",convert(z,$$c14));
} endif
[/highlight]
=> Die Änderung eines Strings wird von change nur "wahrgenommen", wenn er sich tatsächlich ändert. Q.e.d.

[saft6luck]

=> Die Änderung eines Strings wird von change nur "wahrgenommen", wenn er sich tatsächlich ändert. Q.e.d.

So trivial ist es natürlich nicht:

[highlight=epc]
Name_StartPos=find(Name_Buffer,$1500;1500;6;$,0u16 )+size($1500;1500;6;$); \\
Name_EndPos=find(Name_Buffer,$ 1500;1501;6$,0u16)-2u16; \\
Data_Fehler1=split(Name_Buffer,Name_StartPos,Name_ EndPos); \\
Data_Fehler1=Data_Fehler1+$;$; \\
...
/* Parsen der einzelnen Fehler */; \\
if change(Data_Fehler1) and Data_Fehler1!=$$ then \\
[/highlight]

Wann reagiert denn hier das change()?

Hält change() seine eigene Kopie des Strings und kann die mehrfachen Änderungen in Summe als "keine Änderung" wahrnehmen falls sich der Buffer nicht geändert hat?

Oder triggert das Ändern des Strings "Data_Fehler1" das change (eigentlich 2x)?

Und, ist eine Änderung (z.B. falls sich Buffer tatsächlich ändert) nur in diesem Zyklus sichtbar?

[Matthias]

Ich finde da von Dir keine Supportantfrage im System. Ggf. kannst Du da nochmal die Daten schicken.

Das Problem hier ist aber ganz allgemein:

Wir haben keine Innotec WP hier, Jamabala sagt, sein Makro läuft bei ihm seit Jahren stabil, sowie auch bei anderen Usern. Was soll ich da tun? Selbst wenn ich den Code hier teste, wird es ja wohl nicht das selbe sein, da ich nicht deine Anlage habe.

Du müsstest mal Stück für Stück Deinen Code reduzieren, bis es einfach nicht mehr auftritt, bzw. bis das Problem zu erkennen ist.

Ich hatte hier unlängst einen Fall, als ein User über 4000 Timer genutzt hatte, 1 Wire, Webserver, TCP/UDP und was sonst noch alles. Letztlich war es einfach möglich auf nur "400" Timer dessen Usermakros umzubauen, und das Problem ist mittlerweile behoben.

Hallo Michael,

nach Deinem Posting https://knx-user-forum.de/372882-post114.html hab ich am 28.01. die Mail an eibpc@enertex.de geschickt.

Ich verstehe ja dass es für Euch etwas schwer ist sowas zu supporten.
An der Stelle nochmals ausfrücklich meinen Dank für den in der Vergangenheit im Forum und hier geleisteten Support!
Jedoch haben wir in diesem Thread ja bereits rausgearbeitet, dass es _nicht_ die RS232 Kommunikation ist, sondern das Parsen der WäPu-Ausgabe was zu den Verzögerungen führt.

Somit könnt Ihr es ja doch insofern nachstellen, indem Ihr die Ausgabe der Wärmepumpe (den String aus Posting https://knx-user-forum.de/372581-post105.html) in eine Variable (Buffer) schreibt und dann mal das Processing laufen lasst und die Performance beobachtet. Oder?

Vielen Dank!

Schöne Grüße
Matthias