FB_BACnet_RemoteDevice

Der folgende Funktionsbaustein wird für die Anbindung des SPS-Programmes an ein entferntes BACnet-Device Objekt (lokaler Client) verwendet. Die Verknüpfung des Funktionsbausteins erfolgt mit Hilfe von Prozessdaten.

Die Prozessdaten können manuell oder mittels PLC-Automapping automatisch verknüpft werden. Die für das PLC-Automapping nötigen Kommentare ( (* ~ (BACnet... | ??? | ??? ) *) ) sind bereits in der Deklaration des Funktionsbausteins enthalten. Zu den Prozessdaten des BACnet-Device Objekts sind ebenfalls die nötigen Prozessdaten für die Anbindung des BACnet Clients enthalten.

FB_BACnet_RemoteDevice 1:
Bild-1: Prozessdaten des entfernten BACnet Device Objekts und -Client im System Manager.
FB_BACnet_RemoteDevice 2:
Bild-2: Funktionsbaustein des entfernten BACnet Device Objekts und -Client im SPS-Programm.

Verwendung

Mit Hilfe des Funktionsbausteins "FB_BACnet_RemoteDevice" wird der Zustand des entfernten BACnet Device Objects gelesen (System_Status) und im SPS-Programm ausgegeben. Zudem wird mit Hilfe des Prozessdatums "Client Control" und "Client Status" der lokale BACnet Client gesteuert (WriteOnChange sperren/freigeben, Neu-Abonnieren von Properties, automatisches Abonnieren von Properties nach Verbindungsfehlern und Fehlerquittierung).

Für die Verwendung des Bausteins "FB_BACnet_RemoteDevice" wird zudem eine globale Instanz des Bausteins FB_BACnet_Adapter pro SPS-Projekt benötigt. Der Baustein FB_BACnet_Adapter stellt die Verbindung zwischen SPS und BACnet-Adapter im System Manager her. Diese globale Instanz wird bereits von der SPS-Bibliothek bereit gestellt. Im Folgenden ist die Hierarchie zwischen FB_BACnet_Adapter, FB_BACnet_Device bzw. "FB_BACnet_RemoteDevice" und einem Objekt vom Typ AnalogValue dargestellt:

FB_BACnet_RemoteDevice 3:
Bild-3: Beispiel zur Verknüpfung der FB-Instanzen in der SPS.

Informationen zur Verwendung: siehe auch Bausteine FB_BACnet_Adapter bzw. FB_BACnet_Device.

VAR_INPUT

bReset           : BOOL;
bAutoReset       : BOOL;
bDisableWOC      : BOOL;
bReSubscribeCOV  : BOOL;
bAutoReSubscribe : BOOL;

bReset: Zurücksetzen des Fehlerzustands bei Signalwechsel FALSE --> TRUE.

bAutoReset: Bei Setzen des Eingangs auf TRUE werden Fehler mit ID 20 und 21 automatisch quittiert. Verbundene Remote-FBs werden nicht blockiert (bReady an den Objekt-FBs bleibt TRUE). Statt des Fehlers wird ein Fehlerzähler hoch gezählt (siehe nTimeoutCnt und nServiceFailCnt).

bDisableWOC: Bei Setzen des Eingangs auf TRUE wird WriteOnChange (WOC, Schreiben-bei-Änderung) für sämtliche Objekte dieses Clients unterdrückt. Das bedeutet, dass Änderungen der Prozessdaten kein automatisches Schreiben der Properties an die entfernten Objekte auslöst (gilt nur für Properties die für WriteOnChange unter dem Client konfiguriert sind).

bReSubscribeCOV: Bei Signalwechsel des Eingangs von FALSE --> TRUE wird das Neu-Abonnieren sämtlicher Properties die für COV konfiguriert sind ausgelöst. Diese Funktion betrifft unter Umständen potentiell viele Objekte und sollte daher nur bei Bedarf ausgeführt werden. Im Normalfall werden alle abonnierten Properties nach Ablauf einer Timeoutzeit automatisch erneut abonniert (Resubscription-Intervall).

bAutoReSubscribe: Bei Setzen des Eingangs auf TRUE wird das automatische Neu-Abonnieren sämtlicher für COV konfigurierter Properties bei Bedarf ausgelöst. Dies ist nicht mit dem Resubscription-Intervall zu verwechseln! Ein automatisches Neu-Abonnieren wird ausgelöst, wenn z.B. ein entfernter Server nicht mehr erreichbar war und die Verbindung wieder hergestellt werden konnte. Wird der Eingang auf FALSE gesetzt, dann wird ein erneutes Abonnieren erst nach Ablauf des Resubscription-Intervalls ausgelöst.

VAR_OUTPUT

eSystemStatus    : E_BACnetDeviceStatus;
bEthLinkOk       : BOOL;
bGatewayOk       : BOOL;
sAmsNetId        : T_AmsNetId;
bEnabledWOC      : BOOL;
bOperational     : BOOL;
bConnecting      : BOOL;
bFirstCycle      : BOOL;
bError           : BOOL;
nErrorId         : UINT;
bClientTimeout   : BOOL;
bServiceFailed   : BOOL;
nTimeoutCnt      : UDINT;
nServiceFailCnt  : UDINT;

eSystemStatus: Aktueller Status des entfernten BACnet Server Objekts (siehe BACnet-Spezifikation DIN EN ISO 16484-5 zum BACnet Device Objekt und Property System_Status).
0: BACnetDeviceStatus_Operational (Betriebsbereit)
1: BACnetDeviceStatus_OperationalReadOnly (Nur-Lese-Zugriff auf Properties)
2: BACnetDeviceStatus_DownloadRequired (Konfiguration-Laden erforderlich)
3: BACnetDeviceStatus_DownloadInProgress (Konfiguration-Laden wird ausgeführt)
4: BACnetDeviceStatus_NonOperational (Nicht-Betriebsbereit)
5: BACnetDeviceStatus_BackupInProgress (Datensicherung wird ausgeführt)

bEthLinkOk: Die lokale Ethernet-Verbindung ist aktiv (Kabel gesteckt, Adapter verbunden), wenn der Ausgang auf TRUE gesetzt ist.

bGatewayOk: Das konfigurierte Gateway ist erreichbar, wenn der Ausgang auf TRUE gesetzt ist.

sAmsNetId: Ausgabe der AMS-NetID des lokalen BACnet-Adapters (kann für den asynchronen Zugriff via ADS auf BACnet-Objekte verwendet werden).

bEnabledWOC: WriteOnChange (WOC, Schreiben-bei-Änderung) ist für COV konfigurierte Properties aktiviert.

bOperational: BACnet-Device Objekt des entfernten Servers meldet "Operational" (System_Status = 0), der Device-Adapter meldet den Status bEthLinkOk, Status bConnecting ist FALSE und das Bit 0 des Prozessdatums "Client Status" ist nicht gesetzt (nERR_CLIENT_TIMEOUT). Fällt der Ausgang auf FALSE werden sämtliche verbundene Objekte (Bausteininstanzen) gesperrt.

bConnecting: Die Verbindung zum entfernten Server wird aufgebaut (Prozessdatum "Client Status" ist kleiner 0x04xx).

bFirstCycle: Wird mit dem ersten Aufruf der Bausteininstanz nach SPS-Reset bzw. -Neustart für einen Zyklus gesetzt.

bError: Ein Fehler steht an.

nErrorId: Fehlernummer
0 = kein Fehler
1 = Funktionsbaustein des zugehörigen Clients (RemoteDevice) wird gar nicht oder zu unregelmäßig im SPS-Programm aufgerufen.
1 = keine gültige AMS-NetID
3 = keine Netzwerkverbindung (bEthLinkOk = FALSE)
4 = Gateway nicht erreichbar (bGatewayOk = FALSE)
20 = Timeout bei Kommunikation zum entfernten Server
21 = Fehler bei der Ausführung eines Dienstes zum entfernten Server (Subscribe-COV, Property-Write etc.)
Die Fehlernummern können als Baustein-Konstanten über die FB-Instanz abgefragt werden (FB_BACnet_RemoteDevice.nERR_xxx). Alle Fehler mit Fehlernummer größer oder gleich 20 müssen mittels bReset quittiert werden.

bClientTimeout: Bei gesetztem Ausgang liegt ein Timeout-Fehler (ID 20) an. Der Ausgang wird erst zurück gesetzt, wenn 10 Sekunden lang kein Timeout Fehler mehr aufgetreten ist.

bServiceFailed: Bei gesetztem Ausgang liegt ein Service-Fehler (ID 21) an. Der Ausgang wird erst zurück gesetzt, wenn 10 Sekunden lang kein Fehler mehr aufgetreten ist.

nTimeoutCnt: Anzahl aufgetretener Timeout-Fehler (ID 20). Es wird die positive Flanke des entsprechenden Status-Flag des Clients gezählt.

nServiceFailCnt: Anzahl aufgetretener Service-Fehler (ID 21). Es wird die positive Flanke des entsprechenden Status-Flag des Clients gezählt.

Eine Instanz des Bausteins "FB_BACnet_RemoteDevice" ist immer dann nötig, wenn auf Objekte eines entfernten BACnet-Servers mit Hilfe eines lokalen BACnet-Clients aus der SPS zugegriffen werden soll. Mehrere Instanzen des Bausteins "FB_BACnet_RemoteDevice" können problemlos angelegt und mittels SPS-Automapping zu den entsprechenden Clients im System Manager verbunden werden. Alle Instanzen des Bausteins "FB_BACnet_RemoteDevice" verwenden die gleiche, globale Instanz des Bausteins FB_BACnet_Adapter.

Sollen mehrere Instanzen des Bausteins FB_BACnet_Adapter verwendet werden, dann muss vor dem Aufruf der Instanz des BACnet-Client Bausteins zwingend die zugehörige Instanz des BACnet-Adapters Bausteins erfolgen. Im Folgenden ein CFC-Beispiel (Wichtig ist die Aufrufreihenfolge der Bausteine zu beachten!):

FB_BACnet_RemoteDevice 4:
Bild-4: Beispiel für das Verwenden von mehreren Adapter- und Client-Instanzen in einem SPS-Projekt.
FB_BACnet_RemoteDevice 5:
Bild-5: Beispiel für den Aufruf von Bausteinen vom Typ FB_BACnet_RemoteAnalogValue mit unterschiedlichen entfernten BACnet-Servern in einem SPS-Projekt.

Die Verwendung von mehreren BACnet-Adaptern pro SPS-Projekt ist ein Spezialfall und wird nicht empfohlen. Sinnvoll wäre (z.B. bei Verwendung mehrerer Netzwerkkarten und damit getrennte BACnet-Netzwerke) die Verwendung mehrerer SPS-Projekte und damit mehrere SPS-Laufzeiten. Der Datenaustausch zwischen den einzelnen Laufzeiten kann via Prozessdatenmapping oder ADS-Kommunikation realisiert werden. Somit wäre auch die Verwendung des SPS-Automappings für BACnet-Objekte möglich.