Autor Thema: BLIND_INPUT BLIND_NIGHT Problem  (Gelesen 10766 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

mike_roh_soft

  • Gast
BLIND_INPUT BLIND_NIGHT Problem
« am: 11. März 2012, 20:04:14 »
Hi,
ich habe folgende Konstellation:

BLIND_INPUT -> SHADE_S -> NIGHT -> CRL_S

Angenommen es ist Nacht und der NIGHT hat den Rollo zugefahren und alle Bausteine sind wieder im StandyBy/Auto.

Jetzt forciere ich per Visu den INPUT.IN = TRUE und INPUT.PO nimmt den INPUT.PI-Wert an.
Aber es tut sich nichts weil:
Die Ausgänge vom INPUT beide High bleiben und deswegen der NIGHT davon ausgeht, dass sich nichts geändert hat!

Was kann man hier tun?
Entweder könnte man den INPUT ändern, dass sich die Ausgänge anders verhalten oder den NIGHT ändern?

Gruß
Mike

mike_roh_soft

  • Gast
Re: BLIND_INPUT BLIND_NIGHT Problem
« Antwort #1 am: 11. März 2012, 20:11:07 »
Hm... ich bin mir grad nicht sicher ob das so hinhaut was ich da geschrieben habe??

Wenn ich nämlich in der Situtation über die Visu ein Bit setze damit INPUT.S2 betriggert wird und der Rollo also nochmals zugefahren wird (physikalisch bewegt sich jetzt natürlich nichts) dann schlter der INPUT seine Ausgänge um QU=FALSE und QD=TRUE.

Dann warte ich nochmals eine Minute ab bis wieder alle in StandBy/Auto sind und forciere über die Visu wieder einen Wert und siehe da es geht plötzlich auch wenn INPUT.QU und INPUT.QD beide TUR sind.

Was passiert hier? Verliert der Rollo seine Position oder sowas?

Für Hinweise bin ich dankbar!

Offline Fussel0804

  • Entwickler
  • *****
  • Beiträge: 274
    • Profil anzeigen
    • E-Mail
Re: BLIND_INPUT BLIND_NIGHT Problem
« Antwort #2 am: 12. März 2012, 12:17:57 »
Hi!

An dieser Konstellation bin ich auch grad dran.

Nur leider habe ich mangels zeit zum Testen das NIGHT Modul rausgenommen.
Ich schau mal, ob ich das diese woche nochmals ausgiebig testen kann.

Melde mich dann wieder.

Gruß Stefan

mike_roh_soft

  • Gast
Re: BLIND_INPUT BLIND_NIGHT Problem
« Antwort #3 am: 05. April 2012, 20:19:32 »
Schon was Neues Stefan?
Muss das nun mal in Angrif nehmen über Ostern!

Homesps

  • Gast
Re: BLIND_INPUT BLIND_NIGHT Problem
« Antwort #4 am: 06. April 2012, 10:21:39 »
Laut Beschreibung des BLIND_INPUT ist dein beobachtetes Verhalten so gewollt.

Mit IN=TRUE geht der Baustein in den Automatikmodus (QU und QD sind TRUE) und zusätzlich wird der Wert von PO und AO auf PI und AI gesetzt. Im Automatikmodus kann allerdings ein Baustein, der im Ablauf danach kommt, den Wert von PO und AO ändern. Wie BLIND_NIGHT.

Was willst du denn machen? Wenn es darum geht, auch wenn BLIND_NIGHT aktiv ist, eine Position automatisch ansteuern zu können, könntest du auch BLIND_SCENE nach BLIND_NIGHT einbauen und dann dort eine Position (Szene) anfahren.

Ist dein MANUAL_TIMEOUT wirklich bei 60 Sekunden? Der Default ist 60 _Minuten_.

Gruß
Klaus

mike_roh_soft

  • Gast
Re: BLIND_INPUT BLIND_NIGHT Problem
« Antwort #5 am: 06. April 2012, 11:48:28 »
Hi,

ja mein Manual_timeout habe ich zum Testen auf 60Sek geändert.

Ich habe gleich zwei Probleme!

Mein erstes Problem ist, dass der Rollladen nicht reagiert wenn er im AutoMode ist und ich mit einem Impulse den IN triggere um damit die Forcierten Werte anzufahren. Muss der IN länger als ein Impuls anstehen. Ich werde aus der Beschreibung nicht ganz schlau - da steht man kann den IN pulsen um die Werte zu übernehmen. Da steht aber auch, dass man den IN auf TRUE setzen kann. Was bringt ein dauerhaft gesetzter IN?

Mein zweites Problem ist, dass morgens der Rollladen hochfährt und dann nicht auf das Komando vom SHADE reagiert, der eine Beschattung durchführt.
Der Rollladen bleibt statt dessen einfach oben. Der SHADE steuert aber richtig auf shade_pos!
Wenn ich den Hardwaretaster drücke dann fährt der Rollladen nach 60Sek. in die Shade_pos! Das verwundert mich.
Irgendwas hängt doch hier!






Homesps

  • Gast
Re: BLIND_INPUT BLIND_NIGHT Problem
« Antwort #6 am: 06. April 2012, 13:38:28 »
Hallo Mike,

schau dir mal den S_IN vom BLIND_CONTROL an. Der zeigt dir, welches Modul gerade die Kontrolle hat. Das ist die wichtigste Information um zu verstehen, was vor sich geht.

11x ist SECURITY
13x ist INPUT
14x ist NIGHT
15x ist SHADE

Grundsätzlich ist der manuelle Betrieb vom Automatikmodus zu unterscheiden.

Im manuellen Betrieb fährt der BLIND_CONTROL so, wie es UP und DOWN vorgeben, dh bei TRUE an UP hoch und bei TRUE an DOWN runter.
Im automatischen Betrieb (UP und DOWN beide TRUE) fährt der BLIND_CONTROL die Position an, die ihm an PI und AI vorgegeben werden.

Der Wert von PI und AI wird immer vom letzten aktiven Modul in der Kette festgelegt.

Beispiel:

Module INPUT->SHADE->NIGHT->SECURITY->CONTROL

Automatikmodus ist aktiv, alle Module sind deaktiv.

POS und ANG am Input kommen jetzt als Feedback vom CONTROL, INPUT gibt diese Werte auch an PO und AO aus. Alle Module reichen diese Werte weiter durch, da alle inaktiv sind. Am Eingang von CONTROL liegt somit auch dieser Wert an. Nichts bewegt sich.
Jetzt wird der SHADE aktiv, dh der Wert an PI und AI von SHADE wird nicht mehr durchgereicht, sondern SHADE legt jetzt fest, welcher Wert an PO und AO anliegt. Die Folge, CONTROL fährt die Position an, die SHADE ausgibt. Über die Feedbackschleife liegt dieser Wert nun auch am POS, ANG, PO und AO von Input und in der Folge auch an PI und AI von SHADE an. Schaltet sich SHADE ab, bleiben diese Werte also stehen und CONTROL fährt nicht.
Ok, SHADE ist aktiv und hat eine bestimmte Position angefahren, nun wird NIGHT aktiv. PO und AO von NIGHT werden nun von NIGHT festgelegt, CONTROL fährt diese Werte an. SHADE ist immer noch aktiv, PO und AO von SHADE liegen auch an PI und AI von NIGHT an. Das spielt aber keine Rolle, weil NIGHT diese Werte nicht durchreicht.
Schaltet sich NIGHT nun ab, liegen an CONTROL wieder die Werte von SHADE an und CONTROL fährt diese Position wieder an.

Was macht nun der IN von INPUT? Der schaltet den Automatikmodus ein und legt PI und AI von INPUT auf PO und AO. Nur wenn kein anderes Modul aktiv ist, liegen diese Werte dann auch an PI und AI von CONTROL und werden angefahren. Wenn ein anderes Modul aktiv ist, werden diese Werte nicht zu CONTROL durchgereicht.

Kannst du beschreiben, was du eigentlich erreichen willst?

Bei mir war das Problem, dass normalerweise nach Deaktivierung eines Moduls die aktuelle Position stehen bleibt. Bei NIGHT möchte ich das auch so, da wir keine Vorhänge im Haus haben und ich das Hochfahren gern ähhh "situationsabhängig" steuern möchte...
Bei SHADE möchte ich aber, dass nach der Deaktivierung die Raffstore wieder reinfahren.  Dazu habe ich meinen SHADE etwas erweitert

Gruß
Klaus

Noch ein Nachtrag zur Info. BLIND_SECURITY funktioniert ein wenig anders. Bei Alarm werden hier nicht PI und AI gesetzt, da man diese ja mit dem manuellen Betrieb übersteuern könnte. Stattdessen wird UP und DOWN gesetzt. Wenn SECURITY das letzte Modul von CONTROL ist, was es ein muss, kann man so SECURITY nicht übersteuern.
« Letzte Änderung: 06. April 2012, 13:41:54 von Homesps »

mike_roh_soft

  • Gast
Re: BLIND_INPUT BLIND_NIGHT Problem
« Antwort #7 am: 06. April 2012, 13:57:50 »
Also das Prinzip habe ich schon verstanden... Ich muss das mal genau beobachten wenn es wieder nicht "vörwärts" geht.

Erreichen möchte ich mit meinen Konstellation:
BLIND_INPUT -> SHADE_S -> NIGHT -> CRL_S

INPUT für die Hardwaretaster.
SHADE für die Beschattung abhängig von Sonnenstand.
NIGHT ist für Abends runter und morgens hoch zuständig.
CRL_S steuert den Motor.

Wie kann es also sein, dass der Rollo vom NIGHT morgens hochgefahren wird und dann vom SHADE nicht mehr bewegt werden kann.
Das würde doch bedeuten, dass der NIGHT immer noch aktiv ist weil dieser ja in meiner Konstellation nach den SHADE kommt!

Das Hochfahren am Morgen funktioniert ja mit dem BLIND_NIGHT aus der OSCAT-Lib überhaupt nicht. Das habe ich selbst erweitert.
Siehe dazu diesen Beitrag:
http://www.oscat.de/community/index.php/topic,1208.15.html

Habe ich dabei einen Fehler gemacht?

EDIT:
Ich habe gerade das Problem simuliert und festgestellt das wir ich vermutet habe der BLIND_NIGHT im Status 142 hängen bleibt nachdem er morgens den Rollo hochfährt. Das gleich muss aber auch für nachts runter fahren gelten also 141. Das würde auch das Problem erklären das ich den Rollo mit INPUT.IN nach einer Fahrt am Morgen oder Abend nicht aus der Visu forcen kann!

Ich werde mal sehen wie ich den BLIND_NIGHT umschreiben kann damit er aus den Stati 141/142 wieder raus kommt!
« Letzte Änderung: 06. April 2012, 14:10:30 von mike_roh_soft »

mike_roh_soft

  • Gast
Re: BLIND_INPUT BLIND_NIGHT Problem
« Antwort #8 am: 06. April 2012, 14:31:32 »
EDIT nonsense...
« Letzte Änderung: 09. April 2012, 12:39:41 von mike_roh_soft »

mike_roh_soft

  • Gast
Re: BLIND_INPUT BLIND_NIGHT Problem
« Antwort #9 am: 09. April 2012, 12:39:47 »
Ein BLIND_SHADE kann meiner Meinung nach NICHT vor einem BLIND_NIGHT funktionieren!

Der BLIND_NIGHT hat Priorität solange keiner einen Hardwaretaster betätigt! Also kann der SHADE oder sonst ein Modul nichts bewirken.

Man könnte den SHADE nach dem NIGHT platzieren.
Was aber wenn der SHADE aktiv wird während der NIGHT morgens noch hochfährt - dann ist die PI am SHADE kleiner als die POS_SHADE und damit das Minimum im SHADE = PI und der Rollo bleibt stehen.

Ich habe meinen NIGHT geändert mit einer festen internen Zeit von 2Min, die ablaufen muss bis NIGHT oder DAY zurückgesetzt werden können und zwar genau vom Status 151 des SHADE. Es ist keine sehr schöne Lösung.
Wenn es funktioniert schreibe ich den Code hier rein...

EDIT: Den BLIND_NIGHT habe ich in o.g. Beitrag aktualisiert.
« Letzte Änderung: 11. April 2012, 17:18:50 von mike_roh_soft »