Häufig gestellte Fragen (FAQ)

I.  BACnet-Client liefert keine aktuellen Prozessdaten

Ein BACnet-Client liefert keine aktuellen Prozessdaten, die via COV abonniert wurden an die SPS (Prozessdaten auf Client-Seite via Mapping mit der SPS verbunden; das Objekt selbst läuft auf einem entfernten Server). Was könnten mögliche Ursachen sein?

1. Der entfernte Server, auf den der Client zugreift wurde neugestartet (Reboot, TwinCAT Neustart oder Steuerspannungsausfall). Sobald der Server wieder läuft, müssen alle COV-Subscriptions vom Client neu angemeldet werden oder die Zeit die unter Resubscription Interval definiert wurde abgelaufen sein (Resubscription Interval, siehe auch Kapitel "Prozessdaten" unter "Properties als Prozessdaten").
• Wie kann das Neustarten entfernter Server erkannt werden?
• Unter einem Client kann das Prozessdatum SystemStatus gemapped werden. Das Mapping des SystemStatus sollte dabei auf Polling mit einer möglichst kurzen Periode (zwischen 1..5s) gestellt werden. Wird nun der entfernte Server abgeschaltet spricht zuerst das Timeout der Polling-Anfrage an (Server nicht erreichbar, Client-Statusbit 1 = TRUE → Quittierung mittels ClientControl ). Beginnt der entfernte Server mit dem Neustart nimmt der SystemStatus den Zustand "4" (non-operational) an. Wechselt der SystemStatus von "4" auf "0" ist der entfernte Server für Anfragen bereit, so dass COV-Subscriptions neu angemeldet werden können. Das Anmelden der COV-Subscriptions kann mittels ClientControl Bit 3 gesteuert werden.Für weitere Details, siehe Kapitel "Prozessdaten" unter Abschnitt "BACnet Client".
2. Die Netzwerkverbindung zwischen Client und Server ist unterbrochen.
• Wie kann der Status entfernter Server überwacht werden?
• Siehe Punkt 1. Zudem kann mittels Device Status des lokalen BACnet-Adapters der "linked" Zustand des Netzwerkadapters überwacht werden (siehe Kapitel "Prozessdaten" unter Abschnitt "BACnet Device").
3. Der entfernte Server unterstützt kein COV von Properties (COV-P).
4. Siehe auch Punkt IX.
4. Der entfernte Server unterstützt COV-P, jedoch ist die maximale Anzahl von Subscriptions auf das entsprechende Objekt serverseitig überschritten. Im Loggerfenster des System Managers erscheint auf Clientseite folgende Meldung:
   
   Beispiel für COV-P Fehlermeldung
• Wie kann die maximale Anzahl Subscriptions, die der Server pro Objekt zulässt, erhöht werden?
• Auf Seite des Servers muss folgender Parameter angepasst werden, um die maximal Anzahl von Subscriptions pro Objekt zu erhöhen (siehe Erweiterte Einstellungen unter Speicherspezfische Parameter):
• a.  BACnet-Adapter des entsprechenden Server anwählen
  
• b.  Button "Configure" unter "Advanced Settings - Data Structures" betätigen
  
• c.  Parameter "MAX_OBJ_SUBS_COV_ENTRIES" entsprechend erhöhen
  
• d.  Button "Save" zum Übernehmen betätigen / Abbruch mit Button "Cancel"
• e.  Geänderte Einstellung mit Symbol "Activate configuration" bzw. im Modus "CONFIG" mit Symbol "Reload I/O devices (F4)" aus der Toolbar aktivieren.

II.  Beim Stopp/Herunterfahren des TwinCAT-Systems werden die Prozessdaten einiger BACnet-Objekte zurückgesetzt

Beim Stopp/Herunterfahren des TwinCAT-Systems werden die Prozessdaten einiger BACnet-Objekte zurückgesetzt. Dies führt zu ungewollten Effekten, da einige Objektzustände Einfluss auf die Persistenten Daten der SPS nehmen. Wie kann die Gültigkeit der Objekt-Zustände in der SPS überwacht werden?

1. Die Gültigkeit der Objektzustände kann mit Hilfe des Device Status (Bit 8...15) des lokalen BACnet-Adapters überprüft werden, indem der Zustand der Device-State-Machine abgefragt (in die SPS gemapped) wird. Meldet die Device-State-Machine Complete (8), so wurden der lokale Server und dessen Objekte sowie Properties initialisiert und die Kommunikation zu entfernten Servern kann aufgenommen werden. Beim Herunterfahren des TwinCAT-Systems wird die Device-State-Machine zurückgesetzt (< 8). Wird das Zurücksetzten (< 8) in der SPS erkannt, dann sollten die Objektzustände (gemappte Properties) nicht mehr ausgewertet werden.
2. Client-Objekte (von entfernten Servern) können generell nicht auf Gültigkeit geprüft werden, da Kommunikations-Timeouts etc. die zeitnahe Überwachung nicht erlauben. Das Fehlschlagen von BACnet-Diensten kann jedoch aus dem Client-Status entnommen werden (Bit 0 und 1, siehe Kapitel "Prozessdaten" unter Abschnitt "BACnet Client"). Schlagen Anfragen fehl, so werden die entsprechenden Bits im Client-Status gesetzt. Diese müssen anschließend quittiert werden. Die Überwachung des lokalen BACnet-Adapters kann mit Hilfe des Device-Status erfolgen (siehe Punkt 1.).

III.  Das Schreiben von Daten bei Wertänderung zu einem entfernten Server (Write On Change) soll kurzzeitig deaktiviert werden

Das Schreiben von Daten bei Wertänderung zu einem entfernten Server (Write On Change) soll kurzzeitig deaktiviert werden (z.B. für das Nach-Triggern des PresentValue eines BinaryOutput-Objekts, ohne dass der Zustand INACTIVE gesetzt wird). Wie kann das realisiert werden?

1. Im Prozessdatum ClientControl kann mit Hilfe des Bit 2 das Schreiben von Write On Change deaktiviert werden (siehe Kapitel "Prozessdaten" unter Abschnitt "BACnet Client").
2. Das Nach-Triggern des Schreibens auf ein entferntes Objekt kann alternativ mittels ADS-Kommando vorgenommen werden (siehe Kapitel "ADS-Interface"). Die PLC-Library "TcBACnet.lib" bietet dazu den komfortablen Funktionsbaustein "FB_BACnetWriteProp".

IV.  Wie kann das Versenden von Alarm-Events bei BinaryOutput-/-Input- bzw. -Value-Objekten unterbunden werden?

1. Das Versenden der Events kann durch Abwahl der Bits im Reiter "Settings" bzw. "Online" oder durch Schreiben der Property EventEnable Nr. 35 verhindert werden (Value = 0x0005). Damit ist jedoch lediglich das Versenden der Event-Notifications unterdrückbar. Das Status-Bit in_alarm der Property StatusFlags Nr. 111 wird weiterhin gesetzt.
2. Um das Generieren jeglicher Events des jeweiligen Binary-Objekts zu verhindern, kann die Unterstützung für intrinsic reporting (O4) deaktiviert werden (siehe Kapitel "BACnet Objekte und Properties" unter Abschnitt "Konfiguration"). Damit wird ebenfalls das Status-Bit in_alarm der Property StatusFlags Nr. 111 nicht gesetzt.

V.  Wie kann eine NULL (NaN) in das Priority-Array der kommandierbaren Property PresentValue eines AnalogOutput-Objekts von der SPS über die Prozessdaten geschrieben werden?

1. Das PresentValue muss mit der entsprechenden Priorität als Prozessdatum aktiviert werden
2. Das Prozessdatum muss mit der SPS verknüpft werden (Datentyp REAL)
3. Im SPS-Programm kann mit der Library-Funktion "F_BACnet_NAN" aus der Library "TcBACnet.lib" der Zustand NULL (NaN) auf die Prozessdaten geschrieben werden → Die entsprechende Priorität des Priority-Array ist damit gelöscht

VI.  Warum ist das Prozessdatum PresentValue eines Binary*-Objekts vom Typ WORD

Das PresentValue eines Binary*-Objekts wird BACnet-intern als Enumeration vom Typ BACnetBinaryPV (active, inactive) geführt. Enumerationen werden generell mit dem Typ WORD gemapped. Für den einfacheren Umgang mit Binary*-Objekten wurde die herstellerspezifische Property PresentValueBool eingeführt. Diese kann mit Datentyp BOOL mit der SPS gemapped werden (siehe Kapitel "Prozessdaten").

VII.  Der K-Bus eines BACnet-Controllers fällt sporadisch, ohne ersichtlichen Grund aus. Was könnten mögliche Ursachen sein?

1. Der maximale K-Bus-Strom wurde überschritten. Wenn z.B. viele Relais-Ausgangsklemmen im Betrieb gleichzeitig aktiviert werden und dadurch der maximale K-Bus-Strom das zulässige Maximum übersteigt, kommt es zur K-Bus Abschaltung. Der Strombedarf der Klemmen sollte überprüft (siehe Strombedarf im Datenblatt der jeweiligen Klemme) und eine entsprechende K-Bus-Auffrischung (siehe Beschreibung zur KL9400) vorgesehen werden.
2. Wenn der K-Bus-Task durch den BACnet-Task getriggert wird (Mapping ausschließlich zwischen BACnet und K-Bus, keine SPS etc. → asynchrones Mapping), dann kann es bei starker Auslastung des BACnet-Tasks dazu kommen, dass der K-Bus-Task nicht ausreichend oft getriggert wird. Der Grund liegt in der Task-Zeit-Überschreitung des BACnet-Tasks (häufige Exceeds → siehe Exceed counter der entsprechenden Task) bei hohem BACnet-Kommunikationsaufkommen.
• Wie kann der K-Bus-Task unabhängig vom BACnet-Task getriggert werden?
• a.  Einen neuen Task im TwinCAT System-Manager anlegen
  
• b.  Taskkonfiguration vornehmen; Auto start aktivieren und die nötige Zykluszeit (Cycle ticks) einstellen
  
• c.  Eine Variable für das Mapping hinzufügen (Z.B. CycleTime vom Typ UINT)
  
• d.  K-Bus-Variable "CycleTime" und Task-Variable "K_Bus_CycleTime" verknüpfen
  
• e.  Geänderte Konfiguration mit Symbol "Activate configuration" aus der Toolbar aktivieren

VIII.  Warum hat die Property StatusFlags eines Objekts den Wert 0x0004 bzw. die Property EventEnable den Wert 0x0005 obwohl keinerlei Statusbits der Property gesetzt sind?

Properties mit Bit-Flags (Untertyp BitFieldBits) werden intern als sogenannter Bit-String übertragen. Ein Bit-String besteht immer aus einem High- und Low-Byte. Im Low-Byte befindet sich die Angabe wie viel Bits des High-Bytes, von links, nicht benutzt werden. D.h. StatusFlags = 0x0004 bedeutet das die 4 höheren Bits des High-Byte nicht benutzt werden (also nur die Bits 8, 9, 10 u. 11 des WORD-Datentyps werden verwendet). Für weitere Details siehe Kapitel "Prozessdaten / Bit String".

IX.  Ein BACnet-Client dessen Prozessdaten mit der SPS verbunden sind wird im System-Manager immer als "Offline" angezeigt. Bei einem Scan wird der Client jedoch angezeigt. Was könnte das Problem sein?

Bei Verwendung von Prozessdaten, die mit Hilfe des SPS-Automappings verknüpft wurden, werden die Properties im Standardfall mittels COV abonniert. Dies kann zu Problemen führen, wenn der Client COV nicht unterstützt (Loggermeldung wie etwa: "Error TCOM Server (10) [...] BACnet Client [...] - COV subscription failed! Reject Reason: unrecognized service"). Da das COV-Abonnieren fehl schlägt werden entsprechend Neu-Anfragen an den entfernten Server fortlaufend gesendet - dies führt zu Zeitüberschreitungen und schließlich zur Anzeige des Clients im System-Manager als "Offline".

Lösung: Die Eingangsprozessdaten der Properties des Clients müssen im System-Manager auf den Modus "Polling" umgestellt werden.

Wie können die Eingangsprozessdaten (Read) eines Clients von COV auf Polling umgestellt werden?

1. Entsprechenden Client anwählen
2. Reiter "Objects" öffnen
3. Property-Wizard öffnen (siehe auch BACnet Wizards)
   
4. Unter "Select Objects" den Client vollständig anwählen und...
• a.  Option "Optimize Process Data Access (Tick Modulo)" aktivieren
• b.  Option "Change Process Data In Configuration (Read)" aktivieren
• c.  Modus "Process Data Read Mode" auf "Polling" stellen
• d.  Parameter "Cycle Time (ms)" auf z.B. 10000 = 10 Sekunden Lesezyklus einstellen
       Hinweis Dieser Parameter muss auf Grund der Applikationsanforderung optimiert und u.U. individuell für die jeweilige Property bestimmt werden
5. Unter "Select Properties" sämtliche Einträge anwählen (mit rechter Maus-Taste und "Select All")
6. Mit der Betätigung des Buttons "Apply" werden die Änderungen übernommen.

X.  Das PLC Automapping ist wesentlich langsamer als üblich. Was könnte die Ursache sein?

Ursache: Das PLC Automapping sollte nicht durchgeführt werden, wenn der System Manager auf dem Zielsystem eingeloggt ist. Durch die Verbindung zum Zielsystem kommt es zu Verzögerungen beim Anlegen von Verknüpfungen zwischen den Prozessdaten. Da beim PLC Automapping potenziell viele Prozessdaten verknüpft werden, summiert sich diese kurze Verzögerung zu einer wesentlich längeren PLC Automapping Laufzeit.

Lösung: Bevor das PLC Automapping durchgeführt wird, sollte im System Manager die lokale Laufzeit als Zielsystem gewählt werden. Nach dem PLC Automapping kann auf das eigentliche Zielsystem zurück gewechselt werden.