Beckhoff: Zykluszeit <-> Basiszeit

[Itus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Zusammen

Betreffend Zykluszeit bei Beckhoff ist mir Einiges unklar.

Unsere Ansprechpartner hat mir mitgeteilt, dass man bei Beckhoff die Zykluszeit einstellen kann (50us bis 1ms) und diese sich nicht "einfach" so ergäbe. Falls dann die Applikation die eingestellte Zeit überschreite, kann eine Meldung generiert werden.
Für mich hiess dies: Wow, Zykluszeit ist kein Thema bei Beckhoff und ist auf max. 1ms begrenzt (wie die das sicherstellen war mir damals schon ein Rätsel).

Hab dann etwas recherchiert und bin auf folgenden Info gestossen:
http://infosys.beckhoff.com/index.p...emManager/Basics/TcSysMgr_ConfigRT_Intro2.htm

Unter Basiszeit steht dann, dass die Basiszeit die kürzest möglich Zykluszeit ist und dass die Zykluszeit ein vielfaches der Basiszeit sein kann -> dies widerspricht der obigen Aussage, meiner Meinung nach, massiv. D.h. ich kann somit auch 5ms oder 10ms etc. Zykluszeit erhalten.

Hat jemand Erfahrung damit? Wie kann ich das bei Beckhoff Produkten im Vorfeld überschlagsmässig prüfen oder rechnen?
Viele SPS Hersteller geben an, wieviel Zeit für eine Bit-Operation oder auch für 1000 AWL Befehle benötigt wird.

Ich erhoffe mir bei meiner Applikation maximale Zykluszeiten von 2 bis 3ms, da ich ansonsten noch weitere CPU's verbauen muss und eben dies wäre gut zu wissen im Vorfeld des Projektes.

Danke für die Beiträge.

Gruss Itus

 

[Oberchefe]

Also generell kann die Software periodische Tasks, d.h. alle x Millisekunden wird die Logik abgearbeitet. Die Abarbeitung der Logik muß natürlich schneller erfolgen als bei der Taskrate eingestellt ist. Wenn natürlich zu viel Logik in einem "schnellen" Task programmiert ist, funktioniert das Ganze nicht mehr, zaubern kann die Softwaren noch nicht. Andersrum: auch wenn eine Zeit kleiner 1ms eingestellt werden kann heißt das noch lange nicht daß die CPU auch große Programmteile in dieser Zeit schafft. Üblicherweise verwendet man mehrere Tasks mit unterschidelichen Zeiten, die zeitkritische Logik kommt in einen schnellen Task, die weniger zeitkritische in einen langsameren. Die Taskrate muß ein vielfaches der Basiszeit sein, bei einer Basiszeit von beispielsweise 250µS kann die Taskrate 250µS, 500µS, 750µS, 1ms..... sein.

Die periodischen Tasks verhalten sich natürlich etwas anders als kontinuierliche Tasks, wie sie bei anderen Steuerungen zu finden sind, hier wird einfach nach Abarbeitung der Logik der nächste Durchlauf gestartet, je mehr Logik, desto länger dauert es von einem Programmzyklus zum nächsten.

 

[PeterEF]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hat jemand Erfahrung damit? Wie kann ich das bei Beckhoff Produkten im Vorfeld überschlagsmässig prüfen oder rechnen?
Viele SPS Hersteller geben an, wieviel Zeit für eine Bit-Operation oder auch für 1000 AWL Befehle benötigt wird.

Ich hatte neulich die gleiche Fragen und habe in den FAQ zur CX1000 das gefunden:

What is the performance of the CX1000 ?
According to our measurements CX1000 is able to execute 1024 mixed PLC instruction in about 50 microseconds. These mixed instructions include integer and bit operation in various sizes as well as floating point instructions.
For the NC operation, one can count on a base time consumption of 200ìs and add about 100ìs per each axis. For example a system with a configured NC task and two axes, a total of 200µs + 2 x 100µs = 400µs is consumed for the operation of motion control.

More detailed information and comparison may be found at http://www.pc-control.net/ in the pc-control magazines 2/2002 (look for “Customized Automation” article) and 2/2003 (look for “TwinCAT performance” article). Please look into the “archive” section of the online site of the Beckhoff pc-control magazine.

Fazit: CX1000 nimmt 50µs für 1000 AWL-Befehle, diese Abschätzung schien auch ganz gut zu passen.

 

[Itus]

Hallo Oberchefe

Danke für deine Mitteilung.

Also generell kann die Software periodische Tasks, d.h. alle x Millisekunden wird die Logik abgearbeitet. Die Abarbeitung der Logik muß natürlich schneller erfolgen als bei der Taskrate eingestellt ist. Wenn natürlich zu viel Logik in einem "schnellen" Task programmiert ist, funktioniert das Ganze nicht mehr, zaubern kann die Softwaren noch nicht.

Ich erlaube es mir hier zu schreiben, dass dies wohl niemend von der SW erwartet hat.

Andersrum: auch wenn eine Zeit kleiner 1ms eingestellt werden kann heißt das noch lange nicht daß die CPU auch große Programmteile in dieser Zeit schafft. Üblicherweise verwendet man mehrere Tasks mit unterschidelichen Zeiten, die zeitkritische Logik kommt in einen schnellen Task, die weniger zeitkritische in einen langsameren. Die Taskrate muß ein vielfaches der Basiszeit sein, bei einer Basiszeit von beispielsweise 250µS kann die Taskrate 250µS, 500µS, 750µS, 1ms..... sein.

Die periodischen Tasks verhalten sich natürlich etwas anders als kontinuierliche Tasks, wie sie bei anderen Steuerungen zu finden sind, hier wird einfach nach Abarbeitung der Logik der nächste Durchlauf gestartet, je mehr Logik, desto länger dauert es von einem Programmzyklus zum nächsten.

Hm, dann muss ich vorgängig den ganzen Maschinenablauf aufsplitten und in verschiedene Tasks gliedern (wenn es mir Recht ist 4Stück bei TwinCAT) welche ich dann mit unterschiedlichen Zeiten laufen lasse -> gibt das nicht ein durcheinander, wenn die Tasks dann wiederum zusammen arbeiten müssen. (Task 1 wurde schon 3mal behandelt, Task 2 erst 1mal etc.......)

Gruss Itus

 

[drfunfrock]

Nee, du stellst einen Task ein, nach deinem Bedarf. Wenn dann ein Problem auf dem Bus auftritt, hast du verloren. Kurzum. Deine Taskzeit muss mindenstens die Zykluszeit auf dem Bus umfassen. Ich benutze Task für verschiedene Dinge: Z.B. einen Task für RS232-Klemmen, weil die einen Zyklus von 1ms benötigen. Einen anderen Task habe ich mit 20ms eingestellt, weil der dranhängende Profibus recht gemächlich ist. Entsprechend muss mach auch die Variablen in die entsprechenden Images schieben beim Konfigurieren!

Ich benutze nur zyklische Task mit einem festen Zeitraster, um sicherzustellen, dass die Sensoren auch abgetastet werden. Habe ich die Zykluszeit zu eng eingestellt, bekomme ich Fehlermeldungen en Masse. Bei kontinuierlichem Betrieb würde ich sicher einmal vergessen, die Zykluszeit bei Änderungen zu kontrollieren und dann entstehen seltsame Fehler, wenn Sensoren nicht ansprechen.

 

[Itus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo drfunfrock

Danke für deinen Beitrag. Langsam blicke ich überhaupt nicht mehr durch.....
War bis anhin der Meinung, dass ich mit den Beckhoff Maschinen (CPU's werden locker mit 1GHz oder mehr getaktet etc.) überhaupt kein Problem mit Leistung - sprich mit Zykluszeit hab und nun schreibst du, dass du die Zykluszeiten auf 20ms eingestellt hast!

Aktuell arbeite ich mit einer SPS von der Stange und hab ca. 6-7ms Programmzykluszeit, was nicht in allen Fällen mehr genügt. Da hängt auch ein Profibus mit drin, IO's werden ebenfalls eine Menge abgefragt und etliche Schrittmotorachsen sausen los....
Grundsätzlich möchte ich an all dem nichts ändern, einfach dass ich schneller werden muss um mind. Faktor 2. (Ach ja, wir planen dann auch gleich EtherCAT als Bus einzusetzten....).

Gruss Itus

 

[drfunfrock]

Die Frage, wie leistungsfähig eine SPS im Kontext des Programmes ist, kann dir kaum einer beantworten, wenn du nicht exakt die Anzhahl der Befehle kennst die abgearbeitet werden. Wichtig ist aber, dass du mind. die Buszykluszeit im Auge hast.
Da Ethercat richtig. Notfalls teilt man den Ethercat-Bus. Mit PC's kann man selten danebenliegen, aber wie immer, spielt der Preis eine Rolle.

 

[trinitaucher]

Mit ner PC-basierten Steuerung von Beckhoff wirst du mit Sicherheit schnellere Zykluszeiten erreichen, als mit ner Standard-SPS. Natürlich abhängig vom konkret gewählten System (nen CX9000 wird bestimmt nicht schneller sein als ne S7-400).
Aber wichtig für Beckhoff-Steuerungen ist immer:

- SPS-Zykluszeit >= n*Basiszeit
- Wenn Zykluszeit nicht ausreicht, wird SPS-Programm im nächsten Zyklus fortgesetzt.
- Der Feldbus wird immer von einer Task angestoßen, d.h. wenn die zugehörige SPS-Zykluszeit z.B. 100ms lang ist, wird auch ein EtherCAT nur alle 100ms loslaufen.

Zu Beginn nimm dir deinen Feldbus und schau auf die minimal erreichbaren, bzw. gewünschten Update-/Zykluszeiten. Dann dementsprechend die SPS-Task anpassen. Wenn ein (großes) SPS-Programm länger braucht, als die gewünschte Feldbusupdatezeit, kann man über eine getrennte I/O-Task nachdenken. Dann lässt du eine schnelle SPS-Task quasi die Daten einsammeln und die langsamere Task übernimmt dann nur die zur Verfügung gestellten Daten.

 

[Itus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für den Beitrag

Mit ner PC-basierten Steuerung von Beckhoff wirst du mit Sicherheit schnellere Zykluszeiten erreichen, als mit ner Standard-SPS. Natürlich abhängig vom konkret gewählten System (nen CX9000 wird bestimmt nicht schneller sein als ne S7-400).

Wir werden je nach Anwendung CX1020 oder C9625 einsetzen.

- SPS-Zykluszeit >= n*Basiszeit
- Wenn Zykluszeit nicht ausreicht, wird SPS-Programm im nächsten Zyklus fortgesetzt.

........müsste es nich heissen wenn die Basiszeit nicht ausreicht, wird das SPS-Programm im nächsten Takt fortgesetzt? Ich kann doch die Zykluszeit gar nicht einstellen, sondern nur die Basiszeit und die Zykluszeit ist dann ein vielfaches von der Basiszeit.

- Der Feldbus wird immer von einer Task angestoßen, d.h. wenn die zugehörige SPS-Zykluszeit z.B. 100ms lang ist, wird auch ein EtherCAT nur alle 100ms loslaufen.
Zu Beginn nimm dir deinen Feldbus und schau auf die minimal erreichbaren, bzw. gewünschten Update-/Zykluszeiten. Dann dementsprechend die SPS-Task anpassen. Wenn ein (großes) SPS-Programm länger braucht, als die gewünschte Feldbusupdatezeit, kann man über eine getrennte I/O-Task nachdenken. Dann lässt du eine schnelle SPS-Task quasi die Daten einsammeln und die langsamere Task übernimmt dann nur die zur Verfügung gestellten Daten.

Dann start ich doch am Besten den EtherCAT zuerst und wenn alle Daten da sind, starte ich den Applikationstask - somit gewährleiste ich doch, dass ich immer die gleich aktuellen I/O's in der Anwendung verarbeite? Oder seh ich da immernoch nicht durch...?

Gruss Itus

 

[trinitaucher]

Wir werden je nach Anwendung CX1020 oder C9625 einsetzen.

Sollte für "normale" Steuerungsaufgaben locker reichen.

........müsste es nich heissen wenn die Basiszeit nicht ausreicht, wird das SPS-Programm im nächsten Takt fortgesetzt? Ich kann doch die Zykluszeit gar nicht einstellen, sondern nur die Basiszeit und die Zykluszeit ist dann ein vielfaches von der Basiszeit.

Grundsätzlich hast du recht. Die Basiszeit ist der TwinCAT "Systemtick". Aber es muss nicht in jedem Systemzyklus das SPS-Programm abgearbeitet werden. Aber grundsätzlich werden nicht abgearbeitete Tasks im nächsten Zyklus fortgesetzt.

Dann start ich doch am Besten den EtherCAT zuerst und wenn alle Daten da sind, starte ich den Applikationstask - somit gewährleiste ich doch, dass ich immer die gleich aktuellen I/O's in der Anwendung verarbeite? Oder seh ich da immernoch nicht durch...?

Beachte die Denkweise! Nicht DU kannst den EtherCAT starten, sondern der startet grundsätzlich zusammen mit der Task. Wenn du im System Manager eine Verküpfung zwischen der Variablen einer SPS-Task und einem EtherCAT-Teilnehmer machst, wird der EtherCAT nur dann angetriggert, wenn die zugehörige Task abgearbeitet wird. Sprich, wenn du eine SPS-Task, die mit den I/Os verknüpft ist, nur alle 100ms abarbeitest, wird der EtherCAT auch nur in diesen Zyklen gestartet, Du kannst den EtherCAT nicht schneller als die Task laufen lassen. Wenn du aber zB die I/Os alle 100µs abrufen willst, deine SPS-Task zur Abarbeitung aber 10ms braucht, solltest du eine Task einrichten, die die zutreffenden I/O-Variablen schneller abruft. Dein SPS-Programm könnte die Daten zwar nur alle 10ms verarbeiten, aber du könntest die Daten in der Zwischenzeit zB mit anderen Tasks weiter- oder vorverarbeiten.

 

[Itus]

Danke für die Info.

Mit meiner "alten" SPS denkweist ist es nun wohl langsam vorbei......

Die zeitlich kritischen I/O's etc. lass ich in einem schnellen Task laufen und meinen SPS Task lass ich "einfach so vor sich hin rechnen". Die Zykluszeit ergibt sich dann einfach so und ich gehe davon aus, dass ich beim Abarbeiten des SPS Task auch die letzten gültigen Werte der I/O's berücksichtige.

Sag mal, ist das nur bei Beckhoff so kompliziert oder ist dies eine "Eigenart" von TwinCat sprich CoDeSys?

Gruss Itus

 

[zotos]

Zuviel Werbung?
-> Hier kostenlos registrieren

...
Sag mal, ist das nur bei Beckhoff so kompliziert oder ist dies eine "Eigenart" von TwinCat sprich CoDeSys?
...

In dem Beispiel ging es ja um:

...
Wenn du im System Manager eine Verküpfung zwischen der Variablen einer SPS-Task und einem EtherCAT-Teilnehmer machst, wird der EtherCAT nur dann angetriggert, wenn die zugehörige Task abgearbeitet wird.
...

Also EtherCAT und der System Manager (von TwinCAT).

...
Wenn du aber zB die I/Os alle 100µs abrufen willst, deine SPS-Task zur Abarbeitung aber 10ms braucht, solltest du eine Task einrichten, die die zutreffenden I/O-Variablen schneller abruft. Dein SPS-Programm könnte die Daten zwar nur alle 10ms verarbeiten, aber du könntest die Daten in der Zwischenzeit zB mit anderen Tasks weiter- oder vorverarbeiten.

Also ein Task rennt mit 100µs und erfasst z.B. Analogsignale oder Impulse die kann der schnelle Task dann z.B. Filtern oder einfach nur Zählen. Der Langsame 10ms Task kann dann das Ergebnis der Vorverarbeitung über eine Variable Empfangen. Das ist doch nicht Kompliziert.