oscat.lib > oscat.lib fuer Step 7

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

(1/2) > >>

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.

Navigation

[0] Themen-Index

[#] Nächste Seite