Hallo zusammen,
ich habe ein Problem und tue mich schwer es zu lösen. Daher möchte ich
die Runde mal zu einem "best doing" befragen:
Für eine Temperaturregelung verwende ich einen TSic306 Temperatursensor,
welcher leider ein eigenartiges Protokoll besitzt. Ich lese die
Temperatur mit einem PIC aus, was prinzipiell auch gut funktioniert. Als
Checksumme gibt es nur ein Parity-Bit, was aber auch bei falschen
Temperaturen richtig sein könnte...
Jedoch gibt es immerzu Temperaturausschläge, was entweder vom Sensor
direkt, von Störungen oder von einer unstabilen Protokollauswertung
kommt.
Nun möchte ich erkennen ob der Sensor defekt ist, ein Kabelbruch
vorliegt und ob die empfangene Temperatur plausibel ist.
Bisher habe ich:
1. Die Temperatur muss innerhalb +-5K der zuletzt empfangenen Temperatur
sein, sonst ist sie ungültig.
2. Empfange ich >=10s keine gültige Temperatur (+-5K), dann schalte ich
in den Fehlermodus.
Problem:
- Bei Systemstart kann es passieren, dass ich zuerst einen fehlerhaften
Temperaturwert empfange (z.B. 110°C). Dann schlägt automatisch 2. zu und
ich bleibe im Fehlermodus hängen oder ich habe eine vollkommen falsche
Temperatur. 110°C als Starttemperatur könnte aber vorkommen, daher nützt
es nichts zu sagen, dass nur Temperaturen <X°C akzeptabel sind.
- Es kommt selten vor, dass tatsächlich >10s kein gültiger Wert
empfangen wird, das soll eigentlich auch nicht passieren.
Hat jemand von euch eine Idee wie man die Überwachung stabil umsetzt?
Da es um eine Kesselbeheizung geht, darf es max. 1 Minute dauern um zu
erkennen, dass die Temperatur falsch ist.
Danke für eure Hilfe und eventuellen Ideen!
Niine
Niine schrieb:> - Bei Systemstart kann es passieren, dass ich zuerst einen fehlerhaften> Temperaturwert empfange (z.B. 110°C). Dann schlägt automatisch 2. zu und> ich bleibe im Fehlermodus hängen oder ich habe eine vollkommen falsche> Temperatur. 110°C als Starttemperatur könnte aber vorkommen, daher nützt> es nichts zu sagen, dass nur Temperaturen <X°C akzeptabel sind.
Du könnest z.B. 100 Werte empfangen und davon den Durchschnitt nehmen.
Davon darf es dann keine zu starken Abweichungen geben.
Hallo,
> Niine schrieb:> verwende ich einen TSic306 Temperatursensor,> welcher leider ein eigenartiges Protokoll besitzt. Ich lese die> Temperatur mit einem PIC aus, was prinzipiell auch gut funktioniert.
Wie ist der Sensor angeschlassen? Welche Leitungslängen?
Welche Kabelart?
> Als Checksumme gibt es nur ein Parity-Bit, was aber auch bei falschen> Temperaturen richtig sein könnte...
Wie oft wird der Sensor ausgelesen?
> Jedoch gibt es immerzu Temperaturausschläge, was entweder vom Sensor> direkt, von Störungen oder von einer unstabilen Protokollauswertung> kommt.
Oder es kommt von einem total krautigen Anschluss, Software, die nicht
störsicher geschrieben ist und einer elektrischen Umgebung, die mit max.
Störbehaftet installiert wurde?
> Nun möchte ich erkennen ob der Sensor defekt ist, ein Kabelbruch> vorliegt und ob die empfangene Temperatur plausibel ist.
Was sollte den bei Defekt oder Kabelbruch an einem digitalen ensor noch
passieren?
Warum sollte die Temp. bei einer dig. Überrtragung fehlerhaft sein?
> Bisher habe ich:> 1. Die Temperatur muss innerhalb +-5K der zuletzt empfangenen Temperatur> sein, sonst ist sie ungültig.> 2. Empfange ich >=10s keine gültige Temperatur (+-5K), dann schalte ich> in den Fehlermodus.
Warum sollte denn in solch langer Zeit kein Sensorsignal eingelesen
werden können?
Deine Angaben sind unplausibel bzw. zeigen ein generelles Problem an.
> Problem:> - Bei Systemstart kann es passieren, dass ich zuerst einen fehlerhaften> Temperaturwert empfange (z.B. 110°C). Dann schlägt automatisch 2. zu und> ich bleibe im Fehlermodus hängen oder ich habe eine vollkommen falsche> Temperatur.
So macht man es auch nicht. Diese Art von Plausibilitätstest kann immer
leicht in die Hose gehen.
Den Sensor kann man doch zig mal in 10s auslesen. Da sollten doch
zufällige Fehler durch Störungen leicht zu erkennen sein (wo kommen die
den her).
Diese könnte mqan auch leicht mit einem Medianfilter eliminieren.
> - Es kommt selten vor, dass tatsächlich >10s kein gültiger Wert> empfangen wird, das soll eigentlich auch nicht passieren.
Also ist deine Aussage "funktioniert eigentlich ganz gut" wohl eher
nicht korrekt!
> Hat jemand von euch eine Idee wie man die Überwachung stabil umsetzt?
Analysiere das Problem. Das kann niemand aus der Ferne machen.
Nimm die Messwerte auf und prüfe ob diese zuverlässig stabile werte
liefern. Prüfe die signalpegel mit einem Oszi und vor allem prüfe, ob
die Stromversorgung stabil ist.
Hast die die Applikationshinweise zum Sensor gelesen (Stützkond.)?
> Da es um eine Kesselbeheizung geht, darf es max. 1 Minute dauern um zu> erkennen, dass die Temperatur falsch ist.
Das könnte man sicher auch in 1s erkennen.
Ansonsten ist auch eine redundante Auslegung empfehlenswert, wenn es
denn zuverlässig sein muß.
Gruß Öletronika
Erstmal schauen ob man die Fehlerquelle nicht beseitigen/verringern
kann.
Bei Systemstart erstmal >10s Werte sammeln, die höchsten und niedrigsten
Werte löschen(die vermutlich Fehlerhaften) die restlichen Werte mitteln
und als Startwert benutzen.
Solange die Fehler halbwegs gleichverteilt auftreten hilft ein
Medianfilter die Ausreißer rauszuwerfen.
Sachen wie kabelbruch oder Kurzschluss ergeben normalerweise irrsinnig
hohe oder tiefe Temperaturen.
Max D. schrieb:> Solange die Fehler halbwegs gleichverteilt auftreten hilft ein> Medianfilter die Ausreißer rauszuwerfen.
Das kommt sehr auf die Art der Fehler an. Ausreißer die abseits der
richtigen Werte liegen, werden den Median nicht stören, solange sie
nicht zu häufig sind - egal wie sie verteilt sind.
Das ZACwire-Protokoll ist zwar recht eigen, aber doch recht
sicher zu programmieren und liefert bei mir stabile Werte.
Außerdem gibt es 2 Parity-Bits (Hi- und Lo-Byte), zusätzlich
kann man noch auf 5 führende Null-Bits beim Hi-Byte testen.
Was hast du denn für eine "prinzipiell gut funktionierende"
Auslesung programmiert? Wird der Zeitmess-Timer zwischendurch
von anderen Routinen verändert?
Gleichverteilung war nicht ganz richtig ausgedrückt. Ich wollte damit
darauf hindeuten, dass eine plötzliche Fehlerflut den Filter so weit
"füllen" kann, dass ein falscher Wert als Median ausgegeben wird. Also
müssen die Fehler zeitlich halbwegs gleichmäßig verteilt sein (was ich
faulerweise zu gleichverteilt verhunzt hab).
Hi zusammen,
mit dem Median ist prinzipiell ein guter Ansatz, sowas dachte ich mir
auch schon. Von der Fehlerverteilung würde ich auch sagen, dass es zu
99,9% passt.
Die 0,1% werden aber irgendwann wohl aufschlagen. Aber dann könnte ich
ja wenn innerhalb 10sek kein gültiger Wert kommt nochmal die Routine
resetten.
Jacko schrieb:> Was hast du denn für eine "prinzipiell gut funktionierende"> Auslesung programmiert? Wird der Zeitmess-Timer zwischendurch> von anderen Routinen verändert?
Ich habe einen Interrupt auf fallende Flanke, messe die Zeit zwischen
den Flanken (Start-Bit) und halbiere die Zeit und setze den Timer auf
diese Zeit. Dann starte ich den Timer zum Zeitpunkt der nächsten
fallenden Flanke. Beim Timer Interrupt schaue ich ob es 0 oder 1 ist und
speichere die Bits.
Die Auswertung passiert dann beim zyklischen 20ms Timer und das
zurücksetzen.
Ich hab mich da echt schwer getan das Protokoll für den Controller
ressourcenoptimiert umzusetzen. Der hat ja noch jede Menge anderes zutun
als einen Temperatursensor auszulesen...
Aber was schönes:
Hab gestern Abend den TI LMT01LPG gefunden. Gleicher Temperaturbereich,
2-Wire, höhere Genauigkeit, viel günstiger und: wesentlich einfacheres
Protokoll. Ich denke damit wird der TSic das zeitliche Segnen bei mir
:-)
Mit dem Ti-Sensor wird dann auch die Diagnose viel einfacher.
X-Millisekunden keine Flanke erkannt -> Sensor nicht angesteckt oder
kaputt.
Danke für eure Hilfe. Das hat mich viel weiter gebracht :-)
Gruß, Niine
Niine schrieb:> Problem:> - Bei Systemstart kann es passieren, dass ich zuerst einen fehlerhaften> Temperaturwert empfange (z.B. 110°C). Dann schlägt automatisch 2. zu und> ich bleibe im Fehlermodus hängen oder ich habe eine vollkommen falsche> Temperatur. 110°C als Starttemperatur könnte aber vorkommen, daher nützt> es nichts zu sagen, dass nur Temperaturen <X°C akzeptabel sind.
Das kann (laut DaBla) eigentlich nicht vorkommen, da es möglich ist,
TSic306 per uC ein- bzw. auszuschalten und gleich die erste Messung zu
verwenden.
Viel wahrscheinlicher ist, dass du die Startbitlänge (Tstrobe)
falsch, bzw. nicht richtig gerechnet hast.
Niine schrieb:> Aber was schönes:> Hab gestern Abend den TI LMT01LPG gefunden. Gleicher Temperaturbereich,> 2-Wire, höhere Genauigkeit, viel günstiger und: wesentlich einfacheres> Protokoll.
Ich kann mir kaum ein einfacheres Protokoll als ZACwire vorstellen.
Niine schrieb:> Ich habe einen Interrupt auf fallende Flanke, messe die Zeit zwischen> den Flanken (Start-Bit) und halbiere die Zeit und setze den Timer auf> diese Zeit. Dann starte ich den Timer zum Zeitpunkt der nächsten> fallenden Flanke. Beim Timer Interrupt schaue ich ob es 0 oder 1 ist und> speichere die Bits.
Wie, " messe die Zeit zwischen den Flanken und halbiere die Zeit "
Welche Zeit wird halbiert, warum und wo willst du das gelesen haben ?
Anstatt die Angaben aus DaBla zu befolgen:
