Habe kurz mal einen neuen Thread aufgemacht. Gestern wo ich mit meinem 100W LED weiter experimentiert hatte, hatte plötzlich was spannendes entdeckt. Nach dem Einschalten ist die Anzeige geweisse Zeit lang OK, so habe ich bisher gesehen. Siehe Bild Anzeige2. Nach einige Minuten sieht die Anzeige so aus wie auf dem Bild Anzeige1 Aber erstmal evtl. ein paar Eckdaten : Atmega8 16 MHz Quarz 100nF Kerkos direkt an den Versorgungspins 10K Pullup beim Reset Eingang 100nF Am AREF nach GND also alles standard Beschaltung, wie ich immer verwende. Das Kabel zum LED Modul wo auch der DS18B20 Sensor sitzt ist etwa 5 Meter lang. Das Kabel, wurde in einem anderen Thread empfohlen 10x 0.25mm2 2 x 3 Adern verdrillt für LED 3 Adern für den Sensor. Sensorausgang mit 4K7 Pullup an 5V Nun jetzt das spannende. Wenn die Anzeige "spinnt" schalte ich kurz das Gerät aus dann gleich wieder ein, ist die Anzeige wieder normal, die Temperatur wird richtig wieder geben.Gewisse Zeit lang Nun meine Frage. Was wird denn bei der "verwirrte" Anzeige dargestellt ?? Der Code ist auch soweit standard hier mal ein Ausschnitt was zum Theman gehört: $regfile = "M8def.dat" $crystal = 16000000 $hwstack = 100 $swstack = 100 $framesize = 100 Dim Sc(9) As Byte Dim Temperatur As Integer Dim Celsius As Single Config 1wire = Portc.5 Locate 2 , 8 Lcd Fusing(celsius , "##.##") 1wreset 1wwrite &HCC ' Überspringe Rombefehl Seriennummer weglassen 1wwrite &H44 'messen Waitms 1000 1wreset 1wwrite &HCC 1wwrite &HBE ' Start Daten lesen Sc(1) = 1wread(9) ' Gelesene Daten ins Array Waitms 500 Temperatur = Makeint(sc(1) , Sc(2)) ' Die oberen und unteren 8Bit in eine 16Bit Integer Variable speichern Print Bin(sc(1)) ; Bin(sc(2)) Celsius = Temperatur / 16
Angehängte Dateien:
-
Anzeige1.jpg
43 KB -
Anzeige2.jpg
45 KB
Sieht so aus als wenn Du deinen Wertebereich für die Ausgabe "°C/PWM" über- oder unterschreitest!
Es muss irgandwas mit dem Temperaturanzeige zusammenhängen. Die Anzeige PWM Wert 0 bis 100% funktioniert aber tadellos Hier der betreffende Code Zeile : Locate 2 , 1 Lcd Chr(223) ; "C/PWM:" Locate 2 , 15 Lcd Fusing(pwm_perc , "##.#") Locate 2 , 20 Lcd "%" Locate 2 , 8 Lcd Fusing(celsius , "##.##") W = Getadc(0) Waitms 250 Perc = W / 50 Pwm = W / 4 Pwm_perc = Pwm / 2.55
hp-freund schrieb: > Was passiert bei celsius>99.99 ? Gute Frage, bisher hatte ich nur Temperaturen gehabt bis ca 60 C Im muss noch folgendes beobachten ( was mir so gerade einfiel ) - Tritt die Störung nur dann auf, wenn PWM sich ändert - Nach welche Zeit - Sensor mit kurze Leitung Fakt ist, wenn diese Störung auftritt bleibt es dabei. Wenn die Steuerung aus und eingeschaltet wird, also die Einstellung PWM Wert ist identisch und die Temperatur ändert sich nicht in 5 Sec, dann ist die Anzeige OK..wieder gewisse Zeit lang. Spannend ist, daß ich schon einige Temperaturmessgeräte gebaut habe, sowas habe ich nicht nicht gesehen.
Thomas der Bastler schrieb: > Es muss irgandwas mit dem Temperaturanzeige zusammenhängen. Dann würde ich vorschlagen, du verzichtest mal auf die 4. Zeile deines LCD und lässt dir dort die Bytes, so wie du sie vom DS1820 bekommst, einfach mal ausgeben. Debuggen heißt nicht, dass man endlos lange auf eine Anzeige starrt, sondern dass man anfängt sich die beteiligten Variablen und ihre Werte näher anzusehen. Und das beginnt ganz vorne, dort wo die "Werte" das erste mal die Bühne betreten. In deinem Fall: nachdem die Bytes vom Sensor abgegriffen wurden.
Nico ... schrieb: > Oder was passiert wenn dein Temperatursensor keine Daten liefert? Also abgeklemmt.. Ist auch interessant..schaue ich auch an.
Lass dir die Messwerte des Sensors doch mal direkt anzeigen. Bytes 0 und 1 in Hexdarstellung. Dann sollte sich klären was und ob der Sensor Daten lifert.
hp-freund schrieb: > Byte 0 und 1 im Datenblatt. Bei dir dann Sc(1) und Sc(2). Bitte um genau Erklärung..
In Datenblatt Seite 7 im Memory Map siehst Du den Aufbau des Array wenn die Werte ausgelesen werden. Auf Seite 4 den Zusammenhang von Byte 0 und 1 des Arrays mit dem Temperaturwert.
Im Datenblatt steht : Byte 0 and byte 1 of the scratchpad contain the LSB and the MSB of the temperature register, Also wäre dies richtig: Temperatur = Makeint(sc(1) , Sc(2)) ' Die oberen und unteren 8Bit in eine 16Bit Integer Variable speichern ich vermute, das Problem könnte woanders liegen. Wie ich schon gesagt habe auf dem Steckbrett habe ich sowas nicht beobachtet, aber kann mich auch täuschen. Ähnlich wird es hier auch so verwendet : http://pc-rentner.de/index.php/ds18b20-bascom Die Grundlagen habe ich hier gelesen.
Grundsätzlich sollte man Darstellungen auf einem LCD immer softwareseitig begrenzen, damit es einem halt nicht die Anzeige zerschießt... Es ist auch ratsam das LCD alle 10min mal neu zu initialisieren, falls mal n Wackler am Stecker oder auftaucht, läuft es dann selber wieder an. Ingo
Ingo schrieb: > Grundsätzlich sollte man Darstellungen auf einem LCD immer > softwareseitig begrenzen, Lcd Fusing(pwm_perc , "##.#") Lcd Fusing(celsius , "##.##")
Thomas der Bastler schrieb: > Im Datenblatt steht : > > Byte 0 and byte 1 of the scratchpad contain the LSB and the MSB of the > temperature register, > > Also wäre dies richtig: Es geht nicht darum was richtig ist oder nicht, sondern WELCHE WERTE DU VOM SENSOR BEKOMMST! Datenübertragungen können auch schon mal gestört sein! Also sieh dir die Werte an! Direkt vom Sensor. So wie die Bytes daherkommen. Geh doch nicht so naiv in die Welt hinein, dass technische Dinge immer 100% zuverlässig und korrekt funktionieren.
Hi
>Lcd Fusing(celsius , "##.##")
Das macht aber nicht das was du denkst. Lies mal deine BASCOM-Hilfe.
MfG Spess
Ich versteh es so : target = FUSING(source, "mask") Target: Die Zeichenfolge, die mit der formatierten Zeichenfolge zugeordnet ist. Source: Die Quelle Variable vom Typ SINGLE, die konvertiert werden Meine Quelle ist vom Datentyp Single Mask: Die Maske für die Formatierung der Zeichenfolge. also ##.## Theoretisch kann maximal dies ausgegeben werden 99.99 Vermute das Problem liegt am Kabel. Werde aber die anderen Tipps auch anschauen.
Hi >Theoretisch kann maximal dies ausgegeben werden >99.99 Nein. Die Vorkommastellen werden überhaupt nicht beeinflußt. Nur die Zahl der Nachkommastellen werden auf die Zahl der # (gerundet) oder & (nicht gerundet) nach dem Komma begrenzt. Deshalb ist es egal, ob du #.##, ##.## oder ###.## hinschreibst. Angezeigt wird das gleiche. MfG Spess
Welches Problem?`Weißt du denn überhaupt schon, WAS überhaupt das Problem ist? Es gibt praktisch fast immer mehrere Möglichkeiten, was passiert sein KÖNNTE. Nur, mit KÖNNTE kann man nicht Bug-fixen. Erst mal muss Gewissheit her, was denn überhaupt das Problem ist. Und das beginnt damit, das man sich die zu verrechnenden Daten ansieht. Ich versteh gar nicht, warum du dich so mit Händen und Füssen wehrst, das absolut naheliegenste zu tun, und dir mal die Bytes vom Sensor anzusehen und deren Werte mit denen zu vergleichen, bei denen du eine vernünftige Ausgabe bekommst. Vielleicht sieht man da tatsächlich nichts. Aber dann hat man zumindest diesen Punkt schon mal ausgeschlossen. Mir wird das jetzt ehrlich zu bunt. Auch weiterhin fröhliches Weiterraten und Stochern im Nebel.
Hi
>Würde die Funktion "Format" was bringen um das Problem zu lösen ?
Nein. Der Wert ist falsch. Was willst du da an der Ausgabe herumdoktern?
Wenn du den Fehler behoben hast stimmt auch die Ausgabe.
MfG Spess
Das Problem liegt an der Kabellänge bzw Störung von der LED ( Adern im Kabel) Nicht am Code.. Den Sensor habe mal direkt in die Buchse (Frontplatte ) gesteckt, da gibt es keine Geisterzahlen.
Thomas der Bastler schrieb: > Das Problem liegt an der Kabellänge bzw Störung von der LED ( Adern im > Kabel) > > Nicht am Code.. Ja Und was glaubst du, warum wir auf dich eingeredet haben, wie auf eine kranke Kuh, dass du dir mal die Bytes vom Sensor ansehen sollst? Da hätte man das nämlich gesehen, dass sich die Bytewerte vom Sensor plötzlich verändern, obwohl sich die Temperatur nicht verändert hat.
Karl Heinz Buchegger schrieb: > Und was glaubst du, warum wir auf dich eingeredet haben, wie auf eine > kranke Kuh, dass du dir mal die Bytes vom Sensor ansehen sollst? Hihi..Ich liebe Dich.... Aber ich mag den einfachen Weg..direkt durch... Spass bei Seite, ganz klar, hätte ich machen können als nächstes wäre gewesen. Aber dafür die Kiste aufschrauben, Programm umfrickeln flashen usw..bestimmt eine halbe Stunde "Abeit" und 2 flaschen Bier 2 Kippen. Einfacher ist es den Sensor direkt an AVR dran... OK folgende Frage. Gibt es 2 Lösungsansätze 1) Kabel kürzen, so eine Sache wieviel, wissen die Götter ( Kann ich nicht über Wasser laufen und habe auch keine Löcher in den Händen ) 2) 2 getrennte Leitungen ..hmmm 3) Sensorausgang "entstören" ? Nochmal kurz Kabel ist 10 x 0.25
Wie wärs mal mit. "Ursache der Störung finden", dann eliminieren und freuen? Immer die Pferde von hinten aufzäumen, mann-o-mann.
Ganz klar...erstmal das komplizierste ... spontan schrieb: > Ursache der Störung finden Hat man ja doch gefunden .Der Weg ist das Ziel.. spontan schrieb: > freuen Sowieso...
So damit dieses Projekt abgeschlossen werden kann. Habe alles soweit jetzt fertig. Das EINZIGE Problem war ja, das die Sensorleitung zusammen mit der LED Leitung in einem Kabel war. 2 getrennte Leitungen gleiche Länge als ca 5 Meter, absolut kein Problem, keine Geisterzahlen und die Temperaturmessung ist super. Soviel zum Thema....also der Code war von anfang an richtig..LoL
Thomas der Bastler schrieb: > Soviel zum Thema....also der Code war von anfang an richtig..LoL Niemand hat das Gegenteil behauptet. Aber es ist keine Schande, wenn man den Computer dazu benutzt, dass er einem bei der Fehlersuche hilft. Ja, das geht! Und ehe man ein Gehäuse zuschraubt, macht man sowieso einen Funktionstest. Von daher geht mir das Argument "Ja, aber Gehäuse aufschrauben und neu flashen wäre so viel Arbeit gewesen" am Allerwertesten vorbei. Im Endeffekt hat es so länger gedauert, als wenn man von Anfang an gleich Nägel mit Köpfen gemacht hätte.
Karl Heinz Buchegger schrieb: > Im Endeffekt hat es so länger gedauert, als wenn > man von Anfang an gleich Nägel mit Köpfen gemacht hätte. Eben nicht... Sensor in die Ausgangbuchse gesteckt alls OK. Also muss ich nicht am Code herumwurstelt und LCD Ausgaben basteln Sensor am langen Kabel OK Also die ursache für das Problem ist je erkannt. Mann kann eben ein Gericht auf verschiedene Weise zubereiten..smile..
Thomas der Bastler schrieb: > Nochmal kurz Kabel ist 10 x 0.25 Zentimeter, Millimeter, Meter, Kilometer?
Mr. X schrub: >Zentimeter, Millimeter, Meter, Kilometer? Zitat: >Das Kabel, wurde in einem anderen Thread empfohlen 10x >0.25mm2 >2 x 3 Adern verdrillt für LED 3 Adern für den Sensor. >Sensorausgang mit 4K7 Pullup an 5V MfG Paul
Hallo Thomas, ich würde schon den Programmteil ergänzen und eine Fehlerüberprüfung einbauen. Könnte ja ganz einfach sein, dass zwei Messwerte des DS18B20 verglichen werden und wenn |Messwert_alt - Messwert_neu| > FEHLER_SCHWELLE ist, dann wird der Messwert verworfen. Mach mal ein Test mit einem 2m (145MHz) Funkgerät in der Nähe deiner Schaltung. Ich habe hier so ein 15V NG1620-BL Netzteil, da laufen dann alle Anzeigenwerte weg, auch die Ausgangsspannug stimmt nicht mehr mit dem eingestellten Wert überein. Auch großzügige Abblockkondensatoren haben bisher nur die LCD-Pannelmeter zur passenden Reaktion bewegt.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.