CODESYS Control für Linux - weiche Echtzeiteigenschaften

[PAHO]

Zuviel Werbung?
-> Hier kostenlos registrieren

Grüß Euch,

eventuell kann mir hier jemand meine Fragen zur "weichen Echtzeitfähigkeit" beantworten (und mir ist klar, dass es sich hier um eine SoftSPS ohne Echtzeiteigenschaften handelt).

Ich arbeite schon längere Zeit mit CODESYS für Raspberry Pi MC + Real Time Patch. Dort hatte ich für meine Programmzyklen nie Probleme, die Programme selbst sind aber auch nie wirklich zeitkritisch. In der Regel sollte es aber möglich sein, einen 1-10ms Zyklus hinzubekommen, um interne Zähler mit einer hohen Auflösung mitlaufen zu lassen.

Nun soll aber anstatt des Raspi ein richtiger Industrie-PC und der CODESYS Control für Linux verwendet werden. Hier muss ich aber wissen, ob mein Prozesszyklus eingehalten wird. Hier geht es um keine Maschinensteuerungen sondern eher um Temperaturregelungen und Laufzeitmessungen von Stellantrieben usw...

Vielleicht hat ja jemand schon Erfahrungen damit gemacht und kann mir etwas dazu sagen.

Herzlichen Dank!

 

[HausSPSler]

Hallo,

ich denke man kommt ziemlich weit, wenn man zum Beispiel Debian verwendet und dann einfach
wie folgt einen gepatchten rt_preempt Kernel installiert:


sudo apt-get install linux-image-rt-amd64

dann noch paar Tips:
Deactivate any kind of Energy saving modes in BIOS (if available)
Deactivate any kind of HyperV in BIOS (if available)
Set cpu energy saving modes (scheduling_governor) to “performance” (if needed )
more important is to have it fix/stable - you need to
(Can be done with cpufreq-utils) -> sudo apt-get install cpufrequtils

CODESYS Runtime:

• Use Multicore
• Set “DMA_Latency” in configuration file (if not yet set):

[SysCpuHandling]
Linux.DisableCpuDmaLatency=1

Es schadet ja in keinsterweise so einen (pre) gepatchten Kernel zu verwenden um es nicht selber machen zu müssen,
wenn man die ganz harte Echtzeit brauch dann eh selber patchen und genau prüfen wie die qualität des patrches ist. ( Jitter messen - cyclictest usw volles Programm)

Grüße

 

[PAHO]

Zuviel Werbung?
-> Hier kostenlos registrieren

Grüß dich,

danke für die ausführliche Antwort! Der RT-Patch am Raspberry wird wahrscheinlich auch nichts anderes sein, nehme ich mal an…

Empfiehlst du generell Multicore für Codesys? Debian hat im Hintergrund noch NodeJS sowie MongoDB und einige Dienste laufen, welche ich auf die Kerne aufgeteilt hätte, oder sollte ich hier aus Performance-Gründen eher alle Kerne verwenden? Das System soll ja auch so gut es geht stabil bleiben

Danke und LG

 

[Blockmove]

Grüß dich,

danke für die ausführliche Antwort! Der RT-Patch am Raspberry wird wahrscheinlich auch nichts anderes sein, nehme ich mal an…

Empfiehlst du generell Multicore für Codesys? Debian hat im Hintergrund noch NodeJS sowie MongoDB und einige Dienste laufen, welche ich auf die Kerne aufgeteilt hätte, oder sollte ich hier aus Performance-Gründen eher alle Kerne verwenden? Das System soll ja auch so gut es geht stabil bleiben

Danke und LG

Du schreibst oben, dass du Stellantriebe und Temperaturregler hast.
Normalerweise sind das keine besondere Anforderungen an die Echtzeit.
Hängt aber auch von der Programmierweise ab.
Erfahrungsgemäß ist eine feste Zuordnung von Cores für eine SPS besser.
Damit hast du konstante Zykluszeiten.
NodeJS kann viele Threads / Cores nutzen und somit einer SPS in die Quere kommen.
Du solltest auch das Thema Netzwerk betrachten und für die SPS und die IOs lieber eine eigene Netzwerkkarte vorsehen.

 

[HausSPSler]

Multicore ist nur optional...kannst halt dann in CODESYS oben festlegen was genau von der IEC Applikation auf welchem Kern läuft. Z.b Ethercat auf Kern1 Visualisierung auf Kern2 usw.
Aber wie gesagt das geht schon auch ohne.

 

[PAHO]

Zuviel Werbung?
-> Hier kostenlos registrieren

Super, dank Euch für die Unterstützung und Tipps! Hört sich alles schlüssig an.
Ich werde mir mal eine Lizenz für Linux organisieren und mit dem Industrie-PC meine Programme testen.

LG

 

[seehma]

Interessanter Thread, geht die Codesys Runtime auch auf einem Standard Linux? Das hab ich gar nicht gewusst.
Ganz was anderes: Das verstecken von CPU-Cores vor dem Betriebssystem müsste doch auch etwas Schutz bringen oder? Klarerweise ist der Cache gemeinsam genutzt und darüber kann immer etwas Latenz reinkommen, aber geht das mit Codesys?
Sg
M.

 

[Blockmove]

Interessanter Thread, geht die Codesys Runtime auch auf einem Standard Linux? Das hab ich gar nicht gewusst.
Ganz was anderes: Das verstecken von CPU-Cores vor dem Betriebssystem müsste doch auch etwas Schutz bringen oder? Klarerweise ist der Cache gemeinsam genutzt und darüber kann immer etwas Latenz reinkommen, aber geht das mit Codesys?
Sg
M.

Die Codesys-Runtime ist - meines Wissens - ein "normales" Programm. Hier bringt das Verstecken wohl weniger.
Linux bietet aber auch umfangreiche Möglichkeiten für die Virtualisierung.

 

[HausSPSler]

Zuviel Werbung?
-> Hier kostenlos registrieren

wenn du mit Standard Linux Debian oder Ubuntu meinst, ja,
nein reservieren eines CORES exklusiv für die Runtime geht nur unter Windows.
Aber unter WIndows wie auch Linux gibt es Multicore - sprich du kannst in CODESYS in der Taskkonfiguration einstellen was von der IEC Applikation auf welchem Core laufen soll.

 

[PAHO]

Hallo nochmal,
melde mich diesmal mit einem Problem wieder:

Habe nun ein System schon mehrere Wochen mit den von HausSPSler vorgeschlagenen Einstellungen am laufen. Die Zykluszeit beträgt im Schnitt ca. 20us, vom IEC-Programm also überhaupt kein Thema. RT_PATCH ebenfalls geladen.

Das Hauptproblem ist die Ansteuerung eines WAGO Modbus TCP GEN4 Controllers. Angebunden ist dieser über eine direkte, separate Ethernet-Schnittstelle auf meinem Industrial PC, statische IP-Adressen vergeben und grundsätzlich funktioniert die Kommunikation auch.
Allerdings gibt es laufend Timeouts in der Kommunikation (Timeout=1 Sekunde) im ungefähren Verhältnis von 2x OK : 1x ERROR.
Habe vorerst nur einen Digitalen Ausgang definiert, der schaltet jede Sekunde EIN/AUS und die Übertragung an den WAGO Modbus-Client ist als Intervall mit 500ms Zyklus definiert. Kabelverbindungen usw. wurden gecheckt.

Der Ethernet Controller ist ein Onboard Intel I210:

08:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)​

Subsystem: Mitac I210 Gigabit Network Connection​

Flags: bus master, fast devsel, latency 0, IRQ 21, IOMMU group 6​

Memory at 91100000 (32-bit, non-prefetchable) [size=1M]​

I/O ports at c000 [disabled]​

Memory at 91200000 (32-bit, non-prefetchable) [size=16K]​

Capabilities: <access denied>​

Kernel driver in use: igb​

Kernel modules: igb​

Sollte der Linux Real Time Patch nicht auch die Hardware-Interfaces patchen, oder gibt es hier noch zusätzliche Dinge zu beachten? Im CODESYS FAQ gibt es ein eigenes Thema zur Real Time Performance und Linux Kernel driver, allerdings ohne einer Lösung

Lg, PAHO

 

[HausSPSler]

Am besten du schaust mal im Taskmonitor wenn du online bist,
bei der höchstprioren Task - wie da der Jitter ist.
Aber für Modbus kann ich mir nicht vorstellen das du irgend ein Problem hast mit dem rt_preempt Patch - das muss schon eher was anderes sein.
Dann gehts halt meist Richtung Wireshark oder TCPdump usw. auf der Linux Kiste oder aber zuerst einfach mal ins Log schauen bzw die Diagnose der Slaves ( Slavename ins Watchfenster ziehen/schreiben)

 

[PAHO]

Zuviel Werbung?
-> Hier kostenlos registrieren

Anbei sende ich ein paar Screenshots. Es ist sehr seltsam, da ich gestern zusätzlich eine Modbus RTU Verbindung mit einer Busklemme hergestellt habe, auf welcher ich ebenso einen Ausgang im Intervall von 500ms schalte. Das funktioniert sogar mit 100ms oder weniger. Also eher kein Problem der eigentlichen Codesys Runtime, denke ich.
Mit der Modbus TCP Verbindung (wie beschrieben, direkt mit einem Patchkabel verbunden) funktioniert das nicht. Sobald ich aber die Busklemme und auch den Codesys IPC in das "Office" Netzwerk verbinde (beide DHCP, verbunden über einen Switch), scheint es ohne Probleme zu funktionieren. Zumindest habe ich keinen einzigen Fehler im Error Counter.

Achja, ich verwende aktuell Debian (5.10.0-13-rt-am64) ohne Desktop Umgebung auf einem Onlogic Karbon 300. Laut Codesys FAQ dürfte es anscheinend mehr Probleme mit 5.10 geben als mit 4.19. Gibt es da schon von Codesys irgendwelche Infos?
So könnte ich mir einfach mal 4.19 installieren und schauen, ob es mit dem PREEMPT_RT Patch besser funktioniert. Auf der Seite steht dieser Hinweis ja explizit unter dem Network Driver.

Danke!

 

[HausSPSler]

also am Echtzeitpatch liegt es definitiv nicht eher daran das der Slave nicht antwortet...

 

[PAHO]

Es dürfte wirklich am Kernel liegen. Habe es soeben mit Debian Buster 4.19 inkl. PREEMPT_RT Patch versucht, da kann ich jetzt beim Intervall 10ms einstellen und die LED am Controller blinkt so wie sie soll, total regelmäßig. Kein einziger Fehler im Ethernet-Modul + Modbus Master von CODESYS.
Werde es jetzt noch ein paar Stunden so laufen lassen und einige Ausgänge hinzufügen um das ein wenig zu stressen.

 

[PAHO]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
eine kurze Zusammenfassung, für alle die es interessiert. Nachdem ich auch all meine Anwendungen installiert und aktiviert hatte (nginx Server mit JS-App Website, mongodb, NodeJS Backend Server und einige Tools) habe ich beobachtet, dass sich am Jitter kaum was geändert hat. Die Netzwerk-Kommunikation hatte ich vor all den Installationen und Reboot einen Tag getestet und einen Ausgang alle 50ms Ein und nach 100ms Ausgeschaltet. Funktionierte tadellos.
Allerdings nach der Installation der Anwendungen/Services und Reboot musste ich beobachten, dass es alle paar Sekunden mal kleinere Verzögerungen zwischen dem Hin- und Herschalten gab - aber keine fehlerhaften Pakete, einfach nur ein Delay in der Netzwerk-Kommunikation.

Habe dann die Anleitung der CODESYS FAQ befolgt und meine CPU1 im Grub-Bootloader isoliert

isolcpus=1

und im Codesys-Taskmanager für meine Applikation fix zugeordnet. Zusätzlich noch den scaling_governor temporär auf performance

echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

gestellt.

Mit dieser Konfiguration scheint es absolut zuverlässig zu funktionieren. Aktuell arbeite ich mit einem schwächeren Intel Atom der das alles zwar gut meistert, aber eben nur 2 Cores hat und bei intensiven Aufgaben mit mongodb laut htop schon etwas ins schnaufen kommt. Demnächst kommen meine Intel Core i5 IPCs und dann wird das Thema ebenso erledigt sein.

Danke auch für all euren Support!

 

[Blockmove]

Welche Distribution hast du im Einsatz?
Normales Debian?

 

[PAHO]

Genau, Debian Buster, ohne zusätzlichen Packages bei der Installation außer SSH-Server:
Linux * 4.19.0-20-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Genau, Debian Buster, ohne zusätzlichen Packages bei der Installation außer SSH-Server:
Linux * 4.19.0-20-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux

Warum kein Debian Bullseye?

 

[PAHO]

Warum kein Debian Bullseye?

Schau etwas weiter oben, da hatte ich schon Bullseye+RT-Patch mit Codesys eingerichtet. Jitter war auch OK, nur gab es Probleme mit der Netzwerk-Schnittstelle. Immer öfter Timeouts in der Kommunikation und von 10ms-Intervallen bei der Modbus-TCP Übertragung konnte ich nur träumen.
Selbige Konfiguration mit Buster ist kein Thema. Übertrage aktuell alle 10ms an eine WAGO Modbus TCP Gen4 "Write multiple coils" mit 64 Einträgen problemlos. So schnell brauche ich es aber sowieso nicht, komme auch mit Intervallen von ca. 500ms aus. Aber selbst das war mit Bullseye sehr schwer möglich. Erst ab Intervallen von >500ms wurde die Übertragung stabil.