Algorithmus Temperaturüberwachung

[samus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Zusammen

Ich habe eine Temperaturüberwachung von (Tief) Kühler installiert. Die Überwachung funktioniert grundsätzlich. Die Sensoren sind aber sehr sensibel und reagieren bereits auf Temperaturveränderungen der Luft. (Was ja grundsätzlich gut ist) Dies spiegelt aber nicht die Temperatur vom Kühlgut wieder. Es gibt deshalb Fehlalarme wenn z.b. viel, wärmeres Kühlgut in den Kühler kommt oder wenn eine Türe länger offen bleibt. Ebenfalls Probleme macht der Kühlzyklus des Kühlers mit Abtauen, etc. So kann die gemessene Temperatur durchaus 10°C abweichen vom Kühlgut.

Interessanterweise liefern die altmodischen Thermometer viel genauere Werte.

Ich habe bereits schon einen Filter implementiert welcher alle 30 Sekunden einen Wert in ein 30 stelliges Array speichert. Daraus werden die 5 höchsten und tiefsten Werte entfernt und aus den verbliebenen der Durchschnitt gebildet. Auf diesen Wert habe ich noch eine Einschaltverzögerung von 30 min geschaltet.

Am besten wäre eine «mechanische» Verzögerung. Das heisst einfach gesagt eine Masse um den Sensor welche sich ähnlich verhaltet wie das Kühlgut.

Gibt es so etwas? Oder kennt ihr Lösungen zu diesem Problem? Evtl auch softwaretechnische?

Gruss samus

 

[Plan_B]

PT1 Glied mit einer Zeitkonstante von 5...15min.
Findest Du für viele Sprachdialekte in OSCAT.

 

[winnman]

Zuviel Werbung?
-> Hier kostenlos registrieren

Fühler einfach ein einen Metallblock montieren zB.: 50x50x50mm Niro

 

[the_muck]

Am besten wäre eine «mechanische» Verzögerung.

Messung der Ansprechzeiten von elektrischen Thermometern

Wirkungsgrade optimieren, Prozessarbeitsbereiche effizienter nutzen, thermische Überbeanspruchung des Prozessmediums vermeiden – ob ein elektrisches Thermometer diese Anforderungen erfüllen kann, hängt maßgeblich von der Ansprechzeit ab.

www.chemietechnik.de

Eine mechanische Verzögerung wirst du auch per Software realisieren könne

PT1-Glied – Wikipedia

de.wikipedia.org

Wie oben beschrieben kannst du auch den Sensor "Mechanisch" Träger machen. Für mich macht das aber keinen Sinn ein gutes System schlechter zu machen. Du wirst auch da deine "Grenzen" setzen müssen, nimmst dir aber Messmöglichkeiten um auf "Fehler" Schnell zu reagieren.

Ich würde da nicht auf Sensorseite viel ändern sonder an der Auslöse Charakteristik des Alarms.

 

[GrauesHaar]

Vorschlag:
alle 10 Sekunden folgende Berechnung:
T := (Talt * Faktor + Tsensor)/(Faktor + 1.0)

 

[samus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Zusammen

Vielen Dank für eure Antworten!

Vorschlag:
alle 10 Sekunden folgende Berechnung:
T := (Talt * Faktor + Tsensor)/(Faktor + 1.0)

Ich habe in der ersten Version genau diese Berechnung gemacht. Die Ergebnisse waren schlechter als jetzt. Ob dies an zu grossem/kleinen Faktor lag oder an zu kurzer Abtastzeit kann ich nicht genau sagen. Evtl ist diese Methode auch weniger geeignet?

Ein PT1 Glied würde ja sich ja auch nicht stark abweichend von dieser Formel verhalten? Oder habe ich einen Denkfehler? Ich werde es auf jeden Fall mal ausprobieren und euch Rückmeldung geben. Wird aber sicher Ende Monat bis ich an die Anlage komme.
Ich versuche mal die Werte aufzuzeichnen. Ich habe mir auch schon überlegt ob ein besserer "Auswertealgorithmus" nicht der bessere Ansatz wäre, konnte aber noch keinen zuverlässigen Entwickeln, welcher allen Anforderungen gerecht wird.

Es geht auch darum die Temperatur möglichst nahe an die Anzeige des Kühlers zu bringen. In irgendeiner Form muss der Hersteller dieses Kühlers die Temperatur auch filtern. Er hat den Sensor auch in der Luft platziert und wird deshalb die Schwankungen auch messen. Aussen an der Anzeige sind die Werte aber plausibel und nahe an der Temperatur des Kühlguts. Es macht auch einen schlechten Eindruck wenn meine Auswertung teilweise stark schwankt und die Auswertung des Herstellers plausiblere Werte anzeigt.

Ich melde mich wieder nach dem Test mit dem PT1 Glied.

 

[Plan_B]

PT1 kannnst Du nicht mit einem wie uch immer modifizoertem gleitenden Mittelwert vergleichen.

 

[Larry Laffer]

naja ... im Grunde hast du dir da ja auch eine Art PT1-Glied zusammengebaut - nur "ein bisschen" spezialisierter ...

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

PT1 kannnst Du nicht mit einem wie uch immer modifizoertem gleitenden Mittelwert vergleichen.

Ein gleitender Mittelwert besitzt aber das gleiche Filterverhalten wie ein PT1-Glied, d.h. Tiefpasfilter 1. Ordnung. Mal seine Teil-Median-Ergänzung herausgenommen, dürfte sein Mittelwert mit Abtastung alle 30 Sekunden mit 30 Werten, einem PT1-Glied mit ca. T=5,5 Minuten entsprechen.

 

[Onkel Dagobert]

.. Ich habe in der ersten Version genau diese Berechnung gemacht..

Und wo genau habt ihr beide diesen speziellen Algorithmus abgeschrieben ?

 

[GrauesHaar]

Ich habe in der ersten Version genau diese Berechnung gemacht.

Dann nimm mal bitte eine Abtastzeit Größenordnung 60s und einen Faktor ca. 50..100.
Du musst halt die Wärmekapazität deines Gefrierguts simulieren. Da ändert sich die Temperatur nur sehr langsam.
Ja, es ist ein PT1-Glied.
Der gleitende Mittelwert "vergisst" alte Werte. Der ist in deinem Fall ungeeignet.

 

[GrauesHaar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und wo genau habt ihr beide diesen speziellen Algorithmus abgeschrieben ?

"Spezieller Algorithmus": Na ja, es wird halt der Mittelwert mit einer Gewichtung des bisher berechneten Wertes ausgerechnet. Die Formel wurde ja hier im Forum auch schon das eine oder andere Mal diskutiert.

 

[Onkel Dagobert]

... Die Formel wurde ja hier im Forum auch schon das eine oder andere Mal diskutiert.

Mit welchem Resultat? Hast du vielleicht mal einen link?
Für mich ergibt dieser Algorithmus irgendwie keinen Sinn. Und laut sanus funktioniert er wohl auch nicht richtig.

 

[Heinileini]

Für mich ergibt dieser Algorithmus irgendwie keinen Sinn. Und laut sanus funktioniert er wohl auch nicht richtig.

Meinst Du den folgenden Algorithmus, Dagobert?

Vorschlag:
alle 10 Sekunden folgende Berechnung:
T := (Talt * Faktor + Tsensor)/(Faktor + 1.0)

Ich verstehe ihn und kann Dir bzw. mir nur nicht erklären, woher die Festlegung auf "alle 10 s" kommt.
Sinngemäss habe ich schon vor gut 30 Jahren an einer FräsMaschine die Messwerte von zig Pt100 so geglättet.
Als nachteilig war mir nur aufgefallen, dass das "asymptotische Annähern" an einen Endwert nicht wie gewünscht klappt, wenn man die Prozedur mit FestPunktZahlen glaubt rechnen zu können. Aber aus der '1.0' in GrauesHaar "ihm seinen" Algorithmus entnehme ich, dass er ebenfalls die Berechnung mit [L]REAL-Zahlen voraussetzt.

 

[GrauesHaar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die "10s" sollen nur zeigen, dass man die Formel nicht zyklisch berechnen lassen darf. 60s tun es genauso. Dann wird der Faktor halt kleiner.
Real oder von mir aus im LReal Format muss natürlich sein. Bei INT kommt bedingt durch das Runden nichts sinnvolles raus.
Ich werde aber Onkel Dagoberts Nachfrage zum Anlass nehmen, mal die Formel mit einer e-Funktion zu vergleichen.

Hast du vielleicht mal einen link?

Suchst Du "Glättung"

 

[Onkel Dagobert]

... Suchst Du "Glättung"

Da finde ich gaanz viel.

Na egal, für mich ist folgende Berechnung jedenfalls wesentlich plausibler:

T := (Talt * Faktor) + (Tsensor * (1.0 - Faktor));   // wobei Faktor = 0.0 .. 1.0

Wenn man "Faktor" jetzt noch ersetzt durch:

FAKTOR := EXP(- ABTASTZEIT / DAEMPFUNGSZEIT);   // Faktor zur Laufzeit i.d.R. konstant

Dann hat man eine e-Funktion mit definierter Dämpfungszeit als Parameter. D.h. die Sprungantwort erreicht zum Zeitpunkt "Dämpfungszeit" 63% des Endwerts. Oder waren es 64%? Jedenfalls kann man dann von einer definierten Dämpfungszeit reden. Die Abtastzeit wird quasi eliminiert. Sie sollte nur groß genug sein, um Änderungen des Messwertes erfassen zu können. Es empfiehlt sich intern eine Berechnung mit LReal.

 

[GrauesHaar]

Hier mal ein Vergleich der Formeln:
(Alle drei Kurven liegen annähernd übereinander). Überraschung?
Ich denke, wir meinen alle das Gleiche. Um den Pfennig müssen wir nicht fuchsen.
Euch allen eine schöne Woche!

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

um dem eigentlich gelösten Thema nochmal hinterher zu en:

Im TIA gibts auch fertige Funktionen für solche Späße.

 

[samus]

Hallo Zusammen

Habe jetzt im Code nachgeschaut. Die Formel ist ein bisschen anders gewesen. War da gester zu voreilig...

TimerGlaetten(IN:= NOT TimerGlaetten.Q, PT:= T#20S);
IF TimerGlaetten.Q THEN
    rTempberechnet:=(rTempberechnet*(1-rFaktor))+(rActTemp*rFaktor);
END_IF

Dieser "Algorithmus" hat schon funktioniert, allerdings gab es zu viele Auslösungen. Da mir einfach der Mut fehlte, grössere Verzögerungen (mittels Faktor und Aufrufzeit) einzubauen, konnte er die geforderte Funktion auch gar nicht richtig erfüllen.

Aber wie ihr ja schon geschrieben habt, die drei Algorithmen sind sich sehr ähnlich, bzw sie haben das gleiche Ergebniss.

Ich werde jetzt folgendes Versuchen. Natürlich an meine Formel angepasst. Anschliessend gebe ich euch Rückmeldung.

Dann nimm mal bitte eine Abtastzeit Größenordnung 60s und einen Faktor ca. 50..100.
Du musst halt die Wärmekapazität deines Gefrierguts simulieren. Da ändert sich die Temperatur nur sehr langsam.

Ich möchte allen Danken für eure Hilfe!
samus

 

[Onkel Dagobert]

... Ich werde jetzt folgendes Versuchen. Natürlich an meine Formel angepasst. Anschliessend gebe ich euch Rückmeldung...

Bei deiner Formel MUSS der "Faktor" zwischen 0 und 1 liegen, wie bei meiner Variante auch, nur ist dein Faktor umgekehrt proportional zu meinem. Falls du meinen Algorithmus mit der e-Funktion testen solltest, es ist ja nur noch ein kleiner Schritt für dich und die restliche Menschheit , dann entspricht die in #16 genannte "DAEMPFUNGSZEIT" der in #18 dargestellten Zeitmarke "Lag". Man hat also einen konkreten Parameter, unter dem man sich etwas vorstellen kann, und der auch unabhängig von der "ABTASTZEIT" ist. Die "ABTASTZEIT" spielt eigentlich nur noch eine rein mathematische Rolle. Sie muss allerdings über die e-Funktion bei der Berechnung berücksichtigt werden.