FB_BARWithinRangeAzimuth
Dieser Baustein prüft, ob der aktuelle Azimutwinkel (horizontaler Sonnenstand) innerhalb der eingetragenen Grenzen liegt. Wie in der Übersicht erkennbar, gibt der Baustein eine zusätzliche Bewertung, ob der Sonnenschutz einer Fenstergruppe aktiviert werden soll. Daher gelten die Betrachtungen im weiteren Text immer für eine Fenstergruppe.
Eine glatte Fassade wird von der Sonne immer in einem Azimutwinkel von Fassadenausrichtung-90°... Fassadenausrichtung+90° bestrahlt.
Hat die Fassade jedoch seitliche Vorsprünge, so wird dieser Bereich eingeschränkt. Diese Einschränkung lässt sich mit Hilfe dieses Bausteines überprüfen. Dabei spielt aber auch die Lage der Fenstergruppe auf der Fassade eine Rolle. Liegt sie zentral, so ergibt sich folgende Situation (Die Werte sind dabei nur beispielhaft):
Für eine Gruppe am Rand andern sich die Werte:
Der Anfang des Bereiches lrBeginRange darf dabei größer sein als das Ende lrEndRange, es wird dann über 0° hinaus betrachtet:
Beispiel:
lrAzimuth | 10.0° |
lrBeginRange | 280.0° |
lrEndRange | 20.0° |
bOut | TRUE |
Der betrachtete Bereich darf jedoch nicht größer als 180° oder gleich 0° sein, dieses wäre unrealistisch. Derartige Eingaben ergeben einen Fehler am Ausgang bError - der Prüfausgang bOut wird dabei zusätzlich auf FALSE gesetzt.
VAR_INPUT
eDataSecurityType : E_HVACDataSecurityType;
lrAzimuth : LREAL;
eDataSecurityType:Wenn eDataSecurityType:= eHVACDataSecurityType_Persistent ist, werden die persistenten VAR_IN_OUT-Variablen des Funktionsbausteins bei einer Wertänderung im Flash des Rechners abgelegt. Dafür ist es zwingend erforderlich den Funktionsbaustein FB_HVACPersistentDataHandling einmalig im Hauptprogramm, das zyklisch aufgerufen wird, zu instanziieren. Ansonsten wird der instanziierte FB intern nicht freigegeben.
Eine Wertänderung kann vom Gebäudeleitsystem, einem lokalen Bediengerät oder von einem Schreibzugriff von TwinCAT aus erfolgen. Beim Neustart des Rechners werden die gesicherten Daten automatisch vom Flash in den RAM zurück gelesen.
Anwendungsbeispiel: example_persistent.zip
Bei eDataSecurityType:= eHVACDataSecurityType_Idle werden die persistent deklarierten Variablen nicht spannungsausfallsicher gespeichert.
Hinweis | |
Eine sich zyklisch ändernde Variable darf niemals mit der IN_OUT-Variablen eines Funktionsbausteins verbunden werden, wenn eDataSecurityType:= eHVACDataSecurityType_Persistent ist. Es würde zu einem frühzeitigen Verschleiß des Flashspeichers führen. |
lrAzimuth: Aktueller Azimutwinkel.
VAR_OUTPUT
bOut : BOOL;
bError : BOOL;
udiErrorId : UDINT;
bOut: Binärer verzögerter Ausgang des Schwellwertschalters
bError: Dieser Ausgang wird auf TRUE geschaltet, wenn die eingetragenen Parameter fehlerhaft sind.
udiErrorId: Enthält den Fehlercode, sollten die eingetragenen Werte fehlerhaft sein. Siehe Fehlercodes.
VAR_IN_OUT
Damit die eingetragenen Parameter über einen Steuerungsausfall hinweg erhalten bleiben ist es erforderlich, sie als In-Out-Variablen zu deklarieren. Im Programm wird ihnen dann eine Referenz-Variable zugewiesen. Jede Änderung des Wertes dieser Referenz-Variablen wird im Funktionsbaustein persistent gespeichert und nach einem Steuerungsausfall und -wiederanlauf zurück in die Referenz-Variable geschrieben. Wären die Parameter nur als Eingangsvariablen deklariert, so könnten sie eine Referenzvariable nicht beschreiben.
Anwendungsbeispiel: example_persistent.zip.
lrBeginRange : LREAL;
lrEndRange : LREAL;
lrBeginRange: Bereichsanfang in Grad.
lrEndRange: Bereichsende in Grad.
Voraussetzungen
Entwicklungsumgebung | erforderliche Bibliothek | Erforderliche Function |
|---|---|---|
TwinCAT 3.1 ab Build 4022.16 | Tc2_HVAC V3.3.1.0 | TF8000 | TC3 HVAC V1.0.0.0 |