Hallo,
ich bin gerade dabei, mich mit dem RevPi in SPS-Gefilde vorzutasten. Hierfür mochte ich das Programm in Python mit RevPiModIO programmieren. An RevPiModIO gefällt mir insbesondere die RevPi PLC-Control GUI gut, da Sie das Ganze ein wenig idiotensicherer macht.
Was ich machen möchte:
Ich habe vor, mein Steuerungsprogramm als Echtzeit-Thread laufen zu lassen. Da ich nur weiche Echtzeitanforderungen erfüllen möchte, ist dies für mich kein kritischer Punkt. Aber wenn wir schon für ein RT-Linux bezahlt haben, wollen wir das doch nutzen oder ? (Jaja ich weiß: Python => Garbage-Collector != Echtzeit; Damit kann ich leben) Erfahrung mit unixoiden System habe ich. Mit RT-Linux habe ich aber bisher praktisch keinen Kontakt gehabt.
Soweit ich es weiß, bedeutet RT-Linux nur, dass wir einen RT-Scheduler haben, welcher RT-Tasks priorisiert Rechenzeit zuweißt und die restliche an den normalen Scheduler weitergibt.
Die Frage hierzu:
Nun gibt es in der Konfigurationsdatei revpipyload.conf den Konfigurationspunkt rtlevel = 0. Dazu habe ich auf den ersten Blick keine Dokumentation finden können. Hört sich ja sehr verdächtig an und es hat sich auch gezeigt, dass der Punkt einen Einfluss auf die Priorität des Prozesses hat.
Beim Wert 0 habe ich die Priorität 20, was ja Ideal-Standard ist. Beim Verstellen stellt kann die Priorität -2 erreicht werden, welche höher ist. Das ich ja aber nach meinem Verständnis noch immer eine Priorität von dem herkömmlchen Scheduler. Die RT-Priotitäten sind in htop anscheinend mit RT gekennzeichnet.
- Welche Verstellmöglichkeiten gibt es bei dem rtlevel?
- Wie kann ich mein Steuerungsprogramm mit RevPiPyLoad als RT-Thread starten?
- Gibt es Erfahrung bezüglich RT-Thread vs -2-Thread?
Falls es Antworten geben sollte, bedanke ich mich für diese schon einmal im Vorraus!
Beste Grüße
Jan
RT-Linux Implementierung RevPiPyLoad
Moderator: RevPiModIO
- RevPiModIO
- KUNBUS
- Posts: 335
- Joined: 20 Jan 2017, 08:44
- Contact:
Re: RT-Linux Implementierung RevPiPyLoad
Moin Jan!
Ja, da hast du genau richtig geforscht
Die Option habe irgendwann mal in RevPiPyLoad eingebaut und sie bis heute als "undokumentiert" gelassen
Generell kannst du rtlevel auf 0 oder 1 setzen. Ist es auf 1, startet RevPiPyLoad dein SPS Programm, wie gewohnt und setzt es nach 5 Sekunden (Anlaufzeit) auf den SCHED_RR Scheduler. Die Anlaufzeit muss er haben, weil sonst der Start von Python das System so "belastet", dass die piBridge ein Problem bekommt. Wenn Python dann gestartet ist und dein Programm läuft, passt alles.
Das beantwortet soweit auch deine Frage, wie du dein Programm mit rtlevel starten kannst, dass macht RevPiPyLoad für dich automatisch
Die Prios sind so gewählt, dass man die piBridge nicht stört, das würde sich äußern durch rotes blinken der PowerLED am RevPi.
Kannst ja mal etwas damit testen und berichten, wie es läuft! Generell ist der Zyklus aber wirklich sauberer durch rtlevel=1 und wird natürlich auch nicht gestört durch Hintergrundaktivitäten vom OS...
Bin gespannt, Sven
Ja, da hast du genau richtig geforscht
Die Option habe irgendwann mal in RevPiPyLoad eingebaut und sie bis heute als "undokumentiert" gelassen
Generell kannst du rtlevel auf 0 oder 1 setzen. Ist es auf 1, startet RevPiPyLoad dein SPS Programm, wie gewohnt und setzt es nach 5 Sekunden (Anlaufzeit) auf den SCHED_RR Scheduler. Die Anlaufzeit muss er haben, weil sonst der Start von Python das System so "belastet", dass die piBridge ein Problem bekommt. Wenn Python dann gestartet ist und dein Programm läuft, passt alles.
Das beantwortet soweit auch deine Frage, wie du dein Programm mit rtlevel starten kannst, dass macht RevPiPyLoad für dich automatisch
Die Prios sind so gewählt, dass man die piBridge nicht stört, das würde sich äußern durch rotes blinken der PowerLED am RevPi.
Kannst ja mal etwas damit testen und berichten, wie es läuft! Generell ist der Zyklus aber wirklich sauberer durch rtlevel=1 und wird natürlich auch nicht gestört durch Hintergrundaktivitäten vom OS...
Bin gespannt, Sven
python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
Re: RT-Linux Implementierung RevPiPyLoad
Moin Sven,
das ist echt nett gemacht, zumal man zu RT-Linux nicht so viele Inhalte für normalsterbliche findet und dies sonst immer Frickelkram ist. Ich hoffe mal, dass dir die Jungs von Kunbus beim nächsten RevPi-Modell eine ordentliche Kaffeemaschiene und ein Flugticket zu den Galapagos-Inseln oder so mitschicken.
Für alle anderen, welche villeicht mal auf die selbe Idee kommen:
In der Tat ist die Prioriätskennzeichnung htop an der Stelle etwas irreführend. Bei dem Prozess (hier nur eine Endlosschleife, welche bis 1337 zählt) handelt es sich definitiv um einen Prozess vom RR_Scheduler. In htop gibt es Prozesse mit der Priorität RT, was ja etwas wie "realtime" vermuten lässt. Die PiPyLoad-Schleife (welche ja ein RT-Prozess ist) besitzt in htop jedoch die Priorität -2. Somit folgt, dass Echtzeit≠RT ist. RT scheint wohl mal für alle Prioritäten jenenseits von -99 eingeführt worden zu sein, was legacy Krams ist.
Bis es Langzeiterfahrungen gibt, wird es wohl noch ein wenig dauern, da die Steuerung in ein Netz mit Paketüberwachung und bla kommt und dies etwas Zeit braucht.
Beste Grüße
Jan
das ist echt nett gemacht, zumal man zu RT-Linux nicht so viele Inhalte für normalsterbliche findet und dies sonst immer Frickelkram ist. Ich hoffe mal, dass dir die Jungs von Kunbus beim nächsten RevPi-Modell eine ordentliche Kaffeemaschiene und ein Flugticket zu den Galapagos-Inseln oder so mitschicken.
Für alle anderen, welche villeicht mal auf die selbe Idee kommen:
In der Tat ist die Prioriätskennzeichnung htop an der Stelle etwas irreführend. Bei dem Prozess (hier nur eine Endlosschleife, welche bis 1337 zählt) handelt es sich definitiv um einen Prozess vom RR_Scheduler. In htop gibt es Prozesse mit der Priorität RT, was ja etwas wie "realtime" vermuten lässt. Die PiPyLoad-Schleife (welche ja ein RT-Prozess ist) besitzt in htop jedoch die Priorität -2. Somit folgt, dass Echtzeit≠RT ist. RT scheint wohl mal für alle Prioritäten jenenseits von -99 eingeführt worden zu sein, was legacy Krams ist.
Bis es Langzeiterfahrungen gibt, wird es wohl noch ein wenig dauern, da die Steuerung in ein Netz mit Paketüberwachung und bla kommt und dies etwas Zeit braucht.
Beste Grüße
Jan