Lesefehler bei 1-Wire Instanzen

Hallo,

seit einiger Zeit häufen sich bei mir die Lesefehler bei meinen 1-Wire Komponenten.

Zu meinem Aufbau: an einem IPS 1-Wire LAN Gateway hängt ein 1-Wire HUB von Esera. An diesem wiederum hängen 10 Temperatursensoren, zwei DS2450 Analog Input und ein DS2408 8 Kanal Switch.

Die Temperatursensoren werden alle 60 Sekunden abgefragt und die Analog Inputs alle 10 Sekunden.

Dabei treten nun regelmäßig Fehler bei den Analog Inputs auf, vereinzelt auch am 8-Kanal Switch, nie aber bei den Temperatursensoren.

Hier ein Beispiel:

Die Fehlermeldungen treten wirklich häufig auf.

Hat jemand eine Idee, womit das zusammenhängen könnte?

Ich überlege, ob es vielleicht Kollisionen auf dem Bus sind. Aber wie könnte ich die verhindern? Momentan fällt mir nur ein, alle Timer in den Instanzen auf 0 zu setzen und die Aktualisierungen über ein Skript anzustoßen.

Ich bin momentan etwas ratlos.

Burkhard

So habe ich es jetzt gemacht. Ich habe alle UpdateTimer der Instanzen auf 0 gesetzt und stoße nun die Aktualisierungen über ein zentrales Skript mit OW_RequestStatus() an. Das Skript verhindert das zeitgleiche Ausführen von Aufträgen.

Und siehe da: die Fehler sind komplett verschwunden. Nun läuft es wieder wie am Schnürchen.

@paresy: hat sich an der OneWire Implementierung zuletzt etwas geändert?

Burkhard

Ich hatte damals auch solche Probleme. Es gibt aus IPS heraus sporadisch immer mal wieder Probleme mit den Timings am 1-Wire Bus. Mal mehr, mal weniger und mal gar nicht. Seitdem ich den 1-Wire Controller von ESERA einsetze, habe ich keine Schwierigkeiten mehr. Der 1-Wire Teil wird komplett vom Controller erledigt und ich bekomme die fertige Werte geliefert. Kann das Ding nur empfehlen.

Aktuell nicht - wie schnell fragst du die Geräte denn ab? Evtl. fragen wir die 1-Wire Geräte zu schnell hintereinander ab.

paresy

Hi
Naja, solche Themen kenne ich auch, leider.
Hab als Gateway aber zwei Busse mit LinkUSB. Das Bustiming sollte also auch unabhängig von IPS sein. Beide Busse laufen seit etwa 10 Jahren.
Der erste lief ewig stabil, seit 2-3 Jahren stürzt er nun aber so alle 1-2 Monate ab. Das äußert sich insofern als das die USB Schnittstelle nicht mehr ansprechbar ist. LinkUSB getauscht, USB Hub mehrmals getauscht, Treiber Up u. Downgegradet alles ohne Erfolg.
Der läuft zwar in dieser Hinsicht stabil, aber zeitweise gibt es ebensolche Timeouts wie bei Burkhard. Insbesondere beim DS2450.
Stromversorgung ist bei beiden Bussen Ok - denke ich.

Alles sehr merkwürdig.
Bernhard

Interessant. Dann scheint der wohl etwas anders zu machen als das Symcon 1-Wire LAN Gateway. Oder die Anbindung (bei mir über das Symcon „One Wire Gateway“) ist besser.

Ich frage 9 Tempereratursensoren im 59 Sekunden Rythmus ab, einen Temp.Sensor im 10 Sekunden Rythmus. Die machen aber keine Probleme.

Dann frage ich zwei DS2450 im 60 Sekunden Rythmus ab. Die machen die meisten Probleme.

Dann frage ich einen DS2408 im 30 Sekunden Rythmus ab. Da kommt es vereinzelt zu Problemen.

Zusätzlich wird der DS2408 ab und zu gesetzt. Das macht keine Probleme.

Ich würde zum nächsten Update (nach der RC/Release Phase) einen Parameter einbauen, sodass man eine Pause zwischen den Abfragen definieren kann. Das löst hoffentlich das Problem. Denn normal ist das auf alle Fälle nicht.

@bberndhard: Ich bin kein USB Fan (Ich glaube das habe ich öfter schon gesagt…) denn es passiert genau das, was du erzählst… Es fällt einfach paar Mal im Jahr aus. Das ist USB. Das ist meine Erfahrung damit.

paresy

Klingt gut und ist wert ausprobiert zu werden. Ohne es jetzt konkrete Hinweise zu haben „fühlt“ es sich nach Stress am Bus an.
Hatte mal ein setting mit einem DS2408 bei dem ich zu gewissen Tageszeiten die Pollrate deutlich erhöht hatte. Genau zu diesen zeiten häuften sich auch die Timeouts an den DS2450.
So richtig reproduzierbar war es aber nicht, einfach nur häufiger.

Jaja, stimmt schon.
Hab über viele Jahre massiv auf einen ganzen Zoo von USB Gateways gesetzt. Irgendwie aufgefallen ist das die USB Anschlüsse selbst mit der Zeit manchmal zu schwächeln beginnen. Sei es nun ein externer HUB oder die Anschlüsse am Motherboard.
Ich weiß, klingt unglaubwürdig. Bin ja selbst Chipentwickler - wenn mir das jemand erzählen wollte würde ich ihm das Wort glauben. Ist aber trotzdem so, mehrfach beobachtet.

Der Bus bei dem sich der USB Port komplett weghängt läuft übirgens seit einer unserer letzten Diskussion von vor Monaten an einem Silex Remote USB Adapter. Hatte gegen solche Dinger ja große Skepsis geäußert, die haben sich mal so absolut nicht bewahrheitet.
Allerdings sind die alten Hänger mit verschwundenem USB Port trotzdem geblieben.
Woraus man schließen kann das sich der LinkUSB irgendwie verabschiedet.

Um trotzdem auf ausreichende Betriebssicherheit zu kommen tun einige Watchdogs Dienst. Ist nicht schön, da es das Problem nur versteckt aber besser als kalte Wohnzimmer oder gekochte Auariumfische.

schönes Wochenende
Bernhard

Das hört sich gut an. Ich nutze momentan eine Wartezeit von 500ms. Damit läuft es bei mir gut. Ich kann aber auch mal versuchen, die Zeit auf 0 zu setzen. Dann müssten die Probleme ja wiederkommen …

Gerne. Wäre auf dein Feedback gespannt.

paresy

Ich habe meine Versuche nun abgeschlossen.

Zunächst dachte ich, dass das Einbringen einer Wartezeit eine gravierende Verbesserung gebracht hätte. Aber ich hatte in meinem Testaufbau nicht nur eine Wartezeit, sondern auch schon bis zu 3 Versuche eingebaut. Das hatte ich übersehen.

Also im Ergebnis bringt die Wartezeit nur eine leichte Verbesserung. Die größte Verbesserung bringen die Wiederholungen. Bei mir kommen die meisten Befehle spätestens beim 2. Versuch durch. Vereinzelt wird ein 3. Versuch benötigt und nur ganz selten (alle paar Tage) ein vierter.

In Zahlen:

von ca. 6000 Aufträgen am Tag brauchten 222 einen zweiten Versuch, 28 einen dritten, aber keiner einen vierten.