t_lockout bei Bind_control_s

Begonnen von goifalracer, 18. August 2017, 17:08:45

Vorheriges Thema - Nächstes Thema

0 Mitglieder und 1 Gast betrachten dieses Thema.

goifalracer

Hallo zusammen,

ich habe ein Problem. Ich dachte ich habe meine Rollosteuerung jetzt im Griff, doch mir ist jetzt aufgefallen das wenn mein Rollo Status 151 beschattet und gleichzeitig der Türkontakt True wird, der Rollo sofort unverzögert in die andere Richtung fährt.
Das gleiche macht er auch wenn er automatisch fährt und ich mit dem Taster eine Gegenrichtung ansteuere.

Ich habe mir den Code mal angesehen und gemerkt das die Zeit t_lockout gar nicht die Ausgänge um diese Zeit sperrt.

Hat dieses Problem keiner?? Ich finde das nicht so prickelnd das die zeitliche Verriegelung nicht klappt. Ich benutze Blind_Control_S aber beim Blind_Control scheint es laut dem Code zu funktionieren.

Hat sich da vielleicht schon jemand selbst schon was gecodet?

Wäre um Hilfe sehr dankbar.

Gruß

mattsches

Ja, das scheint mir auch so. Die Zeilen


IF UP  AND NOT DN THEN
(*  manual UP *)
rmp.IN := 255;
STATUS := 121;
ELSIF DN AND NOT UP THEN
(* manual DN *)
rmp.IN := 0;
STATUS := 122;


Zu Beginn setzen hart den Status für manuell auf/ab, unabhängig davon, ob die Lockout-Zeit verstrichen ist oder nicht.

Ich würde testweise auf den BLIND_CONTROL umsteigen mit T_ANGLE := t#0ms.

goifalracer

Ja das wäre eine Idee,der hat ja den actuator mit drin.
Es sollte ja mit dem Jalousie Baustein genau so mit Rollo funktionieren?

goifalracer

Hat dieses Problem eigentlich sonst keiner außer ich?

König777

Hallo goilalracer,

hast Du evtl. für dein Problem eine Lösung gefunden? Würde mich auch interessieren, da ich vor habe den Baustein einzubinden.

Gruß König

mattsches

Habt ihr denn meinen Vorschlag mal ausprobiert?

König777

#6
Hallo Mattsches,

kämpfe mich gerade durch den Quellcode vom Blind Control_S. Nun habe ich festgestellt das T_LOCKOUT nur dann greift wenn die Ausgänge QU und QD über den Baustein _RMP_NEXT mit rmp.DN und rmp.Up gesteuert werden. Wird dann z.B. der Rolladen über den Automatikbetrieb z.B . durch einen anderen Baustein nach oben gesteuert und während der Fahrt manuell nach unten, dann wird im Case Status 122 dann sofort ohne Lockout die Richtung gändert.

122:   (* manual down *)       
      MD := TRUE;         
      MU := FALSE;         
      usw.                     
Richtig wäre doch:

MD:= rmp.DN;
MU:=rmp.UP;
usw.

Zusätzlich zu der Änderung habe ich noch folgendes eingefügt.

ELSE
   MU := FALSE;
   MD := FALSE;
   IF ((POS <> PI) AND ((POS =255) OR (POS =0))) OR PI <> PI_last  THEN

Damit soll im Automatikmodus nach Windarlarm usw. von Security der Behang wieder in die Position von PI fahren.
Ist z. B.  Input in Automatik, der Shade aktiv (151) und Security gibt Feueralarm. Dann wird  über UP an Control_S (Status manuelles Öffnen) der Behang nach oben gefahren ohne das die POS von Control_S über Input, Shade usw. weitergereicht wird (ist ja richtig im Automatikbetrierb). D.h an PI von Control_S bleibt 0 (von Shade) obwohl  Control_S POS = 255. Es gibt keine Veränderung PI (=0)<>PI_last (=0) und damit keine Positionänderung wenn der Feueralarm (false). Dafür die Abfrage POS<>PI aber nur bei Endposition Oben oder Unten.

Vielleicht könnt Ihr mal draufschauen und Rückmeldung geben.

Gruß König



[gelöscht durch Administrator]

mattsches

Hallo König,

deine Codeänderung


MD:= rmp.DN;
MU:=rmp.UP;


schaut plausibel aus, damit müsste die Totzeit auch beim Umschalten auf/in Handbetrieb aktiv werden. Oder wie schon gesagt BLIND_CONTROL mit T_ANGLE := t#0ms.

Den Punkt

Zitat von: König777 in 26. Oktober 2017, 00:22:28
Damit soll im Automatikmodus nach Windarlarm usw. von Security der Behang wieder in die Position von PI fahren.
Ist z. B.  Input in Automatik, der Shade aktiv (151) und Security gibt Feueralarm. Dann wird  über UP an Control_S (Status manuelles Öffnen) der Behang nach oben gefahren ohne das die POS von Control_S über Input, Shade usw. weitergereicht wird (ist ja richtig im Automatikbetrierb). D.h an PI von Control_S bleibt 0 (von Shade) obwohl  Control_S POS = 255. Es gibt keine Veränderung PI (=0)<>PI_last (=0) und damit keine Positionänderung wenn der Feueralarm (false). Dafür die Abfrage POS<>PI aber nur bei Endposition Oben oder Unten.

Kannst du viel einfacher und ohne Modifikation des BLIND_CONTROL erreichen, indem du am BLIND_INPUT den Parameter MASTER_MODE auf TRUE nimmst. Dann wird die aktuelle Position nicht auf die Sollposition übertragen, sondern diese beibehalten. Schaltet sich der BLIND_SECURITY ab, schleift er die dann unveränderte Sollposition durch, und der BLIND_CONTROL(_S) fährt sie an.

Kannst du ja mal ausprobieren.

Gruß,
mattsches

König777

Hallo Mattsches,

bei Input Mastermode = True tritt dies ja auf. Wenn Automatik und Shade aktiv (151) und dann z.B. Security Feuer (111) fährt Control_S nach oben. Wenn nun Security Feuer inaktiv und Shade (151 / PO = 0) wieder zum Zug kommt bleibt Control_S auf Pos 255 stehen. Darum Codeänderung "((POS <> PI) AND ((POS =255) OR (POS =0)))".
Blind Control und Blind Control_S verhalten sich diesbezüglich nicht gleich.
Bei Control_S gefällt mir die Option der Einstellung R_POS_TOP und R_POS_BOT um evtl. eine Lüftung im Sommer realisieren zu können.

Gruß König