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:
1 | Do
|
2 | Warte auf fallende Flanke, Timer starten. |
3 | Warte auf steigende Flanke, Timer merken, das ist Tstrobe !!! |
4 | |
5 | Do
|
6 | Warte auf fallende Flanke, danach Tstrobe Zeit abwarten !!! |
7 | TSIC306 Ausgangszustand direkt als bitwert übernehmen. |
8 | Loop 8 Mal |
9 | Warte auf fallende Flanke, danach Tstrobe Zeit abwarten. |
10 | TSIC306 Ausgangszustand direkt als Paritätsbit übernehmen. |
11 | |
12 | Loop 2 Mal |
Kein Wunder, dass du falsche Temperaturwerte gekriegt hast.
:
Bearbeitet durch User
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.