Interessante LCD Ausgabe

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

Oder was passiert wenn dein Temperatursensor keine Daten liefert?

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.

hp-freund schrieb:
> Byte 0 und 1 im Datenblatt. Bei dir dann Sc(1) und Sc(2).

Bitte um genau Erklärung..

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.

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.

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.

Würde die Funktion "Format" was bringen um das Problem zu lösen ?

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.

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

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..

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.