[Erfahrungsbericht] [V4.5 IP3] Schritt für Schritt Umsetzung einer (Dusch)-Lüftersteuerung

[StefanW]

Gu,

zum Verschieben das farbige Feld anfassen und vor dem Beenden Speichern drücken, damit die Positionen gespeichert werden.

lg

Stefan

[jhaeberle]

Mhmm… danke, dann check ich das nochmal mit anderen Browsern. Jedenfalls nicht mit Safari am Mac…

[jhaeberle]

Geht am Mac auch unter Chrome nicht…

[Thimo]

Bei den Ein- und Ausgängen geht das farbige Feld, und damit der Anfasser zum Verschieben, nicht über die ganze Zeile. Man muss mit dem Cursor in den farbigen Bereich hinein.
Etwas anders ist es bei den Variablen, also die Kästen mit dem farbigen Rand. Die lassen sich im gesamten Rechteck-Bereich anfassen.

[Franky]

Eine (miese) Erfahrung mit Sperren… Wenn die Sperre eintrifft während der Lüfter schon läuft, ist es (jedenfalls für mich) nicht selbstverständlich, dass da am Ausgang noch ein Ausschaltsignal ankommt. Per Definition ist ja nix mit Nachlaufzeit… Jedenfalls ist das mit einem Inhibit-Eingang scheinbar so. Der schaltet die Logik einfach ab, wie ein BREAK in vielen Programmiersprachen und du hast keine Möglichkeit, noch irgendwas an den Ausgang zu bringen. Das ist okay, wenn die Logik gar nicht erst anlaufen soll, aber verhindert ein sauberes Ende einer bereits laufenden Logik…

ja, da steige ich noch nicht ganz durch, verstehe aber, was Du meinst und bin ganz Deiner Meinung, dass das in allen Zuständen (deshalb will ich immer die statemachine ) funktionieren muss.

Das werde ich dasnn austesten. (Wofür brauche ich die Sperre nochmal?)

Ich bin gerade dabei das Init-Prblem zu lösen. Ich will, wenn der Bus resettet wird, dass die Logik den aktuellen Schaltzustand noch mal sendet. Aber nur dann und nicht jedes mal, wenn die Logik durchlaufen wird. Ich glaube das habe ich gleich gelöst und dann mache ich auch wieder mit der inhaltlichen Umsetzung weiter. Ich will das ja nicht auf biegen und brechen ans Laufen bekommen, sondern auf dem Weg dahin alles verstehen und mein "Toolset" zusammenbekommen, wie z.B. das mit dem sicheren bus-Reset. Da habe ich irgendwie einen Pin im kopf, seitdem ich nach Hause gekommen bin und ich damit konfrontiert wurde "Der Lüfter ist nicht ausgegangen"

LG Franky

[jhaeberle]

Das werde ich dasnn austesten. (Wofür brauche ich die Sperre nochmal?)

Ich wollte das… Bei mir im Haus darf der Lüfter nachts nicht laufen, weil da sonst in den oberen Stockwerken Menschen aus den Betten fallen… Bei mir hört man den ja kaum…

Ich bin gerade dabei das Init-Prblem zu lösen. Ich will, wenn der Bus resettet wird, dass die Logik den aktuellen Schaltzustand noch mal sendet. Aber nur dann und nicht jedes mal, wenn die Logik durchlaufen wird. Ich glaube das habe ich gleich gelöst und dann mache ich auch wieder mit der inhaltlichen Umsetzung weiter. Ich will das ja nicht auf biegen und brechen ans Laufen bekommen, sondern auf dem Weg dahin alles verstehen und mein "Toolset" zusammenbekommen, wie z.B. das mit dem sicheren bus-Reset.

Sehr, sehr gut. Sorry, dass ich nicht so viel beitragen konnte/kann, aber meine Schwiegermama ist ins KH gekommen und in Folge ist hier alles ein bisserl auf den Kopf gestellt…

Da habe ich irgendwie einen Pin im kopf, seitdem ich nach Hause gekommen bin und ich damit konfrontiert wurde "Der Lüfter ist nicht ausgegangen"

Genau das hatte ich mit der Sperre auch… WhatsApp von oben… mitten in der Nacht… der Lüfter läuft jetzt zwei Stunden… kann man den bitte ausmachen?

Gruß
Jochen

P.S.: Bist du Samstag auf dem Rudeltreffen?

[Franky]

Rudeltreffen: Kann ich zeitlich leider, leider nicht.

Ich muss nochmal kurz einen Stubser bekommen:

Was passiert, wenn beim Warten auf den Ablauf einer Sendeverzögerung ("Logikdurchlauf 1") ein erneuter Trigger für die Logik reinkommt und der Code dann in dem "Logikdurchlauf 2" bspw. sofort einen Ausgang beschreiben soll, vielleicht sogar denselben Ausgang (jetzt unverzögert), der auf den Ablauf der Sendeverzögerung ("Logikdurchlauf 1") wartet. Wird dann erst der neuere Wert "Logikdurchlauf 2" gesendet und dann der veraltete Wert von "Logikdurchlauf 1"?

Und welcher Wert wird für "Logikdurchlauf 2" herangezogen für die Entscheidung, ob es sich um eine Wertänderung handelt? "Logikdurchlauf 1" ist ja noch nicht gesendet und somit für "Logikdurchlauf 2" auch noch nicht der neue Vergleichswert?

Und was macht der Dispatcher, wenn während der Ausführung einer Logik ein weiterer Aufruf durch Eintreffen eines Ereignisses (Triggers) anstünde. Ich denke nicht, dass dann zwei Ausführungen zeitgleich laufen (reentrant Codeausführung?) Oder ist das schon die Antwort auf meine erste Frage? Wartet der Dispatchher mit dem "Logikdurchlauf 2" solange, bis die Sendeverzögerung abgelaufen ist? Gilt dann die Sendeverzögerung für die ganze Logikzelle?

Gruß

Franky

[Robert_Mini]

Eine (miese) Erfahrung mit Sperren… Wenn die Sperre eintrifft während der Lüfter schon läuft, ist es (jedenfalls für mich) nicht selbstverständlich, dass da am Ausgang noch ein Ausschaltsignal ankommt. .....

ja, da steige ich noch nicht ganz durch, verstehe aber, was Du meinst und bin ganz Deiner Meinung, dass das in allen Zuständen (deshalb will ich immer die statemachine ) funktionieren muss.

Ich löse alle Sperren so, das dabei noch ein definierter (meist AUS) Zustand gesendet wird. Ähnlich den KNX-Aktoren, wo man für Sperre auch AUS (oder keine Reaktion) parametrieren kann.

Ich bin gerade dabei das Init-Prblem zu lösen. Ich will, wenn der Bus resettet wird, dass die Logik den aktuellen Schaltzustand noch mal sendet. Aber nur dann und nicht jedes mal, wenn die Logik durchlaufen wird.

Die beste Lösung ist dafür ein Sendexplicit, das man absolut flexibel parametrieren kann, aber auch Fehler einstreuen.

Vielleicht teilst du mal den Letztstand, dass wir auf den gleichen Stand sehen...

lg
Robert

[Robert_Mini]

Puuuh, du bringst mein Hirn zum rauchen

Was passiert, wenn beim Warten auf den Ablauf einer Sendeverzögerung ("Logikdurchlauf 1") ein erneuter Trigger für die Logik reinkommt und der Code dann in dem "Logikdurchlauf 2" bspw. sofort einen Ausgang beschreiben soll, vielleicht sogar denselben Ausgang (jetzt unverzögert), der auf den Ablauf der Sendeverzögerung ("Logikdurchlauf 1") wartet. Wird dann erst der neuere Wert "Logikdurchlauf 2" gesendet und dann der veraltete Wert von "Logikdurchlauf 1"?

Im Normalfall (wenn man das sauber macht und den Ausgang erst gegen Ende der Logik beschreibt), sind das getrennte Themen.
D.h. es gibt ein Timer, der gestartet wird und sein Status wird zB per UND/ODER/LATCH weiterverarbeitet und irgendwie wird der Ausgang beschrieben.
Bei einem weiteren Trigger bei laufenden Timer kann der Ausgang beliebig beschrieben werden. Je nachdem wie die Abhängigkeit zum Timerstatus ist.
Wenn der Timer abläuft, wird die Logik getriggert und damit kann (muss aber nicht) das Ausgang neu beschrieben werden.

Ein Spezialfall wäre die Verwendung der Sendeverzögerung der Zelle (was ich bei Custom Logiken vermeide). Meinst du diese?

Und welcher Wert wird für "Logikdurchlauf 2" herangezogen für die Entscheidung, ob es sich um eine Wertänderung handelt? "Logikdurchlauf 1" ist ja noch nicht gesendet und somit für "Logikdurchlauf 2" auch noch nicht der neue Vergleichswert?

Für die Entscheidung ob eine Änderung vorliegt, wird der Wert der Output-Variable am Ende der Logik mit dem Wert beim Aufruf vergleichen. Ein temporäres Überschreiben während der Logikabarbeitung bleibt unberücksichtigt.

Und was macht der Dispatcher, wenn während der Ausführung einer Logik ein weiterer Aufruf durch Eintreffen eines Ereignisses (Triggers) anstünde. Ich denke nicht, dass dann zwei Ausführungen zeitgleich laufen (reentrant Codeausführung?) Oder ist das schon die Antwort auf meine erste Frage? Wartet der Dispatchher mit dem "Logikdurchlauf 2" solange, bis die Sendeverzögerung abgelaufen ist? Gilt dann die Sendeverzögerung für die ganze Logikzelle?

Der Dispatcher verteilt sequentiell. Damit ist ein Aufruf während der Abarbeitung ausgeschlossen.
Allerdings kann eine Logik sehr wohl während der Wartezeit getriggert werden und der Timer re-triggert, resetted oder nicht beeinflusst werden.

lg
Robert

[Franky]

Die beste Lösung ist dafür ein Sendexplicit, das man absolut flexibel parametrieren kann, aber auch Fehler einstreuen.

ok, den habe ich noch nicht verstanden. Braucht man dafür wie in [NEUHEIT] Modul: SendExplizit
angesprochen, einen eigenen "redundanten" Ausgang, der also auf derselben GA sendet?

Vielleicht teilst du mal den Letztstand, dass wir auf den gleichen Stand sehen...

lg
Robert

ja, sobald ich was neues habe ich mach grade nur so Rumpftests für das Triggern