Probleme mit 1-Wire Bus von Dallas Maxim

Hallo,

ich habe eine Schaltung zur Messung von Temperaturen aufgebaut die den

1-Wire Bus von Dallas bzw. Maxim benutzt. Zum Auslesen über den PC benutze ich den DS9490R/DS9490B USB to 1-Wire/iButton Adapter, ausgelesen werden die ICs DS2450 1-Wire Quad A/D Converter, DS18S20-PAR 1-Wire Parasite-Power Digital Thermometer und DS1822-PAR Econo 1-Wire Parasite-Power Digital Thermometer. Das Ganze dient zur Messung von Temperaturen an mehreren Stellen, teilweise auch mit drahtloser IR Übertragung und müsste über einige Stunden lang störungsfrei funktionieren, bei einer Messung pro Sekunde also einige 1000 Aufrufe.

Die Verbindung ist ein kurzes Kabel mit unter 1 m Länge, der OneWire Bus kann auch bis zu 200 oder 300 m lang sein. Mit verschiedenen Beispielprogrammen von Maxim, aber auch mit eigenen Programmen habe ich immer das gleiche Problem, die Übertragung funktioniert wunderbar für einige 100 bis einige 1000 Aufrufe, aber irgendwann bricht sie ab und das Programm hängt. Bei einem Testprogramm in Visual Basic sehe ich im Debugger genau das das Programm immer im Aufruf tc.doTemperatureConvert(tc_state) oder adc.doADConvert(0, ad_state) des 1-Wire Drivers hängenbleibt. Es ging auch schon mal 17984 mal gut, der Fehler trat aber auch schon nach nur wenigen 100 Aufrufen auf.

Ich habe auch schon verschiednene Entstörungsmaßnahmen probiert, Abschluß der Busleitung mit einem Widerstand 330 oder 470 Ohm, mit einer Reihenschaltung 120 Ohm und 4,7 nF, eine Ferritperle direkt am 1-Wire Slave, ein Klappferrit um den 1-Wire Bus aber bisher ohne Erfolg. Eine Schottkydiode parallel zum 1-Wire Slave wie im 1-Wire Design Guide von

formatting link
beschrieben muß ich noch ausprobieren.

Es sind auch die Quellen der Treiber in Java veröffentlicht, unter Java tritt das Problem ebenso auf, aber mit der Sun Java NetBeans IDE kann man im Debugger nicht feststellen wo das Programm hängt wenn es denn einmal hängt.

Im Moment läuft noch ein Test mit einem Klappferrit um die Leitung, in der Mitte der Leitung trat der "Hänger" nach 264 Aufrufen auf, mit dem Ferrit direkt am 1-Wire Slave nach 399 Aufrufen, mit dem Ferrit direkt an dem 1-Wire to USB Adapter läuft es im Moment schon über 8900 mal ohne Problem. Aber es muß auch einige 100000 Mal sicher funktionieren, der AD Wandler DS2450 rauscht etwas, da muß ich über etwa 8 bis 64 Aufrufe mitteln um saubere Werte zu bekommen, es sollten also auch über eine Million Aufrufe funktionieren, ein Mittelwert pro Sekunde und das über einige Stunden lang.

Verschiedene 1-Wire Slaves habe ich ohne Erfolg probiert, verschiedene kurze Leitungen auch. Leider haben ich nur einen 1-Wire to USB Adapter da, da muß ich erst was bestellen um tauschen zu können.

Das seltene und statistische Auftreten des Fehlers macht es sehr schwer den Fehler zu fassen und zu beseitigen.

Mit dem Support von Maxim habe ich auch einige Emails ausgetauscht, aber das hat mich auch noch nicht weiter gebracht.

Hat jemand noch gute Ideen was ich noch machen könnte?

Vielen Dank schon mal,

Uwe

Reply to
Uwe Hercksen
Loading thread data ...

Adapter tauschen ist wohl die beste Idee, wenn man es nicht gleich selber bauen möchte :-) Das One Wire Protkoll ist ja ziemlich einfach, ich habe das mal vor einiger Zeit in VHDL programmiert:

formatting link

und läuft problemlos seit Jahren in einem Gerät, was kommerziell verkauft wird, auch mit einem Maxim-Chip, der abgefragt wird. Wenn das Programm hängt, würde ich eher auf ein Problem des USB-Adapters tippen. Wenn es z.B. ein HID-Adapter ist, der synchron angesprochen wird und im Microcontroller vielleicht mal ein USB-Paket nicht beantwortet wird, könnte daß das beobachtete Verhalten bei schlecht geschriebener PC-Software erklären. Das One Wire Protokoll selbst bietet nicht viel Möglichkeiten, daß ein Slave es zum hängen bringen kann. Hast du ein Scope da, um mal zu messen, ob noch was auf der Leitung gesendet wird, wenn es hängt? Ich habe in dem englischsprachigen Wikipedia-Artikel mal ein Timing-Diagramm eingefügt, damit kannst du das mit dem Scope leicht testen, ob z.B. das Device nach einem Reset nicht mehr antwortet:

formatting link

Hängt es immer noch, wenn man den USB-Adapter rauszieht und wieder reinsteckt? Die Chips dabei extra versorgen, aber im DS2450 ist das ja vorgesehen, also die werden nicht über die One Wire Leitung versorgt, was schonmal eine Fehlerquelle weniger ist.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Frank Buss schrieb:

Hallo,

Scope ist da, die Messung nach dem Hänger ist eine hervorragende Idee, vielen Dank.

Du meinst die Verbindung zwischen USB-Adapter und dem 1-Wire Bus trennen? Den Adapter selbst aus der USB Buchse rausziehen möchte ich ohne Abmelden lieber nicht.

Im Moment läuft es mit dem Klappferrit direkt am USB-Adapter schon über

22300 mal fehlerfrei, da warte ich jetzt noch bis 35968. Aber schon seltsam, mit dem Ringkern in der Mitte der Leitung ging es nur 264 mal, direkt am 1-Wire Slave nur 399 mal. Diese zwei Positionen muß ich aber noch einige Male prüfen.

Bye

Reply to
Uwe Hercksen

Nein, ich dachte daran, den Adapter aus der USB Buchse rausziehen, um diese Seite des Aufbaus zu testen. USB ist dafür ausgelegt, daß man das machen kann und gute Software sollte das auch verkraften können. Wenn das Device währenddessen konstant mit der Versorgungsspannung versorgt wird und danach wieder läuft, dann liegt es am Adapter.

Ist aber auch nicht auszuschließen, daß vielleicht ein Slave den Bus auf Low hält. Habe dazu letztens einen Trick gehört: niedrigen Widerstand (20 Ohm oder so) in Serie am Ausgang des USB-Adapters oder an den Eingängen der Slaves schalten und vor und nach dem Widerstand messen. Daran kann man gut sehen, welche Seite den Bus auf low zieht.

Bei den niedrigen Frequenzen sollte es eigentlich keine Probleme geben, es sei denn, die Kommunikation läuft im Overdrive-Modus ab, wobei der kleinste Puls 1 us lang sein kann, gegenüber 5 us im Standard Modus. Im Zusammenhang mit zu großen parasitären Kapazitäten auf dem Bus kann das Signal dann schon stark verschliffen sein. Wenn es die Teilnehmer am Bus erlauben, den Pullup-Widerstand niedriger wählen. Hängen sollte es aber auch bei Fehlern nie, da die Devices ja mit dem langen Reset-Puls am Anfang wieder zurückgestellt werden.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Frank Buss schrieb:

Hallo,

die Position des Klappferrits scheint doch nicht so wichtig zu sein, jetzt läuft es mit dem Ferrit in der Mitte des Kabels schon über 18700 mal fehlerfrei.

Es werden auch noch Schottkydioden parallel zum Slave empfohlen gegen negative Spannungsspitzen am Kabel, BAT54 oder 1N5817 (the 1N5818, or

1N5819 or equivalent may be used), aber ich habe nur BAT41 da, das sollte doch auch gehen? Die BAT54 hat eine Vorwärtsspannung von 240 mV bei 0,1 mA, 320 mV bei 1 mA, 400 mV bei 10 mA und 800 mV bei 100 mA. Die Bat41 hat 400 mV bei 1 mA und max 1000 mv bei 200 mA. Etwas wirkungsvoller ist die BAT54 wohl schon.

Bye

Reply to
Uwe Hercksen

Frank Buss schrieb:

Hallo,

jetzt hatte ich mal wieder ohne den Ferrit getestet und einen neuen Hänger, Abziehen des 1-Wire Bus und wieder verbinden brachte nichts, USB Adapter ziehen und wieder stecken brachte eine OneWireIOException Conversion failed to complete bei adc.doADConvert(0, ad_state)

com.dalsemi.onewire.adapter.OneWireIOException occurred Message="Conversion failed to complete." Source="OneWireAPI.NET" StackTrace: at com.dalsemi.onewire.container.OneWireContainer20.doADConvert(SByte inputSelectMask, SByte readOutControl, Int32 timeUs, SByte[] state) at com.dalsemi.onewire.container.OneWireContainer20.doADConvert(Int32 channel, Int32 preset, SByte[] state) at com.dalsemi.onewire.container.OneWireContainer20.doADConvert(Int32 channel, SByte[] state) at GetA2DVolts.GetA2DForm.ButtonGetVolts_Click(Object sender, EventArgs e) in C:\Documents and Settings\Uwe Hercksen\My Documents\Zentrifuge Temperatur\oneWire sdk\1-wiresdkver400_beta2\Examples\OW.NET\VB.NET\GetA2D_V6\GetA2DForm.vb:line

224

wenn man dann das Programm versucht fortzusetzen kommt die OneWireIOException No device detected

com.dalsemi.onewire.OneWireException occurred Message="No device detected" Source="OneWireAPI.NET" StackTrace: at com.dalsemi.onewire.adapter.DotNetAdapterx86.select(SByte[] address) at com.dalsemi.onewire.container.OneWireContainer20.doADConvert(SByte inputSelectMask, SByte readOutControl, Int32 timeUs, SByte[] state) at com.dalsemi.onewire.container.OneWireContainer20.doADConvert(Int32 channel, Int32 preset, SByte[] state) at com.dalsemi.onewire.container.OneWireContainer20.doADConvert(Int32 channel, SByte[] state) at GetA2DVolts.GetA2DForm.ButtonGetVolts_Click(Object sender, EventArgs e) in C:\Documents and Settings\Uwe Hercksen\My Documents\Zentrifuge Temperatur\oneWire sdk\1-wiresdkver400_beta2\Examples\OW.NET\VB.NET\GetA2D_V6\GetA2DForm.vb:line

224

Ich probier jetzt mal zu messen was am Bus passiert wenn das Programm hängt.

Bye

Reply to
Uwe Hercksen

Uwe Hercksen schrieb:

Hallo,

Nachtrag dazu, wenn man ein zweites Mal das Programm im Debugger fortsetzt läuft es normal weiter.

Bye

Reply to
Uwe Hercksen

Lottogenerator!

Das riecht geradezu nach Einstreungen in den DOW/USB Adapter und dann wird da wohl was aus dem Tritt gebracht. Rennen da freilaufende Handys oder Motoren (Frequenzumrichter!) rum?

Logiganalysator an die Leitung und aufzeichnen. Viel Spass und/oder anständigen Adapter nehmen. Warum der Klimmzug über einen USB Adapter, bei dem Du wohl nichts von den Innereien ... sehen kannst.

Falls Einzelstück oder große Serie: kleinen 8031 nehmen (silabs F300), lass den die ganze Arbeit machen und gut isset.

Das ganze USB Geraffel ist zu fehleranfällig.

Gerade noch mal den Thread überflogen: 300m DOW scheint mir sehr mutig, wenn nicht übermütig. Kann mir nicht vorstellen, dass das gehen soll. Ein paar Meter mag ja noch gehen... Hab z.Zt. keine Datenblätter, aber ich kann mir schon 20-30m nicht vorstellen. Wir reden hier von 5V Pegeln, mit einigermassen kurzen Pulsen und passivem, schlappen PullUp.

Ahh, PullUp, passt der und ist der am Ende der Leitung? Wird gerne übersehen, denn dann braucht man schon eine weitere Speiseleitung für den PullUp. Und bei langer Leitung braucht man an jedem Ende einen, und dann noch so ein paar Probleme für den schwer asymetrischen Bus... Nö, muss ich nicht wirklich haben.

DOW ist ok, aber sicher nicht an langer Leitung.

Saludos Wolfgang

--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
 Click to see the full signature
Reply to
Wolfgang Allinger

Dann liegt es wahrscheinlich an der PC-Software für den USB-Adapter. Wenn es hängt und du dann das Programm neu startest (ggf. Visual Studio komplett neu starten), und es dann auch wieder funktioniert, dann ist es mit Sicherheit eine schlecht programmierte Library auf PC-Seite. Wenn es nur durch raus-/reinstecken am USB-Stecker wieder zum Leben zu erwecken ist, könnte es auch schlechte Firmware im USB-Adapter selbst sein.

Normalerweise laufen USB HID Geräte recht gut, wenn die Software gut programmiert ist. Meine Maus ist z.B. noch nie hängengeblieben. Falls es also ein HID-Gerät ist, versuche das Protokoll vom Hersteller zu erfahren und programmiere die Abfrage selbst.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Ich mach mal die Ingrid:

Was meinst Du, warum in der Industrie 0/4-20mA Stromschleifen so beliebt sind? Maximal 300/2400Bd HART Protokoll. Oder 20mA CL? Geht zuverlässig mit 9600Bd über 400-1000m wenn man es

*fachgerecht* macht. Da stört sich auch nicht an Walzwerksantrieben und Kranbahnen.

Du wirst bei Deinen 300m DOW noch einige Tränen vergiessen. Ich wette 1.000G$/m, das das nicht geht!

Saludos Wolfgang

--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
 Click to see the full signature
Reply to
Wolfgang Allinger

Wolfgang Allinger schrieb:

Hallo,

reg Dich wieder ab, 300 m will ich ja gar nicht, so 1 bis 5 m reichen mir schon. ;-)

Etwas zum Lesen:

formatting link
formatting link
formatting link

Bye

Reply to
Uwe Hercksen

Setze mal einen Scope Plot ins Web. Das mit der Empfindlichkeit auf die Position des Klappferrites (... ferriten? fritten?) ist verdaechtig. Da laeuft etwas haarscharf an der Grasnarbe. Du kannst auch mal spasseshalber ein GSM Handy ausschalten und dann in der Naehe der Chose wieder einschalten. Auch mal Lichtschalter und so betaetigen. Wenn das Programm dabei abkachelt, wissen wir mehr ;-)

--
Gruesse, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg

Bau Dir mit einem kleinen Controller Deinen eigenen 1-wire Master und schau dann nochmal.

Mit freundlichen Grüßen

Frank-Christian Krügel

Reply to
Frank-Christian Kruegel

Du schriebst doch: Die Verbindung ist ein kurzes Kabel mit unter 1 m Länge, der OneWire Bus kann auch bis zu 200 oder 300 m lang sein.

Ich hab mich garnicht aufgeregt, wer sich aufregt, muss sich auch wieder abregen und das ist die Sache meist nicht wert. Q.E.D. :-P

Keine Lust/Zeit im Moment.

Saludos Wolfgang

--
Meine 7 Sinne:
Unsinn, Schwachsinn, Blödsinn, Wahnsinn, Stumpfsinn, Irrsinn, Lötzinn.
 Click to see the full signature
Reply to
Wolfgang Allinger

Joerg schrieb:

Hallo,

die Abhängigkeit von der Position lies sich nicht weiter erhärten. Beim Einschalten irgendeiner Last am Netz kommt mal eine CRC16 Exception, aber die kann abgefangen und behandelt werden, das ist überhaupt kein Problem. Es sieht danach aus als ob der USB to 1-Wire Adapter hängt, wenn man den vom Rechner trennt und wieder steckt kann man das Programm fortsetzen.

Bye

Reply to
Uwe Hercksen

Frank-Christian Kruegel schrieb:

Hallo,

den Aufwand wollte ich mir ersparen, da gibt es auch verschiedene andere fertige Lösungen von seriell nach 1-Wire, da kaufe ich lieber so einen Adapter.

Bye

Reply to
Uwe Hercksen

Uwe Hercksen schrieb:

Welchen Treiber verwendest du? Beide Probleme hatte ich letztes Jahr ebenfalls und die Leute von "owfs" haben daraufhin an den Initialisierungsroutinen rumgepatcht. Seitdem geht es hier.

Mit freundlichem Gruß

Jan

Reply to
Jan Kandziora

Jan Kandziora schrieb:

Hallo,

die von Maxim für Windows. Was sind owfs für Treiber? Für Linux?

Bye

Reply to
Uwe Hercksen

Uwe Hercksen schrieb:

Primär für Linux, laufen aber wohl auch mit MS-Windows, wenn man libusb für MS-Windows installiert und das Zeug mit Cygwin kompiliert.

formatting link
formatting link

Mit freundlichem Gruß

Jan

Reply to
Jan Kandziora

Da ich nicht programmieren kann, suche ich eine Möglichkeit um den 1-Wire Bus mit z.B. Labview ansprechen zukönnen also einen OPC Server oder wie man das nennt, ist das sowas?

Ernst

Reply to
Ernst Keller

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.