Gemittelte Aussentemperatur der letzten 24 Std.

Begonnen von martin.k, 28. Oktober 2008, 22:19:07

Vorheriges Thema - Nächstes Thema

0 Mitglieder und 3 Gäste betrachten dieses Thema.

martin.k

Hallo !

Thema: Hausautomatisierung - Temperaturen

Mich interessiert die gemittelte Aussentemperatur der letzten 24 Std. Dazu verwende ich SH_1 und FT_avg.
Variabeln:
xAussentemperaturSued_C ist die Aussentemperatur
xAussentemperaturSued_C24 ist die gemittelte Aussentemperatur auf 24 Std. Ich mache auch noch eine Auswertung auf 72 Std. Diese Variable heisst dann natürlich xAussentemperaturSued_C72

Anbei ein Screenshot.

Leider speichert FT_avg nur 32 Werte was schon bei 24 Std. zu einer gewissen Ungenauigkeit führt...

Viele Grüße



[gelöscht durch Administrator]

McNugget2000

Grundsätzlich wirst Du dir hierfür die OSCAT.Lib direkt öffnen und etwas verändern müssen.
Die Begrenzung von FT_AVG auf 32 hat seinen Ursprung im Baustein Delay, der intern aufgerufen wird.

So wie ich es sehe, könnte das Array im Innern von Delay (da es ja ein INT Wert ist) auf einen höheren Wert umstellen.
Zu beachten wäre dabei, dass dann auch die Werte-Kontrollen im Innern von FT_AVG angepasst werden müssen.

Ich hoffe, das war so richtig... Hugo?? Habe ich es verstanden??

Gruss

McNugget

hugo

#2
sicherlich kann man in der llib dinge anpassen, die lib ist ja auch aus diesem grund open source.

sicherer wäre ein vorgehen wenn man sich neue bausteine mit neuen eigenschaften erzeugt, dann hat man nicht das problem bei jeder neuen release der lib wieder anpassen zu müssen.

nun zum thema aussentemperatur

ein mittelwert ist in diesen fall nichts anderes als ein filter.
genausogut (mit besseren filtereigenschaften) wäre hier ein tiefpass : FILTER_W, FILTER_DW. FT_PT1.  _W ist für 16 bit daten, _DW ist für 32 bit daten und _PT1 ist für REAL.
der Vorteil eines tiefpassfilters sind ein besserer Frequenzgang und ein wesentlich geringerer aufwand. versuchs mal mit einem ft_pt1 mit T1 = T#8h.
Beim Einsatz von FT_PT1 sparst du dir auch gleich den sample and hold am eingang.

Mittelwertbildung als filter hat nur einen Vorteil, einen konstanten Phasengang über den Frequenzbereich. ansonsten sind die Filtereigenschaften sogar schlechter, und Störungen mit hohen Frequenzen werden schlechter gefiltert.

das beispiel unten zeigt den einsatz zweier tiefpässe für t_aussen und T_aussen_long

Die zeit eines tiefpasses bedeutet:
nach der Zeit T1 hat der Ausgang bei einem eingangsprung 63% dieses sprungs mitgemacht, und bei 3*t bereits 95%.
also 8h entspricht etwa einem mittelwert über 24h

[gelöscht durch Administrator]

hugo

bei meinem obigen Beispiel verwende ich ft_pt1 einen tiefpass der mit real zahlen arbeitet.

normalerweise liegen die sensordaten als word oder dword vor.
in diesem fall kann man die sensordaten direkt auf einen filter_w oder filter_DW legen und direkt ohne umwandlung auf reals filtern.

zur info.
die lösung mit sample and hold und avg bildung 32 samples benötigt etwa 25 mal mehr CPU Zeit als die filterung mit tiefpass.

die lösung mit filter_w oder _DW wird nochmals deutlich weniger cpu last erzeugen

ewo

Hallo Hugo,
bisher habe ich meine analogen Messwerte nach dem AIN Modul mit einem FT_PT1 gefiltert. Nach diesem Beitrag habe ich nun zwischen Eingangssignal und AIN einen Filter_W mit der Zeit T#1m40s gelegt, das funktioniert soweit gut, die Ausgangswerte sind schön konstant. Jedoch immer wieder aus unerklärlichem Grund macht der Ausgang Y bei einem Eingangswert X von z.B. 12000 einen Sprung von 12000 auf ca. 8000! Dies passiert so ca alle 20 Minuten. Als Klemme habe ich eine WAGO 750-455 im Einsatz.

Gruß
Ewald

martin.k

Hallo Hugo,

vielen Dank für die Antworten.
Wieviele Messwerte gehen denn bei T#8h in das Ergebnis ein?

Und da ich von dem PT1 keine Anhnung habe: Was für ein T brauche ich um auf den Mittelwert der letzten 72 Stunden zu kommen?

Grüße!

hugo

am beste liest du dir mal den pt1 auf wickipedia durch: http://de.wikipedia.org/wiki/PT1-Glied
der pt1 folgt dem eingang allerdings mit einer zeitkonstante.
man betrachtet üblicherweise die sprungantwort.
das ist ganz etwas simples:
der eingang geht von 0 auf eins und man schaut sich an was der ausgnag macht.
der ausgang beginnt unmittelbar dem eingang zu folgen um dann nach ablauf der zeit T hat der ausgang 0,63 erreicht und nach ablauf von 3*T  0,95.
damit kannst du ungefähr für die durchlaufzeit durch ein avg filter / 3 als T1 für den Tiefpass verwenden.
also wenn du 24h mittels wäre das t#8h für den tiefpass.

hugo

nun ich habe mir das ganze gerade im excel simuliert.
bei einem tagesverlauf der temperatur von -10 um mitternacht nach + 10 mittags usw...
erkennt man ganz gut das für den spezialfall der tagesmitteltemperatur ein avg filter besser geeignet ist als ein tiefpass.
am ersten tag liefert der tiefpass das selbe ergebnis wie der avg filter, das liegt daran weil keine werte vom vortag vorhanden sind.

fakt ist der avg filter ist für die tagesmitteltemperatur besser geeignet als ein tiefpass.

ich werde in der nächsten release ein spezialfilter einbauen das genau die tagesmitteltemperatur ermittelt.
ich werde alle 30 min einen messwert abspeichern und dann über die letzten 48 werte einen mittelwert ausgeben

[gelöscht durch Administrator]

hugo

Zitat von: ewo in 01. November 2008, 12:41:18
Hallo Hugo,
bisher habe ich meine analogen Messwerte nach dem AIN Modul mit einem FT_PT1 gefiltert. Nach diesem Beitrag habe ich nun zwischen Eingangssignal und AIN einen Filter_W mit der Zeit T#1m40s gelegt, das funktioniert soweit gut, die Ausgangswerte sind schön konstant. Jedoch immer wieder aus unerklärlichem Grund macht der Ausgang Y bei einem Eingangswert X von z.B. 12000 einen Sprung von 12000 auf ca. 8000! Dies passiert so ca alle 20 Minuten. Als Klemme habe ich eine WAGO 750-455 im Einsatz.

Gruß
Ewald

hallo ewald,
die klemme 455 ist eine 4-20mA eingangsklemme, sie liefert 12 bit daten als 16bit wert (die obersten 12 bits sind maßgeblich).
kann es sein das du am eingang das datenwort aus versehen einem ingeger übergibst ? die klemme muss als word angeschlossen werden.

ewo

ja klar, da hatte ich aber einen Denkfehler, das kann so ja nicht funktionieren. Da muß ich wohl wieder nach dem AIN einen FT_PT1 nehmen, oder was wäre da ideal um das Rauschen des Temperatursensor zu unterdrücken ?

Vielen Dank

Ewald

hugo

für rauschunterdrückung ist grundsätzlich ein PT1 glied sinnvoll.

wenn der senosr sonderbits (range, overfolw, usw.. ) liefert sollte das pt1 erst nach dem ain liegen, sonst ist es besser vor dem ain zu platzieren.
im falle der klemme 455 musst du die untersten 3 bits ausmaskieren, sie beinhalten statusinfos wie leitungsbruch, überlauf, unterlauf.
also das sensorsignal mit 2#1111_1111_1000 verunden und dann erst auf einen filter: filter_eingang := 2#1111_1111_1000 and sensor_signal;
diese maskierung von bits kann auch schon der ain1 für dich erledigen und die skalierung, danach dann einen ft_pt1 den dort sind es dann real daten die zu filtern sind.
allerdings lassen sich dadurch deine sprünge noch nicht erklären. schau mal ob die leds auf deiner eingangsklemme flakern, das bedeutet einen der fehler siehe hierzu datenblatt des eingangsmoduls, eventuell leitungsbruch oder extreme störungen auf der leitung (ist sie sehr lange? fu in der nähe?)
http://www.wago.com/wagoweb/documentation/750/ger_manu/modules/m045500d.pdf

ewo

Hallo Hugo,

ja, die Leitung ist lang, aber es kommen keine Fehler, LED flackern nicht. Ich habe nun trotzdem einen Test mit dem Filter_w gemacht, und siehe da, da ist irgend etwas nicht in Ordnung. Bitte schau Dir mal die Bilder der Anlage (Testaufbau und Trendaufzeichnung) an.

Gruß
Ewald

[gelöscht durch Administrator]

gravieren

Hi Martin

Machste das auch mit deinem "PT1000-Umschalter"   ?


Falls ja, kann es daran liegen  ?   ;D

hugo

ja leider gibt es im filter_w probleme mit großen werten, Überlauf !!!
der korrigierte code ist wie folgt.
wird in der release 302 enthalten sein, leider nicht mehr für die 301 möglich

(* read system time *)
tx := T_PLC_MS();

(* startup initialisation *)
IF NOT init OR T = t#0s THEN
   init := TRUE;
   Y := X;
ELSE
   Y := Y + DINT_TO_WORD(WORD_TO_DINT(X - Y) * DWORD_TO_DINT(tx-last) / TIME_TO_DINT(T));
END_IF;
last := tx;

martin.k

Hallo gravieren,

Klaro mache ich das auch mit meinem PT1000 Umschalter :-)
Ich ermittle den Mittelwert der Innenraumtemperatur gemischt im 5 min Takt mit der Aussentemperatur  ;D
Ich muss aber noch einen PT100 in den Gefrierschrank hängen, die Werte sind alle unrealistisch...

By the way. Danke für Deine "Datenspeichern in Datei"-Lib.

Grüße

PS: Hätte nicht gedacht das meine Thema so viel Antworten produziert.