oscat.lib > oscat.lib fuer Step 7
BLIND_SHADE Zykluszeit unabhängig umbauen? Siehe XBLIND.. Zykluszeit zu lange.
mattsches:
Hallo,
das kritische Element in der ganzen Kette ist doch nur der BLIND_CONTROL. Denn der macht die Lamellenverstellung und muss schnell genug aufgerufen werden. Also müsste es doch reichen, wenn der in einem schnell aufgerufenem Zeit-OB (oder für die CODESYS-Anwender: in einer schnellen Task) aufgerufen wird. Die übrigen BLIND_x-Bausteine könnten in einem langsameren Zyklus bearbeitet werden. Programmiertechnisch ist das wegen der Kommunikation über die Tasks hinweg nicht besonders hübsch, schon klar. Aber technisch sollte es kein Problem sein.
Ich würde testweise mal den BLIND_CONTROL im "Gesamt-Jalousien-FB" (nehme an, ihr habt einen solchen) auskommentieren und für alle Jalousien Instanzen von BLIND_ACTUATOR in einem schnellen Zeit-OB bilden und aufrufen. Wertübergabe quick and dirty durch Zugriff auf die Instanzdaten der "Gesamt-Jalousien-FBs". Müsste gehen.
Ein Gedanke jedoch: Die Winkelverstellung über die Zeit ist nicht wahnsinnig präzise, völlig ungeachtet der Zykluszeit des BLIND_CONTROL. Hintergrund ist die Totzeit zwischen Schalten des Digitalausgangs (=TRIAC oder Relais) und dem Einsetzen der tatsächlichen Bewegung. Bei meinen Antrieben habe ich empirisch ca. 30 ms festgestellt und dies im BLIND_CONTROL und BLIND_ACTUATOR berücksichtigt. Damit läuft mir der Lamellenwinkel bei Nachführung über die Zeit hinweg nicht mehr weg.
HopeITworks:
Stimmt @ mattsches das ist ja der BLIND_CONTROL der zeitkritisch ist. Der bekommt ja die Werte übergeben und arbeitet das dann (schnell oder eben zu langsam ;D) ab.
Also keine Ahnung was du mit einem Gesamt Jalousie FB meinst. Ich hab hier bei mir immer von BLIND_SHADE z.b. nen FB wo der SCL Code drin ist und in einem weiteren FB rufe ich dann z.B. diesen SCL FB für alle Jalousien im Erdgeschoss auf. Das selbe nochmal mit dem Obergeschoss. Das habe ich mit allen BLIND Bausteinen so gemacht. Also auch BLIND_NIGHT_EG und BLIND_NIGHT_OG zum Beispiel.
Also müsste ich quasi den BLIND_CONTROL_EG und den BLIND_CONTROL_OG in einen Zeiten OB packen und den z.B. alle 10ms laufen lassen, ja?
Zu deinem letzten Punkt: Da hast du natürlich Recht das eine Positionierung auf Zeit immer schlecht ist und ganz besonders in unserem Fall wenn die Winkelverstellung so schnell abläuft. Nur es gibt ja keine Alternative dazu, zumindest fällt mir keine dazu ein :-/ Diese Totzeiten würden mich wohl auch interessieren wie du die eingebaut hast. Denn das wird mich ja auch betreffen, dass die Werte mit der Zeit dann in der Ausführung der Lamellen quasi davondriften und nicht mehr stimmen.
mattsches:
--- Zitat ---Also müsste ich quasi den BLIND_CONTROL_EG und den BLIND_CONTROL_OG in einen Zeiten OB packen und den z.B. alle 10ms laufen lassen, ja?
--- Ende Zitat ---
Genau so hatte ich das gemeint. Bei deiner Struktur hast du natürlich ideale Voraussetzungen für eine Trennung des BLIND_CONTROL von den anderen Bausteinen. Üblicherweise werden alle BLIND_*-Bausteine, die für den Jalousienbetrieb benötigt werden (bei mir _INPUT, _SHADE, _NIGHT, _SECURITY, _CONTROL) in einem FB instanziiert und dieser dann wiederum pro Jalousie einmal instanziiert. In der S7-Welt nennt sich das dann Multiinstanz (FB in FB). Wenn du das aber anders aufgebaut hast, bringt es dir in diesem Fall Vorteile.
Die Berücksichtigung der Totzeit ist einfach. Der Code stammt wieder von Codesys. Aber soweit ich es überblicke, gibt es auch in SCL einen Ausschaltverzögerer namens TON (SFB4?). Sollte also auch auf einer S7 tun.
1. BLIND_ACTUATOR (wird in BLIND_CONTROL aufgerufen):
Deklarationsteil:
--- Code: ---VAR_INPUT
[...]
T_ACTUATOR_DELAY : TIME := T#100ms; (* delay between triggering output and slat movement *)
[...]
END_VAR
VAR
[...]
actuator_delay : TON;
[...]
END_VAR
--- Ende Code ---
Code:
--- Code: ---(* make sure only one motor is active at a given time *)
lock(i1 := UP, I2 := DN, TL := T_lockout);
(* consider delay until slat is moving (mainly relevant for angle calculation) *)
actuator_delay(IN:= lock.Q1 OR lock.Q2, PT:= T_ACTUATOR_DELAY, Q=> , ET=> );
(* ramp up or down to simulate the angle position of the blind slats *)
angle(e := actuator_delay.Q, UP := lock.Q1, PT := T_Angle);
position(e := lock.Q1 AND angle.high OR lock.Q2 AND angle.low, up := lock.Q1, PT := T_UD);
--- Ende Code ---
2. BLIND_CONTROL:
Deklarationsteil:
--- Code: ---VAR_INPUT
[...]
T_ACTUATOR_DELAY : TIME := t#100ms;
[...]
END_VAR
--- Ende Code ---
Code:
--- Code: ---[...]
act(T_UD:=T_UD, T_ANGLE:=T_ANGLE, T_lockout := T_Lockout, T_ACTUATOR_DELAY := T_ACTUATOR_DELAY, MIN_ANGLE := MIN_ANGLE, MAX_ANGLE := MAX_ANGLE);
[...]
--- Ende Code ---
HopeITworks:
So endlich hätte ich mal etwas Zeit das umzubauen und zu testen aber ich hänge schon wieder fest ;-)
Kann ich die Daten von den im InterruptOB aufgerufenen Bausteinen auch in einen Instanzdatenbaustein anlegen? Irgenwie schaff ich es nicht dort mit Instanzdatenbausteinen zu arbeiten in diesem OB. Geht das vielleicht garnicht und somit nur im FB´s?
mattsches:
Nö. Einen FB kannst bzw. musst du immer mit Instanz-DB aufrufen, egal in welchem OB. Ausnahme ist ein Aufruf innerhalb eines FBs - dann kann der Instanz-DB des eingebetteten FB in den des aufrufenden FB integriert werden. Das nennt sich dann Multiinstanz.
Aber du hattest doch geschrieben, dass du alle BLIND_CONTROLs in einen FB pro Stockwerk gepackt hattest. Dann ruf den doch einfach im Zeit-OB auf. Sollte kein Problem sein.
Navigation
[0] Themen-Index
[*] Vorherige Sete
Zur normalen Ansicht wechseln