[Gelöst] [V1.5 RC3] Fehler in der Einschaltverzögerung?

[Matze76]

Hallo,

Ausgangslage ist eine Logik, die nur bei "true" ausgeführt wird. An sich funktioniert sie korrekt.



Kombiniert mit der Einschaltverzögerung ist das Verhalten aber noch nicht so wie erwartet.

(Wegen des Anzeige-Bugs viewtopic.php?f=24&t=1339&p=13749&hilit ... ung#p13716 habe ich für den Screenshot die kombinierte Ein-/Ausschaltverzögerung gewählt - das Verhalten ist aber in beiden Fällen identisch).

Problem 1: Nach dem Speichern wird beim ersten Triggern sofort "false" gesendet (nicht nur angezeigt, sondern es wird tatsächlich eine 0 auf die KNX-Adresse gesendet, sichtbar im KNX-Monitor) - was gar nicht passieren sollte.

Nach Ablauf der Einschaltverzögerung wird dann korrekt "true" gesendet.



Problem 2: Ab der nächsten Ausführung wird die Einschaltverzögerung nicht mehr berücksichtigt, sondern einfach sofort "true" gesendet.

Das Verhalten lässt sich beliebig oft reproduzieren.

Gruß
Matthias

[Matze76]

Hallo Stefan`s,

vielleicht ist dieser Beitrag ja durchgegangen. Eine ganz kurze Rückmeldung (wissen wir schon / schauen wir uns bei Gelegenheit mal an / du hast einen Denkfehler...) wäre nett

Gruß
Matthias

[Matze76]

Hallo,

ich komme nochmal auf dieses Problem zurück, weil diese Konstellation auch mit dem aktuellen Stand (RC 7.1) noch nicht das tut was ich erwarte.

Nochmal die Ausgangslage:
Ich habe einen normalen "AND"-Logikbaustein angelegt, der
a) nur TRUE senden soll (konstanter TRUE-Eingang und mehrere Inhibit-Eingänge zum Sperren) und
b) eine Einschaltverzögerung hat.

Das passt aber entweder noch nicht richtig zusammen, oder ich mache einen Bedienungsfehler und komme nicht auf die richtige Lösung.

Das Verhalten des Ausgangs habe ich mit folgenden Optionen ausprobiert ("C" und "CT" sollten hier nicht relevant sein, da immer nur TRUE auf den Ausgang gesendet werden soll):

1) Ausgang auf "A" (Always) gesetzt:

Ergebnis:

• bei der ersten Ausführung der Logik (also wenn erstmalig kein Inhibit-Eingang mehr blockiert) wird sofort FALSE gesendet => sollte nicht sein, da die Logik ja nur TRUE senden soll.

• nach Ablauf der Einschaltverzögerung wird TRUE gesendet => OK

• Jede weitere Ausführung der Logik sendet immer sofort TRUE. Die Einschaltverzögerung wird ignoriert => nicht gut

Inzwischen habe ich verstanden, dass "A" und Einschaltverzögerung nicht zueinander passen. Obwohl ich intuitiv "A" gewählt hätte, denn das wäre ja ohne Einschaltverzögerung korrekt gewesen. Dass die Einschaltverzögerung hier als Timer zählt ist technisch nachvollziehbar, aber aus Sicht des normalen Anwenders kommt man nicht unbedingt darauf (Timer ist in erster Linie das, was ich am Eingang einstelle).

2) Ausgang auf "T" (Timer) gesetzt:

Ergebnis:

• Bei der ersten Ausführung der Logik wird das TRUE nach Ablauf der Einschaltverzögerung gesendet => gut!

• Bei jeder weiteren Ausführung wird gar nichts mehr gesendet => nicht gut

Ist alles nicht so dringend, aber irgendwann sollte das "rund" gemacht werden. Oder ich brauche Nachhilfe, wie man das richtig löst

[Gecks]

Gab es da nicht ein Problem mit den Timer Triggern? Dachte das irgendwo Mal gelesen zu haben. Vielleicht hängt es ja daran.

[S. Kolbinger]

Hallo Matthias,

ich komme nochmal auf dieses Problem zurück, weil diese Konstellation auch mit dem aktuellen Stand (RC 7.1) noch nicht das tut was ich erwarte.

entschuldige bitte die sehr späte Antwort, aber das ist mir irgendwie durchgerutscht.

Es handelt sich hier eher um ein Missverständnis, bzw. um eine unterschiedliche Ansicht, was die Ein-/Ausschaltverzögerung machen soll.

So, wie ich es implementiert habe, geht es um die Verzögerung des Ein- bzw. Ausschaltvorganges.
Dabei ist der Einschaltvorgang der Zustandswechsel von "Aus" (False) auf "Ein" (True). In der Elektronik nennt man das eine "positive Flanke".
Umgekehrt gilt das für den Ausschaltvorgang (="negative Flanke").
Und genau diese "Flanken" werden bei der Ein- bzw. Ausschaltverzögerung -- um die eingestellte Dauer verzögert -- am Ausgang ausgegeben.

Da bei deinem Lösungsansatz aber nur einmalig am Anfang ein Einschaltvorgang möglich ist (wenn zum ersten mal der Default-Wert von false auf true wechselt), gibt es auch nur einmal eine Verzögerung.

Ich vermute, du erwartest hier eine allgemeine Telegramm-/Meldungsverzögerung. Das habe ich aber wegen nicht vorhersagbarem Speicherbedarf (z.B. bei hoher Telegramm-Rate und langer Verzögerungsdauer) nicht implementiert. Das haben wir für die nächste Haupt-Version vorgesehen und läuft dann vermutlich über die Timeseries-DB als Zwischenspeicher.

@Matze76
Kannst du bitte nochmal die Funktionsweise kurz erklären, wie sich die Logik genau verhalten soll.
Eventuell kann man das leicht mit einem der Timer-Bausteine lösen.

[Matze76]

Hallo Stefan @S. Kolbinger,

danke für deine Erklärung!

Ich vermute, du erwartest hier eine allgemeine Telegramm-/Meldungsverzögerung

Ja, genau!

Das habe ich aber wegen nicht vorhersagbarem Speicherbedarf (z.B. bei hoher Telegramm-Rate und langer Verzögerungsdauer) nicht implementiert.

Besteht das Problem denn nicht auch bei schnellen Flankenwechseln und langer Verzögerungsdauer? Oder wird ein mehrfacher Flankenwechsel während der Verzögerungszeit einfach gar nicht beachtet?

Wäre das nicht auch eine Möglichkeit für eine einfache Verzögerungsfunktion ohne Flankenwechsel? D.h. während einer laufenden Verzögerungszeit lösen weitere Trigger nicht selber wieder einen Timer aus, sondern der eine laufende Timer wird einfach um die Verzögerungszeit verlängert.

Ich denke, es gibt beide Anwendungsfälle:
1) Jeder Trigger soll für sich eine Verzögerungszeit auslösen und nach Ablauf der Zeit auf den Ausgang gehen => mögliches Speicherproblem
2) Wenn die Verzögerungszeit läuft, sollen weitere Trigger nur die Verzögerungszeit verlängern. Am Ende der (ggf. verlängerten) Verzögerungszeit kommt nur 1 x die Meldung auf den Ausgang, egal wie viele Trigger zwischenzeitlich erfolgt sind. Also im Hintergrund ein re-triggerbarer Timer.

Der Fall 2) würde für mich hier völlig ausreichen (weitere Trigger während der Verzögerungszeit sind hier eher theoretisch).

Kannst du bitte nochmal die Funktionsweise kurz erklären, wie sich die Logik genau verhalten soll.

Unter bestimmten Voraussetzungen soll das Garagentor in die Lüftungsposition fahren. Die entsprechende KNX-GA am Ausgang verarbeitet nur "EIN"-Telegramme. Eine Voraussetzung ist, dass das Garagentor geschlossen ist ("Status geschlossen" ist einer der Eingänge). Problem ist, dass der Garagentorantrieb (bzw. das KNX-Modul) nach einem gerade erfolgten Schließvorgang ("Status geschlossen" am Eingang geht auf TRUE) ein paar Sekunden braucht, um weitere Telegramme zu verarbeiten. Kommt also das Lüftungs-Telegramm sofort, wird es nicht verarbeitet. Deshalb soll dieses Telegramm am Ausgang immer erst mit 10 Sekunden Verzögerung gesendet werden.

Eventuell kann man das leicht mit einem der Timer-Bausteine lösen.

Ja, ich denke wenn ich einfach einen (re-triggerbaren) Timer Baustein anlege und diesen mit dem Ausgang der eigentlichen Logik füttere, sollte es funktionieren. Ich probiere es mal. Und damit wäre mir auch erstmal geholfen

[S. Kolbinger]

Hallo Matthias,

wäre das eine akzeptable Lösung für dich:

[Matze76]

Hallo Stefan (@S. Kolbinger ,

danke, ja, das passt!

Interessant, auch auf diesem Weg kann man also einen Sende-Telegrammfilter einrichten Durch das "T" sendet der Ausgang nur bei einem Timer-Ablauf. Und da ich nur eine Einschaltverzögerung habe, wird nur TRUE gesendet. (Der Busmonitor bestätigt mir, dass das FALSE mit dieser Konfiguration nicht gesendet wird).

Die "umgekehrte Logik" mit konstantem true und den Inhibit-Eingängen brauche ich hier also gar nicht. Und dadurch habe ich auch den notwendigen Flankenwechsel, um die Einschaltverzögerung immer wieder erneut zu triggern.

[gbglace]

Ich interpretiere das dann mal als gelöst?

@Matze76 / @Gecks

[Matze76]

@gbglace Ja, korrekt interpretiert