Da so eine Frage sicher für alle hier von Interesse ist, hier unsere Antwort: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?
Ich zitiere mal aus Wikipedia die Entwicklungsziele von Beckhoff für EtherCAT:
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.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.
Noch ein paar Worte zu dem Thema "Echtzeitfähigkeit" (real time system):
Ebenfalls ein Wikipediazitat:
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.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.
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.
