T_AVG24

thommy01 · 16. Januar 2009, 17:15:31

Hallo,

in einer Heizungssteuerung habe ich für die Berechnung der Tagesmitteltemperatur den Baustein "T_AVG24" aus der lib 3.03 verwendet.

Nun habe ich folgendes verhalten :
Bei Beschaltung mit einem negativen Integer Wert berechnet der Bausteine keine durchschnitts Temperatur und zeigt immer 0 an.

Kann der Baustein keine minus Temperaturen berechnen oder gibt es hierzu eine Möglichkeit?

Grüße und Danke
Thommy

hugo · 17. Januar 2009, 00:21:23

t_avg24 macht alle 30 minuten ein sample vom eingang und bildet aus 48 samples (24 stunden) den mittelwert.

das ganze wird also nur dann funktionieren wenn die zeit am eingang sich auch entsprechend ändert.
allerdings vorsicht wenn du die zeit per hand weiterschaltest, denn das eingangsignal wird zusäztlich über einen 10 minuten tiefpass gefiltert.

thommy01 · 19. Januar 2009, 11:31:54

Hallo Hugo,

danke für die Antwort. An den Baustein habe ich die aktuelle Uhrzeit der Klemme angelegt daran kann es also nicht liegen.
Wenn ich im Online Modus in den Baustein schaue sehe ich auch die Werte. Habe zum Test den Eingang fest mit dem Integer Wert -10 beschaltet (= -1Â°C) aber leider immer noch Ausgangswert = 0

Sobald ich einen Positiv Wert anlege bekomme ich auch Mittelwerte.

Habe mal ein Screenshot beigelegt.

Grüße
Thommy

[gelöscht durch Administrator]

hugo · 19. Januar 2009, 14:44:00

klar wenn du den ausgangswert mit einem faktor 0 multiplizierst ist das auch klar.
der eingang scale ist dieser mutiplikator setzte ihn auf 1 oder lasse ihn unbeschaltet dann gilt der default wert

thommy01 · 19. Januar 2009, 15:01:12

Hallo Hugo,

danke für die Erklärung und die Hilfe. So einfach war also die Ursache!

Habe noch den Skalierungsfaktor gesetzt und bei einem "Faktor von 1" auch die Temperatur in Â°C bekommen.

Grüße
Thommy

vicky · 04. Februar 2009, 20:10:27

Die Funktion T_AVG24 ist eine Tolle Sache !!!
Wäre es möglich die Funktion um die Funktionen min24 und max24 zu ergänzen oder eigene Funktionen generieren.

Das wäre echt toll von euch...

hugo · 05. Februar 2009, 00:06:10

das ist ein guter input wir werden das für eine spätere version vormerken

vicky · 10. März 2009, 21:03:26

Hallöle,
beim T_AVG24 sind alle Temperaturwerte im REAL-Format, was auch gut ist.
Wäre es da nicht sinnvoll, die Eingangsvariable auch auf REAL-Format umzustellen.
Diese Werte werden sicherlich von 99% der Anwender in diesem Format gehändelt, oder nicht...

hugo · 10. März 2009, 21:33:03

t_avg24 kann direkt an den ad wandler angeschlossen werden, und dieser liefert im normalfall kein real sonder ganzahlenformat

vicky · 10. März 2009, 21:43:04

warum :o

hugo · 10. März 2009, 21:45:23

warum nicht?

vicky · 10. März 2009, 21:53:18

Na weil sich Gleitpunktzahlen am Besten weiterverarbeiten lassen(Div, Mul, Anzeige in Visu, usw.) auf mehrere Stellen nach dem Komma ohne vorher MULx1000 und anschließend wieder zurück, hin und her, hoch und runter, kreuz und quer, so das nachher keiner mehr weiß was gilt jetzt eigentlich..............
du verstehst schon

hugo · 10. März 2009, 22:04:03

ja nochmal warum:

der sensor hängt am ad wandler dieser gibt niemals ein real du siehst nur ein real im codesys weil das system eine automatische konvertierung macht.
das geht kein problem
nun aber zum problem

da die meisten sps keine fpu haben dauzert eine real operation ca 15 mal so lange wie eine integer operation
da der ad wandler eine int liefert und wir einen int im baustein verarbeiten belegt dieser baustein nur einen bruchteil der cpu zeit wie dies mit real der fall wäre

zum einfacheren weiterverarbeiten gehen wir am ausgang sowieso auf reals