# Mehrere Tasks oder alles im PLC_PRG



## dast (11 Februar 2018)

Mal eine Frage zur Umsetzung:

Steuere momentan alles mögliche in unserem Haus, wie Licht, Raffstores, usw. auf einer WAGO 750-881.
Aktuell läuft dabei alles im PLC_PRG, also alles in einem "freilaufenden" Task.

Jetzt habe ich z.B. auch eine Implementierung für das Soleregister, die temperaturabhängig die Sole der
WP durch das Register der KWL pump (zur Kühlung der Zuluft im Sommer bzw. Vorwärmung im Winter).
Aktuell läuft dieses nun auch im PLC_PRG, hat jetzt aber natürlich keine "echtzeitanforderung".
Ob die Pumpe jetzt ein paar Sekunden früher oder später zuschaltet wäre jetzt egal.

Meine Frage nun: Wäre es sinnvoll, dies separat in einen eigenen Task auszulagern?
Ein weiterer Kandidat wäre z.B. die Dachrinnenheizung, die auch in einen eigenen Task auswandern könnte.

Danke und Grüße,
Daniel.


----------



## GLT (11 Februar 2018)

Solange Du keine Visu nutzt (die "verträgt" sich nicht mit freilaufendem Task) und/oder sonst keine speziellen Anforderungen hast, spricht nichts dagegen, das im PLC_PRG einzubinden.


----------



## dast (11 Februar 2018)

GLT schrieb:


> Solange Du keine Visu nutzt (die "verträgt" sich nicht mit freilaufendem Task) und/oder sonst keine speziellen Anforderungen hast, spricht nichts dagegen, das im PLC_PRG einzubinden.



Ok, warum "verträgt" sich nicht mit freilaufendem Task?

PS: Visu und etwas weitere Logik soll später noch per IP-Symcon kommen. Datenaustausch per Modbus ...


----------



## egro (12 Februar 2018)

Die Visu wird in den Pausen zwischen den Tasks bearbeitet.
Bei einem freilaufenden Task, gibt es keine Pausen...


----------



## Passion4Automation (13 Februar 2018)

Wenn es keine Probleme mit den Zyklus Zeiten gibt, würde ich es in einer Task lassen. Falls Dali oder KNX Karte an der SPS, empfiehlt es sich diese Bereiche in einen seperaten Task zulegen. 
Ich hab z. B. alle Bausteine die mit der Dali Karte kommunizieren in nem seperaten Task. Die Logik z.b Tastereingänge, Zeiten usw. im Haupttask. Ich verarbeite also alle Eingänge und Ausgänge in einer Task, die Verknüpfung zum Dali PRG  schaffe ich dann über globale Variablen. Bin damit bis jetzt gut gefahren. 

So bleibt es strukturiert. 

Viele Grüße


----------



## Player-Ben (13 Februar 2018)

goifalracer schrieb:


> Falls Dali oder KNX Karte an der SPS, empfiehlt es sich diese Bereiche in einen seperaten Task zulegen.



Was nimmst du den als Intervall für den Task. Gibt es keine großen Verzögerungen zwischen drücken des Tasters und Licht an?



dast schrieb:


> ...Logik soll später noch per IP-Symcon kommen. Datenaustausch per Modbus ...



Klappt bei mir auch mit einem freilaufenden Task.


----------



## Passion4Automation (13 Februar 2018)

Das Intervall weiß ich gar nicht, müsst ich nachschauen. Aber das ist sowieso Programm spezifisch. Man muss halt schauen das alle Tasks fertig werden.

Verzögerungen gibt es schon kurze.

Ich hab alles aufgeteilt weil ich im Dali Task Probleme hatte eine Szene per Doppelklick aufzurufen, mit Bausteinen aus der Oscat. Jetzt habe ich alle Taster im selben Task unabhängig von der Taskzeit im Dali PRG. Die Befehle schiebe ich über globale Variablen rüber. Ob das die super Programmstrategie ist weiß ich nicht.


----------



## dast (13 Februar 2018)

egro schrieb:


> Die Visu wird in den Pausen zwischen den Tasks bearbeitet.
> Bei einem freilaufenden Task, gibt es keine Pausen...



Komisch, ich hab nämlich am Handy eine einfache (provisorische) Wago/Codesys Visu am laufen und das scheint zu funktionieren  ...
Hab nur ab und zu mal festgestellt, dass der ein oder andere "Taster" für die Raffstores in der Visu "hängen" bleibt und diese sich dann nicht mehr über die physikalischen Taster bedienen lassen.


----------



## Thruser (14 Februar 2018)

Hallo,


egro schrieb:


> Bei einem freilaufenden Task, gibt es keine Pausen...



laut Handbuch und Hilfe gibt es eine Pause von mindestens 1ms, ansonsten der halben Zykluszeit, bei freilaufendem Task.

Wie sich das auf die Reaktionsfähigkeit der Visu auswirkt kann ich aber nicht sagen.

Gruß


----------



## weißnix_ (14 Februar 2018)

Alles was mit Regelung zu tun hat würde ich nicht unbedingt freilaufend bearbeiten lassen sondern im festen Zeitraster.
Mehrere Tasks sind oft garnicht notwendig:
Einfach eine zyklische Task programmieren, die im schnellsten benötigten Zeitraster läuft. Unterprogramme (sehr sinnvoll zur Strukturierung verwendbar) dann in Main mit einem Zyklenzähler aufrufen alle x Main-Durchläufe.
So bekommt man eine auch zeitlich gut strukturierte Programmierung.


----------



## Player-Ben (14 Februar 2018)

weißnix_ schrieb:


> Alles was mit Regelung zu tun hat würde ich nicht unbedingt freilaufend bearbeiten lassen sondern im festen Zeitraster.


Warum würdest Du dieses so machen?
Wenn man als Beispiel eine Raumtemperaturreglung nimmt, ist es nicht egal ob das im freilaufenden Task alle paar ms überprüft wird oder im zyklischen Task alle paar Sekunden?

Es könnte auch sein, dass ich den Mehrwert von zyklischen Task noch nicht erkannt habe.



weißnix_ schrieb:


> ...dann in Main mit einem Zyklenzähler aufrufen alle x Main-Durchläufe.


Muss man das Programmieren im Variablen und co oder gibt es in Codesys dafür eine direkte Einstellung in den Unterprogrammen wo man die Task konfiguriert?


----------



## weißnix_ (14 Februar 2018)

Player-Ben schrieb:


> Warum würdest Du dieses so machen?
> Wenn man als Beispiel eine Raumtemperaturreglung nimmt, ist es nicht egal ob das im freilaufenden Task alle paar ms überprüft wird oder im zyklischen Task alle paar Sekunden?
> 
> Es könnte auch sein, dass ich den Mehrwert von zyklischen Task noch nicht erkannt habe.



Digitale Regelungen leben idR. vom äquidistanten Aufruf des Regelbausteins. Einige fertige Regler beziehen die zeitliche Distanz direkt in ihre Berechnungen ein. Aber eben nicht alle. Un ein selbstprogrammierter Regler wird halt etwas einfacher, wenn man ihn im fixen Zeitregime bearbeitet.
Freilaufend kenn ich halt von Siemens als Standard und habe anfänglich bei meinem Schwenk zu Beckhoff etwas Zeit gebraucht, die Vorteile zu erkennen.



> Muss man das Programmieren im Variablen und co oder gibt es in Codesys dafür eine direkte Einstellung in den Unterprogrammen wo man die Task konfiguriert?


Wie es bei Codesys genau gemacht wird - kA. Bei Twincat2 mach ich das in den jeweiligen Taskeigenschaften.

Nachtrag:
Freilaufend treibt nach meiner Auffassung nur die Systemlast scheinbar nach oben. Dabei ist es völlig unnötig z.B. Taster für das Licht alle 1...2ms abzufragen. Das funktioniert im 20ms-Zyklus genausogut. Dadurch würden Ressourcen frei um schnellere Vorgänge oder intensivere Berechnungen durchzuführen. Das merkt man aber erst so richtig, wenn man mal an die Grenzen des Controllers kommt.


----------

