Mehrere Tasks oder alles im PLC_PRG

dast

Level-1
Beiträge
146
Reaktionspunkte
6
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 ...
 
Zuletzt bearbeitet:
Die Visu wird in den Pausen zwischen den Tasks bearbeitet.
Bei einem freilaufenden Task, gibt es keine Pausen...
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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?

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

Klappt bei mir auch mit einem freilaufenden Task.
 
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.
 
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 :confused: ...
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.
 
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.
 
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.

...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?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:
Zurück
Oben