Performance Beeinflussung durch Logikbausteine

[Gaston]

[/quote=Taxus;20110]
a) der Experte bei der Übertragung des Projekts die Module in eine bestimmte Reihenfolge bringt (möglicherweise blattorientiert)
[quote]

Ja, so in etwa. Über das gesammte Projekt gesehen und in Laufzeit gilt allerdings das was Michel schon gesagt hatte: Die Blattstruktur ist nur eine logische Gliederung, eigentlich ist alles eine grosse Logik. Nur solange es keine Konnektoren zwischen zwei Blättern gibt sind diese defakto getrennte Logiken da es keine direkte Verbindung gibt (Verbindungen über KOs sind indirekt). Die Blätteraufteilung spielt eigentlich nur bei der Initialisierung eine Rolle.

b) der HS diese Reihenfolge zyklisch abarbeitet, unabhängig davon, ob für das in der Liste gerade berechnete Modul ein Event (Telegramm) eingetroffen ist,

Nein, Bausteine werden nur aufgerufen wenn eine Event eintrifft, d.h. ein Wert an einem Eingang aufläuft oder ein Timer abgelaufen ist.

c) jeder Baustein vollständig durchlaufen und berechnet wird, bis eine Abbruchbedingung (oder eof) erfüllt ist,

Ja, aber nur die Bausteine die ein Event erhalten haben.

d) die Schreibvorgänge des Bausteins auf S, O und A aber nur ausgeführt werden, wenn bei der Berechnung ein EI oder OC oder EC festgestellt wird

Nein, ohne eine diese xC wird der Baustein gar nicht ausgeführt.

Paßt das so etwa für den Hausgebrauch?

Jetzt schon

Da die Ausgangsfrage dieses Threads ja die Performance war, stelle ich mir schon die Frage, warum bei komplexen Modulen eine a-priori-Abbruchbedingung zum Performancetuning vom Entwickler eingetragen werden muss. Der Experte könnte dies anhand der Komplexität eines Bausteins selbstständig optimieren, sogar für jeden Baustein unterschiedlich. Vermutlich ist der HS für die meisten Anwendungen einfach schnell genug .

Da der Baustein nur aufgerufen wird wenn ein Event eintrift ist dies nicht möglich, bzw. nötig. Aber es gibt bausteine die zwar mehrere Eingänge haben, wo die Berechnung aber nur ausgeführt werden muss wen einige davon sich ändern, bei anderen Eingänge ist der neue Wert erst relevant wenn einer der ersten Eingänge sich ändert. Hier kann man dann bei komplexen berechnungen durch eine Abbruchbedingung optimieren wobei dies in den meisten Fällen eher Kontraproduktiv wäre.

Ich hoffe ich habe nun alle Klarheiten beseitigt

Gruss,
Gaston

[Taxus]

Herzlichen Dank für Deine Zeit und die Darstellung, Gaston! Dabei will ich es jetzt auch bewenden lassen; mir geht es ja nicht darum, irgenwelche Interna zu erfahren - das soll ruhig Dacom-vertraulich bleiben. Ich bin irgendwie sicher, dass der Hersteller hilft, wenn ein Poweruser tatsächlich an einer Performance- oder sonstigen Grenze kratzt. Meine Neugier war einfach geweckt, da ich etwas anders verstanden hatte. Nun kann ich mich der weiteren Smartisierung meines Häuschens mit dem großartigen widmen.

[oliverh]

Doku Logikbaustein-Entwicklung

Hallo Rainer,

wir versenden auf Anforderung ein Dokument, wo das Thema "Entwicklung eigener Logikbausteine" genau beschrieben wird.
Auch das Start-Verhalten etc. ist darin beschrieben.

[Taxus]

Hallo Oliver,

besten Dank, die Doku habe ich, und habe sie wirklich gründlich gelesen (oder eher noch studiert ). Hinsichtlich des normalen Ablaufs ist und war mir auch immer alles klar - bis ich in diesem Thread den Satz gelesen habe, wonach in jedem Zyklus alle Bausteine berechnet würden. Das hat mein bisheriges Verständnis in den Grundfesten erschüttert, speziell auch die Ergänzung um Performancesteigerung durch Einfügen einer Abbruchzeile. Nur deshalb meine Nachfragen.

[PepsiMox]

HS Performance down

Hallo all,

zu diesem Thema habe ich ein paar Neuigkeiten, die wiederum Probleme aufwerfen.

Der Ausgangspunkt:
Das Signal eines Bewegungsmelders (kein KNX Teil) wird über einen Binäreingang erfasst.
Im HS wird das Signal verarbeitet
Der HS schaltet die dazugehörige Lampe ein / aus.

Das Problem:
Irgendwann wurde die Verzögerung zwischen dem hörbaren Klicken des Relais im BWM und den erstrahlen der Lampe immer länger, ich spreche von 2-3s. Zusätzlich dauerte es ewig bis ein über die GiraApp (iPhone) versendeter Befehl wirklich eine Aktion erkennen ließ, z.B. Licht an.

Die Ursachenfindung, mein Verständnisproblem:
Ich habe mit mehreren Projekten (ausgehend vom Orginal) die Logik getestet. Anfangs nur für die BWM. Alles superschnell.
Dann habe ich immer mehr reingepackt und irgendwann wurde alles wieder langsam. Was hinzukam waren ca. 40 Betriebsstundenzähler, siehe Bild.

Ist dieses Problem bekannt oder was mache ich verkehrt.

Gruß und Danke,
PepsiMox

[TRex]

wenn ich Deine Logik richtig verstanden habe, dann wertest Du jede Sekunde den Status von 40 Geräten aus und schaltest den Betriebsstundenzähler weiter.
Das kostet selbstverständlich performance, da Du ja jede Sekunde 40* die Logik anstösst....

[Gaston]

Ich würde mal die Messweite der Betriebsstundenzähler vergrössern auf 65, 10 oder 15 Sekunden. Dieser Baustein ist aber leider in meinen Augen nicht gut da er nur Intervalle grösser als die Messweite beachtet. Ausserdem ist er aus dem gleichen Grund sehr ungenau.


Würde ja einen anderen schreiben, habe aber zur Zeit keine ID frei, da meine restlichen wohl vom Wetterstationprojekt verschlungen werden.

Gruss,
Gaston

[MatthiasS]

Ich spende gerne eine ID

[Gaston]

Ich spende gerne eine ID

Is ja schon gut , per PN gabs auch schon ein Angebot für ne ID. Ich werd das Morgen dann mal in Angrif nehmen, dürfte schnell gehen.

Hintergrund:

Der mitgelieferte Baustein funktioniert so dass er nach einer eingestellten Zeit in Sekunden immer wieder Aufgerufen wird. Dabei zählt der Baustein eben diese Zeit dann jedesmal zum Zähler dazu.

Im Fall hier ist die Zeit auf 1 Sekunde eingestellt. Da der Zähler aber nie ganz genau aufgerufen wird summiert sich so jede Sekunde ein Fehler hinzu. Kommen dann noch Performqanceprobleme hinzu ist der Fehler am Ende des Tages gerne mal ne Stunde Differenz.

Ausserdem misst der Baustein die Betriebsstunden immer nur im Messweiteninterval. Wenn er also auf 15 Sekunden eingestell ist und ein Betriebsmittel 59 Sekunden läuft gehen 14 Sekunden "verloren".

Ich gehe aber davon aus dass jeder die höchs mögliche genauigkeit möcht eund nur die Updaterate einstellen möchte mit der der Zähler gesendet wird.

Mein Ansatz ist also folgender:

• Solange das Signal 0 ist läuft kein Timer da sinnlos
• Wird das Signal auf 1 geschaltet speichere ich die augenblickliche Zeit und starte den Update timer Timer
• Bei jedem Ablauf des Timers wird die Differenz aus momentaner Zeit und Einschaltzeit gebildet, zum schon bestehenen Stundenzähler hinzuaddiert und ausgegeben
• Beim Ausschalten des Signals wird die Restdifferenz auch noch aufaddiert
• Da bei jedemmal die Startzeit die für das neue Interval gespeichert ist genau die gleich eist mit der das vorherige Interval berehcnet wurde, summiert sich kein Fehler auf da die Summe aller Intervalle genau gleich mit der Differenz über die Gesammtzeit ist

Gruss,
Gaston

[Gaston]

So, bin jetzt dran, hab auch noch eine freie ID zwischen den anderen gefunden

Frage:

Gibt es eine Anwendung bei der eine Messweite wie jetzt im Baustein realisiert, von Interesse wäre.

Also, bedeutet dass bei einer Messweite von z.B. 60 Sekunden nur volle Minuten zu den Betriebsstunden dazugezählt werden. Bedeutet in der Praxis dass wenn man das Betriebsmittel 1000 mal 59 Sekunden an macht der Betriebsstunden Zähler immer noch bei 0 steht, sprich über 16 Stunden nicht gezählt werden, oder bei 1:59 werden 16 Stunden gezählt (erste Minute) und 16 Stunden unterschlagen (59 Sekunden).

[Gaston]

Der Baustein läuft zur Zeit bei mir im Test. Ich habe den Baustein mit Sollwert (Lebensdauer) Vorgabe implementiert.

Noch irgendwelche Wünsche ?

Gruss,
Gaston

[Gaston]

Hmm, irgendwie schaffe ich es nicht dass der Baustein seine Interne Betriebstundenvariable Remanent speichert.

5000|"Gaston\Zähler\Betriebsstundenzähler"|1|5|"Signal"|"Interval"|"Reset"|"Sollwert"|"Flags"|3|"Betriebsstd."|"Restwert"|"Alarm"
...
#5003|[x]|Init|Remanent?
5003|1|0|1 # Zähler

Trotzdem ist der Zähler nach Start immer auf 0.

Und ja, ich habe das Abspeichern des Remanentspeichers vor dem restart abgewartet

Also, betriebsstunden 0.28, rebootet. Im Debugfenster verifiziert dass die Remanentdaten 2 Minuten vor dem Reboot gespeichert wurden, sollte als ca. 0.25 drauf sein.

[Gaston]

Jetzt verstehe ich gar nix mehr

Nachdem ich di eRemanenz des Bausteins einfahc nciht hinbekommen habe, habe ich einen Ausgang angelegt und den internen Zähler als erstes darauf ausgegeben so wie ein zweiter Ausgang an dem ich die Aufrufe des Zählers mitzähle. Beides sind die beiden ersten Zeilen des Bausteins gewesen.

Die sum sicher zu gehen dass der Zähler nicht beim Init auf 0 gesetzt wird.

Und siehe da nun funktioniert die Remanenz obwohl ich sonst nix geändert habe. Die zwei Ausgänge wieder rausgenommen...funktioniert immer noch

Lange Rede kurzer Sinn: Ich habe den Baustein zum Testen in den Downloadbereich hochgeladen

Gruss,
Gaston

[PepsiMox]

Ordner für Logikbausteine

Hallo all,

danke für die vielen Antworten und den mein Problem behebenden Logikbaustein.

Leider habe ich große Probleme, denn Baustein im Experten laden zu können.

Ich habe ihn in die meiner Meinung nach dafür vorgesehenen Ordner kopiert. Leider wird er jedoch nicht angezeigt, was mache ich verkehrt?

Gruß,
PepsiMox

[Gaston]

Der richtige Ordner hängt von der Experten- und Windowsversion ab.

Experte 2.5 & 2.6 und Windows 7 (englisch):

C:\Users\Public\Public Documents\HS+FS Experte 2.x\logic

wobei x=5 oder 6