Übliche Struktur der Tasks?

marsmännchen

Level-2
Beiträge
110
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo mal wieder.
Als Anfänger frage ich mich immer wieder mal wie das mit der Strukturierung der Taskaufrufe üblich ist.
Anhand von Beispielen kann ich mich leider schlecht orientieren.
Bei mir läuft eine PFC200 im Haus mit Dali für das Licht, Rollläden, alle Taster sind auf Eingänge geführt.
Die Visu ist von IoBroker und wird per Modbus an die PFC übertragen.
Durch den Wechsel von e!Cockpit zu Codesys baue ich das Programm neu auf und wollte eure Meinung wissen ob z.B.: so viele Aufrufe in einem Task problematisch sein können?
strukt1.PNG
Für mich als Laie wäre es eine der übersichtlichsten Versionen alles per Raum aufzuteilen.
Es kommen vermutlich noch weitere Tasks mit diversen aufrufen dazu (Modbusübertragung in eigenen Task, Poolregelung in eigenen Task,...?)
In e!Cockpit war es z.b: nur Obergeschoss und Untergeschoss. Was aber dann in der CFC zu recht viel Scrollerei führt.

Gibt es da eine generelle Richtlinie? Ich meine nicht das ich da wirklich ein Zyklusproblem oder ähnliches auslöse bei so einem "Spielzeugprogramm" aber es sollte schon nach gängigen Regeln aussehen.

MfG
Patrick
 
Eventuell kannst Du darüber nachdenken, für die Kommunikation ne eigene Task aufzumachen.
Der Rest wird innerhalb eines Programms als FB oder PRG strukuriert.

Nein, keine Regel, aber warum den Controller zusättlich mit dem Taskmanagement belasten?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Tasks zur Strukturierung zu verwenden, ist keine gute Idee.
Für einen Task muss es einen vernünftigen technischen Grund geben.
Ich hab hier eine ähnliche Konfiguration wie du, also auch Wago und ioBroker.
Dafür habe ich 2 Tasks. Einmal SPS und einmal Wago-Visu.
Das sind im Prinzip die automatisch erzeugten Tasks.
Falls du für deine Poolheizung irgendwelche PI-Regler verwendest, dann kann es sinnvoll sein, diese Regler in einen Task mit festem zeitlichen Raster zu legen.
Zur Strukturierung kann man PRGs verwenden. Auch da muss man nicht übertreiben.
Primär sollte - meiner Meinung nach - die Strukturierung in FBs erfolgen.
 
Ok. Nur damit ich das nicht falsch verstehe. Auf meinem Screenshot sieht man einen task. In dem task sind etliche Programme?programmaufrufe?. Diese Vielzahl sollte aber kein Problem sein? Oder sollte das auch so wenig wie möglich gehalten sein?
 
Ok. Nur damit ich das nicht falsch verstehe. Auf meinem Screenshot sieht man einen task. In dem task sind etliche Programme?programmaufrufe?. Diese Vielzahl sollte aber kein Problem sein? Oder sollte das auch so wenig wie möglich gehalten sein?
PRG kannst du als Mittel zur Strukturierung verwenden. Hier hat jeder seine eigenen Vorlieben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Auch Regler kann man in dem einen Task abwickeln, wenn man den auf festen Zyklus einstellt. Abweichende (längere) Aufrufzyklen kann man als bedingte Aufrufe in vielfachen der Taskzeit realisieren.
 
Zuletzt bearbeitet von einem Moderator:
Auch Regler kann man in dem eigenen Task abwickeln, wenn man den auf festen Zyklus einstellt. Abweichende (längere) Aufrufzyklen kann man als bedingte Aufrufe in vielfachen der Taskzeit realisieren.
Letztlich sieht man es schön am Unterschied Siemens <-> Codesys.
Bei Siemens hast du im Prinzip keine Taskkonfiguration.
Du hast zyklische und ereignisabhängige "Tasks" in Form von entsprechenden OBs.
Auch damit kann man eigentlich alle Aufgaben lösen.
Codesys ist hier zwar deutlich flexibler, aber das bringt auch Risiken .
Gerade für Quereinsteiger, die von der IT-Seite kommen.
Ein SPS-Task ist nun mal nicht das selbe wie ein Task auf dem PC.
 
Ok, danke. Aber nochmal zu meinem Screenshot. Angenommen ich habe so viel CFC Programme in einem task (bei mir jetzt Light, oder nur im automatisch erstellten) . Ist das normal? Schwachsinn? Ungünstig?
 
Angenommen ich habe so viel CFC Programme in einem task ... . Ist das normal? Schwachsinn? Ungünstig?
"Viel" ergibt sich ja meistens aus der Aufgabenstellung bzw. aus den umfangreichen TeilAufgaben, die die PLC schnell, d.h. mit kurzen ReaktionsZeiten und parallel erledigen soll.

"Viel" kann aber auch daraus resultieren, dass die gewählten LösungsWege zu kompliziert ausgeknobelt sind und unnötig umständliche und umfangreiche Rechnereien erfordern.
Letzteres kann sich durchaus zur Normalität entwickeln, wenn man beim Erreichen einer scheinbar(?) funktionierenden Lösung sich unverzüglich glücklich und zufrieden zurücklehnt.
Versuchen, den ZeitDruck zu entschärfen. Nicht verrückt machen lassen möglichst einen klaren Kopf bewahren.
Wer kennt das nicht, dass etwas nicht auf Anhieb ganz so läuft, wie man es geplant hatte.
Dann bitte nicht chaotisch an diversen Symptomen herumbasteln, sondern zurück zur Logik und nochmal untersuchen und gründlich überlegen, worin die eigentliche Ursache des Problems liegt und die dann beseitigen.
Kommt man zu der Erkenntnis, dass der eingeschlagene LösungsWeg unzweckmässig ist und hat man mittlerweile eine bessere Idee, dann dem neuen Weg eine Chance geben.
Zugegeben, es ist bitter, wenn man schon viel Zeit in den Sand gesetzt hat, aber die bereits vertane Zeit ist nicht automatisch ein Argument dafür, noch mehr Zeit in einen schlechten LösungsWeg zu investieren.
 
Zurück
Oben