Zykluszeit beim RevPi Core 3
Hallo,
in eurer Ankündigung der Gateways vom letzten Jahr wurde die aktuelle Zykluszeit mit 5 ms angegeben, limitiert durch die sinnvoll nutzbare Systemlast des RevPi Core.
"Die Zykluszeit zwischen dem RevPi Core und einem RevPi Gate haben wir aktuell mittels Treiber auf 5 ms eingestellt. Die RevPi Gate Module könnten zwar Zykluszeiten von unter 2 ms erreichen, jedoch würde das die Systemlast des RevPi Core unverhältnismäßig belasten. Denn, je kleiner die Zykluszeiten im Treiber eingestellt werden, umso stärker ist die Systemlast des RevPi Core, die für diesen Prozess aufgewendet werden muss."
https://revolution.kunbus.de/blog/revol ... /#more-387"
Der RevPi Core 3 hat ja deutlich mehr Rechenpower, wirkt sich das auch auf die minimal nutzbare Zykluszeit aus? Und wie verhält es sich, wenn man statt 2 Gateways + 1 DIO nur 1 Gateway + 1 DIO nutzt?
Schönen Gruß,
Matthias
in eurer Ankündigung der Gateways vom letzten Jahr wurde die aktuelle Zykluszeit mit 5 ms angegeben, limitiert durch die sinnvoll nutzbare Systemlast des RevPi Core.
"Die Zykluszeit zwischen dem RevPi Core und einem RevPi Gate haben wir aktuell mittels Treiber auf 5 ms eingestellt. Die RevPi Gate Module könnten zwar Zykluszeiten von unter 2 ms erreichen, jedoch würde das die Systemlast des RevPi Core unverhältnismäßig belasten. Denn, je kleiner die Zykluszeiten im Treiber eingestellt werden, umso stärker ist die Systemlast des RevPi Core, die für diesen Prozess aufgewendet werden muss."
https://revolution.kunbus.de/blog/revol ... /#more-387"
Der RevPi Core 3 hat ja deutlich mehr Rechenpower, wirkt sich das auch auf die minimal nutzbare Zykluszeit aus? Und wie verhält es sich, wenn man statt 2 Gateways + 1 DIO nur 1 Gateway + 1 DIO nutzt?
Schönen Gruß,
Matthias
Schönen Gruß,
matt.s
matt.s
Re: Zykluszeit beim RevPi Core 3
Die Rechenpower ist aktuell weniger der limitierende Faktor, sondern die beim CM1 und CM3 leider viel zu niedrige Bitrate der UART-Schnittstelle, mit der wir die RS485 auf der PiBridge ansteuern. Wir können da nicht wesentlich schneller werden, denn das Protokoll ist schon sehr stark optimiert, mit einem optimalen Verhältnis der Payload zum Gesamttelegramm. Nun hängt es stark von Deiner Konfiguration ab, welche Zykluszeit realisierbar ist. Die 5 ms sind leider schon lange nicht mehr aktuell. Da wir ja inzwischen auch Encoder und PWM erlauben und auch ein AIO Modul haben, werden auf der PiBridge für diese Funktionen wesentlich mehr Byte benötigt, als für 16 binäre Ein- und Ausgänge pro DIO. Die Konfiguration bestimmt daher ganz entscheidend die minimal realisierbare Zykluszeit. Wir stellen sie inzwischen dynamisch ein. Wenn Du viele DIO Eingänge als Encoder / Zähler definierst und viele Ausgänge als PWM, dann steigt Deine Zykluszeit drastisch. Sie bleibt zwar in der Regel deutlich unter 50 ms, ist aber leider meist größer als 5 ms. In der Realität must Du leider aktuell bei einer gegebenen Konfiguration Deine Zykluszeit über ein Oszilloskop und einen Ausgang, den Du toggelst, selber bestimmen. Eventuell statten wir PiControl in der Zuklunft mit einer Funktion aus, die Dir die Zykluszeit ausgeben kann. Näheres werde ich zu dem Thema morgen nach Rücksprache mit unserem PiControl Experten schreiben.
Unser RevPi Motto: Don't just claim it - make it!
- RevPiModIO
- KUNBUS
- Posts: 322
- Joined: 20 Jan 2017, 08:44
- Contact:
Re: Zykluszeit beim RevPi Core 3
Ich dachte, die aktuelle Zykluszeit steht in einem Ausgang am RevPiCore im Prozessabbild zur Verfügung? Jedenfalls wenn ich beim Jessie Image den RevPiCore 1.2 nehme.
Den kann man dann auslesen über piTest oder Python mit RevPiModIO rpi.core.iocycle
Gruß, Sven
Den kann man dann auslesen über piTest oder Python mit RevPiModIO rpi.core.iocycle
Gruß, Sven
python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
Re: Zykluszeit beim RevPi Core 3
Sven hat natürlich recht, unser SW Team hat tatsächlich diese Anforderung bereits umgesetzt. Sven, Du kennst das System inzwischen besser als ich ![Zwinkern ;-)](./images/smilies/icon_e_wink.gif)
unter dem Offset 1 steht im PA ein byte, welches die aktuelle Zykluszeit in ms angibt. Diese Zeit steht aber ausschließlich für Di, DO, DIo und AIO Module. Die Kommunikation mit den Gateways läuft in einer separaten Task und sit beim Core 3 fix auf 10 ms eingestellt. Beim Core 1 ist sie auf 20 ms eingestellt.
![Zwinkern ;-)](./images/smilies/icon_e_wink.gif)
unter dem Offset 1 steht im PA ein byte, welches die aktuelle Zykluszeit in ms angibt. Diese Zeit steht aber ausschließlich für Di, DO, DIo und AIO Module. Die Kommunikation mit den Gateways läuft in einer separaten Task und sit beim Core 3 fix auf 10 ms eingestellt. Beim Core 1 ist sie auf 20 ms eingestellt.
Unser RevPi Motto: Don't just claim it - make it!
Re: Zykluszeit beim RevPi Core 3
Hallo Volker,
vielen Dank für deine Ausführungen. Die Zykluszeit für Feldbusse ist beim Core 3 also fest auf 10 ms eingestellt. Findet man diese Infos eigentlich auch irgendwo gesammelt oder muss man sich das wirklich aus (teilweise überholten) Blogeinträgen und Forensuchen zusammenklauben?
Wie würde sich ein RevPi Core 3 + EtherCAT-Gateway an einem EtherCAT-Bus verhalten der mit 1 ms Zykluszeit läuft? Würde der Master dann einfach zehnmal den gleichen Wert zurücklesen und es würden vom RevPi nur alle 10 Takte neue Befehle angenommen oder würde der RevPi gar nicht an diesem Bus teilnehmen können?
Schönen Gruß,
Matthias
vielen Dank für deine Ausführungen. Die Zykluszeit für Feldbusse ist beim Core 3 also fest auf 10 ms eingestellt. Findet man diese Infos eigentlich auch irgendwo gesammelt oder muss man sich das wirklich aus (teilweise überholten) Blogeinträgen und Forensuchen zusammenklauben?
![Lächeln :)](./images/smilies/icon_e_smile.gif)
Wie würde sich ein RevPi Core 3 + EtherCAT-Gateway an einem EtherCAT-Bus verhalten der mit 1 ms Zykluszeit läuft? Würde der Master dann einfach zehnmal den gleichen Wert zurücklesen und es würden vom RevPi nur alle 10 Takte neue Befehle angenommen oder würde der RevPi gar nicht an diesem Bus teilnehmen können?
Schönen Gruß,
Matthias
Schönen Gruß,
matt.s
matt.s
Re: Zykluszeit beim RevPi Core 3
Unsere Slave Gateways sind in der Lage mit allen spezifizierten Buszyklen zurecht zu kommen. Aber auch wenn Du sie in ihrer ursprünglichen Nutzung einsetzt (also als modulares Gateway-Paar) kann ein Feldbus nur so schnell Datenaustauschen, wie der andere Feldbus sie übernehmen oder liefern kann. Der langsamere Feldbus bremst also den schnelleren aus.
Auf einem klassischen Feldbus werden IOs ja zyklisch übertragen, egal ob sich Werte ändern oder nicht. Wenn also ein Profibus mit 10 Mbps konfiguriert ist, dann bedeutet dies nicht, dass eine Simatic in einer Sekunde 10 Mbit unterschiedliche Prozessdaten überträgt. Allerdings bedeutet es in der Regel, dass eine sehr kurze Latenzzeit von wenigen µs zwischen dem Senden eines Bits aus der PLC in die IO Baugruppe besteht. Welche Zykluszeit erreicht wird, bestimmt das PLC Programm, welches i.d.R. wesentlich langsamer läuft und bei schnellen Steuerungen für Latenzzeiten im Bereich vom 1 ms vom lesen eines Bits aus der IO zum Schreiben in einen IO sorgt.
Beim RevPi sieht es dann so aus, dass das lokale IO-Datenabbild im Gatewaymodule immer dem über den Feldbus übertragenem IO-Abbild entspricht. Das ist unabhängig von der gewählten Zykluszeit des Feldbusses, weil wir Module nur zertifiziert bekommen, die auch alle Taktraten des Feldbusses unterstützen, welche die jeweiligen Normen vorsehen.
Wenn also alle 10 us ein IO-Telegramm an den Slave gesendet wird, dann können dort alle 10 us auch andere Daten im IO-Prozessdatenabbild des Slaves stehen. Einige unserer Gateways arbeiten deshalb mit feldbus-spezifischen ASICs (z.B. Profibus), welche diese hohen Verarbeitungsgeschwindigkeiten ermöglichen. Ob der master allerdings überhaupt einen so schnellen zyklus in seiner Verarbeitung hat, ist eine ganz andere Frage. In der Regel wohl eher nicht, denn Zykluszeiten von 10 us sind bei PLCs eher unüblich.
Nun müssen diese Daten aber ja auch über die PiBridge in das Prozessabbild unseres Revpi Core. Und da wird das IO-Prozessabbild eben nur alle 10 ms gespiegelt. Der aktuelle Zustand des Io PAs wird also genommen und übertragen (immer konsistent!). Wenn sich zwischen zwei Übertragungen die IO Daten ändern, dann bekommt dies der RevPi Core definitiv nicht mit. Das ist halt ganz im Sinne einer zyklischen Datenverarbeitung nach EN61131 und eine andere Denkweise, als eventbasierte Datenströme über Protokolle wie TCP/IP, USB, etc., bei denen jedes eintreffende Datenpaket neue Informationen transportiert.
Ein weiterer Schritt ist dann ja noch die Verarbeitung der Daten, die im Prozessabbild stehen, z.B. durch eine "soft-PLC" wie logi.cad3. Diese Software arbeitet ja auch wieder zyklisch und ihre Zykluszeit ist unter Umständen noch mal langsamer, so dass auch einige Änderungen im PA des RevPi Core von dieser Software gar nicht wahrgenommen werden. unter dem Strich ist das ganze System wie ein Tiefpassfilter für IO-Ereignisse. Alles was kürzer als die längste Zykluszeit ist wird nicht zwangsläufig von diesem System erkannt, sondern herausgefiltert. Daher ist es wichtig, dass man die Applikation und die kürzesten Ereignisse kennt, die man verarbeiten will. diese Zeit (zusammen mit der Latenzzeit und dem Jitter der Latenzzeit) legen fest, ob die Echtzeitfähigkeit des Systems für die zu steuernde Anwendung ausreicht.
Für azyklische Datenströme sind unsere Gateways nicht geeignet. Solche Datenströme sollten mit Eventbasierten Protokollen und verarbeitet werden und ggf. auch nicht über PiControl und das PA ausgetauscht werden, sondern über andere Mechanismen, wie sie Linux z.B. für USB oder TCP/IP bereitstellt.
Ich hoffe, ich konnte ein wenig Klarheit in die Gateway-Kommunikation bringen.
Zentrale Informationen gibt es übrigens am besten im Blog (leider sind einige der ursprünglichen Informationen nicht mehr so ganz up-to-date) oder in den Datenblättern unter "Projekt" und dann "Gateway". Danke für den Hinweis, dass dort die Zykluszeit des Datenaustauschs mit dem RevPi fehlt, wir werden das ergänzen.
Auf einem klassischen Feldbus werden IOs ja zyklisch übertragen, egal ob sich Werte ändern oder nicht. Wenn also ein Profibus mit 10 Mbps konfiguriert ist, dann bedeutet dies nicht, dass eine Simatic in einer Sekunde 10 Mbit unterschiedliche Prozessdaten überträgt. Allerdings bedeutet es in der Regel, dass eine sehr kurze Latenzzeit von wenigen µs zwischen dem Senden eines Bits aus der PLC in die IO Baugruppe besteht. Welche Zykluszeit erreicht wird, bestimmt das PLC Programm, welches i.d.R. wesentlich langsamer läuft und bei schnellen Steuerungen für Latenzzeiten im Bereich vom 1 ms vom lesen eines Bits aus der IO zum Schreiben in einen IO sorgt.
Beim RevPi sieht es dann so aus, dass das lokale IO-Datenabbild im Gatewaymodule immer dem über den Feldbus übertragenem IO-Abbild entspricht. Das ist unabhängig von der gewählten Zykluszeit des Feldbusses, weil wir Module nur zertifiziert bekommen, die auch alle Taktraten des Feldbusses unterstützen, welche die jeweiligen Normen vorsehen.
Wenn also alle 10 us ein IO-Telegramm an den Slave gesendet wird, dann können dort alle 10 us auch andere Daten im IO-Prozessdatenabbild des Slaves stehen. Einige unserer Gateways arbeiten deshalb mit feldbus-spezifischen ASICs (z.B. Profibus), welche diese hohen Verarbeitungsgeschwindigkeiten ermöglichen. Ob der master allerdings überhaupt einen so schnellen zyklus in seiner Verarbeitung hat, ist eine ganz andere Frage. In der Regel wohl eher nicht, denn Zykluszeiten von 10 us sind bei PLCs eher unüblich.
Nun müssen diese Daten aber ja auch über die PiBridge in das Prozessabbild unseres Revpi Core. Und da wird das IO-Prozessabbild eben nur alle 10 ms gespiegelt. Der aktuelle Zustand des Io PAs wird also genommen und übertragen (immer konsistent!). Wenn sich zwischen zwei Übertragungen die IO Daten ändern, dann bekommt dies der RevPi Core definitiv nicht mit. Das ist halt ganz im Sinne einer zyklischen Datenverarbeitung nach EN61131 und eine andere Denkweise, als eventbasierte Datenströme über Protokolle wie TCP/IP, USB, etc., bei denen jedes eintreffende Datenpaket neue Informationen transportiert.
Ein weiterer Schritt ist dann ja noch die Verarbeitung der Daten, die im Prozessabbild stehen, z.B. durch eine "soft-PLC" wie logi.cad3. Diese Software arbeitet ja auch wieder zyklisch und ihre Zykluszeit ist unter Umständen noch mal langsamer, so dass auch einige Änderungen im PA des RevPi Core von dieser Software gar nicht wahrgenommen werden. unter dem Strich ist das ganze System wie ein Tiefpassfilter für IO-Ereignisse. Alles was kürzer als die längste Zykluszeit ist wird nicht zwangsläufig von diesem System erkannt, sondern herausgefiltert. Daher ist es wichtig, dass man die Applikation und die kürzesten Ereignisse kennt, die man verarbeiten will. diese Zeit (zusammen mit der Latenzzeit und dem Jitter der Latenzzeit) legen fest, ob die Echtzeitfähigkeit des Systems für die zu steuernde Anwendung ausreicht.
Für azyklische Datenströme sind unsere Gateways nicht geeignet. Solche Datenströme sollten mit Eventbasierten Protokollen und verarbeitet werden und ggf. auch nicht über PiControl und das PA ausgetauscht werden, sondern über andere Mechanismen, wie sie Linux z.B. für USB oder TCP/IP bereitstellt.
Ich hoffe, ich konnte ein wenig Klarheit in die Gateway-Kommunikation bringen.
Zentrale Informationen gibt es übrigens am besten im Blog (leider sind einige der ursprünglichen Informationen nicht mehr so ganz up-to-date) oder in den Datenblättern unter "Projekt" und dann "Gateway". Danke für den Hinweis, dass dort die Zykluszeit des Datenaustauschs mit dem RevPi fehlt, wir werden das ergänzen.
Unser RevPi Motto: Don't just claim it - make it!
Re: Zykluszeit beim RevPi Core 3
NACHTRAG:
Ich habe mich noch einmal vergewissert und muss meine Informationen korrigieren:
Die 10 ms gelten nur auf dem Revpi Core 1. Bei dem RevPi Core 3 haben wir 5 ms eingestellt. Das CM1 hat dann bei 2 Gateways bereits 80% Systemlast, warum wir einen betrieb der Gateways am CM1 eigentlich nicht mehr empfehlen. Ein CM3 hat auf einem der 4 Kerne bei 5 ms eine Last von ca. 50%, was absolut akzeptabel ist. Aktuell ist ein Tuning dieser Werte leider nicht einfach machbar, es sei denn Du möchtest den Wert in der Quelldatei anpassen und den Kernel neu kompilieren (mit dem Risiko, dass die PiBridge eventuell dann nicht stabil und mit minimalem Jitter läuft, wenn Du den Wert wesentlich geringer einstellen würdest).
Diese aktuellen Angaben haben wir inzwischen in das Datenblatt und den Shop übernommen.
Ich habe mich noch einmal vergewissert und muss meine Informationen korrigieren:
Die 10 ms gelten nur auf dem Revpi Core 1. Bei dem RevPi Core 3 haben wir 5 ms eingestellt. Das CM1 hat dann bei 2 Gateways bereits 80% Systemlast, warum wir einen betrieb der Gateways am CM1 eigentlich nicht mehr empfehlen. Ein CM3 hat auf einem der 4 Kerne bei 5 ms eine Last von ca. 50%, was absolut akzeptabel ist. Aktuell ist ein Tuning dieser Werte leider nicht einfach machbar, es sei denn Du möchtest den Wert in der Quelldatei anpassen und den Kernel neu kompilieren (mit dem Risiko, dass die PiBridge eventuell dann nicht stabil und mit minimalem Jitter läuft, wenn Du den Wert wesentlich geringer einstellen würdest).
Diese aktuellen Angaben haben wir inzwischen in das Datenblatt und den Shop übernommen.
Unser RevPi Motto: Don't just claim it - make it!
Re: Zykluszeit beim RevPi Core 3
Hallo,
ich will diesen alten Thread noch mal aufgreifen für eine verwandte Frage zur Zykluszeit:
Mein RevPi Core3 schafft nur Zykluszeiten von rund >400ms (sig!). Ich vermute, es liegt am Programm, was darauf abläuft: Der RevPi ist mit einem AIO-Modul verbunden. Ein logiCAD Programm fährt an einem Ausgang ein Spannungstrapez langsam ab (über einen Timer TON), an einem anderen Eingang wird diese Spannung spaßeshalber gleich wieder gemessen. Zusätzlich laufen noch ein paar INTs als Zählervariablen hoch und alle 2 Sekunden blinkt die eine eingebaute LED des RevPi Cores, mehr passiert nicht. Messe ich die Spannungen mit einem DMM oder lasse mir live die Zustandsvariablen in logiCAD anzeigen (in den Programminstanzen), kann ich die oben genannten langsamen Zykluszeiten nachvollziehen.
Laut logi.cals liegt die Zykluszeit des RevolutionPi ja bei 500us (siehe hier) und lässt sich einstellen über die logiCAD-Engineering Software:
Im Projektbaum: RevolutionPi --> RevolutionPi --> RevolutionPiResource in der Zeile
Verwende ich ein sehr vereinfachtes Programm (das nur die eingebaute LED vom RevPi Core-Modul blinken lässt, auch über einen Timer TON), dann kann ich sehr schnelle Zykluszeiten erreichen von unter 50ms (validiert über Zustandsvariablenanzeige in den Programminstanzen).
Also scheint es wirklich an dem analogen AIO-Modul zu liegen!?
EDIT:
Der Haken ist wohl die Berechnung der Ausgangsspannung i_u_motor am AIO-Modul für das Spannungstrapez, z.B. hier der ansteigende Teil:
Die Zykluszeit von t_zeit_verg ist deutlich schneller, trotzdem wird i_u_motor nur alle 400ms aktualisiert.
ich will diesen alten Thread noch mal aufgreifen für eine verwandte Frage zur Zykluszeit:
Mein RevPi Core3 schafft nur Zykluszeiten von rund >400ms (sig!). Ich vermute, es liegt am Programm, was darauf abläuft: Der RevPi ist mit einem AIO-Modul verbunden. Ein logiCAD Programm fährt an einem Ausgang ein Spannungstrapez langsam ab (über einen Timer TON), an einem anderen Eingang wird diese Spannung spaßeshalber gleich wieder gemessen. Zusätzlich laufen noch ein paar INTs als Zählervariablen hoch und alle 2 Sekunden blinkt die eine eingebaute LED des RevPi Cores, mehr passiert nicht. Messe ich die Spannungen mit einem DMM oder lasse mir live die Zustandsvariablen in logiCAD anzeigen (in den Programminstanzen), kann ich die oben genannten langsamen Zykluszeiten nachvollziehen.
Laut logi.cals liegt die Zykluszeit des RevolutionPi ja bei 500us (siehe hier) und lässt sich einstellen über die logiCAD-Engineering Software:
Im Projektbaum: RevolutionPi --> RevolutionPi --> RevolutionPiResource in der Zeile
Code: Select all
TASK DefaultTask(INTERVAL := TIME#400ms, PRIORITY := 38229);
Also scheint es wirklich an dem analogen AIO-Modul zu liegen!?
EDIT:
Der Haken ist wohl die Berechnung der Ausgangsspannung i_u_motor am AIO-Modul für das Spannungstrapez, z.B. hier der ansteigende Teil:
Code: Select all
i_u_motor := i_u_min + ((i_u_max-i_u_min)/TO_INT(IN := t_an))*TO_INT(IN := t_zeit_verg);
Re: Zykluszeit beim RevPi Core 3
Falls hier noch mal jemand drüber stolpert, will ich meine Frage selbst beantworten:
Mein Fehler lag in der falschen Verwendung von Integern (TO_INT(t_zeit_verg) gibt einen Integer zurück). Die Variable "vergangene Zeit" wurde in t_zeit_verg gespeichert und auch mit der angegebenen Zykluszeit aktualisiert. TO_INT() änderte sich jedoch natürlich nur, wenn eine neue Ganzzahl (hier: Sekunden) erreicht wurde. Daher sah es für mich so aus, als würde die Zykluszeit nicht eingehalten, obwohl sie eingehalten wurde. Die letzte Code-Zeile aus meinem vorangehenden Post müsste Floats verwenden und also lauten
wobei die Variablenformate wie folgt sind:
Mein Fehler lag in der falschen Verwendung von Integern (TO_INT(t_zeit_verg) gibt einen Integer zurück). Die Variable "vergangene Zeit" wurde in t_zeit_verg gespeichert und auch mit der angegebenen Zykluszeit aktualisiert. TO_INT() änderte sich jedoch natürlich nur, wenn eine neue Ganzzahl (hier: Sekunden) erreicht wurde. Daher sah es für mich so aus, als würde die Zykluszeit nicht eingehalten, obwohl sie eingehalten wurde. Die letzte Code-Zeile aus meinem vorangehenden Post müsste Floats verwenden und also lauten
Code: Select all
r_u_motor := i_u_min + ((i_u_max-i_u_min)/TO_REAL(IN := t_an))*TO_REAL(IN := t_zeit_verg);
i_u_motor := TO_INT(r_u_motor);
Code: Select all
VAR // mit default-Werten initialisieren
i_u_min: INT := 500; // mV, Minimalspannung, Spannungsboden
i_u_max: INT := 3500; // mV, Maximalspannung
t_an: TIME := T#3s500ms; // Zeit, Anstiegszeit für die Spannungsrampe
END_VAR
VAR_OUTPUT
i_u_motor: INT := 0; // mV, zu berechnende Spannung für den Motor (genauer: für den FU)
r_u_motor: REAL :=0; // Motorspannung als float, Hilfsvariable zur Berechnung
END_VAR