Mehrere Programme gleichzeitig laufen lassen

  • Hallo an alle,


    ich habe nun meine Gewächshaus Steuerung fast fertig. Ich habe die Aufgaben in Python auf 3 Programme aufgeteilt, die einzeln wunderbar funktionieren.
    Die drei Programme sind:


    -Wieder Befüllung einer Regentonne mit Hilfe eines Magnetventiels und einem Min- und einen Maxsensor.
    -Bewässerung der Pflanzen über eine Pumpe nach Zeit
    -Öffnung der Fenster nach Zeit, mit Hilfe zweier Servos.


    Nun möchte ich diese Parallel laufen lassen, doch irgendwie stören sich diese und ich weiß nicht wieso. Meistens ist, auch wenn alle Programme am laufen sind nur ein Programm Aktiv und die Anderen laufen dann gar nicht.


    Wie kann ich also die drei Programme gleichzeitig laufen lassen sodass jede Ausführung über die GPIOs funktioniert?


    Danke im voraus an alle...


    Raspberry Pi: 3b
    Betriebsystem: Raspbian
    Python version: 3

  • Also du willst 3 Programme, die alle auf GPIOs zugreifen gleichzeitig laufen lassen?
    Ich glaube das die sich schwer tun mit den GPIOs, wie wärs mit einem Programm was ungefähr so aussieht:


    import subprocess



    Ich empfehle dir LogDateien mit genauer Zeitangaben und allen Strings anzugeben, um besser Debuggen zu können

  • Erstmal vielen Dank für die Antwort,


    Doch leider laufen die Programme ja so nicht Parallel sondern nacheinander, und das ist für eine Zeitsteuerung nicht so toll... denn so kann es zu auch sein , das wenn eine Sache nicht funktioniert, der Rest nicht weiter geht etc... daher wollte ich es auch in einzelnen Programmen machen.


    LG

  • Der von linusg beschriebene Weg birgt ein Hindernis: Wird das über SSH gemacht und anschließend die Session beendet, werden auch die in den Hintergrund geschickten Scripts beendet. Um das zu verhindern stellt man "nohup" voran.


    Wenn du auch noch jederzeit die Ausgabe der Scripts sehen möchtest empfiehlt es sich die Scripts in einem sog. Virtuellen Terminal auszuführen. Dafür bietet sich "tmux" oder "screen" an.


    Wenn die Scripts wirklich unabhängig und auch ohne Wissen voneinander laufen sollen, dann führt man entweder jedes Script separat so aus dass es im Hintergrund ausgeführt wird, oder richtet ein weiteres Python Script (zB "Main.py") ein worüber die anderen dann kontrolliert über 'multiprocessing' ausgeführt werden, natürlich auch parallel.


    Wenn die Scripts aber voneinander wissen sollen/müssen, gäbe es selbstverständlich auch mit Python andere Wege...

  • Hallo,


    1. Vergiß' den Post von TheOverclocker - wenn du ein Python-Skript aus einem anderen Python-Skript heraus per Subprocess ausführst, kannst du dir zu 99,9% sicher sein, dass du was falsch gemacht hast.
    2. meigrafd hat es ja schon gesagt: wenn du quasi-Parallelität brauchst, dann brauchst du ein Hauptpgramm, das alles kontrolliert. Beim Start kannst du den Unterprozessen ein Instanz von GPIO mitgeben und später über eine Queue mit den Prozessen kommunizieren.


    Alternativ könntest du auch eine Art Message Queue einrichten, in der alle anstehenden Aufgaben hinterlegt sind und die dann vom Hauptprogramm sequentiell abgearbeitet werden.


    Gruß, noisefloor

  • Hallo marhar,


    wie "meigrafd" schon geschrieben würde ich auch die Python Scripte im Hintergrund laufen lassen. Dies kann man machen indem man an den Startbefehl ein Leerzeichen und danach ein "&" daran hängt, also Bsp.: python xxxx.py &


    So kann man ein Script nach dem anderen starten. Wenn Du allerdings ein GPIO Pin durch mehrere Scripte verwendest wird dies nicht funktionieren, vermute ich.


    Bin selbst noch lange kein Profi aber ich hoffe dass ich helfen konnte und nicht all zuviel Blödsinn geschrieben habe


    Grüße

  • Das mit "&" dahinter setzen wurde ja bereits in Beitrag#4 gezeigt. Wenn man sich aber via SSH verbindet, das Script dann mit "python xxxx.py &" in den Hintergrund schickt und dann die SSH Verbindung wieder trennt, wird auch das Script beendet. Abhilfe: "nohup python xxxx.py &" oder besagte tmux / screen ...
    Eine Weitere Möglichkeit wurde kürzlich am Ende folgenden Beitrags erwähnt: http://www.forum-raspberrypi.d…erry?pid=293996#pid293996 ... Hinter dem "Prozess im Hintergrund" Link in dem Beitrag verbirgt sich auch eine genauere Erklärung.


  • Alternativ sollte Screen als Tool auch funktionieren, oder?


    Generell zu empfehlen, wenn man sich per SSH verbindet.

    .NET-, Unity3D-, Web-Dev.
    Mikrocomputer-Hobbyist.

  • Hallo zusammen,


    hierfür nutze ich ein Programm namens MONITOR.


    Über eine Konfigurationsdatei definiert man eine beliebige Anzahl der zu startenden Programme und Pfade zu den Programmen. In dieser Konfigurationsdatei kann man auch festlegen, welcher Programmstart mit dem Eintreten eines bestimmten Ereignisses verbunden sein soll. Weiterhin kann man auch festlegen, bei welchem Ereignis ein Programm unterbrochen, aktiviert, abgeschossen oder erneut gestartet werden soll.


    Das Programm selber ist vergleichsweise simpel gestrickt - die Magie steckt in der Konfigurationsdatei und der damit verbundenen Möglichkeiten.



    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.

    Einmal editiert, zuletzt von Andreas ()

  • Zitat von "Timm Thaler" pid='294064' dateline='1501874569'


    Wäre es nicht sinnvoller, die Scripte per cron beim Hochfahren zu starten?


    Ja, wahrscheinlich schon und als Daemon einrichten.


    Beim zweiten Lesen glaube ich aber, dass es vor allem darum geht, den gleichzeitigen Zugriff auf das GPIO Interface zu lösen.

    .NET-, Unity3D-, Web-Dev.
    Mikrocomputer-Hobbyist.

  • Denke ich auch, dafür wär es aber gut die Skripte zu kennen, um erkennen zu können ob diese sich eventuell gegenseitig beeinflussen.


    Bspw. wie wirkt sich ein (angenommen RPi.GPIO wird verwendet) GPIO.cleanup() auf die anderen beiden Skripte aus. Schätzungsweise böse, aber noch nicht getestet.

  • Wenn 3 Scripts parallel die GPIOs ansprechen/nutzen darf kein Script zwischendurch GPIO.cleanup() ausführen, denn das würde alle GPIOs wieder zurücksetzen.
    Sofern die Scripts unterschiedliche GPIOs nutzen gibt es da aber keine weiteren Probleme.
    Wenn aber zB Script#1 die selben GPIOs nutzt wie Script#3 kann natürlich Chaos entstehen wenn #1 einen GPIO ausschaltet, der auch aus bleiben soll, aber #3 diesen kurze Zeit später wieder einschaltet... Dann sollte man entweder sein Konzept noch mal überlegen oder wie bereits erwähnt ein zentrales Steuer-Programm/Script einführen sodass bei jedem Schaltvorgang vorher kontrolliert wird ob eine andere Prozedur bereits "was vor hatte". Da gäbe es aber wie schon erwähnt freilich mehrere Möglichkeiten.


    marhar sollte uns aber einfach mal die Scripts zeigen und genau erklären was zu welchem Zeitpunkt ausgeführt wird - dann brauchen wir hier nicht wild spekulieren und alle Eventualitäten abdecken.



    Andreas : Das von dir erwähnte "monitor" scheint kein reguläres Tool im Repository zu sein? Daher wäre es besser du gäbst auch einen Link an, ansonsten wär die Info leider nutzlos.


    Renão : "screen" ist das bekannteste Tool seiner art, besser ist jedoch "tmux".

  • Hallo,


    Andreas : hat MONITOR irgendwelche Vorteile gegenüber einer systemd Service Unit? Nach deiner Beschreibung macht das Programm nichts anderes als systemd. Vermutlich gab es MONITOR aber schon vor systemd ;-) Gehört habe ich von dem Programm aber noch nie...


    Früher, also vor systemd, war supervisord noch rechts gängig. Aber mit systemd hat supervisord kaum noch spezifische Vorteile.


    systemd hat gegenüber cron den Vorteil, dass man die Abhängigkeiten besser definieren kann.


    Gruß, noisefloor

  • Hallo Meigrafd, hallo Noisefloor,


    Zitat von "meigrafd" pid='294095' dateline='1501927961'


    Andreas : Das von dir erwähnte "monitor" scheint kein reguläres Tool im Repository zu sein? Daher wäre es besser du gäbst auch einen Link an, ansonsten wär die Info leider nutzlos.


    MONITOR ist eine Eigenentwicklung von mir und diente im Rahmen einer Auftragsentwicklung dazu, bestimmte Features zu erreichen, die anderweitig wahrscheinlich nur nach einer wesentlich intensiveren Beschäftigung mit den Tiefen des Betriebssystems möglich gewesen wäre.


    Da es sich um eine Auftragsarbeit handelt, verbietet sich Link & Code. ;) Das Programm besteht aus rund 200 Zeilen, wobei ein Großteil auf die GUI und das Eventhandling entfällt. Der Kern der Anwendung besteht in der Auswertung der Konfiguration und Anstoßen entsprechender Aktionen.


    Ob die "Info nutzlos" ist, muss jeder selber beurteilen. Ich habe für mich den Schluss gezogen, das bestimmte System-Interna recht aufwändig zu erschließen sind oder es wenig Sinn macht, sich möglicherweise nur kurzfristigen Gegebenheiten des Betriebssystems zu unterwerfen. Dafür habe ich in den vergangenen knapp 40 Jahren zuviel kommen und gehen gesehen.


    Sich Hinsetzen und selber ein Tool zu entwickeln macht mehr Spaß und man lernt auch mehr dabei, als einfach nur irgendwelche "Mustervorlagen" ohne Verstand abzuändern und per Try&Error sich einem Ziel nur langsam anzunähern. Die Entwicklung von MONITOR hat gerade mal eine halbe Stunde gedauert. Solange brauche ich üblicherweise, um mir durch eine Internet-Recherche einen Überblick über mögliche Lösungsansätze zu verschaffen. Wenn ich bedenke, dass ich dann dieses und jenes ausprobiere, ändere, verwerfe, was Neues ausprobiere, dann führt die Eigenentwicklung in aller Regel deutlich schneller zum Ziel.



    Zitat von "noisefloor" pid='294099' dateline='1501929852'


    Andreas : hat MONITOR irgendwelche Vorteile gegenüber einer systemd Service Unit? Nach deiner Beschreibung macht das Programm nichts anderes als systemd. Vermutlich gab es MONITOR aber schon vor systemd ;-) Gehört habe ich von dem Programm aber noch nie...


    Die Frage kann ich Dir noch nicht mal beantworten, da ich mich mit systemd nicht beschäftigt habe. Der Vorteil von MONITOR besteht einfach darin, dass ich es programmiert habe und ich deswegen auch genau weiß, was dort passiert und was ich machen muss, um ein bestimmtes Systemverhalten hervorzurufen, um das Zusammenspiel mehrerer unabhängig laufender Programme (Anwendungen, Tools, ...) zu ermöglichen.



    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.

    Einmal editiert, zuletzt von Andreas ()

  • Zitat von "Andreas" pid='294181' dateline='1502005971'


    Da es sich um eine Auftragsarbeit handelt, verbietet sich Link & Code. ;)


    :wallbash:


    Was hat diese Information dann noch für einen Nutzen, zumal in deinem ersten Beitrag nicht mals beschrieben steht dass das eh nie jemand von uns zu Gesicht kriegen würde?
    In wiefern kann das dem TE bei seinem Anliegen helfen? Was hat er von dieser Info?
    Soll jetzt jeder sich ein OS selber schreiben nur weil er ne Frage zu nem OS hat?


    Also sorry aber das ganze kommt seltsam rüber