BLIND_SHADE Zykluszeit unabhängig umbauen? Siehe XBLIND.. Zykluszeit zu lange.

[HopeITworks]

Ich habe eine Frage: Hat vielleicht einer nen Tip wie ich die BLIND_SHADE Module Zykluszeitunabhängig umbauen kann? Mit den XBLIND Modulen wurde das scheinbar auch so gemacht, aber diese wurden ja leider nie offizielle released und auch nicht dokumentiert.

Ich habe nämlich das Problem das ich schon 50ms +xx Zykluszeit habe und das ist für eine genaue Lamellenverstelleung kaum brauchbar, da meine Lamellenwinkelverstellung gerade mal 1,1 Sekunden dauert. Jetzt muss ich SENS so stark erhöhen, dass die Abweichung / Tolleranzen viel zu hoch sind um den BLIND_SHADE effektiv nutzen zu können.

Daher würde ich den gerne irgendwie umbiegen damit der zykluszeitunabhängig arbeitet wie in den XBLIND Modulen :)


Vielleicht hat ja einer nen Tip für mich wo ich da ansetzen könnte :)

[Timmerx]

Kannst du den Blind Baustein nicht in einem OB circle Interrupt laufen lassen ?

[HopeITworks]

Hmm ich habe keine Ahnung ob das in dem Fall irgendwas bringen würde? Denn es muss ja noch der ganze Code durchlaufen werden weil die Arbeit ja BLIND_ACTUATOR ausführt schlussendlich?!

[fu_zhou]

Ich arbeite mit den Weckalarmen OB32-OB35. Den OB 32 lasse ich im 20 ms Zyklus laufen mit den Raffstores drin. Temperaturregelungen etc. lasse ich dann im OB35 mit 500 ms laufen. Das resultiert in einer Gesamtzykluszeit bei einer 315 PN von weit unter 20 ms. In der Anleitung steht, dass sich SENS auf die Zeit zur Bearbeitung des Bausteins (BLIND_SHADE) und nicht auf die Zykluszeit der CPU bezieht. Meine Raffstores brauchen auch ca. 1.1 Sekunde zum Lamellenverstellen. Demnach müsste die Zykluszeit bei SENS=5 < 0,43 ms sein. Für den Baustein stimmt das bestimmt bei einer Zykluszeit von 20ms, aber für die CPU halte ich das für nicht machbar. Im Moment fehlt mir sogar eine Idee, wie das überhaupt unabhängig von der Zykluszeit gehen soll. Wenn die Lamellen z.B. 1,0 s für die Verstellung brauchen und die Zykluszeit 50 ms ist heißt das ja, dass ein DO mindestens für 50 ms ausgegeben wird, was automatisch bedeutet, dass ich die Jalousie nur in 5% Schritten fahren kann und nicht in 1% Schritten. Demnach müsste sich die Zykluszeit in der Anleitung doch auf den CPU Zyklus und nicht auf die Bearbeitungszeit des Bausteins beziehen. Zur Veranschaulichung ein extremes Beispiel: Deine Zykluszeit geht auf 500 ms hoch, keine Chance das zu optimieren. Damit sitzt ein DO für minestens 500 ms, was zur Folge hat, dass bei einer Lamellenverstellung von 1 s diese immer zu mindestens 50% fährt. Ist jetzt die Auflösung kleiner als 50, erkennt BLIND_SHADE eine Abweichung von Soll zu Ist und setzt wieder den anderen Ausgang und dann nimmt das Unglück seinen Lauf - auf, zu, auf zu, weil der Sollwert z.B. 25% ist, die angefahrene Position aber durch die Zykluszeit nur 100%, 50% oder 0% sein kann.

[HopeITworks]

Danke für deine ausführliche Antwort @ fu_zhou  :)

Ja das meine ich eben auch, dass es nicht stimmen kann das sich die Zeit auf die Bearbeitung von BLIND_SHADE bezieht, sondern auf die Zykluszeit der CPU. Und dann hat man immer Probleme da die CPU Zykluszeit schnell mal 40ms hat. Dann muss ich den SENS Wert so hoch drehen das er erst bei hoher Abweichung überhaupt fährt, da es eben ansonsten zu deinen unkontrollieren AUF / AB Bewegungen kommt wie du schon geschrieben hast.

Nur wie kann ich das nun anpassen damit die Winkelpositionierung genauer abläuft? :-/

Ich habe mein Projekt komplett mit TIA V14 erstellt und ich kann leider die Zykluszeit durch z.B. optimierte Bausteine nicht weiter erhöhen. Das ist ein weiteres Problem vor dem ich stehe. Ich habe im Moment noch 28% Arbeitsspeicher frei. Schalte ich nun alle Bausteine auf optimierte Bausteine dann geht mir der Arbeitsspeicher der 1214C aus :( Ich habe bisher leider auch noch nicht rausgefunden, warum der Arbeitsspeicher Verbrauch von optimierten Bausteinen um so viel höher ist, als von nicht optimierten.

Die optimierten Bausteine würde mir allerdings 10ms CPU Zykluszeit sparen und wären daher natürlich schon sehr wichtig in dem Fall. Im Schnitt ist es so, dass z.B. beim Umschalten nicht optimiert auf optimiert meines BLIND_SHADE FB der den SCL Code enthält, ich sofort alleine für diesen schon 3-4% mehr Arbeitsspeicher benötige. Das macht man dann noch für die ganzen anderen Bausteine und schon ist der Arbeitsspeicher auf 100% belegt und nichts geht mehr.

[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]

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?

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 Auswählen Erweitern


VAR_INPUT
[...]
T_ACTUATOR_DELAY : TIME := T#100ms; (* delay between triggering output and slat movement *)
[...]
END_VAR
VAR
[...]
actuator_delay : TON;
[...]
END_VAR


Code:

Code Auswählen Erweitern


(* 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);


2. BLIND_CONTROL:
Deklarationsteil:

Code Auswählen Erweitern


VAR_INPUT
[...]
T_ACTUATOR_DELAY : TIME := t#100ms;
[...]
END_VAR

Code:

Code Auswählen Erweitern


[...]
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);
[...]


[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.