Problem mit One-Wire-Bus

Hallo,
ich bastel an einer Regelung für meine FBH rum. Ich verwende einen Arduino Mega 2560 mit Ethernet-Shield. Als Temperatursensoren vewrwende ich den DS18B20 von Dallas mittels One-Wire-Bus. Das Haus erstreckt sich über vier Etagen, vom Keller bis zum Dachgeschoss. Die Regelung befindet sich bei der Heizung im Keller und von dort führen vorhandene Kabel sternförmig jeweils in eine Etage. An den Enden hängen dann, wieder sternförmig, 6 bis 14 Sensoren. Dadurch ist das Leitungsnetz und damit der One-Wire-Bus umfangreich. Keller- und Dachgeschoss sind angeschlossen und funktionieren. Der Vorwiederstand zwischen Plus und Digital-Pin ist schon auf 1,2 kOhm reduziert. Beim Anschluss weiterer Sensoren in einer weiteren Etage hört die Zuverlässigkeit auf.
Meine C- und Programmierkentnisse sind begrenzt. Ich habe viele Teile meines Sketches von unterschiedlichen Stellen zusammenkopiert. Einige Daten, die im Sketch verwendet werden, befinden sich in einer Datei auf der SD-Karte: die Sensor-ID und ein Klarname, die Auflösung, die Nummer eines zu schaltenden Pins, eine Soll-Temperatur. Zu Beginn des Sketches, im Setup, vergleiche ich die Anzahl Sensoren am Bus und in der Datei. Zusätzlich prüfe ich, ob unbekannte Sensoren am Bus sind und ob bekannte Sensoren fehlen. In der Loop werden dann die einzelnen Sensoren angesprochen, ihre Temperatur abgefragt, auf der SD gespeichert und am Terminal per USB angezeigt. Weiterhin wird die Temperatur mit dem Soll-Wert verglichen und der Ausgangspin nach einigen Berechnungen geschaltet.
Die Temperaturmessung funktioniert noch zuverlässig. Die Unzuverlässigkeit tritt bei der Prüfung des Sensor-Bestandes auf. Obwohl dies sehr hilfreich ist, wenns funktioniert. Sowie ich einen neuen Sensor hinzufüge wird mir die ID angezeigt und ich kann sie in die Datei übernehmen. Es ist jetzt aber die Situation eingetreten, wenn ich einen Sensor hinzufüge, dann werden plötzlich mehrere bekannte Sensoren als fehlend angezeigt und andere als neue. Daraus schließe ich, dass die Struktur des One-Wire-Busses an seine Grenzen stößt.
Als Ursache sehe ich drei Möglichkeiten:

    • mein Sketch ist fehlerhaft. Der betreffende Teil ist (hoffentlich) fehlerfrei beigefügt. Die eingefügten Delays haben keine wirkliche Verbesserung gebracht.
    • die Hardware (Arduino) ist überfordert. Stromversorgung?
    • der One-Wire-Bus ist an seiner Grenze. Ich habe überlegt, den One-Wire-bus zu teilen, z.B. jede Etage ein eigener Bus. Habe aber überhaupt keine Idee wie ich das im Sketch umsetzen soll. Der Pin für den One-Wire-Bus ist in allen Beispielen im allgemeinen Teil der Sketche definiert. So auch in meinem Sketch. Mir fehlt schon die Idee, wie ich in einer Schleife mehrere One-Wire-Bus-Pins durchlaufen kann.
      Anmerkung: Aufgrund der Größe musste ich den Sketch als Anlage anfügen.
      Gerd

HR_42a.ino (23.9 KB)

Hallo,

eine verzweifelte Möglichkeit wäre zu prüfen ob jeder Dallas Sensoren wirklich eine andere Adressen hat? Dafür müßtest Du jeden Sensor einzeln "auslesen" und die Adresse notieren. Es könnte ja sein das Du nach 100 Sensoren den 101. anschließt und der eine Adresse hat die schon ein anderer hat.

Spannungsversorung extra zugeführt oder als Parasit?

Sterntopologie kann Probleme machen was man so liest, da dadurch Refklektionen an den Knotenpunkten entstehen.

Ist es möglich die zusätzlichen Sensoren an einen neuen Strang anzuschließen, statt an den ersten? Das wäre erst mal das vernünftigste.

Programm-technisch ist das simpel. Du legst einfach eine weitere Instanz von OneWire an und DallasTemperature an. z.B. so:

OneWire oneWire1(2);
DallasTemperature sensors1(&oneWire1);

OneWire oneWire2(3);
DallasTemperature sensors2(&oneWire2);

Dann muss man die Funktionen jeweils einmal mit sensors1 und sensor2 aufrufen. Man könnte sich auch ein Array aus DallasTemperature anlegen, aber bei 2 Instanzen bringt das noch nicht wirklich was.

P.S.: Man kann das interne Array der String Klasse neuerdings mit c_str() ansprechen (nur lesender Zugriff natürlich). Der extra Puffer und toCharArray() ist also nicht mehr nötig. Das ist nicht dokumentiert, aber entspricht der C++ std::string Klasse:
http://www.cplusplus.com/reference/string/string/c_str/

Damit geht dann einfach sowas:

String test = "123";
int i = atoi(test.c_str());

Hallo Doc_Arduino,
Danke, für den Hinweis. Es wäre mal interessant zu wissen,

  1. ob es schon vorgekommen ist, dass Dallas eine ID mehr als einmal vergeben hat und
  2. wie sich Arduino mit dem One-Wire-Bus verhält, wenn zwei gleiche IDs am Bus hängen.
    Aber ich glaube, dass ist in Bezug auf mein Problem ein darüberhinausgehender akademischer Denkansatz.
    Gruß Gerd

Hallo Serenifly,
die Aufteilung des One-Wire-Busses war ja schon mal meine Überlegung. Bei meiner Busstruktur, vier Etagen = vier Stränge, würden sich schon vier Busse anbieten. Wenn ich meine Gedanken weiter Denke, könnten noch zwei bis drei dazu kommen. Da sie vermutlich alle die gleichen Routinen durchlaufen bevorzuge ich eine Schleife über die Busse.
Dass ist meine Vorstellung. Aber in Software umsetzen kann ich das nicht. Ich kann ja keine Schleife über "sensor-n" laufen lassen. Kannst Du mir ein realisierbares Beispiel geben?
Gruß Gerd

Hallo Doc_Arduino,
ich vergaß zu erwähnen, dass ich keine parasitäre Versorgung habe, sondern die 5V direkt durchführe, also dreiadriger Bus.
Gruß Gerd

gerd-wolfgang:
Ich kann ja keine Schleife über "sensor-n" laufen lassen. Kannst Du mir ein realisierbares Beispiel geben?

Natürlich geht das. Wie gesagt mit Arrays.

DallasTemperature sensors[] = { &OneWire(2), &OneWire(3), &OneWire(4), &OneWire(5) };

oder ausführlich:

OneWire oneWire1(2);
OneWire oneWire2(3);
OneWire oneWire3(4);
OneWire oneWire4(5);
DallasTemperature sensors[] = { &oneWire1, &oneWire2, &oneWire3, &oneWire4 };

Man kann dann z.B. sensors[0].getDeviceCount(); machen um die Anzahl der Sensoren zu bekommen die an Pin 2 hängen

Vielen, vielen Dank.
Heute Nacht kam mir noch der Gedanke, ich hätte vermutlich auch die 5V der einzelnen Stränge schalten können. Aber das Array ist viel besser. Da fehlen mir leider immer die Kenntnisse.
Gruß Gerd