HC-SR04 Ultraschallmessung. Skript bleibt sporadisch hängen, Messung schlägt fehl...

  • Guten Abend liebe RPi-Freunde,

    ich habe derzeit den Ultrasonic Ultraschallsensor im Einsatz, welcher im derzeitigen Projekt eine wichtige Entfernungsmessung macht, welche zuverlässig laufen soll.
    Es kommt sporadisch vor, dass folgendes Beispielscript in der Ausführung hängen bleibt im Bereich der Messung.
    Es wird dann noch der print "Starte Messung.." Befehl ausgeführt, ansonsten nichts wiedergegeben.

    Kann man (generell gefragt) ein Python-Script verlassen wenn es nicht durchläuft/stoppt und hängen bleibt?

    Ich konnte bisher im Netz nichts zu diesem Problem finden, ich schließe aus dass es am Sensor liegt, denn diesen tauschte ich bereits gegen einen anderen aus zu Testzwecken.

    Vielen könnt ihr mir helfen :angel:

    Schönen Abend an alle

    opc

    Hier der Testcode:

  • HC-SR04 Ultraschallmessung. Skript bleibt sporadisch hängen, Messung schlägt fehl...? Schau mal ob du hier fündig wirst!

  • Zwei Dinge würde ich machen:

    1) Deine while Loops sind busy loops und das ist ziemlich CPU fressend. Ich würde den Code so umschreiben, dass bei einem gewünschten Flankenwechsel im GPIO weitergemacht wird. Siehe z.B. hier

    2) Würde ich Deinen Code weiter mit print Zeilen instrumentieren um die genauere Stelle herauszufinden wo es hängt.

  • ich würde erstmal das GPIO-Warning einschalten und das "try" und "except" entfernen, dann bekommst du sicher auch die passenden Meldungen um dein Problem lösen zu können.

    Kann es sein, dass dein Script in einer der beiden While-Schleifen zu GPIO.input(Echo) hängen bleibt?


  • Kann man (generell gefragt) ein Python-Script verlassen wenn es nicht durchläuft/stoppt und hängen bleibt?

    Wenn man das einbaut, ja :fies: Hast du aber eigentlich bereits getan -> KeyboardInterrupt
    Du könntest aber auch die Bedingung der while verändern... Ein Beispiel dazu am Ende meines Beitrags

    Was ich aber auch noch anmerken muss ist das dein Script etwas fehlerhaft ist:
    - Du scheinst da einen Einrückungsfehler bei "start" und "stop" zu haben, dadurch wird die Distanzmessung verfälscht. Die Distanz wird anhand dessen angezeigt wie lange der Echo-Pin an ist

    Im Prinzip läuft das so ab:
    Trigger muss für 10µs (0.01ms ; 0.00001s) eingeschaltet sein sodass ein Signal raus geschickt wird.
    Ein Echo benötigt max. 20µs bis es zurück kommt. Wenn es länger dauert ist die Distanz zu groß und "out of range". Der HC-SR04 kann maximal 4m erfassen.
    Der Echo-Pin signalisiert dann durch die Dauer des HIGH die Distanz, also die verstrichene Zeit die der pin auf HIGH ist dient dann zur Berechnung der Distanz.

    Signal wird über TRIG gesendet. Solange ECHO auf 0 ist wird die StartZeit gesetzt. Echo wird empfangen -> Echo-Pin geht auf HIGH und bleibt so lange HIGH wie das Ultraschall-Signal gebraucht hat um zwischen senden und empfangen benötigt hat.

    Du musst also die "start" Zeit da setzen wo ECHO auf 0 gesetzt wird, und "stop" dort wo ECHO auf 1. Die Differenz dieser beiden Zeiten kann dann zur Berechnung der Distanz genutzt werden


    Falsch:
    [code=php]
    def messung():
    GPIO.output(Trig, 0)
    time.sleep (0.1)
    print ""
    print "Starte Messung..."
    GPIO.output(Trig, 1)
    time.sleep(0.00001)
    GPIO.output(Trig, 0)
    start = time.time()

    while GPIO.input(Echo) == 0:
    pass
    start = time.time()
    while GPIO.input(Echo) == 1:
    pass
    stop = time.time()[/php]

    Besser:
    [code=php]
    def messung():
    GPIO.output(Trig, 0)
    time.sleep (0.1)
    print ""
    print "Starte Messung..."
    GPIO.output(Trig, 1)
    time.sleep(0.00001)
    GPIO.output(Trig, 0)
    start = time.time()

    while GPIO.input(Echo) == 0:
    start = time.time()
    while GPIO.input(Echo) == 1:
    stop = time.time()
    [/php](um Fehler zu vermeiden, da der Echo pin ggf schon recht früh getriggert seon könnte, wird "start" schon früher gesetzt)

    Da der HC-SR04 mit 5V arbeitet, brauchst du vor dem ECHO pin auch einen Spannungsteiler, da die GPIO's des Raspberrys nur 3V3 vertragen - hast du daran gedacht?


    Und eigentlich ist das "return" in deiner Anweisung dazu da auch entsprechend genutzt zu werden ;)
    Beispiel wies imho besser wäre:

    Spoiler anzeigen

    [code=php]# -*- coding: utf-8 -*-
    import RPi.GPIO as GPIO
    import time

    Trig = 18
    Echo = 15
    LED = 16

    GPIO.setmode(GPIO.BOARD)
    GPIO.setup(Trig, GPIO.OUT)
    GPIO.setup(Echo, GPIO.IN)
    GPIO.setup(LED, GPIO.OUT)

    running = True

    def messung():
    GPIO.output(Trig, 0)
    time.sleep (0.1)
    print ""
    print "Starte Messung..."
    GPIO.output(Trig, 1)
    time.sleep(0.00001)
    GPIO.output(Trig, 0)
    start = time.time()
    while GPIO.input(Echo) == 0:
    start = time.time()
    while GPIO.input(Echo) == 1:
    stop = time.time()
    #distanz = (stop - start)*34000/2
    distanz = (stop - start)*17000
    return distanz

    try:
    while running:
    abstand = messung()
    print("%.2f cm" % abstand)
    if abstand < 20:
    GPIO.output(LED, 1)
    time.sleep(2)
    else:
    GPIO.output(LED, 0)
    time.sleep(2)
    except KeyboardInterrupt:
    running = False
    print("Abbruch durch Benutzer")
    GPIO.cleanup()[/php]

    Quellen:
    http://www.gtkdb.de/index_36_2272.html
    http://www.tutorials-raspberrypi.de/gpio/entfernun…sensor-hc-sr04/
    http://www.raspberrypi-spy.co.uk/2012/12/ultras…-python-part-1/

    Eine Optimierung wäre aber das ganze auf Interrupts zu ändern

  • Hallo zusammen,

    vor ein paar Tagen habe ich den HC-SR04 auf einen Servo-Motor gesetzt, an einen Arduino angeschlossen. Der Motor dreht sich im Halbkreis, der HC-SR04 misst den Abstand zu Gegenständen bis Wänden und zeichnet den Messwert in Abhängigkeit des Winkels auf. Die Messwerte werden auf die serielle Schnittstelle ausgegeben - parallel dazu liest ein Icon-Programm die serielle Schnittstelle aus und zeichnet die angehängte Graphik. Momentan erhalte ich etwa 90 Messwerte pro Sekunde.

    Die Messwerte und Polarkreise sind per Tastatur skalierbar...

    Sieht ganz nett aus, oder?


    Um zum Problem von opc zu kommen. Es liegt meiner Meinung nach daran, dass nach dem Ping-Signal auf Abwesenheit eines Echos gewartet wird. Wenn die erste while-Schleife beendet ist, liegt ja ein Echo vor. Dann wird aber nochmals auf Echo geprüft. Bei einem solch kurzen Ping-Signal mag Python nicht schnell genug sein, um das Echo (was ja bereits vorlag) nochmals erkennen zu können. Die Zeitdifferenz müsste also bereits nach der ersten while-Schleife ermittelt werden - aufs explizite Echo-Abfragen würde ich verzichten - da ohne Mehrwert.

    Mein Sensor - zusammen mit der Ansteuerung und Abfrage - kann auch 5 cm ziemlich genau messen.

    Beste Grüße

    Andreas

  • Danke für die zahlreichen Antworten!

    meigrafd: ja an den Spannungsteiler habe ich gedacht :) Ich bin zuerst deinem Tipp nachgegangen und habe "start" und "stop" vorgesetzt, das scheint die Lösung gewesen zu sein. Super!

    Gibt es -außer KeyboardInterrupt- einen Befehl der ein Skript beenden kann?
    Dies bräuchte ich bald für eine Art "Endschalter"-Schaltung... quasi es laufen mehrer if-Anweisungen ab, welche währenddessen durch den Endschalter unterbrochen werden, wie löst man eine solche Unterbrechung in Python?

  • dbv: Laut Datenblatt kann der HC-SR04 maximal 400cm und minimal 2cm erkennen, alles außerhalb dieses Bereiches ist "out of range". Aber es stimmt, es gibt da leider unterschiedliche Aussagen/Datenblätter, einige schreiben 4m, andere nur 3m - aber mein HC-SR05 kann 5m definitiv nicht mehr erkennen ;) Vielleicht gibts unterschiedliche Versionen? :s


    Andreas: Das ist schon Oke so, python ist auch schnell genug.
    Die erste while Schleife dreht sich so lange im Kreis wie der Echo Pin LOW ist (0). Sobald eine 'Antwort' empfangen wird bleibt der Echo-Pin solange auf HIGH wie die Antwort gebraucht hat - anhand dessen kann die Distanz errechnet werden.

    Nochmal anders:
    Signal wird über TRIG gesendet. Solange ECHO auf 0 ist wird die StartZeit gesetzt. Echo wird empfangen -> Echo-Pin geht auf HIGH und bleibt so lange HIGH wie das Ultraschall-Signal gebraucht hat um zwischen senden und empfangen benötigt hat, solange der Pin also HIGH ist wird immer wieder die StopZeit gesetzt.
    Wechselt der Pin dann wieder von HIGH auf LOW wird die 2.while Schleife beendet und die Berechnung findet statt.

    Vielleicht bin ich auch zu unfähig das verständlich zu erklären, deswegen hier mal eine andere Erklärung:


    Man könnte diese ganze Sache aber auch über Interrupts lösen um zumindest die CPU zu entlasten - ggf ist das ein Grund wieso es sich "aufhängt", denn diese while Schleifen verballern recht viel Last - alleine diese "while ... pass" Geschichte lässt die CPU Last auf 99% steigen - was utopisch ist.



    Gibt es -außer KeyboardInterrupt- einen Befehl der ein Skript beenden kann?
    Dies bräuchte ich bald für eine Art "Endschalter"-Schaltung... quasi es laufen mehrer if-Anweisungen ab, welche währenddessen durch den Endschalter unterbrochen werden, wie löst man eine solche Unterbrechung in Python?

    Ja, über signal ;)
    Siehe dazu: Script sanft beenden

  • Hallo Meigrafd,


    Andreas: Das ist schon Oke so, python ist auch schnell genug.
    Die erste while Schleife dreht sich so lange im Kreis wie der Echo Pin LOW ist (0). Sobald eine 'Antwort' empfangen wird bleibt der Echo-Pin solange auf HIGH wie die Antwort gebraucht hat - anhand dessen kann die Distanz errechnet werden.

    Nochmal anders:
    Signal wird über TRIG gesendet. Solange ECHO auf 0 ist wird die StartZeit gesetzt. Echo wird empfangen -> Echo-Pin geht auf HIGH und bleibt so lange HIGH wie das Ultraschall-Signal gebraucht hat um zwischen senden und empfangen benötigt hat, solange der Pin also HIGH ist wird immer wieder die StopZeit gesetzt.
    Wechselt der Pin dann wieder von HIGH auf LOW wird die 2.while Schleife beendet und die Berechnung findet statt.

    Vielleicht bin ich auch zu unfähig das verständlich zu erklären, deswegen hier mal eine andere Erklärung:

    Da liegt meines Erachtens ein Denkfehler vor:
    Ein Ultraschallimpuls von n µs breitet sich in einer Richtung aus. Das Ultraschallsignal wird von einem Objekt reflektiert.

    Die Zeit zwischen Absetzen des Impulses (erste Welle) bis zum Eintreffen der ersten reflektierten Welle entspricht dem doppelten Abstand Ultraschall-Sensor - Objekt. Über die Schallgeschwindigkeit und der Zeit erhält man den (doppelten) Abstand.

    Die Zeit des Impulses ist pille-palle. Sollte möglichst kurz sein, um bei kurzen Abständen erkannt werden zu können. Die Zeit, in der der Echo-Pin auf HIGH steht, wenn die reflektierte Welle eintrifft, hat mit der Entfernung gar nichts zu tun. Diese Zeit sollte sogar identisch mit der Impulsdauer des emittierten Impulses sein.

    Streng genommen müsste man noch die Impulsdauer zur Messzeit addieren (falls die Messzeit mit Abschluss des Impulses startet). Dies wird dann bei extrem kurzen Abständen zu besseren Ergebnissen führen.


    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

    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 (27. Januar 2015 um 23:58)


  • Die Zeit zwischen Absetzen des Impulses (erste Welle) bis zum Eintreffen der ersten reflektierten Welle entspricht dem doppelten Abstand Ultraschall-Sensor - Objekt. Über die Schallgeschwindigkeit und der Zeit erhält man den (doppelten) Abstand.

    Ja, stimmt :D
    Das ein UltraSchall die Strecke 2x zurücklegen muss ist klar, deshalb wirds dann auch durch 2 geteilt und die Schallgeschwindigkeit von 34000 steht in der Berechnung auch irgendwo drin :fies:

    Die Zeit des Impulses ist pille-palle. Sollte möglichst kurz sein, um bei kurzen Abständen erkannt werden zu können.

    Die Zeit, in der der Echo-Pin auf HIGH steht, wenn die reflektierte Welle eintrifft, hat mit der Entfernung gar nichts zu tun. Diese Zeit sollte sogar identisch mit der Impulsdauer des emittierten Impulses sein.

    Hm ich glaube da wird etwas missverstanden :-/

    Wie viel Zeit zwischen Triggern und Empfangen vergeht ist für uns "pille-palle". Natürlich vergeht da zwischen kaum Zeit da das Signal sehr schnell wieder zurück kommt (sofern nicht "out of range").
    ABER:
    Der Ultraschall Sensor regelt es eigenständig. Sobald ein Ultraschall empfangen wurde setzt die Hardware des Sensors den ECHO pin auf HIGH und bleibt so lange auf HIGH wie das Signal zwischen Triggern und wieder empfangen gedauert hat...

    Beispiel:
    Der HC-SR04-Sensor verschickt ein Signal.
    Das Signal wird wieder empfangen.
    Dazwischen verging eine Zeit von 20us.
    Dann wird vom HC-SR04-Sensor himself der ECHO pin für 20us auf HIGH gesetzt.
    Die Zeit, die der ECHO auf HIGH ist, nutzt man dann um die Distanz zu berechnen.

    (wie diese Berechnung letztlich aussieht, isst für diesen Umstand nebensächlich)

    Streng genommen müsste man noch die Impulsdauer von der Messzeit abziehen. Dies wird dann bei extrem kurzen Abständen zu besseren Ergebnissen führen.

    Wozu? Die Zeit wird erst durch den ECHO-Empfang gespeichert...

    Wie gesagt - ich glaube du bringst hier einiges durcheinander =(
    Der ECHO pin signalisiert uns wie viel Zeit zwischen abschicken und empfangen verstrichen ist - um alles andere muss ich mich nicht wirklich kümmern.


    ..aber wir driften hab... das hat mit dem Thema hier nichts zu tun


    //EDID: Hier ist auch ein Python Script was "out of range" (timeout) beachten würde: http://shanksi.blogspot.de/2013/05/raspbe…r04-module.html

  • Hallo Andreas.
    Du meinst:


    1.
    Die Zeit des Impulses ist pille-palle. Sollte möglichst kurz sein, um bei kurzen Abständen erkannt werden zu können. Die Zeit, in der der Echo-Pin auf HIGH steht, wenn die reflektierte Welle eintrifft, hat mit der Entfernung gar nichts zu tun. Diese Zeit sollte sogar identisch mit der Impulsdauer des emittierten Impulses sein.
    2.
    Streng genommen müsste man noch die Impulsdauer zur Messzeit addieren (falls die Messzeit mit Abschluss des Impulses startet). Dies wird dann bei extrem kurzen Abständen zu besseren Ergebnissen führen.


    Dem kann ich absolut nicht folgen.
    Zu 1.
    Die Zeit ist eben nicht pille-palle, sondern vom Hersteller vogegeben.(10 µSec)
    Denke das dient dazu, dem Baustein zu signalisieren, dass ein "echter" Triggerpuls kam.
    Hab das mal vor x-Wochen mit nem Oszi getestet.
    Unter 4 µSec ...abhaken, geht mal, meist nicht.
    Also nix mit möglichst kurzem Puls.
    Zu 2.
    Wozu zuaddieren ?
    Nach dem (anerkannten) Triggerpuls beginnt der Sensor (negative Flanke) mit seiner Arbeit.
    Er jagt seinen Puls raus und setzt Echo auf high.
    Nach dem Epfang des Pulses wieder auf low, fertig.
    Dann die Berechnung wie von dir beschrieben.
    Will dich nicht kritisieren aber denke du schmeist das was durcheinander.

    Nix für ungut.

    gruß root

    Einmal editiert, zuletzt von root (28. Januar 2015 um 01:32)

  • Könnte mir jemand das mit dem "signal" Befehl mit eigenen Worten erläutern bitte?

    Heißt das ich muss den signal handler implementieren kann von einem anderen Skript aus einen Interrupt auslösen?

    Auf einen arbeitsreichen Arbeitstag

    Gruß
    opc

  • Hallo.


    Könnte mir jemand das mit dem "signal" Befehl mit eigenen Worten erläutern bitte?

    Heißt das ich muss den signal handler implementieren kann von einem anderen Skript aus einen Interrupt auslösen?


    ...die Frage verstehe ich net ganz...
    Das ganze läuft doch nach folgendem Schema:

    1. 10 µsec Puls rausjagen.
    2. Positive Flanke des Empfangspulses abwarten, dann 1. Zeitstempel setzen.
    3. Negative Flanke abwarten, dann 2. Zeitstempel setzen.
    4. (Zeitstempel 2 - Zeitstempel 1)/2 ergibt Signallaufzeit, und somit die Entfernung.
    siehe Anhang.

    Ob du den Flankenwechsel per polling oder Interrupt abfängst ist dir überlassen, wobei ich Interrupt bevorzuge.
    Um das ganze noch abzurunden würde ich 2 Zähler mit einbauen, die beim warten auf die Flanken hochgezählt werden, und bei erreichen einer oberen Grenze abgebrochen wird.
    Somit wird eine Fehlmessung automatisch erkannt.(auch der Grund... steigende oder fallende Flanke kam nicht)
    Mit Python kann ich dir nicht dienen, und C wird dir dann wohl nichts sagen.

    gruß root

    • Offizieller Beitrag

    Wenn du einen Signal handler einbaust, wird das script, sobald es einen SIGINT erhält, eine definierte Aktion durchführen. Ich klau mal ganz frech meigrafds code, dann muss ich nicht soviel tippen ;)
    [code=php]
    import signal
    import sys

    def signal_handler(signal, frame):
    GPIO.cleanup()
    sys.exit(0)

    signal.signal(signal.SIGINT, signal_handler)
    signal.pause() [/php]

    Wenn du ein aus einem anderen Script heraus
    [code=php]
    kill -s SIGINT PID_des_ersten-Scripts[/php]
    aufrufst. Spring das erste script in die definierte Funktion, macht ein cleanup und exitet dann sauber.
    Wie du die PID rauskriegst, finest du wenn du meigrafds verlinkungen folgst

  • Danke für die Erklärung. Das ist genau, dass was ich mir vorgestellt habe für meinen Einsatzzweck.

    Vlt. doch noch eine Frage an meigrafd (oder alle falls es jemand weiß):

    Was muss individuell angepasst werden bei diesem PID Befehl? anstelle "test.py" natürlich der Pfad von Skript#1... ansonsten?

    kill -s SIGINT $(ps aux | grep -v grep | grep test.py | awk {'print $2'})


    Für eine weitere Erklärung an dieser Stelle wäre ich sehr dankbar.

    Gruß
    opc

    Einmal editiert, zuletzt von opc241 (28. Januar 2015 um 11:08)

  • Code
    kill -s SIGINT $(ps aux | grep -v grep | grep test.py | awk {'print $2'})

    Da reicht es wenn du den Dateinamen des Scripts änderst, also in diesem Fall test.py

    Und dann eben das Signal welches verschickt werden soll. Das muss halt mit dem was im Script steht übereinstimmen... Wenn du im Script auf SIGINT reagieren willst aber hier SIGTERM schickst, wird das Script nichts machen da das Signal ja ein anderes ist. ;)


    - Generell sei an dieser Stelle erwähnt das jeder Befehl eine sog. manual page hat in der auch oft Beispiele drin stehen, aber vorallem alles genau erklärt ist. Aufruf über:

    Code
    man BEFEHL

    Was der von dir genannte Befehl macht:

    kill -s SIGINT
    Verschickt das angegebene Signal. Mehr dazu bzw eine Liste steht in man signal

    $( )
    Das in dieser Klammer stehende wird ausgeführt und die Ausgabe an dieser Stelle ausgegeben... Manche schreiben das auch so:

    Code
    `befehl`

    was aufs selbe raus kommt, aber ich find erste Schreibweise schöner und eindeutiger (manche verwechseln `mit ' und wundern sich dann wieso nichts geht, das passiert mit meiner Schreibweise nicht ;))

    ps aux
    ruft die Prozessliste auf, aller Benutzer

    |
    Ist eine Pipe. die Ausgabe des links stehenden Befehls wird an den nachfolgenden Befehl übergeben, der das dann verwendet.

    grep -v grep
    Das sorgt dafür das in der Prozessliste alle Befehle bezüglich "grep" nicht angezeigt werden, denn sonst würde der gleich folgende Befehl einen Treffer auf sich selbst ergeben.
    (mit grep sucht man nach etwas. search for (a string of characters) using grep.)

    grep test.py
    Sucht nach einer Zeile die "test.py" beinhaltet, also darauf zutrifft. Hierbei wird GROSS-/-kleinschreibung unterschieden (ist ja generell der Fall). Wenn die Datei also nicht 'test.py' sondern'Test.py' heißt dann verläuft diese Suche ins leere! (man kann aber auch den Parameter -i verwenden dann wird das ignoriert (ignore-case))

    awk {'print $2'}
    gibt die 2.Spalte aus.
    Generell werden Spalten (und auch Anzahl der Parameter usw) anhand von Leerstellen erkannt. Die erste Stelle / Spalte ist $1, die zweite wäre $2, die dritte $3 usw.
    Um das anhand eines Beispiels zu zeigen:

    Code
    root@RoPi:~# ps aux | grep -v grep | grep "sshd:"
    root     12070  0.0  0.8   9772  3292 ?        Ss   13:06   0:00 sshd: root@pts/0 
    root@RoPi:~#


    Wenn wir hier auch noch den "awk {'print $2'}" mit anfügen würden, würde der Befehl nur das ausgeben:

    Code
    root@RoPi:~# ps aux | grep -v grep | grep "sshd:" | awk {'print $2'}
    12070
    root@RoPi:~#

    ..und das ist übrigens die PID -> ProzessID.. Eine eindeutige Zahl die niemals gleichzeitig doppelt vergeben wird.


    Noch etwas unklar :huh:
    :angel:


    PS: Beachte auch mein EDID am Ende von Beitrag#10. Denn wie root auch schon angemerkt hat wurde bisher nicht darauf eingegangen das bei der Messung kein "out of Range" bzw Timeout zur Geltung kommt, denn der UltraSchall-Sensor hat nur eine begrenzte Reichweite.
    Wenn du die bisher erwähnten Scripts verwendest kann es passieren das ewig auf eine Antwort, bzw ein wechsel des ECHO-pins von LOW auf HIGH (Flankenwechsel), gewartet wird und das Script dann vllt so aussieht als hätte es sich aufgehangen, weil ja der ECHO dann niemalsnie auf HIGH wechselt und die 1.while dann Ewigkeiten sich weiter dreht...

    Je nachdem welche Version des UltraSchall Sensors man verwendet kann die maximale Reichweite zwischen 3 und 5 Metern variieren... der Counter muss also passend für die maximale Reichweite gesetzt werden, sonst unterbricht das Script zu früh.

  • Ich danke dir für diese super Erklärung! :bravo2:
    soweit habe ich es verstanden :thumbs1:

    kann man den kill -s SIGINT $(ps aux | grep -v grep | grep test.py | awk {'print $2'})-Befehl auch aus einem Python-Skript starten?
    Es scheitert noch beim absenden des Signals via Python-Skript, da bekomm ich an der Stelle SIGINT immer einen Syntax-Error.

    (mein Skript habe ich testweise auch mal "test.py" genannt.)

    Ich hoffe ich habe alles richtig interpretiert, falls nein bitte ich um Aufklärung :stumm:


    Edit: deinem Tipp, mit dem Timeout bin ich gerade am umbasteln. Danke für den Link!

    Einmal editiert, zuletzt von opc241 (28. Januar 2015 um 20:49)

  • Basierend auf meiner Recherche nach dem Aufrufen von Shell Befehlen aus einem Python Skript, bin ich auf das Modul "subprocess" gestoßen. Mit "command =" wurde ein Beispiel angeführt welches einen Shell-Befehl ausführen sollte.

    Ansonsten soll testweise ganz simpel der Befehl ausgeführt werden, wenn der Input an Pin22 Low-Pegel hat.

    Wo liegt der Fehler? :-/

    Hier der Ausschnitt aus dem Code: (vorher natürlich die ganze Startroutine etc...)

    Code
    while True:
        if GPIO.input(22) == 0:
            command = (kill -s SIGINT $(ps aux | grep -v grep | grep test.py | awk{'print$2'}))

    :helpnew:

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!