Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ankündigung
Einklappen
Keine Ankündigung bisher.
Anlagenstatus einer Alpha Innotec Wärmepumpe (Luxtronik 1.0)
Natürlich, sind würd ich ja hier nicht so einen Wind machen..
Bitte bau Dir mal die Delays um, wie in https://knx-user-forum.de/384050-post145.html
beschrieben.
Es kommt natürlich insgesamt drauf an, was die WP zurückliefert. Entsprechend viel kann kurzzeitig verarbeitet werden müssen. Daher würde die Entzerrung mit mehreren ms dazwischen sicher was bringen, auch wenn Du Dein Gesamtprogramm einspielst.
Bitte bau Dir mal die Delays um, wie in https://knx-user-forum.de/384050-post145.html
beschrieben.
Es kommt natürlich insgesamt drauf an, was die WP zurückliefert. Entsprechend viel kann kurzzeitig verarbeitet werden müssen. Daher würde die Entzerrung mit mehreren ms dazwischen sicher was bringen, auch wenn Du Dein Gesamtprogramm einspielst.
Hallo Michael,
das mit dem Umbauen kann ich noch machen. Jedoch verstehe ich nicht, wie es bei dir "nur" zu 900ms Verzögerung für die komplette Abarbeitung kam und bei mir sind es knapp 19.000ms bis zum nächsten Zyklus!?!
Ich habe jetzt mal deine Zeitmessung implementiert und ohne RS232 Kommunikation zu betreiben nur das Parsing laufen lassen. Eine Verzögerung von 19s bleibt:
Das "line xxx" ist die Zeile im Makro, an welcher der Text ausgegeben wird.
Die darauffolgende Zeile ist noch mal die gleiche Zeilennummer gefolgt von einem Doppelpunkt und dann der Inhalt der Variable MaxZyklusZeit.
Ich habe noch mal für jedermann zum Testen den Code angehangen.
Compilieren, einspielen und dann Variable "Test" auf "EIN" setzen. Nebenbei die Telegramme beobachten. Wer sieht noch so eine Riesenverzögerung? Vielleicht ist ja auch nur mein EibPC kaputt/zu langsam...
Grüße
Matthias
Update1:
Habe mal die Zyklus Zeit auf 50ms gesetzt - jedoch ohne Veränderung...
Damit habe ich getestet:
[highlight=epc]
// Berechnet die minimale und maximale Zyklusdauer
// der Verarbeitung. Dabei ist die Performance-Angabe im EibStudio immer
// als Offset dabei.
Max=1000000000000000u64
Restzeit=0u64
StoppZeit=Max
MaxZyklusZeit=0u64
MinZyklusZeit=Max
// Im EibStudio ggf. geändert, Defaultwert ist 20ms
PerformanceZeit=20u64
// Die erste Zyklus kann etwas länger dauern ...
if afterc(after(systemstart(),10000u64), Max, Restzeit) then {
StoppZeit=0u64;
} endif
if change(Restzeit) then {
MaxZyklusZeit=max(StoppZeit-Restzeit-PerformanceZeit,MaxZyklusZeit);
MinZyklusZeit=min(StoppZeit-Restzeit -PerformanceZeit,MinZyklusZeit);
StoppZeit=Restzeit;
} endif
[..]
[/highlight]
kann man dann die max. Verarbeitungszeit bis zu dieser Anweisung evaluieren.
Maximaler Wert bis heute: 18446744073709551615 (ff ff ff ff ff ff ff ff). Das stimmt wohl nicht, oder?
Hallo Michael,
das mit dem Umbauen kann ich noch machen. Jedoch verstehe ich nicht, wie es bei dir "nur" zu 900ms Verzögerung für die komplette Abarbeitung kam und bei mir sind es knapp 19.000ms bis zum nächsten Zyklus!?!
Ich habe lediglich die Zeiten der Verarbeitung geprüft - ob das der Verzögerung, die Du auf dem Bus hast, gleich ist, weiss ich nicht.
Die vielen Debugmeldungen, die da inzwischen sind, machen das alles nicht schneller.
ich wiederhole mich:
Code:
// Parsen der einzelnen Informationsblöcke der Comfort-Platinen Daten
if delay(change(BufferComfort),Data_Delay*1u64) and size(BufferComfort)>=10u16 then {
// Parsen der einzelnen Temperaturwerte
if delay(change(Data_Temperatur),Data_Delay*2u64) and Data_Temperatur!=$$ then {
// Parsen der einzelnen Wärmepumpeneingänge
if delay(change(Data_Eingaenge),Data_Delay*3u64) and Data_Eingaenge!=$$ then {
usw.
Ich habe lediglich die Zeiten der Verarbeitung geprüft - ob das der Verzögerung, die Du auf dem Bus hast, gleich ist, weiss ich nicht.
Die vielen Debugmeldungen, die da inzwischen sind, machen das alles nicht schneller.
Hallo Michael,
tu mir bitte noch einmal den Gefallen und führe mein Programm wie oben in Post 167 beschrieben aus. (Oder auch Jeder das das hier liest und mal 10 Minuten Zeit hat)
Bitte dann hier die Telegramme Posten die das EibStudio ausgegeben hat.
Einfach nur um zu testen ob die Performance meines EibPCs "normal" ist.
Die Verzögerung von den knappen 20s hatte ich ja schon immer. Die ganzen Debug-Meldungen sind erst hinterher reingekommen und haben es nicht langsamer gemacht.
Ich würde gerne sehen ob es ein globales Problem (mit dem Code) ist oder nur bei mir auftritt.
Mir will nach wie vor nicht in den Kopf dass die Verarbeitung von 650Byte so lange dauern soll. Nach den Debug-Meldungen zufolge scheint der der EibPC während der Verarbeitung keine Schleifen zu drehen o.ä.
Das mit den Delays würde ich erst in Angriff nehmen wenn klar ist, dass der EibPC halt nicht scheller ist und man das entzerren muss.
Also: Bitte, bitte einen Test! (Oder könnt ihr mir einen EibPC ins Netz stellen auf dem ich das selbst testen kann ohne jedes mal meine Automatisierung für Tests pausieren zu müssen?)
Also: Bitte, bitte einen Test! (Oder könnt ihr mir einen EibPC ins Netz stellen auf dem ich das selbst testen kann ohne jedes mal meine Automatisierung für Tests pausieren zu müssen?)
Bei einem Testlauf gestern mit deiner Version habe ich keine Auffälligkeiten gesehen. Allerdings hatte ich vergessen, die KNX-Schnittstelle wieder richtig zu konfigurieren. In deinen Loggings sieht man aber auch keinen normalen Busverkehr, oder? Hast du die Schnittstelle auch abgeklemmt?
Je nach Feedback kann ich den Test aber wiederholen.
Generell habe ich aber das gleiche Problem (der eibPC hängt unregelmäßig für ~20sec und vergisst Events) wenn das Makro in meinem Code läuft (bei funktionierender KNX Kommunikation).
Generell habe ich aber das gleiche Problem (der eibPC hängt unregelmäßig für ~20sec und vergisst Events) wenn das Makro in meinem Code läuft (bei funktionierender KNX Kommunikation).
habe ich nun auch so nachvollzogen.
Das Problem sind nicht allein die Stringoperationen, sondern auch die Float-Operationen. Deine delays sind so nicht wirksam (s.o.).
Bei einem Testlauf gestern mit deiner Version habe ich keine Auffälligkeiten gesehen. Allerdings hatte ich vergessen, die KNX-Schnittstelle wieder richtig zu konfigurieren. In deinen Loggings sieht man aber auch keinen normalen Busverkehr, oder? Hast du die Schnittstelle auch abgeklemmt?
Nein, Schnittstelle war nicht abgeklemmt. Der "normale" Busverkehr ist auch an der Stelle uninteressant. Den hab ich bei allen hier von mir geposteten Protokollen immer rausgelöscht (sofern welcher vorhanden war um nicht abzulenken).
Interessant war ja immer das Verhalten des EibPCs und ob er es schafft jede Sekunde die Zeit auf den Bus zu schreiben. Anfangs hab ich ja parallel immer den GA-Monitor der ETS mitlaufen lassen - aber das war irgendwann nicht mehr notwenig da in EibStudio selbst das Verhalten während des Monitorings der Gruppentelegramme beobachtet werden kann..
habe ich nun auch so nachvollzogen.
Das Problem sind nicht allein die Stringoperationen, sondern auch die Float-Operationen. Deine delays sind so nicht wirksam (s.o.).
Hallo Michael,
soll also heissen das ist "normal" und zu akzeptieren?
Da kann man (auf Eurer Seite) nichts optimieren?
Ist der Prozessor wirklich so lahm?
Gut, wenn dem so ist kan ich die Delays nach Deinem Beispiel einbauen.
Aber irgendwie empfinde ich das nur als eine Art von schlechten Workaround...
habe den ganzen gestrigen Abend damit verbracht weiter an dem Problem zu forschen.
Dabei habe ich mir die Mühe gemacht die Zykluszeiten der einzelnen Blöcke die geparst werden zu messen.
Dabei bin ich zu folgendem Ergebnis gekommen (durch mehrere Tests verifiziert):
Der EibPC benötigt knapp 1.800ms um die Daten zu parsen.
Das klappt aber nur, wenn man große Pausen zwischen den einzelnen Verarbeitungszyklen lässt.
Wenn er die hintereinander verarbeiten soll hängt das System knapp 19.000ms.
Ich weiss nicht, ich werd das Gefühl nicht los dass es sich hier um einen ganz großen Käfer handelt. Was blockiert / wo entsteht der (Dead-)Lock (wenn die Verarbeitungszeit zu groß wird)?
Versteh ich leider nicht, kannst du den Code korrigieren?
Kannst du bitte das Makro korrigieren!
Aus deiner Erklärung wird man nicht schlau und eine "Triviale Korrektur", wie von dir scheinbar angegeben ("Mach mal -1 bei der Performancezeit, ohne das im EibStudio anzusetzen": PerformanceZeit=19u64 bei 20ms Zykluszeit) führt weiterhin zu 18446744073709551615 (ff ff ff ff ff ff ff ff).
Wenn er die hintereinander verarbeiten soll hängt das System knapp 19.000ms.
Wir haben das weiter untersucht bzw. arbeiten hier noch. Wie es ausschaut, wird durch die hohe Last, in jedem Zyklus, den anderen Prozessen zu wenig Luft zum atmen gegeben.
Das wird in der nächsten Release gefixt. Zudem kann man die Verarbeitungpause auf mehr als 50ms erhöhen, wohlgemerkt bleibt die Verarbeitung von eintreffenden Telegramme davon unbenommen (es geht also nix verloren).
Meist alle 5 Minuten ist der eibPC derart beschäftigt, dass er nichts mehr macht, dann bleibt auch kurz die Visu stehen.
Getestet mit nur einem iPad/CommandFusion, bei 20ms Zykluspause. Maximale Zyklus-Laufzeit ist 999ms, Patches: 3.008.ptc.
Es ist auch schon (oder immer noch) mehrfach passiert, dass die Rollos nicht gefahren sind oder die Displays nicht auf Nachtbetrieb gingen.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar