Hallo,
ich habe die unterschiedlichen Blind-Module endlich mal zusammengepackt und mir quasi einen FB gebastelt, damit ich nicht immer mit sovielen DBs arbeiten muss.
Und während der letzten schönen Tagen ist mir eine leichte Unstimmigkeit beim Shade-Modul aufgefallen.
Wenn die Rollade nun unten ist zum beschatten und der Sonneneingang geht weg, dann läuft der Timer ab für "topen_delay".
Sollte die Sonne wiederkommen, fängt der Timer für "tshade_delay" an zu laufen.
Soweit so gut, nur ich hatte das Phänomen, dass ich hier im Wohnzimmer saß und sah, wie die Rollade hochgefahren wurde und kaum war sie oben, fuhr sie auch wieder runter.
Warum?
Die Sonne kommt, Einschaltverzögert fährt das Rollo runter.
tshade_delay.Q wird auf 1 gesetzt und somit auch topen_delay.IN und topen_delay.Q ebenso auf 1.
Wenn die Sonne weggeht, wird tshade_delay.Q auf 0 gesetzt und auch topen_delay.IN, somit läuft die Zeit für das hochfahren runter.
Kommt die Sonne wieder wird tshade_delay.IN auf 1 gesetzt und die Zeit für das runterfahren wird angestossen.
Und genau hier passiert der "Bug".
Die Zeit für das hochfahren wird nicht angehalten, sondern läuft munter weiter, erst wenn tshade_delay.Q gesetzt wird, würde sie angehalten werden.
Also kann es passieren, wenn die öffnen zeit eher kommt als die wieder beschatten bitte, dass erst das Rollo hochgefahren wird und dann relativ schnell wieder runter.
Ich habe dies umgangen, indem ich im SCL-Code beim öffnen weitere Bedingungen mit eingebaut habe, bevor die Zeit läuft.
Zum einen muss der topen_delay.IN auf 0 gehen (wie bisher), aber gleichzeitig sage ich ODER Sonne und topen_delay.Q zusammen dürfen nicht 1 sein.
Zweiteres sagt nichts anderes aus wie, ich beschatte gerade (also Rollo unten) und es kommt wieder Sonne. Somit wird der Eingang des TOF wieder auf 1 gesetzt und der Timer unterbrochen :-)
Als Code sieht es dann so aus und das bitte austauschen wer es möchte:
ich habe die unterschiedlichen Blind-Module endlich mal zusammengepackt und mir quasi einen FB gebastelt, damit ich nicht immer mit sovielen DBs arbeiten muss.
Und während der letzten schönen Tagen ist mir eine leichte Unstimmigkeit beim Shade-Modul aufgefallen.
Wenn die Rollade nun unten ist zum beschatten und der Sonneneingang geht weg, dann läuft der Timer ab für "topen_delay".
Sollte die Sonne wiederkommen, fängt der Timer für "tshade_delay" an zu laufen.
Soweit so gut, nur ich hatte das Phänomen, dass ich hier im Wohnzimmer saß und sah, wie die Rollade hochgefahren wurde und kaum war sie oben, fuhr sie auch wieder runter.
Warum?
Die Sonne kommt, Einschaltverzögert fährt das Rollo runter.
tshade_delay.Q wird auf 1 gesetzt und somit auch topen_delay.IN und topen_delay.Q ebenso auf 1.
Wenn die Sonne weggeht, wird tshade_delay.Q auf 0 gesetzt und auch topen_delay.IN, somit läuft die Zeit für das hochfahren runter.
Kommt die Sonne wieder wird tshade_delay.IN auf 1 gesetzt und die Zeit für das runterfahren wird angestossen.
Und genau hier passiert der "Bug".
Die Zeit für das hochfahren wird nicht angehalten, sondern läuft munter weiter, erst wenn tshade_delay.Q gesetzt wird, würde sie angehalten werden.
Also kann es passieren, wenn die öffnen zeit eher kommt als die wieder beschatten bitte, dass erst das Rollo hochgefahren wird und dann relativ schnell wieder runter.
Ich habe dies umgangen, indem ich im SCL-Code beim öffnen weitere Bedingungen mit eingebaut habe, bevor die Zeit läuft.
Zum einen muss der topen_delay.IN auf 0 gehen (wie bisher), aber gleichzeitig sage ich ODER Sonne und topen_delay.Q zusammen dürfen nicht 1 sein.
Zweiteres sagt nichts anderes aus wie, ich beschatte gerade (also Rollo unten) und es kommt wieder Sonne. Somit wird der Eingang des TOF wieder auf 1 gesetzt und der Timer unterbrochen :-)
Als Code sieht es dann so aus und das bitte austauschen wer es möchte:
Code Auswählen
tshade_delay(IN := sun, PT := shade_delay);
topen_delay(IN := tshade_delay.Q OR (sun AND topen_delay.Q), PT := open_delay);