HS/FS Logikbaustein MindestZeit

[swenga]

'n Abend zusammen,

ich habe momentan ein Baeume-Wald Problem Ein Baustein soll folgende Funktion erfüllen: Wenn das Eingangssignal auf 1 wechselt und für mindestens x Sekunden 1 bleibt, dann wird eine 1 auf dem Ausgang gesendet. Fällt der Eingang vorher ab, erfolgt keine Sendung. Realisieren wollte ich das mit einer internen Speichervariable und nem Zeitspeicher. Der Eingang des Bausteins erfolgt auch, der LocalTime-Wert wird abgespeichert und SN[1] wechselt auf 1, aber der Ausgang wird nie getriggert....

Any ideas?

#5000|"Text"|Remanent(1/0)|Anz.Eingänge|.n.|Anzahl Ausgänge|.n.|.n.
#5001|Anzahl Eingänge|Ausgänge|Offset|Speicher|Berechnung bei Start
#5002|Index Eingang|Default Wert|0=numerisch 1=alphanummerisch
#5003|Speicher|Initwert|Remanent
#5004|ausgang|Initwert|runden binär (0/1)|typ (1-send/2-sbc)|0=numerisch 1=alphanummerisch
#5012|abbruch bei bed. (0/1)|bedingung|formel|zeit|pin-ausgang|pin-offset|pin-speicher|pin-neg.ausgang

5000|"SG\MindestZeit"|0|2|"Signal"|"Mindestzeit(Se c)"|2|"Trigger"|"Debug"

5001|2|2|1|2|1

5002|1|0|0 # Signal
5002|2|0|0 # MindestZeit Sec

#Speicherwerte
5003|1|0|0 # Signal
5003|2|0|0 # ZeitEin

#Ausgänge
5004|1|0|0|1|0 #Abgelaufen
5004|2|0|0|1|1 #Debug

#Funktionen
#Wenn Eingang 1 geschossen hat, dann Speicherwert 1 auf 1 setzen
5012|0|"EC[1] and (EN[1]==1)"|"1"|""|0|0|1|0
#Wenn Eingang 1 geschossen hat, dann Aktuelle Zeit als Zeitstempel in #2 abspeichern
5012|0|"EC[1] and (EN[1]==1)"|"(__import__('time').localtime()[3]*3600 + __import__('time').localtime()[4]*60 + __import__('time').localtime()[5])"|""|0|0|2|0

#Wenn Eingang 1 zurueckgesetzt dann Speicherwert 1 auf 0 setzen
5012|0|"EC[1] and (EN[1]==0)"|"0"|""|0|0|1|0
#Wenn Zeitspeicher abgelaufen und Speicher 1 aktiv TriggerAusgang setzen
5012|0|"OC[1] and (SN[1]==1)"|""|"1"|1|0|0|0
#Wenn Eingang 1 geschossen hat, dann Zeitspeicher erneut aufrufen
5012|0|"EC[1] and (EN[1]==1)"|""|"EN[2]"|0|1|0|0

#Debug Ausgang
5012|0|""|"'Sp:' + str(int(SN[1])) + ' Zeit:' + str(int(SN[2]))"|""|2|0|0|0

[Tokamak]

Etwas zu umständlich. Wenn eine 1 eintrifft, ziehe einen Timer von x Sekunden auf und merke dir das. Trifft eine 0 ein, stoppe den Timer.
Wenn der Baustein durch den Timer getriggert wird (OC[1]), ist's vollbracht.

Also:

...
 
5002|1|0|0 # Signal
5002|2|0|0 # MindestZeit Sec
 
#Speicherwerte
5003|1|0|0 # Timer läuft
 
#Ausgänge
5004|1|0|1|1|0 #Abgelaufen
 
# Wartezeit nicht sinnvoll? Abbrechen
5012|1|"EN[2]<=0"|""|""|0|0|0|0
 
# setze Timer, wenn Wert <>0 und noch kein Timer läuft
5012|1|"EC[1] and EN[1]<>0 and SN[1]==0"|"1"|"EN[2]"|0|1|1|0
 
# setze Timer zurück, wenn eine 0 eintrifft
5012|1|"EC[1] and EN[1]==0"|"0"|"0"|0|1|1|0
 
# wenn der Timer den Baustein auslöst, gebe eine 1 aus und setze
# den Merker zurück
5012|0|"OC[1]"|"1"|""|1|0|0|0
5012|1|"OC[1]"|"0"|""|0|0|1|0

Das sollte es gewesen sein.

[swenga]

Hallo Tokamak,

danke fuer den Input. Mein Denkfehler war die 1 beim Wert des Timer-Triggerns, die hatte ich weggelassen und daher wurde dieser immer nur deaktiviert. Habs jetz mal angepasst.

Merci,

[ChristianB]

Ein Baustein soll folgende Funktion erfüllen: Wenn das Eingangssignal auf 1 wechselt und für mindestens x Sekunden 1 bleibt, dann wird eine 1 auf dem Ausgang gesendet. Fällt der Eingang vorher ab, erfolgt keine Sendung.

Wald-Bäume-mäßig ausgedrückt:
So verhält sich der Baustein Telegrammverzögerung.

[MatthiasS]

Oder der serienmäßige Baustein "watchdog"

[swenga]

Wald-Bäume-mäßig ausgedrückt:
So verhält sich der Baustein Telegrammverzögerung.

Also meine Hilfe zu diesem Baustein sagt:

Empfängt der Eingang ein beliebiges Telegramm, wird am Ausgang auch eines gesendet. Welches Telegramm gesendet wird, ist abhängig von der Telegrammfolge am Eingang. Es gilt: Eingang = EIN => Ausgang = EIN, Eingang = AUS => Ausgang = AUS. Unabhängig vom Wert des Eingangstelegramms wird die Ausgabe verzögert.

Daher: Wenn 60Sek Verzoegerung, bei T0 komt eine 1 und bei T10 eien 0 rein folgt bei T60 eine 1 raus und bei T70 eine 0 raus. Nicht das was ich wollte.

[MatthiasS]

Genau deshalb musst du den watchdog-Timer nehmen!

[swenga]

Genau deshalb musst du den watchdog-Timer nehmen!

Also MUESSEN tu ich gar nix...

Der Watchdog waere eine interessante Alternative gewesen. Leider melden bei mir zwei Kanäle unsynchronisiert den Trigger, und da ist nicht auszuschliessen, dass beide Ein-Signale auch mal kurz hinterinander kommen und da den Watchdog ungluecklich "verlaengern". Und ausserdem lernt man durchs selber proxxeln doch was....

Schoenen Abend,

[eibling]

Ist DAS Dein Problem / Deine Lösung?

[swenga]

Hallo Alex,

keine Ahnung, Deine Logik muss ich erst mal verdauen.

Zum Hintergund: Es geht mir um den Trigger zur Lüftungshöherschaltung nachdem im Bad geduscht/gebadet wurde. Dabei sind Strömungsfühler verbaut, die auf einen 230V-BE gelegt wurden.

Bisher hat jeder Schaltvorgang die Lüftung für eine Stunde hochgezogen, auch wenn das Wasser nur kurz aufgedreht wurde. Zeitweise gingen die Strömungsschalter in der Früh an, wenn die Zirkulation anlief.

Jetzt soll die Konstruktion erst dann schiessen, nachdem das Wasser mindestens eine Minute lief, aber den Treppenlichtbaustein auch nachtriggern, wenn das Wasser länger läuft.

mfg

[ChristianB]

Daher: Wenn 60Sek Verzoegerung, bei T0 komt eine 1 und bei T10 eien 0 rein folgt bei T60 eine 1 raus und bei T70 eine 0 raus. Nicht das was ich wollte.

Das ist wunderschön, dass es in der Doku steht, aber.......

Der Baustein wird auch bei einer 0 neu getriggert und erfüllt somit Deine beschriebenen Anforderungen. Der geneigte Leser möge das selbst ein Mal probieren
Wird die Telegrammverzögerung nachgetriggert, wird der neue Wert verzögert. Ist das eine 0, so wird dann auch am Ende eine 0 ausgegeben. Immer der letzte Wert triggert die Telegrammverzögerung neu.

An dem o.a. Beispiel bedeutet das: Wenn 60s Verzögerung, bei T0 kommt eine 1 und bei T10 eine 0 rein kommt nur bei T70 eine 0, weil die 0 bei T10 den Baustein erneut um 60s triggert.

[swenga]

Hallo Christian,

aha. Das ist dann aber mal wieder ein Beispiel für die vernachlässigte und ungenaue Hilfe im Experten (neben zum Beispiel der Beschreibung NTP sowie des Schaltlistenimprts, der komischerweise immer .dat heissen muss). Eigentlich wollte ich das "Durchprobieren" von Bausteinen vermeiden, da in dieser Zeit ein operatives System steht. Ideal waäre natuerlich eine State Machine im Experten, mit der man das Verhalten von Bausteinen und Logiken offline testen kann.....

Anyway: Ein Problem fällt mir bei Deinem Vorschlag noch auf: Bei T0 kommt eine eins rein, es wird für T60 eine 1 geplant. Bei T30 kommt nochmal eine eins, es wird für T90 eine 1 geplant und die erste zurueckgesetzt, richtig?. Jetzt kommt bei T60 eine 0 und damit wuerde nie eine 1 gesendet werden.

mfg

[ChristianB]

ja,
nicht "4 Gewinnt" - sondern der Letzte gewinnt. So ist es halt beim KNX.

Irgendwo habe ich auch mal gelesen, dass Du Merker geschrieben hast,oder? Du kommst von der SPS-Denke, richtig?

[swenga]

Hallo Christian,

noe. Wald- und Wieseninformatiker, Anwendungsentwicklung, C++ und C#, Win und Linux.

mfg

[NilsS]

Vielleicht hilft dir das (ungetestet)

 

# Wenn Telegramm an EN[1] das nicht SN[1] ist (um zu verhindern das eine weitere 1 den Timer erneut startet) und der Timer nicht abgelaufen ist, dann starte Timer mit Zeit EN[2] und Wert EN[1] und setze SN[1] auf EN[1]
5012|1|"EC[1]==1 and EN[1]<>SN[1] and OC[1]==0"|"EN[1]"|"EN[2]"|0|1|1|0

# Wenn Timer abgelaufen und den Wert 1 hat und EN[1] immernoch 1 ist sende 1 an Ausgang
5012|0|"EN[1]==1 and OC[1]==1 and ON[1]==1"|"1"|""|1|0|0|0
 
# SN[1] reset um neue Timer zu akzeptieren
5012|0|"EN[1]==1 and OC[1]==1 and ON[1]==1"|"0"|""|0|0|1|0