Mehrere DS18B20 Sensore gleichzeitig auslesen

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Liebe Raspberry Enthusiasten,

    ich bin ein Neuling, sowohl auf dem Gebiet der Python Programmierung als auch auf dem RP. Entschuldigt also bitte wenn die Frage für so manchen fast eine Beleidigung darstellt. Dennoch bin ich mit meinem Latein am Ende.

    Ich habe ein Temperaturmesssystem zur Vermessung einer Fahrzeugkühlung mit dem RP3 und 18 DS18B20 Temperatursensoren aufgebaut. Dazu habe ich mir ein Pythonscript geschrieben, welches die Sensoren ausliest, in einer GUI darstellt, in einer Datei speichert und in einer excel ordnet. Die Sensoren werden mit einem 1 Wire protokoll am GPIO (Pin4) betrieben. Das funktioniert hervorragend, soweit so gut. Allerdings liegt zwischen der Messung des ersten Sensors und des letztens Sensors 14(!) Sekunden. Ich muss immer eine Momentaufnahme aller Sensoren haben (alle Sensoren müssen gleichzeitig ausgelesen, oder wenigstens annähernd gleichzeitig). Das ist laut Datenblatt auch möglich:

    "The master can use this command to address all devices on the bus simultaneously without sending out any ROM code information. For example, the master can make all DS18S20s on the bus perform simultaneous temperature conversions by issuing a Skip ROM command followed by a Convert T [44h] command."

    Und jetzt die 1000€ Frage: Wie sendet man denn so ein command?

    Beste Grüße

  • Servus,
    was versprichst Du Dir davon? Das kann nach meinem Verständnis bei mehreren Sensoren nicht funktionieren ...

    Und wenn Du den Text, den Du teilweise gequotet hast, mal zu Ende liest, dann gibt mir das Datenblatt recht:


    ...
    Und jetzt die 1000€ Frage: Wie sendet man denn so ein command?

    steht doch auch direkt da:

    Zitat


    Skip ROM [CCh] ... followed by a Convert T [44h] ... Note ... Read Scratchpad [BEh] ...

    btw: wohin darf ich Dir meine Kontodaten schicken? :lol:
    cu,
    -ds-

  • Das ist machbar, allerdings darf man dann nicht die Standard-Funktionen des (Kernel-)Treibers benutzen, weil dieser die Sensoren nur einen nacheinander auslesen kann. Du muesstest also einen neuen Treiber bzw. eine Routine schreiben, die die einzelnen Komandos in anderer Reihenfolge für alle Sensoren gleichzeitig absendet.

    (Wenn es Dir gelingt, würde es mich auch interessieren). Es gibt aber noch eine andere Möglichkeit, die Temperaturwerte auch so auf eine gemeinsame Zeit zu bezihen. Du musst halt mehrere Messungen machen und dann dazwischen interpolieren. (Bei mir bekommt jede Messung von einem Temperatursensor einen individuellen Zeitstempel. Damit kann man dann ganz gut arbeiten, z.B. plots machen etc.) Wenn sich die emperaturen aber inerhalb der 14 Sekunden mehrmals rauf und runter aendern, dann bekommst Du das so aber natuerlich nicht mit.

  • Hallo zusammen und Danke für den Input,

    @dreamshader: Ich verspreche mir davon eine Momentaufnahme an jeder Stelle eines Kühlsystems. Du kannst auch gerne einen Vorschlag für nur 2 Sensoren bringen. Das Problem bleibt das selbe. Es ist nicht möglich mit den vorhandenen Protokoll, das ist richtig. Generell ist ein gleichzeitig auslesen aber möglich.

    wend: Das ist ein guter Lösungsansatz den ich weiter verfolge. Das habe ich auch schon in Betracht gezogen, hatte aber auf einen einfachen Weg gebaut. Das es möglich ist, bestätigte mir der Kundensupport:

    "...It is possible to initiate a temperature conversion to all DS18B20 on the 1-Wire bus at the same time. However, each DS18B20 would need to be addressed one at a time with the Read Scratchpad command to attain the resulting temperature value."

    Dieser Beschreibt im weiteren Verlauf das nötige Sensen der Commands, also schon den Funktionspfad. Aber wie man das letztendlich praktisch durchführt ist mir NOCH ein Rätsel. Aber ich bleibe dran.

    Beste Grüße


  • Das ist nicht machbar. Auch nicht mit einem anderen Treiber. Das 1wire Protokoll bleibt 1wire Protokoll und ist nicht geeignet für parallele Datenübertragung. Interpolieren ist wohl für die Anwendung nicht zielführend.


    Danke für die Antwort. Ja, ich kann das natürlich nicht weiter mit einem 1 Wire Protokoll betreiben. Das muss auch anders gemacht werden.

    Beste Grüße

  • Ich lese 4 Sensoren "quasiparallel" aus (RasPi / Python) indem ich 4 Threads aufziehe und diese unmittelbar nacheinander starte.
    Jeder dieser Threads sendet an seinen DS das Startsignal und erwartet seine Antwort.
    Der Bus bzw. die Logig des Busses regelt die Serialisierung der Antworten.

    Threading unter Python ist ja bekanntermaßen eine Sache, die nicht sonderlich gut implementiert ist:
    Innerhalb der Threads wird jedoch jeweils ein CLI-Kommando abgesetzt, so dass das dann wiederum auch unter Python funktioniert...

    Das läuft bei mir schon seit Jahren, natürlich prüft jeder der Threads, ob der Sensor valide Werte oder ein "NA" zurückliefert, in diesem Fall wird nochmal gemessen (was sehr selten passiert).

    Dieses Thema wurde in fast gleichem Wortlaut vor ca. 3 Monaten schon einmal hier behandelt... mal sehen, ob ich den Thread finde...

    Edit: Thread nicht gefunden, war vermutlich innerhalb eines anderen Threads mal ausgeführt...

  • Die Loesung von Zentris ist ein guter Kompromiss, ansonsten kann es natuerlich mit dem 1Wire gehen, da die Messkommandos ja aus mehreren Teilen bestehen und waehrend der Prozess auf die Antwort von einem Sensor wartet, kann er ja schon den anderen Sensor scharfmachen.

  • Quasiparrallel ist nicht gleichzeitig. Es geht aber, wenn ich den TE richtig verstanden habe, genau darum, dass alle Temperaturen an allen Messpunkten zeitgleich erfasst werden, um diese Temperaturen auf ein bestimmtes Verhalten zu prüfen und zwar in gegenseitiger Abhängigkeit. Man kann zwar den Prozess der Temperaturumwandlung gleichzeitig für alle Sensoren starten, die Antwortzeiten und Reihenfolge dann jedoch kaum beeinflussen.

  • Ok, ich habe versucht, mich vorsichtig auszudrücken ("quasiparallel"), da ich mir ja einiger penibler Zeitgenossen bewusst bin...

    Also: Die Threads werden "gleichzeitig" gestartet (müSec Unterschied) und geben ihren Request auf die Leitung.
    Da die Antwortzeit (Umsetzzeit) der DS zw. 0.7-0.9sec. beträgt, antworten die quasi auch (fast) gleichzeitig...

    Ich habe hier nach spätestens 1,2sec _alle_ 4 Sensorendaten vorliegen.
    Noch zeitgleicher bekommst du es nur mit dedizierter Elektronik für jeden Sensor (z.B. je ein Arduino oder sowas pro DS - und ob das wirklich besser ist ?
    (Bei 18 Sensoren oder so ist das in der Tat eventuell sicherer, aber das müßte man mal untersuchen).

    Zw. 14sec des TO und 1,2 sec meines Vorschlages liegt eine Zehnerpotenz... unter die Umsetzzeit kommst du nicht, "Echtzeit" dann nur mit PT100 Messfühler + Elektronik ...

  • Hi Zentris,


    Zw. 14sec des TO und 1,2 sec meines Vorschlages liegt eine Zehnerpotenz... unter die Umsetzzeit kommst du nicht, "Echtzeit" dann nur mit PT100 Messfühler + Elektronik ...


    Doch, es geht noch schneller: Wenn Du im Configuration Register des DS18B20 die Bits R1 und R0 von 11 auf 00 setzt, dann reduziert sich die Umwandlungszeit von 750 ms auf 93,75 ms.

    Die Frage ist dann allerdings, ob der TO 12-Bit-Werte benötigt, die im Abstand von 1,2 Sekunden verfügbar sind - oder ob 9-Bit-Werte, die im Abstand von rund 100 ms verfügbar sind, aufschlussreicher für eine Kühlung sind.

    Details sind der Application Note 126: 1-Wire Communication Through Software von Maxim Integrated Circuits zu entnehmen. Application Note 74: Reading and Writing iButtons via Serial Interfaces ist in dem Zusammenhang auch noch ganz interessant.


    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 (10. Februar 2017 um 23:04)

  • Andreas:
    Ich bin natürlich von 12 bit ausgegangen.
    Mit reduzierter Auflösung kann man natürlich arbeiten, aber da es ein thermisches System ist, gehe ich von einer gewissen thermischen Trägheit aus, die dem System innewohnt.
    In wie weit eine 0,1sec - Auflösung der Einzelmessungen angestrebt ist, kann uns nur der TO sagen...

    Mein Eindruck war eher die Gleichzeitigkeit der Probennahme, die der TO erreichen will.

Jetzt mitmachen!

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