The Industrial Raspberry Pi Forum

Hallo Gemeinde,
hat schon jemand konkret Erfolg bei der Implementierung der "CODESYS Control for Raspberry Pi SL"
auf dem RevPi zu verbuchen?
Mir scheint das CODESYS-Universum derzeit größer und mit mehr Erfahrung gesegnet zu sein als andere, da mag aber auch das "Henne-Ei-Problem" mit reinspielen ...
Gab es seitens Kunbus schon Gehversuche mit dem o.g. CODESYS-Laufzeitsystem?

Grüße

Das System lässt sich problemlos installieren und Du kannst alles damit machen, außer unsere IO Module direkt ansprechen. Daran arbeiten wir aber. Aktuell geht das nur mit einem kleinen Umweg:
Ein (Python)programm kopiert alle IO Werte aus dem PA in die PA-Speicherbytes eines virtuellen Moduls Modbus TCP Slave. In Codesys werden dann diese Bytes mit dem eingebauten Modbus TCP Master ausgelesen. Also quasi eine interne Modbus-Modbus Datenbrücke. Dabei gehen aber die Datenstrukturen und namen verloren, Du musst mit reinen Bytes arbeiten und diese dann selber "zu Fuß" wieder strukturieren und benennen.
Aber wenn Du die IOs nicht brauchst und z.B. mit Ethercat Kopfstation Wago-IO Klemmen ansprechen willst, dann geht das völlig stressfrei.

Danke für die schnelle Antwort, das hilft schonmal!

Wenn ich es aber richtig im Kopf habe, ist das System mit Codesys nicht Echtzeitfähig, oder gibt es hierzu schon Neuerungen? Nutz Codesys für den Raspi einen CPU Kern oder mehrere?

Au wei, jetzt kommt dieser komplizierte Begriff "Echtzeitfähig"...
Wenn Du da eine korrekte Antwort haben möchtest, dann musst Du erst mal definieren, was Du darunter verstehst. Codesys läuft genau wie logi.rts oder andere Steuerungs-Runtime-Software auf dem Raspi genauso wie auf unserem RevPi im User Space. Jeder Software auf dem RevPi steht es frei, sich in dem Scheduler vom RT-Patch eine hohe Priorität einzutragen, so wie das bei unserem piControl ist, der im Kernel läuft. Eine Software (oder ein User) der das nicht nutzt, bekommt vom Scheduler eben nur die "Restzeit" ab. Wenn dann bestimmte Kerneltreiber zuschlagen (USB, Ethernet, SPI, PiControl), dann kann es schon mal sein, dass für solche Software über ms lang Sendepause ist. Dadurch entsteht ein Jitter, der relativ groß ist. Software, die im RT Scheduler eine hohe Prio eingeräumt bekommt, hat diesen Jitter eben nicht. Im allgemeinen versteht man das unter RT-Fähigkeit. Viele USer verstehen aber darunter die Zykluszeit einer Steuerungssoftware, die irgendeinen (willkürlichen) Mindestwert unterschreiten muss, damit diese User eine Software RT-fähig nennen. Das muss dann aber jeder selber wissen, worauf es bei seiner Anwendung ankommt. Die Zykluszeit von Codesys ist definitiv nicht schlechter, als die von logi.RTS. Wenn allerdings die oben erwähnte Modbus-Brücke verwendet wird, dann erzeugt man bei sehr kleinen Modbuszykluszeiten (<10 ms) eine extreme Systemlast und daher empfehle ich das nicht zu tun.
Wir werden sicher auch mal ein Tutorial zum Thema Rt Scheduler machen, in dem step by step erklärt wird, wie man die Prio seiner Software einstellen kann.

Jetzt wäre es nur noch interessant ob es möglich ist Codesys auf mehrere Kerne des Raspi laufen zu lassen. Ich glaube das die Codesys Runtime nur auf einen Kern läuft, also wären die anderen 3 nicht großartig genutzt.
Wenn wir für Codesys im Scheduler vom RT-Patch eine hohe Priorität eintragen können und Codesys auf allen Kernen laufen würde, denke ich das dieses System leicht mit einem indrustrie-System (wie Beckhoff oder Siemens) mithalten kann.

Noch eine Frage zum EtherCat:
Wenn ich die LAN-Schnittstelle von RevPi Connect verwende, habe ich dann Einschränkungen bei der EtherCat Geschwindigkeit, da ja die Schnittstelle nur 100Mbit/s hat. Kann ich mit der Schnittstelle die volle EtherCat Funktionalität nutzen, oder ist der Ethernet Anschluss nur über USB an den Connect angeschlossen?

viele Grüße,
Michael

Hallo Michael,
das ist jetzt ein wenig zu optimistisch... Leider hat das CM 3 keine Ethernet IOs (der SoC hat sie glaube ich, aber Raspi nutzt diese nicht und daher wurde auch beim CM3 kein Ethernet verbaut. Somit ist Ethernet exakt wie beim Raspi (sogar mit demselben Chip) über USB realisiert. Das ist auch der Grund, warum Du in der Regel keine 100 Mbit Durchsatz bekommst. Wenn die restlichen USb Schnittstellen, die über einen Hub alle auf die eine CM3 USB gehen, ebenfalls genutzt werden, dann sinkt die Übertragungsrate. rechne mal eher mit max. 50 Mbit.