HS/FS Initialisierung der Logik

[GKap]

Hallo!

Beim Programmieren des HS entstehen bei mir immer wieder Konstrukte, wo ich mit Bordmitteln (d.h. mit den mitgelieferten Bausteinen) nur schwer eine vernünftige Initialisierung erreichen kann.

Im Anhang ein einfaches Beispiel, welches zeigt, wo die Probleme liegen: Die beiden KOs haben "Beim Starten abfragen" gesetzt. Wunsch wäre, dass schon beim Systemstart der Mittelwert der beiden Windstärken gesendet wird, tatsächlich wird aber erst einmal eine 0 gesendet.

Ursache ist, dass Addition und Division bei der Initialisierung ausgeführt werden. Daraus ergibt sich, dass beim Systemstart zuerst die Division initialisiert wird und 0 sendet. Dann wird die Addition initialisiert und damit die Division nochmals angestossen. Soweit ist alles erklärbar, aber wie kann man das Senden der ersten 0 vermeiden?

Ich habe mir so geholfen, dass ich etliche Bausteine neu geschrieben habe, mit einem weiteren Eingang "Init", der steuert, ob der Baustein beim Systemstart ausgeführt wird oder nicht. Nur: Ist das wirklich der Weisheit letzter Schluss? Bin ich hier an die Grenzen des HS gestossen oder gibt es doch noch einfachere Lösungswege?

überlegt
GKap

[NilsS]

Wenn du einen sauberen Durchschnitt willst versuchs mal damit https://knx-user-forum.de/downloads.php?do=file&id=391

[GKap]

Hallo NilsS!

Es geht mir hier nicht um den Durchschnitt, ich habe dieses Beispiel nur gewählt, um die Problematik zu verdeutlichen!

Gruß
GKap

[NilsS]

Trage doch in den Additionsbaustein fix 0 / 0 ein (gelb) und nimm dann sbc

[TRex]

Das wird sich so kaum lösen lassen. Meine Idee: speichere die Windstärke remanent und überschreibe sie nur wenn Wert <> 0

[GKap]

Hallo TRex!

Das wird sich so kaum lösen lassen. Meine Idee: speichere die Windstärke remanent und überschreibe sie nur wenn Wert <> 0

Das verkompliziert die Logik doch sehr - und bringt ein anderes Ergebnis! (Die Windstärke könnte sich während der Downzeit des HS stark geändert haben!)

Diese Logik ist auch nur als einfaches Beispiel gedacht, meine wirklichen Logiken sind meist wesentlich komplizierter - wenn ich dann noch solche Klimmzüge nur wegen einer sauberen Initialisierung einbaue, dann kenne ich mich später mal überhaupt nicht mehr aus!

Es scheint also doch so zu sein, dass man sich in vielen Fällen die passenden Bausteine selber schreiben muss!

Gruß
GKap

[Taxus]

Bevor Du alles umschreibst: eine einfache Sperre, die erst n Sekunden nach Systemstart öffnet, löst das Problem doch ohne nennenswerten Aufwand.

[GKap]

Hallo Taxus!

Bevor Du alles umschreibst: eine einfache Sperre, die erst n Sekunden nach Systemstart öffnet, löst das Problem doch ohne nennenswerten Aufwand.

Das habe ich auch schon versucht und das funktioniert auch. Allerdings ist das programmiertechnisch sehr unsauber! Schliesslich weiss man ja nie genau wie lange der HS nach dem Start beschäftigt ist, bis der Normalbetrieb errreicht ist!

meint
GKap

[Taxus]

Schliesslich weiss man ja nie genau wie lange der HS nach dem Start beschäftigt ist, bis der Normalbetrieb errreicht ist!

Das ist in dem Fall auch gar nicht nötig. Egal wie lange der Startvorgang dauert, es gibt nur eine Initialisierung der Logik, und die dauert so lange, bis alle KOs vom Bus abgefragt sind oder der Timeout greift.

Du willst verhindern, dass direkt nach der Initialisierung einmalig etwas nicht gesendet wird. Wenn die Sperre am Sperreingang per Fixwert gesperrt wird, greift das bei der Initialisierung der Logik. Die Sperröffnung erfolgt also in jedem Fall spät genug, egal, wie lange der Startvorgang dauert (was ja wesentlich von den abgefragten KOs abhängt).

[sti87]

Hallo Gerhard, et al,

wie gehst Du nun damit um, dass nach einem HS Neustart die Zustände konsistent sind?
Ich hänge hier auch etwas fest, da sich die Initialisierung meiner Meinung nach unterschiedlich verhält.

Hier ein Beispiel einer Logik "Mückenschutz": ist ein gewisses Fenster offen ist der BWM gesperrt.

Mückenschutz ist ein iKO mit einem Initwert von "0", wird hier nach dem Systemstart mit der Logik auf "1" gesetzt.
Die Reedkontakte sind auf "Beim Starten abfragen" gesetzt.

HS_Logik.PNG


Nun habe ich ein komisches Startverhalten wo das Fenster "OG WC" offen ist, jedoch nur eine der 2 Logiken den BWM sperrt.
Die unterste Logik mit 2 Reedkontakten sperrt den 2/0/203, die oberste mit dem Reedkontakt WC lässt 3/0/200 jedoch "frei".

Zustand des Reedkontakts während des Starts:

HS_Start_Zustand-Reedkontakt WC.PNG

Zustand der Sperren während des Starts:

HS_Start_Zustand-Sperren.PNG

Zustand der Sperren nach der Logik, durch das setzen von Mückenschutz auf "1":

HS_Start_Sperren nach Logik.PNG
Es wird nur 2/0/203 gesperrt, 3/0/200 bleibt unberührt obwohl das selbe Fenster offen ist.

Ich muss entweder das Fenster öffnen/schliessen oder die GA Reedkontakt nochmals lesen.

Was mache ich hier falsch, bzw. wie geht ihr mit soetwas um?

Danke und Gruss
sti