HS/FS - √ - HS Zeit-Logiken Performancebremsen?

[busfahrer79]

Ich bin heute auf etwas gestossen, bei dem ich fast verzweifelt bin.

Ich hab eine Bewässerungssteuerung zusammengestellt und wollte diese heute beim Kunden Betrieb nehmen.
Das Programm habe ich mit unserem Test-HS durchgespielt, lief wunderbar. Auf dem Kunden HS gab allerdings es ein paar merkwürdige Situationen. Ich habe in meiner Logik ein paar Countdowns, Zeitschaltuhren und diesen Uhrzeit-Baustein. Nun lief die Sache auch erstmal gut an, aber nach einer Weile spielte die Logik verrückt, Aktionen wurde gestartet, bevor die Zeit heruntergezählt wurde, keine Bedienung möglich usw. Stundenlang habe ich die Logik analysiert und neu gestrickt, bis mir einfiel mal gelesen zu haben, daß man bei der Logikschaltuhr oder diesem Zeit/Datum-Baustein den Zyklus/Ganggenauigkeit nicht so "fein" einstellen soll, da dies ziemlich anstrengend für den HS sein soll. Jedenfalls habe ich eben diese Parameter ein wenig hochgestellt und siehe da, es lief!
Sind solche Zeitfunktionen, wenn sie "hoch aufgelöst" programmiert werden, wirklich solche Bremsen oder Durcheinander-Wirbler? Beim Kunden laufen natürlich noch ein paar andere Sachen, deswegen gab es wahrscheinlich auf dem Test-HS kein Durcheinander.

Muss man nun bei sowas wirklich ein wenig aufpassen, oder ist das absoluter Quatsch und ich habe ein ganz anderes Problem? Bisher hatte für mich so ein HS praktisch unbegrenzt Power für so ein paar Spielereien.

[MatthiasS]

HS Zeit-Logiken Performancebremsen?

Klar muss man aufpassen. Gewisse Funktionen brauchen reichlich Resourcen.


Sent from my iPhone using Tapatalk

[busfahrer79]

Und welche Funktionen sind das im Groben? Also scheinbar alles bei dem eine Art Uhr oder Countdown läuft, gibts da noch mehr?

[gaert]

Klar braucht z.B. ein Timer (Countdown) mehr Ressourcen als ein simples Gatter - schließlich muss der Zeitwert in einer Variable zwischengespeichert werden und die Funktion zyklisch aufgerufen werden (aus Programmierer-Sicht).

Aber: Das sollte selbst die nicht mehr ganz so frische Hardware des HS auch mit hunderten Timern problemlos packen Der Fehler liegt sehr wahrscheinlich in Deiner Logik, möglicherweise kommt es zu "Interferenzen" mit der vorhandenen Logik beim Kunden (Schleifen, etc.).

Bau doch mal eine Logik mit gaaaaaanz vielen Timer-Funktionen zum Testen - dann wirst Du sehen, dass es zu keiner Performance-Einbuße kommen wird... Auf der Debug-Seite sieht man übrigens sehr schon die mittlere Abweichung der Timer-Bausteine!

Meiner Erfahrung nach hakt es i.d.R. nicht an dem "fein aufgelösten" Timer (z.B. Oszillator zwecks Blinklicht), sondern an der Telegramrate des EIB: Die Defaulteinstellung 6 Telegramme pro Sekunde reicht eben nicht für ein Blinken mit 10 Hz Dann kommt es natürlich zu Problemen und Überlagerungen...

[busfahrer79]

Also ich habe gerade auf die schnelle im Test-Programm auf dem Test-HS den Zyklus beim Zeit+Datum Baustein (ich habe zwei Stück) auf 1 sek heruntergeregelt, da war gleich alles zu spät. Die selben komischen Phänomäne wie gestern beim Kunden. Also denke ich,daß man bei diesen Zeitsachen echt aufpassen muss, hier ist scheinbar schnell Terror.

Auf der Debug-Seite sieht man übrigens sehr schon die mittlere Abweichung der Timer-Bausteine!

Sorry für die vielleicht dumme Frage. Steht das unter "Timer" und was muß ich da erkennen, vergleichen, bewerten?

[division]

Das würde mich auch mal interessieren.....

Viele Grüße

[gaert]

Auf der Debugseite unter "Wait" steht die Anzahl der "Timer"-Berechnungen und die mittlere Abweichung.

Also ich habe bestimmt 20 "Treppenhaus-Lichtfunktionen" mit 0,5 Sekunden (also Trigger quasi) im Einsatz und keinerlei Probleme damit. Weniger als 0,5 s habe ich noch nicht getestet - vielleicht darf's nicht weniger sein?!

[busfahrer79]

Ich glaub Treppenhausautomaten sind okay. Als Ressourcenfresser habe ich den Zeit+Datum Baustein, Timer-Trigger und Alarm-Countdown in Verdacht. Ich versuch gerade die Timer-Trigger gegen Treppenhausautomaten zu tauschen und probier auf neue.

"Wait" habe ich gefunden, da stehen irgendwelche 0,XYZ-Werte, kann ich nichts dazu sagen. Ich hab heute auch mal GIRA angerufen, dort wurde mir die Überwachung der Queues zum nahegelegt. Auffällig hoch war der EIBSendQueue, hier stand bei "wait" 30,.... Dies soll wohl zu hoch sein. Das sind doch die Telegramme, welche auf den Bus gesendet werden, hier hab ich aber keine Sorgen, also Busmonitor okay und Lichtszenen werden ordnungsgemäß (ohne Wartezeit) abgerufen. Oder hab ich was falsch verstanden?

[gaert]

Der Alarm-Countdown funktioniert bei mir auch nicht richtig, oder besser gesagt: Der Baustein funktioniert genau 1-mal, dann sendet er am Ausgang 1 keine "1" mehr (für 1 Sekunde). Egal was ich mache (retriggern, etc.) - daher vermute ich mal, dass die Implementierung irgendwie spinnt.

[MatthiasS]

Der Wait-Wert in Queue bei EIBSend kommt in der Regel von der Startphase, kann man vergessen.

Bei den Queues sollte unter IST generell 0 stehen, höchstens mal ein kleiner einstelliger Wert, dann ist alles im grünen Bereich.

Die Performance des Zeitbausteines liegt an dessen verwendeter Python-Funktion zur ZEITBERECHNUNG, die braucht einfach Resourcen. Aber...den Baustein braucht man DAFÜR nur ein einziges Mal. Der Fehler ist oft, dass der für Zeitformat-Wandlungen missbraucht wird und dann im Projekt häufig vorkommt und so den HS in die Knie zwingt.

[busfahrer79]

Also Alarm-Baustein funktioniert super.
Ich hab jetzt Time-Trigger gegen Treppenhausautomaten getauscht, kann da zwar nicht mehr pausieren, aber wichtiger ist daß es sauber läuft.
Die IST-Werte bei den Queues sind alle bei null, sozusagen okay.
Danke für den Tip mit dem Datums-Baustein. Ich hatte zwei davon, hab nun einen eingespart, war purer Luxus.

[gaert]

Der Wait-Wert in Queue bei EIBSend kommt in der Regel von der Startphase, kann man vergessen.

Sorry, aber das stimmt nicht. "Wait" zeigt die mittlere Abweichungen aller "waits" an - also sämtlicher Timer-Berechnungen:


Wait

Anzahl 77171
Abweichungen Min:0.001 Max:0.115 D:0.024 Akt:0.007/0.045/0.011

Man beachte die Anzahl... Bei jedem Timer-Aufruf kann man erkennen, wie die Anzahl um 1 erhöht wird.

[busfahrer79]

Er meinte den die Wait-Spalte bei den Queues.