Hallo,
Arduino Mega 2560, Ethernet-Shield, 39 Thermometer DS18B20 an 4 Bussen, 16 Rls. a ca. 50 mA. Stromversorgung 9V 4A.
Einige Thermometer "messen" kurzzeitig 127,94 °C. woher kommt dieser Wert? Weiß jemand eine Ursache? Kann es sein, dass der 5V-Regler auf dem Arduino den Strom nicht kann? Was mach ich dann? Kann mir jemand Tipps geben?
Gruß Gerd
Hallo,
Wie schnell liest du die Werte ein ?
Es gibt da Mindestwerte die eingehalten werden muessen
gerd-wolfgang:
Arduino Mega 2560, Ethernet-Shield, 39 Thermometer DS18B20 an 4 Bussen, 16 Rls. a ca. 50 mA. Stromversorgung 9V 4A.
Einige Thermometer "messen" kurzzeitig 127,94 °C. woher kommt dieser Wert? Weiß jemand eine Ursache?
Bei einem Sensor, der überhaupt nur bis maximal 125°C messen kann, kannst Du einen Wert von 127,94°C nur durch eine fehlerhafte Fehlerbehandlung bekommen.
"Statt "Messung ERROR" bekommst Du "Messung 127,94°C", weil Du das so programmiert hast.
Wieso der Messfehler auftritt, ist ohne nähere Angaben schwierig zu sagen.
Prüfen würde ich die folgenden zwei Punkte:
Werden die Sensoren "parasitär" oder "normal" mit Strom versorgt?
Die "normale" Stromversorgung ist um ein Vielfaches zuverlässiger, insbesondere bei knappen Timings.
Da es sich um einen 1-Wire-Bus handelt, sollten mehrere angeschlossene Sensoren auch immer in Bus-Topologie verkabelt sein. Hier im Forum hat man aber schon diverse Bastler gesehen, die 1-Wire-Sensoren in Stern-Topologie an Ihr Arduino-Board angeschlossen haben und sich dann über fehlerhaftes Funktionieren von Sensoren wundern, insbesondere wenn die Leitungen länger als ein paar Zentimeter sind.
Normale Stromversorgung und Verkabelung in Bus-Topoligie ==> gute, fehlerfreie Funktion
Parasitäre Stromversorgung und Verkabelung in Stern-Topologie ==> fehlerträchtig
Und egal ob Deine Sensoren wegen problematischer Anschluss- und Betriebsbedingungen Fehler liefern oder nicht: Werte über 125,0°C mußt Du per Software stets als "Fehler" behandeln, das sind nie im Leben gültige Temperaturen eines DS18B20 Sensors.
Hallo,
die Zeit der Widerholrate zum auslesen des Sensor hälst Du ein?
Ist die Ausgabe richtig formatiert, nicht das da einfach nur eine Ziffer stehen bleibt.
Wie hollst Du den Wert? Nur einmal, egal wie oft der Sketch durchlaufen wird?
Gruß und Spaß
Andreas
P.S. ein wenig Sketch-Auszug von "der Abfrage"?
Hallo,
die Stromversorgung ist "normal".
Topologie: An jeweils einem 1-Draht-Bus hängt ein langes 3-adriges ungeschirmtes Kabel, 5-8 m. Am anderen Ende befindet sich ein Verteiler und daran sind die Sensoren und der Abschlusswiderstand jeweils über ca. 50cm Kabel angeschlossen.
Ein Auszug aus der Loop:
// TEMPeraturen BEREITSTELLEN: Aufruf an alle Sensoren an allen Bussen
for (i = 0; i < AnzBus; i++) sensors[i].requestTemperatures();
// Die Antwort kommt fast unmittelbar. Sofortige Datenausgabe
delay(100); // in Millisekunden
// IST-TEMPeraturen AUSLESEN und in Array schreiben
for (i = 0; i < AnzahlSensoren; i++) {
sensorList[i].isttemp = sensors[sensorList[i].busnr].getTempC(sensorList[i].address);
sensorList ist ein Array.
Gemessen wird jede Minute.
Der Wert 127,94 wird als float ins Array geschrieben. Ich mache damit nichts Anderes als ihn in eine txt-Datei auf SD zu schreiben.
Dass dieser Wert nicht real ist, ist mir klar. Aber, bevor ich ihn einfach weg filtere, möchte ich gern die Ursache wissen und lieber diese abstellen. Der besagte Sensor misst an einer Rücklaufleitung einer Fußbodenheizung.
Ich suche also erstmal die Ursache.
Gruß Gerd
Hi
Das hört sich aber nach einer Sternförmigen Verkabelung an und nicht nach einem Bus.
Ich würde das als erstes mal auf einen Bus umstellen und dann noch mal kontrollieren, ob der Fehler immer noch auftaucht.
Grüsse
Peter
Hallo,
zeig mal den gesamten Sketch. Mit 100ms delay, betreibst Du alle Sensoren mit 9 Bit Auflösung?
gerd-wolfgang:
Topologie: An jeweils einem 1-Draht-Bus hängt ein langes 3-adriges ungeschirmtes Kabel, 5-8 m. Am anderen Ende befindet sich ein Verteiler und daran sind die Sensoren und der Abschlusswiderstand jeweils über ca. 50cm Kabel angeschlossen.
Für eine verläßliche Verkabelung eines One-Wire-Netzwerks, das vom Controller viel weiter weg führt als die Controllerplatine lang ist, schaust Du am besten mal da rein:
Da wird übrigens als Verkabelung schon mal Cat-5 Netzwerkkabel vorausgesetzt: "Category 5, twisted-pair copper wire"
Und für verlässliche Funktion wird noch zu kleinen Widerständen von 100 bis 150 Ohm an den Abzweigpunkten vom Bus geraten, siehe im Text unter "Distributed Impedance Matching". Einen PullUp-Widerstand gibt es insgesamt jedoch nur einen einzigen für den gesamten Bus, Du hast doch wohl nicht einen PullUp pro Sensor verbaut?
Ich benutze für meine "Messstrecke" ein 3poliges Flachbandkabel von ca. 23 m Länge - ungeschirmt mit aktuell 7 Sensoren (DS1820 und DS18x20 gemischt).
Die Sensoren sind natürlich (da Bus) HINTEREINANDER angeordnet.
Es geht wohl auch die genannte STERN-Topologie (wir hatten vor Monaten mal etwas Ähnliches, finde es aber nicht mehr) , AFAIK aber nur mit DS18B20 und Widerstand an JEDEM Sensor.
Der Wartezyklus nach dem Init des Sensors beträgt 750ms, danach mache ich eine Pause von 1250 ms bis zum einlesen des nächsten Wertes.
Ohne Sketch (wie schon mehrfach erbeten) ist sonst nur alles (graue) Theorie.
Hallo,
den Sketch hänge ich als Anlage an.
Was die Topologie angeht, meine ich keine Fehler gemacht zu haben, bis evtl. auf die Kabelsorte. Meine vier Busse hängen natürlich jeder an einem separaten Pin, und jeder Bus ist mit EINEM Pull-Up-Widerstand von z. Z. 1k2 Ohm am "Stern" versehen. Die Längen von ca. 50cm zwischen Verteiler und Sensor sind lt. erwähntem Maxim-Dokument "insignificant" - uninteressant. Die 100-150 Ohm-Widerstände können keine Pull-Up-Widerstände sein, die werden zur Entkopplung der einzelnen Stichleitungen dienen, die aber sehr viel länger sind als meine.
Ich betreibe alle Sensoren mit einer Auflösung von 12 Bit.
Meine Anordnung funktioniert ja auch im Prinzip. Nur 3 von 39 Thermometern "spinnen". Und ich möchte gern die Ursache abstellen. Die fehlerhaften Messwerte einfach wegzufiltern ist für mich nicht die erste Wahl.
Gruß Gerd
HR_49.ino (59.4 KB)
Sind es immer die selben 3 Sensoren oder -wenn Du schon ausgetauscht hast- immer dieselbe Position im Bus ?
z.Zt. bin ich der Meinung, dass es immer die gleichen sind. Sie zeigen aber unterschiedliche "fehlerhafte" Ergebnisse. Ich habe mich jetzt erstmal auf einen Sensor konzentriert, der, wenn Fehler, dann einheitlich 127,94 °C anzeigt. Dem habe ich einen zweiten dazugetan und warte jetzt bis morgen, um das Ergebnis zu sehen.
Gruß Gerd
Yo, check das mal.
Bei den DS18x20-Teilen gibt es ja kalibrierte und nicht-kalibrierte; die Letzteren stammen aus der laufenden Fertigung und werden -da sie ja nicht kalibriert werden- ergo auch nicht getestet.
Mag daher sein, dass 3 fehlerhaft sind.
Hallo,
wenn Du die Sensoren testen willst, dann würde ich sie an ihrem montierten
Platz belassen. Dort die Leitung unterbrechen, und den Sensor mit einem
Beispielprogramm auslesen.
Bei der Anzahl von Sensoren und Leitungen können es auch Verdrahtungsfehler
oder Kriechströme sein.
Nur wenn der Sensor an seinem Platz stand alone geprüft wird, kannst Du
sicher sein ob es der Sensor ist/nicht ist.
Wenn Du keinen zweiten Arduino hast, dann tausche nur die Sensoren.
Einen der i.O. ist gegen einen der nicht i.O. ist.
Der Fehler könnte dann ja auf der anderen Leitung auftreten...
Gruß und Spaß
Andreas
Hallo,
mir ist nicht bekannt, dass es kalibrierte und unkalibrierte geben soll. Es müssen ja alle Sensoren die Werte im Datenblatt einhalten. Also müssen alle den Specs entsprechen. ???
Zum Sketch. Auch wenn es für Außtenstehende schwierig ist bei einem umfangreichen fremden Programm den Durchblick zu bekommen, bin ich der Meinung, dass Du Deine Sensoren falsch ansprichst.
Eine von Dir definierte 12 Bit Auflösung finde ich nicht.
byte = aufloesung;
ist eigentlich gleich Null.
Oder holst Du bestimmte Einstellungen von der SD-Karte?
Aber, wenn Du mit 12 Bit fährst, dann ist Deine Wartezeit mit 100ms zu kurz. Die muß 750ms betragen.
Datenblatt Seite 8 http://datasheets.maximintegrated.com/en/ds/DS18B20.pdf
Und dann würde ich das delay umbauen mit millis um nicht den Programmablauf zu blockieren an der Stelle.
Mit dem Bsp. der Library "WaitForConversion2" hab ich meine 2 Sensoren "eingebunden".
Hallo Doc,
die 12 Bit stehen im Array drin.
Die Wartezeit habe ich auf 800 erhöht.
millis muss ich erstmal studieren.
Danke, für diese Hinweise.
Gruß Gerd
Hallo doc,
zu millis. Ich verstehe millis so: Es ist eine weitere "Uhr". Der Trick in dem Beispiel scheint mir die if-Abfrage zu sein und kein delay.
Das gleiche mache ich aber im sketch auch.
// Ende if
Oder habe ich millis nicht verstanden?
Gruß Gerd
Ja, das hast Du richtig verstanden.
nur die Kontrolle würd ich anders machen:
2. if t + Wartezeit >= now()
t muß eine unsigned long Typ Variable sein.
Auch mußt Du innerhalb der if t neu setzen:
t= millis();
Grüße Uwe
Hallo,
wenn es mit 750ms funktioniert, Deine jetzigen 800 kannste ruhig auf 750 absenken, würde bestätigen wie ich Deinen Programmablauf verstanden habe.
Du startest über "if t + Wartezeit <= now()" eine neue Messung. Wartest 100ms und liest die Temperaturwerte aus. Genauso funktioniert das aber nicht mit der benötigten Wartezeit.
Zwischen dem Befehl "Messung starten" und neue "Werte auslesen" müssen bei 12Bit besagte 750ms Wartezeit liegen. Weil der Sensor so viel Zeit für die interne Messung und Wandlung benötigt. Nach dem auslesen kannst Du meinetwegen sofort eine neue Messung starten.
Du kannst auch Deine 100ms beibehalten, wenn Du nur 9 Bit Auflösung einstellst. Dann ist der Sensor laut Datenblatt in 93ms fertig. Geht aber nur bei Deinem DS18B20. Ich habe den billigeren DS18S20, der nur 9 Bit in 750ms kann.
Hier folgt jetzt mein alter Testcode mit dem Bsp. der Library. Nach dem Befehl "Messung starten" wird sich der aktuelle millis Wert gemerkt und wenn der um die Zeitspanne vom eingestellten delay weiter ist, erst dann wird ausgelesen und sofort wieder eine neue Messung gestartet. Hat auch den Vorteil, dass man seinen Programm nicht blockiert.
// loop läuft unter 1ms
//
// Sample of using Async reading of Dallas Temperature Sensors
//
#include <SPI.h>
#include <DogLcdSPI.h> // für Hardware SPI angepaßte DogLcd.h
DogLcdSPI lcd(26, 27); // Pins für RS und CSB
#include <OneWire.h>
#include <DallasTemperature.h>
// Data wire is plugged into port 3 on the Arduino
#define ONE_WIRE_BUS 3
// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONE_WIRE_BUS);
// Pass our oneWire reference to Dallas Temperature. DS18S20
DallasTemperature sensors(&oneWire);
DeviceAddress sensor1 = { 0x10, 0x40, 0xDD, 0xC3, 0x2, 0x8, 0x0, 0xB4 };
DeviceAddress sensor2 = { 0x10, 0x8A, 0xB, 0xAC, 0x2, 0x8, 0x0, 0x2C };
float TempSensor1 = 0.0; // Zwischenspeicher zum auslesen und SD Card
float TempSensor2 = 0.0; // Zwischenspeicher zum auslesen und SD Card
unsigned long lastTempRequest = 0;
int delayInMillis = 750;
//float temperature = 0.0;
//
// SETUP
//
void setup(void)
{
Serial.begin(9600);
sensors.begin();
sensors.setResolution(sensor1, 9);
sensors.setResolution(sensor2, 9);
sensors.setWaitForConversion(false);
sensors.requestTemperatures();
delayInMillis = 750;
lastTempRequest = millis();
SPI.begin();
// set up the LCD type and the contrast setting for the display
lcd.begin(DOG_LCD_M163); // EA-DOGM Display 3 zeilig
lcd.noCursor(); // Cursor nicht sichtbar
lcd.print(F("MEGA")); // Print a message to the LCD.
}
void loop(void)
{
if (millis() - lastTempRequest >= delayInMillis) // Wartezeit vorbei ?
{
TempSensor1 = sensors.getTempC(sensor1); // 1. Dallas Sensor auslesen (Device Adresse)
TempSensor2 = sensors.getTempC(sensor2); // 2. Dallas Sensor auslesen (Device Adresse)
TempToDisplay( 0,1,TempSensor1); // DS18S20 Temperaturwert Ausgabe auf Display (X,Y,Wert)
TempToDisplay(10,1,TempSensor2);
sensors.requestTemperatures();
lastTempRequest = millis();
}
// we can do usefull things here
}
// DS18S20 Ausgabe auf Display
void TempToDisplay(byte Spalte, byte Zeile, float Temp)
{
lcd.setCursor(Spalte,Zeile);
lcd.print(Temp,1);
lcd.write(0xDF); // ° Zeichen vom DOGM internen Zeichensatz
lcd.print(F("C"));
}
Hallo,
melde mich hier zu diesem, meinem, Thema nochmal.
Die Wartezeit hatte ich geändert. Das Hauptproblem war aber vermutlich, dass ich die 5V-Versorgung des Arduino überfordert habe, weil ich eine Anzahl von Relais darüber versorgt habe. Seitdem dies getrennt ist, gibt es kaum noch Messfehler, die ich weiter beobachte.
Danke für die Hilfe.
Gruß Gerd