Zeitkritische GPIO Anwendung

  • Ich überlege, ob der Raspberry Pi (3B) hinreichend schnell für eine produktionstechnische Steuerungsaufgabe ist. Es geht dabei um die Schaltung relativ schneller Ventile, die zur Materialbearbeitung auf einem Fließband dienen.


    Folgende Anforderungen sind gegeben:
    - Es müssten ein bis drei GPIO Eingänge ausgewertet werden.
    - Abhängig vom Eingangssignal müsste nach einer Wartezeit (t1, t2 oder t3) ein GPIO Ausgang für eine Zeitdauer (t4, t5 oder t6) eingeschaltet werden (um das Ventil anzusteuern).
    - Die Werte t1, t2, t3 liegen voraussichtlich im Bereich von "null" bis ca. 20 ms - fallweise auch höher. Möglicherweise sind auch alle drei stets gleich - es würde dann also einer genügen.
    - t4, t5, t6 >= 40 ms - bis hin zu ca. 1000 ms.
    - Die Geschwindigkeit der Maschine beträgt ca. 0,125 mm/msec. Also acht Millisekunden pro Millimeter. Die Abweichungen sollten nicht mehr als 4 ms ~ 0,5 mm betragen und sich natürlich auch nicht aufaddieren.
    - Die nachfolgenden Zeitverzögerungen durch die elektronische Ansteuerung der Ventile durch Transistoren/Optokoppler oder was auch immer sind nach meiner Einschätzung vernachlässigbar.


    Evtl. kommt je ein weiterer Eingang und Ausgang dazu - die wären aber nicht zeitkritisch.


    Für die drei Eingänge wären ggf. also je zwei Werte nötig - insgesamt also sechs ( t1 - t6 ).
    Die Werte könnten auf der Benutzerschnittstelle jeweils beliebig eingestellt werden.
    Gegenüber einer Hardware-Schaltungslösung aus Timern, Quarzen, Teilern, Potis, Kondensatoren, Widerständen o. ä. hätte der Pi den Charme einer relativ einfachen Realisierung der Logik, einer verständlichen Benutzerschnittstelle, einer exakten Parametrisierung und einer bei Defekten leicht austauschbaren Hardware. Ein kleiner Touchscreen würde das ganze sogar richtig sexy machen! ;)
    Der Pi wäre nur für diese Steuerung eingesetzt und müsste keine weiteren Aufgaben bewältigen, die Last wäre also sehr gering. Netzwerkanbindung ist nicht nötig. Notfalls muss nicht mal eine grafische Benutzeroberfläche sein. Eine einfache alphanumerische Bedienoberfläche würde genügen.


    Hat jemand Erfahrung mit zeitkritischen Zugriffen auf die GPIOs? Mit welchen Verzögerungen ist schon durch die programmtechnische Ansprache der GPIOs (über die Bibliotheken oder APIs und das Interrupthandling) zu rechnen?


    Schafft der Pi diese kurzen Zeiten mit hinreichender Genauigkeit? Nach allem, was ich gelesen habe, liegen die Verzögerungen beim Pi in Bereichen bis 500 µs - allerdings bin ich nicht sicher, ob es nicht in Einzelfällen auch mal deutlich mehr sein kann... Ein hängendes System, das die Ventile sekundenlang nicht schaltet, wäre schlecht.


    Ich habe von einem Realtime-Kernel gelesen. Ist es hier ratsam oder notwendig, einen RT-Kernel einzusetzen? Hat jemand Erfahrung mit diesem Kernel und dem Zugriff auf GPIOs? Nach allem, was ich gelesen habe. liegen die Verzögerungen mit dem RT-Kernel auch bei hoher Last unter 200 µs.


    Gibt es Unterschiede in den Programmiersprachen hinsichtlich der Zeitverzögerungen? Welche Sprache ist ggf. geeignet? Einfach wäre die Programmierung in Python. Ich scheue mich aber auch nicht C#, C/C++ einzusetzen, wenn es erforderlich ist. (Assemblerprogrammierung wollte ich aber wirklich vermeiden! ;) Ist Python als Interpretersprache zu langsam? Angeblich gibt's auch einen Compiler für Python - würde das was bringen?


    Bin für jeden Tipp und jede Erkenntnis dankbar. :helpnew::danke_ATDE:

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • zeitkritisches mit Arduino oder AVR und Daten für Weiterverarbeitung zum PI

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hallo Gnom,


    herzlich Willkommen in unserem Forum!



    Bei zeitkritischen Anwendungen, die echtzeitfähig sein müssen, verbietet sich eigentlich der Einsatz eines Raspberry Pi - sofern kein RT-OS eingesetzt werden soll.


    Ich setze bei solchen Sachen einen Arduino ein, der Sensoren erfasst und digitale Ausgänge setzt etc. - die Visualisierung erfolgt dann über den Raspberry Pi.


    Die Wahl der Programmiersprache würde ich davon abhängig machen, was Du kannst. Bei einem nicht-echtzeitfähigen Betriebssystem wirst Du um C / C++ nicht herumkommen.


    Bei einer Lösung mit Arduino & Raspberry Pi ist die Programmiersprache auf dem RPi weniger entscheidend, wobei ich da auch bei C/C++ bleiben würde.


    Bei dieser Hardware-Kombination würde ich auch mal einen Blick auf Processing werfen. Das ist quasi C++ für den Raspberry Pi und fast identisch mit dem Arduino-C++. Das heißt, Du brauchst nur eine Syntax zu erlernen. Processing erlaubt beispielsweise auch die Programmierung von Visualisierungen.



    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Edited once, last by Andreas ().


  • Bis hier hin wäre das mit einem Computer wie dem Pi kein Problem, aber:



    - Die Geschwindigkeit der Maschine beträgt ca. 0,125 mm/msec. Also acht Millisekunden pro Millimeter. Die Abweichungen sollten nicht mehr als 4 ms ~ 0,5 mm betragen und sich natürlich auch nicht aufaddieren.
    - Die nachfolgenden Zeitverzögerungen durch die elektronische Ansteuerung der Ventile durch Transistoren/Optokoppler oder was auch immer sind nach meiner Einschätzung vernachlässigbar.


    Ich habe von einem Realtime-Kernel gelesen. Ist es hier ratsam oder notwendig, einen RT-Kernel einzusetzen? Hat jemand Erfahrung mit diesem Kernel und dem Zugriff auf GPIOs? Nach allem, was ich gelesen habe. liegen die Verzögerungen mit dem RT-Kernel auch bei hoher Last unter 200 µs.


    Wozu der Aufwand? Wieso möchtest du aus einem Computer auf biegen und brechen etwas anderes machen als es nun mal ist?
    Wenn deine Anwendung wirklich derart anfällig für nur minimale Abweichungen ist solltest du so wenig wie möglich "Hardware" dazwischen haben und das wirft einen Computer automatisch aus dem Rennen, egal ob mit RTOS oder sonstigen Tricks.

  • Das Problem ist bei Betriebssystem, dass diese die Prozesse untereinander wechseln (scheduler) und dadurch entstehen unterschiedliche zeit (jitter). Das ist für eine GPIO anwendung im zeitkritischen Bereich nicht vorteilhaft. Der zeitkritische Bereich liegt bei Raspbian (aus Erfahrung) bei unter 2-4ms, kann varieren abhängig vom Betriebsystem (Version und Addons).


    Raspbian:
    Es ist möglich ein Thread auf einem Kern laufen zu lassen sowie die Prio (scheduler) eines Threads hoch zu setzten aber bringt nur minimal was, zudem kann es sein, dass das Betriebssystem abschmiert.

  • Vielen Dank für die netten Antworten.


    Ich werde es mit einem Arduino Mega probieren. Der ist sicher schnell genug und hat so viele Eingänge, dass ich die Parameter übersichtlich mit BCD-Codierschaltern eingeben kann. Der Aufwand für die Benutzerschnittstelle ist damit minimal. Hätte ich ja auch selbst drauf kommen können, dass ein Arduino viel weniger Overhead hat. :wallbash:
    Die Programmierung scheint recht einfach zu sein. Ein bisschen C kann ich auch...

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Guck dir aber auch mal einen Freescale an - den würde ich hierfür evtl. bevorzugen. Zum Beispiel der FRDM-KL25Z, FRDM-KW40Z oder FRDM-K64F ... Die Community ist des Arduino oder Pi's ebenbürtig.


    => https://www.heise.de/ct/artike…bau-Massstab-2848834.html ...bzw... https://www.heise.de/newsticke…ellfahrzeuge-2818782.html