Page 1 of 1

RevPi + Codesys = high performance PLC?

Posted: 31 Jul 2018, 10:48
by volker
Ein User hat per Email folgende Frage gestellt:
Ich würde ausschließlich den RevPi Connect [mit Codesys] als Steuerung verwenden und über die LAN-Schnittstelle (über EtherCat) einen Beckhoff Buskoppler mit Beckhoff IO Modulen verwenden (also keine Kunbus Erweiterungsmodule). Also das bedeutet doch, dass ich mit diesem Aufbau ähnlich kurze Zykluszeiten wie mit einer Industriesteuerung erreichen kann, oder?
Da so eine Frage sicher für alle hier von Interesse ist, hier unsere Antwort:

Ich zitiere mal aus Wikipedia die Entwicklungsziele von Beckhoff für EtherCAT:
The goal during development of EtherCAT was to apply Ethernet for automation applications requiring short data update times (also called cycle times; ≤ 100 µs) with low communication jitter (for precise synchronization purposes; ≤ 1 µs) and reduced hardware costs.
Dieses Ziel konnte nur erreicht werden, indem man das TCP/IP Protokoll umgeht und mit speziellen Ethernetcontrollern (ASICs) nur dann die Payload aus den Ethernet-Telegrammen holt, wenn man Empfänger der Nachricht ist. Ein normaler Ethernet Controller in einem IPC muss die Ethernettelegramme komplett extrahieren, dann dem protokollstack übergeben, der dann erst feststellt, ob das Telegramm überhaupt für diesen IPC bestimmt ist. Damit lassen sich solche Vorgaben (100 µs Zykluszeit mit 1 µs Jitter) nicht erfüllen.

Noch ein paar Worte zu dem Thema "Echtzeitfähigkeit" (real time system):
Ebenfalls ein Wikipediazitat:
In computer science, real-time computing (RTC), or reactive computing describes hardware and software systems subject to a "real-time constraint", for example from event to system response.[1] Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".[2] The correctness of these types of systems depends on their temporal aspects as well as their functional aspects. Real-time responses are often understood to be in the order of milliseconds, and sometimes microseconds. A system not specified as operating in real time cannot usually guarantee a response within any timeframe, although typical or expected response times may be given.
Mit anderen Worten: Ab welcher Zykluszeit ein System "Echtzeitfähigkeit" besitzt, diese Schwelle ist ein Absolutwert, der in irgendeiner Norm stände, sondern ist von der jeweiligen zu steuernden Anwendung abhängig. Was aber für alle Anwendungen gilt, ist die Vorhersagbarkeit einer maximalen Reaktionszeit. Diese Vorhersagbarkeit wird maßgeblich in einem Steuerungssystem durch den sogenannten "Jitter" der Zykluszeit beschrieben und der Jitter benennt die nicht vorhersagbare Abweichung von einem Mittelwert in beide Richtungen. In einem Multi-User, Multi-Tasking, Multi-CPU Kern Betriebssystem ist eine Aussage über den Jitter komplex und hängt von der Vorgehensweise des sogenannten Schedulers ab, der die Tasks "pseudo-parallel" oder wirklich parallel (Mehrkern CPU) zum Abarbeiten aufruft. Und genau dort greift eben ein RT-patch bei Debian ein. Er stellt einen speziellen Scheduler bereit, der verhindert, dass bestimmte Hardwarekomponenten (USB, Ethernet, etc.) mal eben für viele Millisekunden das gesamte System blockieren können. Dafür müssen die Treiber dieser Komponenten aber auch in der Lage sein, sinnvoll mit so einem Scheduler nach RTC Prinzipien zu arbeiten.
Im Kern bekommen die Prozesse klare Prioritäten zugeordnet, so wie es bei einer CPU mit Interrupts schon immer funktionierte.
Über die Zykluszeiten unseres Backplanebusses "PiBridge" haben wir bereits viel geschrieben., Wer (wie der Fragesteller) nicht mit PiBridge und PiControl arbeiten will, sondern direkt mit Codesys oder anderer Software die Ethernetschnittstelle nutzt, um über diese die IOs zu bedienen, der bekommt natürlich die volle Rechenleistung eines 4-Kern 1,2 GHz Systems als Basis. Es bleibt aber leider die Einschränkung, dass ein Raspi genau wie das ComputeModul seinen Ethernetverkehr über einen Umsetzer auf USB abwickeln muss und sich die Bandbreite von USB 2.0 mit allen anderen USB Teilnehmern teilt. nach unseren Messungen sind damit noch nicht einmal mehr die 100 MBit zu erreichen, sondern der mittlere Durchsatz liegt dann eher bei der Hälfte.

FAZIT:
Ja, aus einer solchen Kombination kann eine vollwertige Steuerung aufgebaut werden, aber nein, hochperformante EtherCAT Steuerungenlassen sich damit ganz sicher nicht realisieren.

Re: RevPi + Codesys = high performance PLC?

Posted: 20 Aug 2018, 13:38
by volker
Hier eine Vorgehensweise zur Priorisierung der Codesys-Projekte:
Mit "ps aux |grep -i code" die beiden Codesysprojekt-pid suchen (z.B. 1463 und 1502)
Mit "psr |grep code" die prozesse auf ihre priorität prüfen (in der Prio Spalte sollte erst mal nichts stehen)
Mit "sudo chrt --pid 20 1463" und "sudo chrt --pid 20 1502" (bitte die pid durch die eigenen ersetzen!!!) die Prioritäten auf 20 setzen.
Mit "psr |grep code" kontrollieren, ob das Erfolg hatte.

Die Prio sollte maximal auf 25 gesetzt werden, um dem piControl Treiber genügend Luft zu lassen!
Damit sollte ein eventueller Jitter (z.B. bei FTP-Dateitransfer zu beobachten) weitgehend verschwunden sein. Allerdings würde ein kompletter RT-Umbau natürlich auch Aufrufe zu bestimmten Kernelfunktionen durch Aufrufe in die RT-optimierten Funktionen ersetzen. Aber das kann dann wirklich nur der Hersteller umsetzen...

Re: RevPi + Codesys = high performance PLC?

Posted: 03 Apr 2019, 10:36
by nirvana_xun
seems the answer is negative, we can not just combine Rev PI and Codesys together to form an industrial realtime controller

Re: RevPi + Codesys = high performance PLC?

Posted: 08 Apr 2019, 13:08
by dirk
Basically you have a real time os with the RevPi as the real time patch is applied. So you may just reconfigure the Codesys process to real time priority.