Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
kann man pauschal nicht beantworten. Der passende Taskzyklus hängt davon ab, welche Vorgänge in der Task laufen. Einen Temperaturregler z.B. für großvolumige Eisenteile (Pressformen o.ä.) kann man getrost mit 200 ms oder größer laufen lassen. Für eine Servoachse wäre ein solcher
Taskzyklus aber wohl eher ungeeignet.
Gruß Rolf
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rolf hat absolut recht es hängt davon ab was dein Programm Tun soll. 100ms können eine verdammt lange Zeit sein. Kleines Beispiel: Nimm einen Taster (Eingang) und eine Lampe (Ausgang) Weise in deinem Prog. einfach dem Ausgang den Eingang zu. Und jetzt spiele mal mit deinen Taskzeiten meine Erfahrung Verzögerungszeiten > 30ms sind sichtbar.
Bei 100ms klingeln mir die Ohren in der zeit kann man ziemlich viel Tun. Wenn es also da Probleme gibt sollte man sich mal Gedanken um einen zyklusoptimierten Programmierstil machen (Schleifen? Für den aktuellen Zustand unnötige Bausteinaufrufe, ...) und nicht einfach mal ein paar Tasks anlegen damit man sich neue Probleme einhandelt. Gravieren hat die Richtigen Stichworte geliefert wenn man Tasks braucht.
Dateien, Große Berechnungen, Positionierungen, Regelungen
Datei und Netzwerkzugriffe sind blockierende Zugriffe d.h die halten euch euere Task solange an wie sie eben brauchen um z.B.Dateien zu lesen. Desshalb sollte sowas in eine eigene Task mit niedrigerer Priorität (größere Zahl) als euer SPS Programm
Regelungen und Positionierungen brauchen einen festen Zyklus desshalb eigene Task.
Gruß ins Netz
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ich habe in eine bestehende Hausautomation mit einer 750-841 SPS eine serielle RS485 Klemme eingebaut. Diese ist als 5 Byte Klemme konfiguriert. Meine Wetterstation sendet nun wohl Daten an die Klemme, die auch zu Beginn nach einem Download auf den Controller, korrekt verarbeitet werden. Nach einer Zeit allerdings, werden die Daten nicht mehr übertragen.
Da ich bis jetzt keinen Task konfiguriert habe, wird das Programm wohl freilaufend abgearbeitet. Wie kann ich den bestehenden Task eine feste Zeit geben (Vorschlag ms) und wie erzeuge ich einen weiteren, in dem ich den Wetterstation Baustein (Wago) einbinden kann? Wie werden die Daten zwischen den Tasks ausgetauscht oder läuft das wie gewohnt durch eine globale Variable?
Sorry, aber die einfachen Dinge waren kein Problem. Aber sobald es ins Details wie Dali und RS485 geht, wirds etwas happig.
Besten Dank
Gruß
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
will noch mal auf die Antwort von Uwe zurückkommen. Ich weiss, ein bisschen spät, aber die Arbeit hat mich in den letzten Tagen heftig vom Forum abgehalten
Wir haben bei uns ziemlich komplexe Anwendungen und verteilen diese auf mehrere Tasks, damit die zeitkritischen Aufgaben wirklich die CPU-Zeit haben die sie brauchen und die weniger wichtigen Dinge den Prozessor nicht unnötig belasten.
Bei uns kommunizieren die Tasks über globale Variable miteinander. Die Koppelvariablen sind reine Standardtypen (BOOL, INT, REAL etc), keine Strukturen. Damit gibt es keine Probleme. Man sollte nur darauf achten, dass die Koppelvariablen nur einen einzigen Sender haben; wenn mehrere Tasks schreibend darauf zugreifen, hat man bei der Fehlersuche keine Chance ...
Muss man Strukturen austauschen, sind unbedingt Vorkehrungen zu treffen, dass die Daten konsistent sind. Schließlich kann die Task, die die Daten sendet, gerade während des Schreibens in die Koppelstruktur durch eine höher priorisierte Task unterbrochen werden, dann steht dort nur ein Teil der aktuellen Daten. Am einfachsten deklariert man in der Struktur eine zusätzliche Variable z.B. , setzt diese zurück beim Beginn des Schreibens und setzt sie wieder, wenn das Schreiben der Daten beendet ist. Nun weiss jeder, der in die Struktur hineinschaut, ob alles aktuell ist oder nicht.
Dieser Schutzmechanismus wird normalerweise durch Semaphoren hergestellt, aber die werden meines Wissens nicht von jeder SPS unterstützt. Wer also plattformneutral programmiert oder eine Seifendosen-SPS verwendet, kann es auch wie beschrieben machen.
Gruss Rolf
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
welche Werte sind sinnvoll bei der Einstellung der Taskzeiten ?
Abhängig von der Programmgrösse, ... ?
Ich hab im Moment 100 ms und es kommt manchmal vor dass der Watchdog zuschlägt. Ist es sinn voll die Zeiten höher zu stellen ?
Grüsse,
Dieter
Hallo,
kann man pauschal nicht beantworten. Der passende Taskzyklus hängt davon ab, welche Vorgänge in der Task laufen. Einen Temperaturregler z.B. für großvolumige Eisenteile (Pressformen o.ä.) kann man getrost mit 200 ms oder größer laufen lassen. Für eine Servoachse wäre ein solcher
Taskzyklus aber wohl eher ungeeignet.
Gruß Rolf
Hi
100 ms Zykluszeiten sollten reichen.
Hast du komplexe "Berechnungen" oder Schleifen ?
B.z.w. schreibst du grosse Datenmengen in eine "Datei" ?
Falls Ja, Versuche diese auf mehere Tasks zu verteilen.
Wichtig, manche Funktionen sind NICHT Multitred-fähig.
Hi Leute,
eigentlich wollte ich mich da raushalten aber:
Rolf hat absolut recht es hängt davon ab was dein Programm Tun soll. 100ms können eine verdammt lange Zeit sein. Kleines Beispiel: Nimm einen Taster (Eingang) und eine Lampe (Ausgang) Weise in deinem Prog. einfach dem Ausgang den Eingang zu. Und jetzt spiele mal mit deinen Taskzeiten meine Erfahrung Verzögerungszeiten > 30ms sind sichtbar.
Bei 100ms klingeln mir die Ohren in der zeit kann man ziemlich viel Tun. Wenn es also da Probleme gibt sollte man sich mal Gedanken um einen zyklusoptimierten Programmierstil machen (Schleifen? Für den aktuellen Zustand unnötige Bausteinaufrufe, ...) und nicht einfach mal ein paar Tasks anlegen damit man sich neue Probleme einhandelt. Gravieren hat die Richtigen Stichworte geliefert wenn man Tasks braucht.
Dateien, Große Berechnungen, Positionierungen, Regelungen
Datei und Netzwerkzugriffe sind blockierende Zugriffe d.h die halten euch euere Task solange an wie sie eben brauchen um z.B.Dateien zu lesen. Desshalb sollte sowas in eine eigene Task mit niedrigerer Priorität (größere Zahl) als euer SPS Programm
Regelungen und Positionierungen brauchen einen festen Zyklus desshalb eigene Task.
Gruß ins Netz
Ralph
Hallo Leute,
dann werfe ich auch noch schnell ein paar Bemerkungen zur Verwendung von Tasks ein.
Ich denke das häufig ziemlich schnell auf das Tasksystem zugriffen wird ohne sich
wirklich der möglichen Konsequenzen bewusst zu sein.
Meine Erfahrung sagt mir das häufig blauäugig gesagt wird
"Dann verteil dein Programm doch auf unterschiedliche Tasks"
Aber wenn ich unterschiedliche Tasks benutze, dann müssen diese Tasks in der Regel
auch miteinander Daten austauschen.
Mal ehrlich, wer macht sich da Gedanken über Datenkonsistenz und Semaphore ?
Ich fürchte das dieses Thema leider häufig vernachlässigt wird was dann zu sporadischem
schwer nachvollziehbarem Fehlverhalten des Programms führen kann.
Was ist eure Meinung und wie regelt ihr eure Tasksynchronisation ?
Uwe
Hallo zusammen,
ich habe in eine bestehende Hausautomation mit einer 750-841 SPS eine serielle RS485 Klemme eingebaut. Diese ist als 5 Byte Klemme konfiguriert. Meine Wetterstation sendet nun wohl Daten an die Klemme, die auch zu Beginn nach einem Download auf den Controller, korrekt verarbeitet werden. Nach einer Zeit allerdings, werden die Daten nicht mehr übertragen.
Da ich bis jetzt keinen Task konfiguriert habe, wird das Programm wohl freilaufend abgearbeitet. Wie kann ich den bestehenden Task eine feste Zeit geben (Vorschlag ms) und wie erzeuge ich einen weiteren, in dem ich den Wetterstation Baustein (Wago) einbinden kann? Wie werden die Daten zwischen den Tasks ausgetauscht oder läuft das wie gewohnt durch eine globale Variable?
Sorry, aber die einfachen Dinge waren kein Problem. Aber sobald es ins Details wie Dali und RS485 geht, wirds etwas happig.
Besten Dank
Gruß
Michael
Hallo,
will noch mal auf die Antwort von Uwe zurückkommen. Ich weiss, ein bisschen spät, aber die Arbeit hat mich in den letzten Tagen heftig vom Forum abgehalten
Wir haben bei uns ziemlich komplexe Anwendungen und verteilen diese auf mehrere Tasks, damit die zeitkritischen Aufgaben wirklich die CPU-Zeit haben die sie brauchen und die weniger wichtigen Dinge den Prozessor nicht unnötig belasten.
Bei uns kommunizieren die Tasks über globale Variable miteinander. Die Koppelvariablen sind reine Standardtypen (BOOL, INT, REAL etc), keine Strukturen. Damit gibt es keine Probleme. Man sollte nur darauf achten, dass die Koppelvariablen nur einen einzigen Sender haben; wenn mehrere Tasks schreibend darauf zugreifen, hat man bei der Fehlersuche keine Chance ...
Muss man Strukturen austauschen, sind unbedingt Vorkehrungen zu treffen, dass die Daten konsistent sind. Schließlich kann die Task, die die Daten sendet, gerade während des Schreibens in die Koppelstruktur durch eine höher priorisierte Task unterbrochen werden, dann steht dort nur ein Teil der aktuellen Daten. Am einfachsten deklariert man in der Struktur eine zusätzliche Variable z.B. , setzt diese zurück beim Beginn des Schreibens und setzt sie wieder, wenn das Schreiben der Daten beendet ist. Nun weiss jeder, der in die Struktur hineinschaut, ob alles aktuell ist oder nicht.
Dieser Schutzmechanismus wird normalerweise durch Semaphoren hergestellt, aber die werden meines Wissens nicht von jeder SPS unterstützt. Wer also plattformneutral programmiert oder eine Seifendosen-SPS verwendet, kann es auch wie beschrieben machen.
Gruss Rolf