DS18B20 auslesen wird immer langsamer.

[Tom P. (booner)]

Hallo Leute,

ich lese bis zu 80 Stück DS18B20 an einem einzigen Bus aus.
Pro Zyklus einen Sensor. Nun dachte, ich dass es pro Sensor immer gleich 
lange dauert. Pustekuchen!
Die ersten zehn Sensoren gehen schnell (Gefühlt innerhalb von 100ms),
dann wird es immer langsamer, bis die letzten Sensoren schon eine 
Sekunde oder länger pro Sensor benötigen.

µC ist ein Atmega328
Programmierumgebung Ardunio 1.01
Onwire.h
DalllasTemperature.h und
SPI.h
sind included.

void loop(void)
{ 
  if (millis() - lastTempRequest >= delayInMillis) // waited long enough??
  {
   switch (Schreiben) {
      case 0:
      digitalWrite(13, HIGH);
      Temperature = sensors.getTempCByIndex(Sensor_Counter);
      if (Temperature>40){
       Serial.print(Sensor_Counter);
       Serial.print(": T:"); 
       Serial.print(Temperature);
       Serial.print(" Serie:");
       sensors.getAddress(tempDeviceAddress, Sensor_Counter);
       Serial.print(sensors.getHighAlarmTemp(tempDeviceAddress),DEC);  
       }
      Sensor_Counter++;
      if (Sensor_Counter >= sensors.getDeviceCount()) // Wenn alle Sensoren durch, dann requeste neue Temperatur
      {
         Schreiben=1;
         Sensor_Counter=0;
      }
     break;
   
     case 1: // Temperaturmessung anstoßen
      sensors.requestTemperatures(); 
      lastTempRequest = millis(); 
      Schreiben=0;
      digitalWrite(13, LOW);
     break;
   
     default:
      Schreiben=0;  
    }
  }  
}

Vielleicht hat jemand von Euch eine Idee woran das liegen könnte?
Das Problem dabei:
Ich möchte zugleich einen Modbus-Slave auf dem µC laufen lassen.
Wenn der nicht innerhalb z.b. 200ms antwortet, gibts nen Timeout.

Vielen Dank schon mal fürs drüber schauen!

Grüße,

TOm

[Cyblord -. (cyblord)]

Ja wenn man ein solch großes Projekt (80 Sensoren!!!) mit Arduino und 
ner fremden Lib hochzieht, dann muss man sich halt damit abfinden was 
die lib so macht. Man kann ja eine fertige OW lib nehmen, aber die 
Sensorabfrage würde ich in solch einem Fall sicher NIEMALS aus der Hand 
geben. Selber machen, dann weiß man was passiert und kann auf die 
eigenen Anforderungen optimieren.

Aber du nutzt fertiges Zeug und andere sollen jetzt darin rumkramen und 
schauen warum es nicht das tut was du willst? Klar doch.

gruß cyblord

[Tom P. (booner)]

Hei,

cyblord vielen Dank fürs lesen.
Ich hab von keinem verlangt, darin rumzukramen.
Ich habe nur darum gebeten, falls einer nen Hinweis hat.

Auch habe ich schon Stunden über der "fremden" Bibliothek verbracht und 
nicht einfach schnell ne Frage ins Forum geschmissen.

ABER: Ich bin halt noch ziemlicher Anfänger, was die µC Programmierung 
angeht. Dafür klappt es aber schon erstaunlich gut, was ich mir so 
vornehme.
Modbus läuft, Sensoren auslesen läuft, dRGB-Led ansteuern läuft...
Ist halt nur noch das kleine Problem mit der Anzahl der Sensoren.

Also lehn dich zurück, genieße das Leben und nimms mal ein wenig 
lockerer...

Hier noch ein Link auf die DallasTemperature.cpp, fall es sich doch 
jemand antun will:
http://code.google.com/p/dallas-temperature-control-library/source/browse/trunk/DallasTemperature.cpp?r=5


Grüße,

Tom

[Peter D. (peda)]

Ich kann mit Deinem Code auch nichts anfangen.
Ich sehe nur einen Haufen unbekannter Funktionen und Variablen 
unbekannten Typs und nichts davon ist kommentiert.

Daß es immer langsamer wird, kann daran liegen, daß die Sensoren immer 
per ROM-Search durchgezählt werden.
Will man einen bestimmten Sensor auslesen, ohne dessen Adresse zu 
kennen, dann adressiert man quasi alle vorherigen Sensoren und das 
dauert eben.

Will man aber alle auslesen, dann gibt man sie einfach der Reihe nach 
aus, d.h. das ROM-Search adressiert immer den nächsten.
Es muß dafür 2 Funktionen geben:
"ROM-Search-first" liest den ersten Sensor und:
"ROM-Search-next" dann immer den folgenden.
Genaueres sollte in der Doku zu der Arduino-Lib stehen.

Und "Loop" ist ein schlechter Name für eine Funktion, die keine Loop 
enthält, das ist irreführend.


Peter

[Tom P. (booner)]

Hallo Peter,

ich glaube, Du hast mich da auf eine heisse Spur gebracht!

// finds an address at a given index on the bus
// returns true if the device was found
bool DallasTemperature::getAddress(uint8_t* deviceAddress, uint8_t index)
{
  uint8_t depth = 0;

  _wire->reset_search();

  while (depth <= index && _wire->search(deviceAddress))
  {
    if (depth == index && validAddress(deviceAddress)) return true;
    depth++;
  }

  return false;
}

Diese Funktion wird bei jedem Mal Sensor-Auslesen aufgerufen.
Ich hab sie zwar noch nicht ganz kapiert, scheint aber so wie Du 
schreibst, dass er da erstmal alle Sensoren durchgeht, bis er die 
passende Adresse findet.

Ich werde jetzt einfach mal zu Beginn meines Programms alle gefundenen 
Adressen in ein Array speichern, (sofern soviel Speicher zur 
Verfügung...) und dann nur noch mit den Adressen statt den Indexes 
arbeiten.

Melde mich, wenn ich es ausprobiert habe.
Schon mal vielen Dank!


Grüße,

Tom

[bernd59 (Gast)]

Hallo,

Sind für alle Sensoren die gleiche Auflösung eingestellt?

Bernd

p.s.

Für Fragen mit dem Arduino würde ich lieber das deutschsprachige 
Arduino-Forum nutzen.
http://arduino.cc/forum/index.php/board,31.0.html
Da sind sie auch netter:)

[Tom P. (booner)]

Hallo Bernd,

hast ja eigentlich recht. ;-)
(Mit dem Forum)

Ja alle Sensoren sind auf 12bit eingestellt.
Wenn alle die gleiche Temperatur haben,
(Was wirklich schwierig ist!) dann weichen die Werte gerade mal so 0,2K 
von einander ab. Bin begeistert, wie genau die Sensoren sind.


Grüße,

Tom

[Cyblord -. (cyblord)]

bernd59 schrieb:

> Da sind sie auch netter:)
Aber können halt nix:
social skills don't pay any bills

gruß cyblord

[Peter D. (peda)]

Tom P. schrieb:
> Diese Funktion wird bei jedem Mal Sensor-Auslesen aufgerufen.

Es hindert Dich niemand daran, sie nicht zu benutzen.
Du brauchst immer nur einen Paß aufrufen und dann den adressierten 
Sensor auslesen.
Es ist schon ein deutlicher Unterschied, ob man n * die Zeit braucht 
oder n*(n+1)/2.

Hier mal ein Code ohne die A-Lib:

Beitrag "DS1820, DS18B20 in C"


Peter

[Tom P. (booner)]

Peter Dannegger schrieb:
> Tom P. schrieb:
>> Diese Funktion wird bei jedem Mal Sensor-Auslesen aufgerufen.
>
> Es hindert Dich niemand daran, sie nicht zu benutzen.

Doch! Mein Unwissen hat mich dran gehindert. :-)
Problem erkannt, Problem gebannt. So hoffe ich zumindest.
Vielen Dank Peter, für den Hinweis!
Dafür ist doch ein Forum super, dass man mal andere Sichtweisen 
aufgezeigt bekommt.
Manche Stänkerer sind halt dabei, aber die kann man ja einfach 
"überlesen"... ;-)


Grüße,

Tom

[Tom P. (booner)]

Hei,

danke Bernd und vor allem Peter.
Jetzt fetzt es.
Bis aufs erste Mal Adressen auslesen und abspeichern.
Aber "langes booten" ist man ja von Windows gewohnt LOL


Dann steht meinem "großen Projekt (80 Sensoren!!!) " ja nichts mehr im 
Wege.
Hehe, naja soo groß ist das nun auch wieder nicht...


Grüße,

Tom

[Henrik W. (skudderon)]

Hallo,

ich bin ganz neu hier und über die Suche nach DS18B20 und 1-wire auf 
diesen Threat gestoßen. Ich weiß der ist eigentlich Steinzeit aber ich 
steh grad vor der selben Herausforderung.
Vielleicht ist Tom so nett und zeigt mal die Lösung? :)

Vielen Dank im Voraus

Henrik

[Tom P. (booner)]

Hei,

na die Lösung steht doch schon ein paar Beiträge weiter oben!
Beitrag "Re: DS18B20 auslesen wird immer langsamer."


Grüße,

Tom

[Henrik W. (skudderon)]

Danke für die schnelle Antwort Tom :)

Ich meinte diesen Abschnitt:
"Ich werde jetzt einfach mal zu Beginn meines Programms alle gefundenen
Adressen in ein Array speichern, (sofern soviel Speicher zur
Verfügung...) und dann nur noch mit den Adressen statt den Indexes
arbeiten."

Viele Grüße
Henrik

[Tom P. (booner)]

Hei,

genau das ist die Lösung. Mach es doch auch so.
Den Code dazu habe ich leider nicht mehr zur Hand.
Aber da war ich noch blutiger Anfänger und habe das geschafft.
Kann also nicht schwierig gewesen sein. ;-)


Grüße,

Tom

[Henrik W. (skudderon)]

Danke

[Patrick J. (ho-bit-hun-ter)]

Hi

Das ist aber doch 'Quatsch' - wenn ich Das Mal so nennen darf.
Im Datenblatt der Sensoren sollte enthalten sein, wie man den ROM_Search 
benutzt.
Diese Funktion richtig angewendet findet IMMER den NÄCHSTEN Sensor - 
wenn's keinen Hinteren mehr gibt, wird der Erste wieder gefunden.
(zumindest in meinem in in ASM auf einem ATtiny45 nachgebautem Programm)

Hat natürlich auch einen Nachteil:
Man weiß nie, Welcher Sensor wann an die Reihe kommt (da die Reihenfolge 
sich aus den IDs ableitet, die Richtung aber 'verkehrt herum' ist.
Theoretisch müssten die IDs, binär notiert und umgedreht, dann sortiert, 
die Reihenfolge der Funde ergeben - habe ich mir gerade zusammen gereimt 
(also ungetestet, klingt aber recht gut).
Nebenbei würfelt es Dir die Reihenfolge durcheinander, wenn Du einen 
neuen Sensor einsetzt oder ein Sensor getauscht werden muß - dann sogar 
2x!!

Selber habe ich angedacht, in den User-Bytes eine Sensor-ID und einen 
Korrekturwert einzutragen -ä da die Sensoren zwar 1/16tel °C Auflösung 
haben, aber (glaub) nur 0,5°C Genauigkeit.
Wenn man jetzt die Abweichung zu einem Master-Sensor in den 
Slave-Sensoren einträgt, kann man Diese immer Korrekturrechnen.
Auch kann man dann gezielt Sensoren austauschen - der Getauschte braucht 
'nur' die gleiche ID wie der Auszutauschende.

Und - man sucht zwar immer noch die I2C-IDs durch, selektiert aber nach 
der enthaltenen ID.

Sollte Das Alles nicht zu Deinem Problem passen - hast Du vll. bei den 
'hinteren Sensoren' die volle Auflösung (12bit) und bei den schnellen 
'Vorderen' vll. nur 9bit?

MfG

[Forist (Gast)]

Tom P. schrieb:
> Hier noch ein Link auf die DallasTemperature.cpp, fall es sich doch
> jemand antun will:
> 
http://code.google.com/p/dallas-temperature-control-library/source/browse/trunk/DallasTemperature.cpp?r=5

Inzwischen ist die Library umgezogen nach
https://github.com/milesburton/Arduino-Temperature-Control-Library
s.a.
https://www.milesburton.com/Dallas_Temperature_Control_Library

[c-hater (Gast)]

Cyblord -. schrieb:

> social skills don't pay any bills

Cooler Spruch, muss ich mir unbedingt merken.

Wobei es konkret natürlich nicht unbedingt um die Kohle geht, sondern 
einfach darum, dass erzwungenen "nette Umgangsformen" de facto nix 
anderes sind als Vernichtung von Information.

Das nützt niemandem! Das Problem ist halt nur, dass gerade die Doofen 
das nicht begreifen können...