Hi! Ich möchte für meine Heizugssteuerung digitale Temperatursensoren verwenden. Meine Wahl viel auf den DS18B20. Laut Datenblatt und Beiträge+Codebsp. hier im Forum kann man mehrere Sensoren an einen Pin hängen, da ja jeder Sensor eine eigene Seriennummer im ROM hat. Meine Frage: Was nützt mir die Seriennummer, wenn ich die Temperatursensoren nicht zuordnen kann? Ich kann mir zwar die einzelnen Seriennummer auslesen, aber welcher jetzt die Kesseltempetatur und welcher die Vorlauftemperatur wieder gibt, weiß ich nicht. Die einzige Anwendung wo diese Seriennummer nützlich ist, ist z.B wenn man eine Temperaturdifferenz braucht, oder? Mir ist bis jetzt nur die Möglichkeit eingefallen einen analogen Mutiplexer zu verwenden, um somit die Sensoren eindeutig zuordnen zu können.(CD 4051) Gibts da besserer Möglichkeiten, oder hab ich da was überdehen? Grüsse Rick
Vielleicht so, wie man es bei Netzwerkkarten macht: Die "Seriennummer" (im Fall der Netzwerkkarte MAC-Adresse) auf den Sensor drauf schreiben. Dazu wäre es halt nötig, die Seriennummern der Sensoren vor dem Einbau festzustellen. Das sollte aber auch ein relativ kleines Problem sein...
Die Sensoren habe 2 Byte EEPROM, darin kannst Du z.B. die Meßstellennummer ablegen. Dazu die Sensoren einzeln anschließen, dann weißt Du ja, welcher dran ist. Mit ROM-Search liest man sie dann immer der Reihe nach aus und speichert das Ergebnis entsprechend der Meßstellennummer. Peter
Hi! Danke erstmal für eure Antworten. Das ist dann bei ungefähr 10 Sensoren eine ganz schöne Initialisierungsprozedur....ggg...und sollte einmal ein Sensor den "Geist" aufgeben, so muss ich alle anderen Sensoren wieder abschließen und alles beginnt von vorne. Wenn man über einen Multiplexer immer nur einen Sensor am Pin hat, so kann man außerdem auch einfach die ROM-Prozedur überspringen und hat gleichzeitig eine eindeutige Zuordnung (8 Sensoren pro Multiplexer). Hat jemand Erfahrungen von euch, wie lange die Kabel zu den Sensoren sein dürfen? Hie im Forum hab ich gelesen, daß bis etwa 10m man die DS12B20 direkt anschleißen kann, darüber braucht man ne Ausgleichsschaltung. Grüsse Rick
Also zur Kabellänge kann ich sagen, dass ich mehrere 18S20 und diverse andere Sensorik an 25m + Abzwige cat.5 direkt an einem AVR IO betrieben habe und keine Fehler in der Übertragung auftraten. Ich halte 10 m auch für absolut unkritisch, alles größere würd ich erst mal ohne ext. Beschaltung testen.
Rick wrote: > Das ist dann bei ungefähr 10 Sensoren eine ganz schöne > Initialisierungsprozedur....ggg...und sollte einmal ein Sensor den > "Geist" aufgeben, so muss ich alle anderen Sensoren wieder abschließen > und alles beginnt von vorne. Man kann es natürlich auch schön machen. Ein neuer Sensor hat im EEPROM 0xFFFF stehen, dann springt man in einen Routine, mit der man die Meßstelle zuweist. Somit muß ein einmal definierter Sensor nicht mehr abgesteckt werden. Es reicht, einen neuen Sensor anzustecken. Wenn es nicht stört, daß jeder Sensor ne extra Leitung hat, kann man auch multiplexen. Dann fallen bei ner Leitungsstörung nicht alle Senosren gleichzeitig aus. Statt extra Multiplexer kann man besser einen ganzen Port nehmen, wo dann der 1-Wire Funktion der aktive Pin per Bitmaske übrgeben wird. Beim Starten der Wandlung kann man dann mit der Maske 0xFF alle 8 Sensoren gleichzeitig starten. Peter
Rick wrote: > Das ist dann bei ungefähr 10 Sensoren eine ganz schöne > Initialisierungsprozedur....ggg...und sollte einmal ein Sensor den > "Geist" aufgeben, so muss ich alle anderen Sensoren wieder abschließen > und alles beginnt von vorne. Stimmt schon, man sollte diese Sensoren so montieren, dass man sie ohne die Wand aufzumeisseln vom Bus trennen kann. Kann ja auch mal einer kaputt gehen und den Bus lahmlegen. Letzten Endes benötigst du eine Zuordnungstabelle ID=Funktion. Wenn man die Dinger also einen nach dem anderen an den Bus dranhängt, wird es einfach. Und der Fall eines Austauschs ist auch trivial: der Neue ist der einzige, der noch keine Zuordnung zu einer Funktion hat. > Wenn man über einen Multiplexer immer nur einen Sensor am Pin hat, so > kann man außerdem auch einfach die ROM-Prozedur überspringen und hat > gleichzeitig eine eindeutige Zuordnung (8 Sensoren pro Multiplexer). Wenn der dabei entstehende Strippensalat akzeptabel ist, dann mach das. > Hat jemand Erfahrungen von euch, wie lange die Kabel zu den Sensoren > sein dürfen? Dallas/Maxim hat davon jede Menge, und das auch zu (e)Papier gebracht. Lies: such dort nach entsprechenden Appnotes.
@Rick: Ich habe bei meiner Steuerung zwei Pins verwendet. An einem hängen alle Sensoren im Normalbetrieb dran. Am zweiten Pin hänge ich einen neuen Sensor dran wenn ich ihn "beschriften" will bevor an den Pin für den Normalbetrieb drankommt. Sollte also ein Sensor ausfallen, "beschrifte" ich einen neuen und klemm ihn da zu den anderen Sensoren dran, so ist der Normalbetrieb nicht gestört bzw. geht der Austausch schnell von statten. Markus
Hi! @Markus neu: An diese Möglichkeit hab ich auch schon gedacht. Wie hast Du das im Detail gelöst? Weißt du per Display dann zu der ausgelesenen Seriennummer die ensprechende Mess-Stellennummer zu? Eure Lösungen sind programmiertechnisch gesehen natürlich elleganter als die meinige. Jedoch muß ich leider berücksichtigen, daß ich immer noch blutiger Anfänger in Sachen C-Programmierung und AVR-Controller bin. Somit hab ich mir gedacht, ich nehm 2 Stück 8in1 analog Multiplexer, häng jeden an einen eigenen Pin und hänge die 3 Adressleitungen zusammen und schließe sie ebenfalls an den Controller an. Somit benötige ich für 16 Temp.sensoren nur 5Pins (3 Adress- und 2 Datenleitungen) Eine Wahrheitstabelle für die Adressierung der einzelnen Sensoren sollte eigentlich kein Problem sein. Programmiertechnisch gesehen, aus meiner Sicht, die einfachste Methode. Mit einder Funktion kann ich dann alle Sensoren auf einmal resetten. Die ROM-Funktion überspringen, den Temp.-Konvertierungsbefehl senden und nach 1sec die Temparatur einzeln auslesen. Grüsse Rick
Rick wrote: > Hi! > > @Markus neu: > > An diese Möglichkeit hab ich auch schon gedacht. > Wie hast Du das im Detail gelöst? > Weißt du per Display dann zu der ausgelesenen Seriennummer die > ensprechende Mess-Stellennummer zu? Nein, nicht ganz. Im Display stell ich eine Nummer ein (1 - 9) und schreibe sie ins ROM des Sensors. Diese Nummern kann ich dann natürlich in meinem Programm fest zuordnen (1=Pufferspeichersensor, 2=Aussentemperatur, 3=Ölkesseltemperatur usw.). Beim Auslesen der Sensoren lese ich neben der Temperatur auch die 2Byte Eeprom mit aus (das LowByte würde eigentlich genügen) - schon kann ich wieder zuordnen was für ein Sensor das ist. > Eure Lösungen sind programmiertechnisch gesehen natürlich elleganter als > die meinige. Jedoch muß ich leider berücksichtigen, daß ich immer noch > blutiger Anfänger in Sachen C-Programmierung und AVR-Controller bin. > Somit hab ich mir gedacht, ich nehm 2 Stück 8in1 analog Multiplexer, > häng jeden an einen eigenen Pin und hänge die 3 Adressleitungen zusammen > und schließe sie ebenfalls an den Controller an. Somit benötige ich für > 16 Temp.sensoren nur 5Pins (3 Adress- und 2 Datenleitungen) > Eine Wahrheitstabelle für die Adressierung der einzelnen Sensoren sollte > eigentlich kein Problem sein. > Programmiertechnisch gesehen, aus meiner Sicht, die einfachste Methode. > > Mit einder Funktion kann ich dann alle Sensoren auf einmal resetten. > Die ROM-Funktion überspringen, den Temp.-Konvertierungsbefehl senden und > nach 1sec die Temparatur einzeln auslesen. > > Grüsse Rick Ich betrachte mich schon auch als Anfänger was die C-Programmierung betrifft, aber deine Lösung erscheint mir aus meiner (bescheidenen) Sicht aufwändiger. Wenns für dich so lösbar und praktikabel ist würd ich natürlich dabei bleiben! Viele Wege führen nach Rom ;-)! Gruß - Markus
Hi! @Markus: Du meinst Du schreibst die Mess-Stellennummer ins RAM und von dort ins EEPROM.(EERAM) Ins ROM kannst nu nichts schreiben, denn das steht ja nur die Kennung, die Seriennummer und die CRC darüber. Deine Lösung spricht mich technisch gesehen auch mehr an. Du würdest mir nicht zufällig Deinen Code überlassen, damit ich mir mal ansehen kann, wie man so was macht, oder? ------------------------------------------------------------------ Ich habe mir die App.Notes Nr. 127, 148, 163, 187 und 203 von Maxim runtergeladen. Danke für den Tipp. Grüsse Rick
Also ich denke mal, dass Du deine Sensoren ja mit einem Stecker an deinen Atmel anschließt und die nicht direkt einlötest :-) Also ist es doch kein Problem: a) Neuen Sensor anstecken b) Romsearch auslösen (Taste an deiner Steuerung) c) neuer Sensor wird am Display angezeigt d) Sensor zuweisen über weiteren Tastendruck e) wenn mehr Senoren, weiter bei a) Man hat sofort einen Kabel Test. Und wenn deine Steuerung ein Display hat und 2 Tasten (Menü und Enter) kann man das Komfortabel Implementieren. Die Zuordnung der Sensoren kann man dann im EEPROM des AVR sichern. Ich würde hier die Eindeutige ID sichern. Der Zugriff aufs EEPROM des AVR ist schneller und einfacher. Und ich muss nicht immer suchen Wer hat den die Sensor ID x im EPROM stehen. Zyklisches Vorgehen: a) lese nächste Sensor ID aus EEPROM b) Sensor mit ID anweisen Temperatur zu messen c1) kein ACK Sensor defekt nicht mehr da -> Fehlermeldung und ab zu a) c2) wenn ACK Sensor auslesen und nutzen d) ab zu a) So würde ich das tun... Auch kann man zyklisch einen Romsearch machen und neue Sensoren Automatisch anbieten im Menü als "unassigned" und Fehlende einfach feststellen. Das würde bei der Ablage der Sensor ID im EEPROM des Sensors nicht so einfach gehen. Und die Sensor ID muss ja so oder so zugewiesen werden. Also hilft hier nur Stückweises anstecken und zuordnen. Mit der Kabellänge habe ich keine Erfahrung, aber da kamen ja schon genug Hinweise zu App Notes. Gruß Juergen
Rick wrote: > Hi! > > @Markus: > > Du meinst Du schreibst die Mess-Stellennummer ins RAM und von dort ins > EEPROM.(EERAM) > Ins ROM kannst nu nichts schreiben, denn das steht ja nur die Kennung, > die Seriennummer und die CRC darüber. Gemeint ist natürlich das EEPROM! > Deine Lösung spricht mich technisch gesehen auch mehr an. > Du würdest mir nicht zufällig Deinen Code überlassen, damit ich mir mal > ansehen kann, wie man so was macht, oder? > Basis meiner 1Wire Funktionen ist die 1Wire Lib von Peter Dannegger. Die findest du hier in der Codesammlung. Meine Funktion zum Speichern der ID sieht folgendermassen aus:
1 | char ow_setID(unsigned int id) |
2 | {
|
3 | if(W1_IN & (1<<W1_PID)){ //prüfen ob Bus an PD4 i. O. (high) ist |
4 | if(w1_reset(W1_PID)){ //resetten und prüfen ob Sensor antwortet |
5 | return 'K';} //Kein Sensor gefunden |
6 | |
7 | w1_byte_wr(SKIP_ROM, W1_PID); //SKIP_ROM an Sensor senden |
8 | w1_byte_wr(WRITE, W1_PID); //Schreibvorgang initiieren |
9 | w1_byte_wr(id, W1_PID); //1.Byte schreiben |
10 | w1_byte_wr(id, W1_PID); //2.Byte schreiben - immer 0 da nicht benutzt |
11 | w1_byte_wr(0x7f, W1_PID); //3.Byte: Config Byte -> 12bit Auflösung |
12 | |
13 | if(w1_reset(W1_PID)){ //resetten und prüfen ob Sensor antwortet |
14 | return 'S';} //Kein Sensor nach Schreibvorgang gefunden |
15 | w1_byte_wr(SKIP_ROM, W1_PID); //SKIP_ROM an Sensor senden |
16 | w1_byte_wr(EE_WRITE, W1_PID); //Neue Werte im EEProm speichern |
17 | _delay_ms(10); //Warten bis Speichervorgang abgeschlossen ist |
18 | return 'E'; //Kommando erfolgreich |
19 | }//1.if |
20 | else{ |
21 | return 'F'; //Busfehler |
22 | } //1.else |
23 | |
24 | }
|
Ich hab die Lib von Peter so abgeändert dass immer der Pin mitgegeben wird, an dem der Sensor angeschlossen ist. Der Rest ist relativ einfach bzw. nach einem eingehenden Studium der Maxim Datenblätter nicht allzu schwierig. Gruß - Markus
Hier mal Bilder vom "Pilotbetrieb" meiner Heizungssteuerung. Zu sehen ist die Verkabelung zu den Sensoren im Pufferspeicher, alles noch "frei Luft" verdrahtet.
Hi! @Markus Danke für Dein Beispiel. Ich versuche gerade selbst den erforderlichen Code für meine Methode zu schreiben. Überprüfst Du auch per CRC, ob die Daten richtig ankommen? Ich schnall das nicht wirklich. In der AVR libc gibts dafür die Bibliothek <util/crc16.h> Die Funktion "crc_ibutton_update" generiert die CRC nach dem Polynom von MAXIM. Mit den Parametern komm ich jedoch nicht klar. Was ist seed? Ich habe folgenden Code gefunden (von AVR Freaks): Funktion für CRC: unsigned char ow_ComputeCRC8(unsigned char inData, unsigned char seed) hier sind die Parameter seed und inData im Gegensatz zur libc Bibliothek vertauscht. Aufruf beim Auslesen der Temparatur: crc=0 crc= ow_computeCRC8(scratchpad[i], crc); scratchpad enthält die 9 ausgelesenen Bytes des RAM des DS18B20. i wird von 0 bis acht durchgezählt anschließend wird diese crc mit dem 9Byte (die CRC vom Sensor) verglichen. Grüße Rick
Hi, nein ich überprüfe per Code nicht ob die Daten richtig gespeichert wurde. Zum Anzeigen der ID hab ich eine Funktion die diese aus dem Sensor ausliest und auf dem Display anzeigt, so "prüfe" ich. Gruß - Markus
Hi! Ich meinte auch, die CRC zu verwenden, um zu überprüfen, ob die Temparatur korrekt ausgelesen und übertragen wurde. Aber über die ROM-Daten kann man ja auch eine CRC machen. Kennt sich jemand mit der CRC aus? Grüsse Rick
Hallo Rick! Eine CRC Funktion für Dallas ist in der AVR-libc dabei, die nutze ich auch. Funktioniert prima. Schau mal in die Doku. Gruß Stefan
Hallo Stefan! Ein bißchen weiter oben, hab ich über genau diese CRC-Funktion geschrieben;-) Wie hast Du diese eingebunden? Bei mir gibts immer ne Compiler Fehlermeldung. undefined reference to 'crc_ibutton_update' Ich habs so gemacht: for(c=0;c<=7;c++) crc = crc_ibutton_update(crc, scratchpad[c]); if( crc == scratchpad[8]) // wenn CRC ok, dann Temparatur aufgeben ....... Gruß Rick
Hallo Rick
1 | uint8_t checkcrc(uint8_t bytes, uint8_t data[]) |
2 | {
|
3 | uint8_t crc = 0, i; |
4 | for (i = 0; i < bytes; i++) |
5 | crc = _crc_ibutton_update(crc, data[i]); |
6 | return crc; // must be 0 |
7 | };
|
Versuchst mal damit. Gruß
Hi Stefan! Der return-Wert verwirrt mich etwas. Soll der nicht der gleiche CRC-Wert sein wie das 9. ausgelesene Byte aus dem Scratchpad?(=CRC vom Sensor) Anschließender Vergleich: if( crc == scratchpad[8]) // wenn CRC ok, dann Temparatur aufgeben Gruß Rick
Hallo Rick Habe die funktion aus der libc Doku. Seite 113, Version 1.4.6 Habe sie nur etwas umgestrickt, funktioniert bei mir tatellos. Schau mal im Angehangen Daten blatt seite 8 Letzter Absatz Auszug: Next, the 8-bit ROM code or scratchpad CRC from the DS18B20 must be shifted into the circuit. At this point, if the re-calculated CRC was correct, the shift register will contain all 0s Gruß
Hallo Stefan! Ich hab, jedenfalls dachte ich das, das selbe Datenblatt ausgedruckt vor mir liegen. Da steht das nicht drinnen :( Also wenn ich das jetzt richtig geschnallt habe: Ich schiebe die empfangenen 7Bytes beginnend mit dem 0. Byte aus dem Scratchpad in die CRC-Fkt. dann entsthet mein eigener CRC Code. Wenn ich dann das 8.Byte aus dem Scratchpad, die CRC vom Sensor, in die CRC_Fkt. reinschiebe so muß das Resultat null sein. Vielen Dank, Du hast mir sehr geholfen! Gruß Rick
Hallo Rick so stehts in meinem Daten blatt und so funktionierts auch bei mir. Und so wie du das verstanden hast ist es auch richtig Viel erfolg Gruß Stefan
Hi @ Markus _neu und ander Erfahrene.... wie habt Ihr die Sensoren eingegbaut? Schrumpfschlauch, Alu-Hülse mit Zeikomponenntenkleber..etc? Wie ist da die Temperaturdifferenz und die Ansprechzeit? Könnte man Eure gesammelten Ratschläge (zB: ID schreiben) nicht ins Wiki stellen....die Fragen tauchen ja zyklisch NEU auf und man sollte doch das Rad nicht neu erfinden. Danke für jede Antwort Achim
Hi Achim! Vor dieser Entscheidung steh ich auch noch. Die Methode mit dem Schrumpfschlauch oder ne Hülse machen und vergießen? Was ich so hier im Forum gelesen habe arbeiten die meisten mit der Schrumpfschlauch-Methode. Wie ich es selber schachen werde, weiß ich auch noch nicht. Auch das was das Vergußmaterial betrifft, kann ich dir keine Antwort geben. Bei Conrad gibt es die Niro-Hülsen zum selber vergießen. Ach n Vergußharz. Gruß Rick
Hi, ich hab meine Sensoren in einer Messinghülse mit Flüssigmetall verklebt. Als Sensor für die Heizung passen sie so optimal in jede Tauchhülse rein. Das Ansprechverhalten verzögert sich dadurch natürlich, aber das ist in dem Fall auch gewünscht. Ne Temperaturdifferenz konnte ich dadurch nicht feststellen. Ich hab z. B. in meiner Schaltung den gleichen Temperaturwert für den Ölkessel wie die Steuerung des Ölkessels selber. Anbei mal ein Bild davon. Als Kabel habe ich 3X1 Ölflex genommen und hinten mit Kleber in der Messinghülse fixiert. Markus
Hi Markus! Hast Du nicht Angst, daß das Flüssigmetall eine Leitende "Schicht" bildet? Woher hast Du die Hülse? Gruß Rick
@Rick: Die Anschlüsse zum Sensor sind komplett mit Schrumpfschlauch isoliert. So ein Messingrohr kriegt man hier: http://www.modellbauschraube.de Markus
Hi! Ich hab da noch ein Verständnisproblem beim Ausleseforgang des Sensors: Ein Bit wird lt. Datenblatt folgendermaßen vom Sensor ausgelesen: Ein Lesevorgang wird durch den Master durch eine fallende Flanke initialisiert. Der Master muß die DQ-Line für mindestens 1 usec auf "0" halten. Anschl. muß der Master die DQ-Line freigeben, damit der DS18B20 senden kann. Die Antwort des Sensors liegt innerhalb von 15 usec ab der fallenden Flanke des Masters. Alle Lesezyklen haben eine Mindesgesamtdauer von 60usec und eine Mindesterholzeit von 1usec zwischen den untersch. Abfragezyklen. Jetzt habe ich aus versch. Beispielcodes unteranderen auch von Peter Dannegger folgende Auslesesequenz gesehen: 1.) DQ-Line auf "0" 2.) 1 usec warten, oder etwas mehr 3.) DQ-Line freigeben (per Pullup-R auf high) 4.) 15-1 usec warten 5.) Pin auf Antwort des Sensors auslesen 6.) 60-15 usec warten + Erholzeit von min. 1usec Die Antwort des Sensort liegt aber genau während der Wartezeit von Punkt 4. Da tut der Controller aber nix anderes als warten. Erst wenn das Zeitfenster vorbei ist wird der Pin abgefragt, wie kann das funktionieren? Müsste man nicht zuerst den Pin abfragen und anschl warten? Grüsse Rick
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.