NEU! UPGRADE IP 11 verfügbar!
NEU! LICHTWIDGET - DPT 7.600 - Logik Manager Update - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/B9MUEJj2
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
NEU! LICHTWIDGET - DPT 7.600 - Logik Manager Update - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/B9MUEJj2
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
[Gelöst] [V1.5 RC3] Fehler in der Einschaltverzögerung?
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
- Reactions:
- Beiträge: 314
- Registriert: Mo Sep 24, 2018 9:59 am
- Hat sich bedankt: 284 Mal
- Danksagung erhalten: 195 Mal
[V1.5 RC3] Fehler in der Einschaltverzögerung?
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
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
Zuletzt geändert von gbglace am Mi Nov 13, 2019 8:58 pm, insgesamt 2-mal geändert.
Gruß
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache
-
- Reactions:
- Beiträge: 314
- Registriert: Mo Sep 24, 2018 9:59 am
- Hat sich bedankt: 284 Mal
- Danksagung erhalten: 195 Mal
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
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
Gruß
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache
-
- Reactions:
- Beiträge: 314
- Registriert: Mo Sep 24, 2018 9:59 am
- Hat sich bedankt: 284 Mal
- Danksagung erhalten: 195 Mal
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:
2) Ausgang auf "T" (Timer) gesetzt:
Ergebnis:
Ist alles nicht so dringend, aber irgendwann sollte das "rund" gemacht werden. Oder ich brauche Nachhilfe, wie man das richtig löst
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
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
Gruß
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache
-
- Elaborated Networks
- Reactions:
- Beiträge: 588
- Registriert: Mi Aug 15, 2018 11:34 am
- Hat sich bedankt: 82 Mal
- Danksagung erhalten: 559 Mal
Hallo Matthias,
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.
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.
Gruß,
Stefan K.
Stefan K.
-
- Reactions:
- Beiträge: 314
- Registriert: Mo Sep 24, 2018 9:59 am
- Hat sich bedankt: 284 Mal
- Danksagung erhalten: 195 Mal
Hallo Stefan @S. Kolbinger,
danke für deine Erklärung!
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).
danke für deine Erklärung!
Ja, genau!Ich vermute, du erwartest hier eine allgemeine Telegramm-/Meldungsverzögerung
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?Das habe ich aber wegen nicht vorhersagbarem Speicherbedarf (z.B. bei hoher Telegramm-Rate und langer Verzögerungsdauer) nicht implementiert.
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).
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.Kannst du bitte nochmal die Funktionsweise kurz erklären, wie sich die Logik genau verhalten soll.
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 geholfenEventuell kann man das leicht mit einem der Timer-Bausteine lösen.
Gruß
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache
-
- Elaborated Networks
- Reactions:
- Beiträge: 588
- Registriert: Mi Aug 15, 2018 11:34 am
- Hat sich bedankt: 82 Mal
- Danksagung erhalten: 559 Mal
Hallo Matthias,
wäre das eine akzeptable Lösung für dich:
wäre das eine akzeptable Lösung für dich:
Gruß,
Stefan K.
Stefan K.
-
- Reactions:
- Beiträge: 314
- Registriert: Mo Sep 24, 2018 9:59 am
- Hat sich bedankt: 284 Mal
- Danksagung erhalten: 195 Mal
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.
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.
Gruß
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache
Matthias
TWS 2500 ID:110 + PBM, VPN offen, Reboot nach Rücksprache
-
- Reactions:
- Beiträge: 3614
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1272 Mal
- Danksagung erhalten: 1674 Mal
Ich interpretiere das dann mal als gelöst?
@Matze76 / @Gecks
@Matze76 / @Gecks
Grüße
Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension