t h e n e w d i m e n s i o n e i n e B r ü c k e z w i s c h e n W e l t e n NETxLAB VoyagerServer 1.0 System Dokumentation

Transkript

1 e i n e B r ü c k e z w i s c h e n W e l t e n t h e n e w d i m e n s i o n NETxLAB VoyagerServer 1.0 System Dokumentation Mitglied der OPC Foundation. Mitglied der Konnex Association. Jänner 2010, Version: 1.0

2 I n d e x NETxLAB VoyagerServer Systemaufbau... 9 Voyager Studio Menu Edit Server Clients Project Tools Windows Info Toolbar Save All Print To Excel From Excel Connection Start Simulation Shutdown Project Tree Items Tree Search System Messages Telegram Monitor Cell Monitor Gateway Monitor Gateway Info Telegram Definition Tabelle Link Manager Event Processor Info desk Send Interval Last Cell Set Telegrams Received Telegrams Sent Status Start Date/Time Mode N-Mesh Mode Date/Time Server Arbeitsweise Dienst/Server Konfiguration Verzeichnisse Version: 1.0 Seite 2 von 86

3 Router configuration: nxaopcrouter.35.cfg System configuration: nxaopcsystem.35.cfg Telegram Definitionen: nxatelegramdefinitions.35.dat Gateway Definitionen: nxagatewaydefinitions.35.dat Device Definitionen: nxadevicedefinitions.35.dat N-Mesh Subsystem Konfigurationsdatei: nxanmesh.35.cfg N-Mesh Routing Definitionen: nxanmeshroutingdefinitions.35.dat System - Protokolldatei: nxaopcsystem.35.log Datenaufzeichnung: nxaopcdata.35.log Telegram-Protokolldatei: nxaopctelegram.35.log Die OPC ITEM Eigenschaften Der Aufbau der OPC Strukturen Anbindung von OPC Clients Mögliche Datentypen NETxLAB Voyager Server Direct(KNX) Version Das Konvertierungstool: NETxLAB ConvertETS Lizenzierungsvarianten: Softwareschutz Softlock Hardlock Gateways Das Ethernet Netzwerk Systemvorraussetzungen Multicore Prozessoren werden empfohlen Support und Kontakt Wichtige Notizen Version: 1.0 Seite 3 von 86

4 Copyright Diese Veröffentlichung bezieht sich auf das Release 1.0 des Software-Systems NETxLAB VoyagerServer. Sie wird herausgegeben von NETxAutomation, Maria-Theresia-Straße 41, 4600 Wels, Österreich. (C) Copyright by NETxAutomation, Gewährleistung für die Richtigkeit, Anwendbarkeit und Brauchbarkeit dieser Dokumentation kann nur im Rahmen der Bestimmungen des Software-Überlassungsvertrages übernommen werden. Änderungen am Funktionsumfang der beschriebenen Software sind jederzeit vorbehalten und müssen keine Änderungen der diesbezüglichen Dokumentation nach sich ziehen. Alle Rechte vorbehalten. Vervielfältigungen, Übersetzungen, Mikroverfilmungen sowie die Einspeicherung und Verarbeitung in elektronischen Systemen sind urheberrechtlich geschützt. Nachdruck nur mit schriftlicher Genehmigung von NETxAutomation. Version: 1.0 Seite 4 von 86

5 NETxLAB VoyagerServer 1.0 Das System ermöglicht in Verbindung mit einem geeigneten OPC Client, die Steuerung und die Visualisierung von KNX-Anlagen. Er ist eine Schnittstelle zwischen KNX, SmartVoyager Clients und einem zentralen Serversystem (z.b.: NETxKNX OPC Server Babylon). Es stellt eine Brücke zwischen der KNX Welt und anderen Systemen dar, die über die OPC-Schnittstelle einen direkten Einfluss auf das Geschehen in dieser Welt nehmen können. Die Erfahrung, das Know How, das bei großen Projekten gewonnen wurde, konnte bei der Entwicklung einer ganzen Reihe von neuen Systemen optimal eingesetzt werden. So ist auch dieses System als ein zuverlässiges, offenes und benutzerfreundliches konzipiert und realisiert worden. Version: 1.0 Seite 5 von 86

6 Die Hauptmerkmale:. NETxLAB Schnittstelle zu den Clients Hohe Zuverlässigkeit für den Dauerbetrieb konzipiert und entwickelt Bei VoyagerServer Direct(KNX) Falcon Treiber inclusive VoyagerServer Direct(KNX) 1 Gateway; bis zu 10 Clients VoyagerServer Unified Driver bis zu 20 Gateways; bis zu 500 Clients UnifiedDriver unterschiedliche Gateway Typen können gemeinsam verwendet werden. ABB IG/S 1.1, KNX NetIP Gateways oder eibnode können zusammen in einem Arbeitsbereich verwendet werden. Alle offiziellen EIS-Datentypen werden unterstützt und mehr Telegrammdefinitionen Enormer Datentransfer Redundanz mit Main- and Backup Server Konfiguration Clustering von NETxLAB Voyager Servers mit N-Mesh Konfiguration KNX Geräte Erreichbarkeit Überprüfung MultiProject Kern Workspace Management - mehrere Arbeitsbereiche können bequem verwaltet werden Event Processor zyklische, zeitbezogene und ereignisbezogene Aktionen können im Voyager Server definiert werden Link Manager - das Verwalten von verlinkten Gruppenadressen kann jetzt direkt im Voyager Server realisiert werden KNX Telegram Overflow Manager ein erweiterter Schutz vor Überlastung des KNX Real Database Refresh - die Updates der Voyager Server Datenbank erfolgen automatisch Direkte Wertabfragen von KNX-Geräten für Initialisierung des virtuellen Models der Anlage Erweiterter Adressraum die reale Adresse des Datenpunktes besteht aus der logischen KNX-Adresse und der IP-Adresse Datenaufzeichnung im Ringspeicher eine große Anzahl an gesendeten/empfangenen Telegrammen kann gespeichert werden. Version: 1.0 Seite 6 von 86

7 Prozesszustand des gesamten Systems kann ebenfalls gespeichert und automatisch beim Starten wieder geladen werden. Online-Überprüfung des Zustandes aller angeschlossenen Gateways Echtzeit-Anzeige des Telegrammverkehrs mit Klartext-Beschreibung und erweiterten Informationen Zahlreiche Erweiterungsmodule verfügbar Version: 1.0 Seite 7 von 86

8 Arbeitsweise des Systems KNX Linie Schalter KNX log. Adresse: 1/1 Deckenleuchte KNX log. Adresse: 1/2 Datenfluss in NETxLAB VoyagerServer Version 1.0: KNX IP Gateway KNX IP Gateway Hier werden KNX- Telegramme in LAN- Telegramme konvertiert und umgekehrt KNX-Telegramme werden von Gateways in LAN-Telegramme konvertiert, die dann über LAN an den NETxLAB Voyager Server weitergeleitet werden. Der Server empfängt, analysiert, führt Fehlerüberprüfungen durch, protokolliert und sendet über die OPC-Schnittstelle die Daten an alle angeschlossenen OPC Clients. Alle Ereignisse werden in den LOG-Dateien protokolliert, die für Systemanalyse und Fehlersuche verwendet werden können. NETXKNX SERVER Schnittstellen Jeder Ausfall eines Gateways wird sofort entdeckt, angezeigt und ebenfalls protokolliert. Ein virtuelles Modell der gesamten KNX-Anlage wird vom Server verwaltet, jede Telegrammdefinition wird dort als Cell, eine Zelle abgebildet. In dieser Zelle wird nicht nur der aktuelle Wert des Datenpunktes, sonder auch eine Reihe von Zusatzinformationen (wie z.b. Zeitpunkt der letzten Zustandsänderung) mitgespeichert. Der aktuelle Wert jeder Zelle kann im Studio, im Cell Monitor überprüft werden. Der Event Prozessor ist eine Erweiterung des NETxLAB Voyager Server Kernes, und ermöglicht die Realisierung von komplexeren, ereignisabhängigen Aufgaben. LAN 1/1#1 1/2#1 EVENT PROCESSOR Version: 1.0 Seite 8 von 86

9 Systemaufbau Das System besteht aus zwei wesentlichen Teilen: dem Server und dem Studio. Der Server ist ein autonomes Programm, das die gesamten Abläufe durchführt und kontrolliert. Das Studio stellt eine Schnittstelle zwischen dem Server und dem Administrator dar, die nur für die Dauer der Zustandsanalyse gestartet wird. Diese Umgebung verfügt über mehrere nützliche Tools, die dem Administrator das Verwalten, Analysieren und die Fehlersuche im gesamten KNX-Projekt ermöglichen. Physikalischer Aufbau des Systems: Version: 1.0 Seite 9 von 86

10 Voyager Studio Das NETxLAB Voyager Studio ist in mehrere Bereiche aufgeteilt. Durch den Fenster-Manager ist es dem Benutzer überlassen, wie er die Umgebung seinen Bedürfnissen anpasst. Version: 1.0 Seite 10 von 86

11 Menu Workspace New Workspace Erstellt einen neuen Arbeitsbereich dabei wird der Inhalt des Workspaces\Default Verzeichnisses in das neu erstellte Verzeichnis kopiert. Das neue Verzeichnis wird mit dem Namen des neuen Arbeitsbereiches benannt. Open Workspace Öffnet einen bestehenden Arbeitsbereich. In dem Open Workspace Dialog werden alle Unterverzeichnisse des Workspaces -Verzeichnisses aufgelistet. Wird eine neue Workspace geöffnet, wird der Server gestoppt und mit der neuen Konfiguration wieder gestartet. Version: 1.0 Seite 11 von 86

12 Save Workspace As Speichert den aktuellen Arbeitsbereich unter neuem Namen dabei werden alle relevanten Dateien des Quellverzeichnisses in das neue Verzeichnis kopiert. Edit Delete Workspace Löscht unwiderruflich den Arbeitsbereich mit dem gesamten Inhalt und sein Verzeichnis. Exit Beendet das Studio, der Server wird dabei nicht heruntergefahren. Search Dies sucht einen Text in der Definitionstabelle (es wird aktiviert, wenn die Tabelle im aktuellen Fenster aktiviert wird). Search and Replace Dies sucht und ersetzt einen Text in der Definitionstabelle (es wird aktiviert, wenn die Tabelle im aktuellen Fenster aktiviert wird) Version: 1.0 Seite 12 von 86

13 Server Import ETS(c) Project Startet das Importierungstool, mit dem die exportierten ETS OPC Dateien (*.esf) in Telegramm- und Linkdefinitionsdateien konvertiert werden können. Genauere Informationen finden Sie unter Das Konvertierungstool: NETxLAB ConvertETS. Nach jeder Änderung in Telegrammdefinitionsdatei muss der Voyager Server neu gestartet werden. Folgende Information wird dementsprechend angezeigt: Server Configuration Hier können spezielle Server Parameter verändert werden. Die Optionen sind beschrieben und auswählbar. Diese Parameter sind auch in der System Konfigurationsdatei beschrieben. Version: 1.0 Seite 13 von 86

14 Router Configuration Hier können spezielle Router Parameter verändert werden. Die Optionen sind beschrieben und auswählbar. Diese Parameter sind auch in der Router Konfigurationsdatei beschrieben N-Mesh Configuration Hier können spezielle N-Mesh Parameter verändert werden. Die Optionen sind beschrieben und auswählbar. Diese Parameter sind auch in der N-Mesh Konfigurationsdatei beschrieben Version: 1.0 Seite 14 von 86

15 System Settings zeigt das Konfigurationsfenster an. Hier können die Systemparameter verändert werden, die im laufenden Betrieb das Verhalten des Systems beeinflussen. Alle anderen Parameter können nur direkt in den Konfigurationsdateien (Dateien nxaopcrouter.35.cfg und nxaopcsystem.35.cfg ) verändert werden. Send Interval definiert die Zeitabstände in welchen die Telegramme an ein bestimmtes Gateway verschickt werden. Da das KNX ca. 17 Telegramme pro Sekunde übertragen kann, trägt das Datenmanagement Modul des Servers die Sorge, dass die Telegramme in vordefinierten Zeitabständen an ein Gateway versendet werden. Sollten z.b Telegramme an das Gateway versendet werden, wird das 2000x200ms = 6,6 Minuten dauern bis alle versendet worden sind. Group Address Type definiert wie die logischen EIB-Adressen im Studio angezeigt werden, 2- oder 3-stufig. Dieser Parameter hat keinen Einfluss auf die OPC ITEM ID (diese bestehen zum Teil aus der log. KNX Adresse), der Typ der Adresse, der für die OPC ITEM ID verwendet wird, ist in der Datei nxaopcsystem.35.cfg festgelegt. Start Server Startet den Voyager Server (wird aktiviert wenn der Server nicht hochgefahren ist, oder das Studio die Verbindung zum Server verloren hat). Shutdown Server Der Server wird heruntergefahren. Sind zur Zeit OPC Clients mit dem Server verbunden, wird dieses Dialogfenster angezeigt: Hier wird informiert, dass noch ein OPC Client angeschlossen ist, und abgefragt, ob der Server wirklich gestoppt werden soll. Achtung: obwohl das System über die OPC Shutdown Schnittstelle verfügt, und die Information über das Herunterfahren vom Server an die Clients verschickt wird, berücksichtigen einige Clients dies nicht und melden einen Verbindungsfehler. Version: 1.0 Seite 15 von 86

16 Restart Server Initialisiert das System neu und ladet die aktuellen Definitionstabellen und Konfigurationsdateien. In diesem Fall wird der Server niedergefahren, und die Verbindung zu den OPC Clients wird unterbrochen. Sind zur Zeit OPC Clients mit dem Server verbunden, wird dieses Dialogfenster angezeigt: Hier wird informiert, dass noch ein OPC Client angeschlossen ist, und abgefragt, ob der Server wirklich gestoppt werden soll. Werden Fehler in den Definitionen entdeckt, werden Fehlermeldungen in der Event Tabelle angezeigt. Reload N-Mesh Routing Mit diesem Befehl wird die N-Mesh Routing Datei manuell nachgeladen. Set Cell Value Dieses Tool ermöglicht das direkte Setzten eines Zellenwertes. Dieser Wert wird in dem virtuellen Modell der Anlage im Serverspeicher verändert, und an die OPC Clients weitergegeben. Es wird aber kein Telegramm zum KNX verschickt. Somit können bestimmte Datenpunkte mit Werten initialisiert werden. Die Voraussetzung ist, dass die angegebenen Parameter gültig sind, sonst wird eine Fehlermeldung ausgegeben und die Durchführung unterbrochen. Send Telegram Das Versenden eines KNX-Telegramms wird durch dieses Tool ermöglicht. So wird nicht nur der Zellenwert verändert, es wird auch ein Telegramm zum KNX geschickt. Ist kein Telegramm definiert, zu dem die Angaben passen, wird eine Fehlermeldung generiert, und die Aufforderung wird ignoriert. Sollten die Angaben stimmen, aber die Verbindung zum LAN unterbrochen sein, wird ebenfalls keine Aktion durchgeführt. Der Typ des Telegramms definiert die Funktion: WRITE Schreib-Telegramm RESPONSE Antwort-Telegramm READ Lese-Telegramm Version: 1.0 Seite 16 von 86

17 Advanced Configuration Extended Logging ON/OFF Schaltet die erweiterte Protokollierung der OPC-Schnittstelle ein und aus. Clients Project Add Client Definition Erstellt eine neue SmartVoyager Client Definition. Es öffnet sich ein neues Dialogfenster. Hier können der Name des Clients, ein Passwort, eine Beschreibung und das zu übertragende Projekt eingestellt werden. ACHTUNG: Die Daten Name und Passwort müssen im SmartVoyager Client ident eingestellt werden. Edit Client Definition Lässt eine bereits bestehende SmartVoyager Client Definition editieren. Delete Client Definition Löscht eine bereits bestehende SmartVoyager Client Definition. Upload project project name Mit dieser Funktion kann ein bereits importiertes SmartVoyager Projekt auf einen SmartVoyager Client, der mit dem Server verbunden ist, übertragen werden. Disconnect Client Trennt die Verbindung zu einem bestehenden SmartVoyager Client. Add Project Importiert ein neues SmartVoyager Projekt in den Projektbaum. Delete Project Löscht ein importiertes SmartVoyager Projekt aus dem Projektbaum. Version: 1.0 Seite 17 von 86

18 File System Log File Open Es wird die System-LOG-Datei des aktuellen Arbeitsbereiches geöffnet, und der gesamte Inhalt in einer Tabelle angezeigt. Bei größeren Dateien kann dieser Vorgang länger dauern. Close Schließt die Systemprotokolldatei. Gateway Definitions Open Öffnet die Gateway-Definitionstabelle Save Speichert die Gateway-Definitionstabelle (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Nach dem Speichern erscheint die Abfrage nach einer Neuinitialisierung des Systems. Close Schließt die Gateway-Definitionstabelle, ohne den aktuellen Zustand zu speichern (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Telegram Definitions Open Öffnet die Telegrammdefinitionstabelle. Save Speichert die Telegrammdefinitionstabelle (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Nach dem Speichern kommt die Abfrage nach einer Neuinitialisierung des Systems. Close Schließt die Telegrammdefinitionstabelle, ohne den aktuellen Zustand zu speichern (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Device Definitions Open Öffnet die Devicedefinitionstabelle Save Speichert die Devicedefinitionstabelle (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Nach dem Speichern kommt die Abfrage nach einer Neuinitialisierung des Systems. Close Version: 1.0 Seite 18 von 86

19 Schließt die Devicedefinitionstabelle, ohne den aktuellen Zustand zu speichern (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Link Definitions Open Öffnet die Linkdefinitionstabelle Save Speichert die Linkdefinitionstabelle (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Nach dem Speichern kommt die Abfrage nach einer Neuinitialisierung des Systems. Close Schließt die Linkdefinitionstabelle, ohne den aktuellen Zustand zu speichern (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Response Event Definitions Open Öffnet die Antwort-Ereignis -Definitionstabelle Save Speichert die Antwort-Ereignis -Definitionstabelle (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Nach dem Speichern werden die Änderungen nicht übernommen hier muss der Server manuell gestoppt und wieder gestartet werden. Close Schließt die Antwort-Ereignis -Definitionstabelle, ohne den aktuellen Zustand zu speichern (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird) Timer Event Definitions Open Öffnet die Schaltuhr-Ereignis -Definitionstabell Save Speichert die Schaltuhr-Ereignis -Definitionstabelle (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Nach dem Speichern werden die Änderungen nicht übernommen hier muss der Server manuell gestoppt und wieder gestartet werden. Close Schließt die Schaltuhr-Ereignis -Definitionstabelle, ohne den aktuellen Zustand zu speichern (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird).. Version: 1.0 Seite 19 von 86

20 Cyclic Event Definitions Open Öffnet die Zyklische -Ereignis -Definitionstabelle Save Speichert die Zyklische -Ereignis -Definitionstabelle (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Nach dem Speichern werden die Änderungen nicht übernommen hier muss der Server manuell gestoppt und wieder gestartet werden. Close Schließt die Zyklische -Ereignis -Definitionstabelle, ohne den aktuellen Zustand zu speichern (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). N-Mesh Routing Definitions Open Öffnet die N-Mesh Routing-Definitionstabelle Save Speichert die N-Mesh Routing-Definitionstabelle (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Nach dem Speichern werden die Änderungen übernommen. Der Server muss nicht manuell gestoppt und wieder gestartet werden. Close Schließt die N-Mesh Routing-Definitionstabelle. Advanced Configuration System Configuration File Open Öffnet die System-Konfigurationsdatei Save Speichert die System-Konfigurationsdatei. Nach dem Speichern werden die Änderungen nicht übernommen hier muss der Server manuell gestoppt und wieder gestartet werden. Close Schließt die System-Konfigurationsdatei, ohne den aktuellen Zustand zu speichern. Router Configuration File Open Öffnet die Router-Konfigurationsdatei. Version: 1.0 Seite 20 von 86

21 Save Speichert die Router -Konfigurationsdatei. Nach dem Speichern werden die Änderungen nicht übernommen hier muss der Server manuell gestoppt und wieder gestartet werden. Tools Print Close Schließt die Router-Konfigurationsdatei, ohne den aktuellen Zustand zu speichern. N-Mesh Configuration File Open Öffnet die N-Mesh Router-Konfigurationsdatei. Save Speichert die N-Mesh Router -Konfigurationsdatei. Nach dem Speichern werden die Änderungen nicht übernommen hier muss der Server manuell gestoppt und wieder gestartet werden. Close Schließt die N-Mesh Router-Konfigurationsdatei, ohne den aktuellen Zustand zu speichern. Druckt die Definitionstabellen (wird aktiviert, wenn die Tabelle als aktuelles Fenster ausgewählt wird). Telegram History Explorer Startet den Telegram History Explorer, mit dem die aufgezeichneten Telegramme analysiert werden können. Version: 1.0 Seite 21 von 86

22 Windows Project Tree Schaltet die Projekt Baum -Ansicht ein und aus. Dieser zeigt die definierten SmartVoyager Clients und importierten SmartVoyager Projekte. Durch einen Doppelklick auf einen SmartVoyager Client, können seine Verbindungseinstellungen geändert werden. Items Tree Schaltet die OPC Items -Ansicht ein und aus. Version: 1.0 Seite 22 von 86

23 Event Monitor Schaltet die Ereignismonitor ein und aus. Telegram Monitor Schaltet die Telegrammmonitor ein und aus. Info Cell Monitor Schaltet den Zellenmonitor ein und aus. Gateway Monitor Schaltet den Gateways-Monitor ein und aus. Search Hilft ein OPC Item nach ItemID oder Beschreibung zu finden. Suchmuster wie 1/* sind möglich. About Ein allgemeiner Info-Dialog wird angezeigt. Version: 1.0 Seite 23 von 86

24 Toolbar Save All Speichern aller offenen Definitionstabellen. Wird eine Tabelle gespeichert, folgt die Abfrage über die Neuinitialisierung des Servers. Wird diese Abfrage mit JA bestätigt, wird das System mit der neuen Tabelle initialisiert. Achtung: der Voyager Server wird in diesem Fall neu gestartet und die Verbindung zu den OPC Clients wird unterbrochen. Print Druckt eine Definitionstabelle (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird) To Excel Exportiert eine Definitionstabelle in Microsoft Excel (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). From Excel Importiert eine Definitionstabelle aus einer Microsoft Excel Datei (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Connection Öffnet den Falcon Verbindungsmanager. (Nur in der Direct(KNX) Version). Start Startet den Voyager Server (wird aktiviert wenn der Server nicht hochgefahren ist, oder das Studio die Verbindung zum Server verloren hat). Simulation Startet den Voyager Server im Simulations Modus. Keine Daten werden an den KNX gesendet. Version: 1.0 Seite 24 von 86

25 Shutdown Der Server wird heruntergefahren. (wird aktiviert wenn das Studio eine Verbindung zum hochgefahrenen Server aufgebaut hat) Achtung: obwohl das System über die OPC Shutdown-Schnittstelle verfügt, und die Information über das Herunterfahren vom Server an die Clients verschickt wird, berücksichtigen einige Clients dies nicht und melden in diesem Fall einen Verbindungsfehler. Sind zur Zeit OPC Clients mit dem Server verbunden, wird dieses Dialogfenster angezeigt: Hier wird informiert, dass noch ein OPC Client angeschlossen ist, und abgefragt, ob der Server wirklich gestoppt werden soll. Project Tree Es startet den Projekt Baum, der die definierten SmartVoyager Clients und verfügbaren SmartVoyager Projekte anzeigt. Items Tree Es startet den OPC Baum. Search Es startet ein Such Tool für OPC Items. Version: 1.0 Seite 25 von 86

26 System Messages Hier werden alle relevanten Ereignisse des Systems angezeigt. Jeder Informationstyp wird entsprechend markiert. Alle angezeigten Informationen werden gleichzeitig in der nxaopcsystem.35.log Datei gespeichert, was eine spätere Systemanalyse ermöglicht. Wenn eine Spaltenüberschrift genommen und auf das Gruppierfeld über der Tabelle losgelassen wird, wird die Überschrift herausgezogen und die Tabelle wird nach dieser Überschrift gruppiert. Wenn man zusätzlich die Strg Taste drückt, während des Verschiebens, bleibt die Überschrift in der Tabelle erhalten. Mit dem Mistkübel Icon können alle Systemnachrichten in der Tabellenansicht gelöscht werden. Fehler Nachrichten sind rot gefärbt. Warnungen Nachrichten sind gelb gefärbt. Info Nachrichten sind nicht eingefärbt. Version: 1.0 Seite 26 von 86

27 Telegram Monitor Die empfangenen bzw. gesendeten Telegramme werden im Telegramm Monitor angezeigt. Es werden nur die Telegramme aufgelistet, die im System tatsächlich definiert worden sind, alle anderen werden ignoriert. Die erste Spalte zeigt, ob ein Telegramm gesendet ( OUT ) oder empfangen ( IN ) wurde. Die zweite Spalte beinhaltet den Typ des Telegramms. In der dritten wird der Zeitpunkt des Ereignisses angezeigt. Bei den ankommenden Telegrammen wird in der vierten Spalte die IP-Adresse des sendenden Gateways aufgelistet, bei gesendeten wird hier die Ziel- IP-Adresse stehen. BROADCAST steht für ein Telegramm das an alle Gateways gleichzeitig geschickt wird ( zentrales Telegramm ). Die nächste Spalte zeigt die logische KNX-Adresse, die das Telegramm übermittelt. Die physikalische KNX-Adresse der Quelle des empfangenen Telegramms steht in der sechsten Spalte. Der Klartext-Beschreibung des Telegramms folgt dann der Wert. In Anlagen, in denen das Telegrammaufkommen sehr hoch ist, soll die Tabelle nur zur Systemüberprüfung verwendet werden, und danach wieder geschlossen werden, um dem Server keine wichtigen Ressourcen zu entziehen. Konfiguration der Tabelle Die Breite einer Spalte kann verändert werden. Wenn eine andere Reihenfolge der Spalten gewünscht ist, einfach per Drag und Drop umgruppieren. Filter Der Filter ermöglicht die gezielte Überwachung von bestimmten log. KNX-Adressen/ KNX-Bereichen und/oder bestimmten Gateways. Set Filter Diese Funktion vereinfacht die Analyse des Datenverkehrs. Mit diesem Filter kann festgelegt werden, welche Telegramme in der Telegrammliste gezeigt werden sollen. Der Filter besteht aus drei Teilen. Der erste Teil definiert den Bereich der log. KNX-Adressen, die gezeigt werden sollen. Im zweiten Teil kann noch die IP-Adresse definiert werden, so werden nur die Telegramme aufgelistet, die von oder zu diesem Gateway empfangen/geschickt werden, das diese Adresse besitzt. Version: 1.0 Seite 27 von 86

28 Der letzte Teil legt den Typ der Telegramme fest, die gezeigt werden sollen. Die Filter-Teile können beliebig kombiniert werden. Cell Monitor Gateway Monitor Das virtuelle Modell der Anlage ist im Server-Speicher abgebildet. Die einzelnen Datenpunkte sind hier als Zellen ( Cell ) implementiert. Die Wertänderungen einer Zelle können in Echtzeit mit Hilfe des Cell Monitors mitverfolgt werden. Die Überwachung einer Zelle kann durch Angabe der gesamten Adresse (log. KNX-Adresse + IP-Adresse) und Drücken des ADD Buttons eingefügt werden. Eine Überwachung kann entfernt werden, indem die gewünschte Zeile angeklickt wird, und die Entfernen oder Löschen Taste auf der Tastatur gedrückt wird. Ist einer Zelle noch kein Wert zugewiesen, wird in der Value Spalte das Zeichen??? erscheinen. Es können nur die im System definierten Zellen (Telegrammdefinitionstabelle) überwacht werden. Der Gateways Monitor listet alle in der Gateway- Definitionstabellendatei definierten Gateways auf. Hier ist auch der aktuelle Zustand (OFF für Offline, ON für Online), die Zeitdauer seit dem letzten Zustandswechsel und die IP-Adresse dargestellt. Ist ein Gateway für das System nicht erreichbar, wird es mit rotem Kreuz und OFF gekennzeichnet. Das BROADCAST Gateway stellt ein imaginäres Gerät dar, es wird verwendet um die zentralen Telegramme, also die, die an alle Gateways gleichzeitig geschickt werden, zu versenden. Hat das BROADCAST Gerät Offline Status, bedeutet das, dass der Server keine Verbindung zum Netzwerk hat. In diesem Fall muss die Netzwerk-Konfiguration des Rechners überprüft werden. Durch das Doppelklicken auf ein aufgelistetes Gateway, wird das Gateway Info - Fenster geöffnet. Version: 1.0 Seite 28 von 86

29 Gateway Info Dieser Bereich zeigt die vorhandenen Informationen über das ausgewählte Gateway. Das Fenster wird aktiviert, indem ein Gateway-Icon aus dem Gateways Monitor mit Doppelklick ausgewählt wird. Current Status der aktuelle Status des Gerätes (ONLINE/OFFLINE) Name die Bezeichnung des Gateways IP Address die IP-Adresse Locality Standort Description die Kurzbeschreibung Status changed at der Zeitpunkt zu welchem die letzte Statusänderung statt gefunden hat. Status changes die Anzahl der Statusänderungen seit der letzten Initialisierung des Systems. Telegrams received die Anzahl der Telegramme, die der Server von diesem Gerät empfangen hat. Telegrams Sent die Anzahl der Telegramme, die an das Gateway versendet worden sind. Telegram Definition Tabelle Die gesamte Datenstruktur des Systems ist in der Telegram Definitions Tabelle festgelegt. Diese Tabelle wird aus der nxatelegramdefinitions.35.dat Datei herausgelesen, und in dieser Form dem Benutzer zur Verfügung gestellt Zur Bearbeitung dieser Datei empfiehlt sich das Microsoft Excel Programm (CSV Datei Import). Version: 1.0 Seite 29 von 86

30 Diese Darstellung ermöglicht die Durchführung kleinerer Anpassungen, bzw. das Erweitern der Tabelle, so können auch eventuelle Fehler leichter korrigiert werden. Das Popup-Menü zum Bearbeiten der Tabelle wird über die rechte Maustaste geöffnet. Insert new Definition fügt eine neue Zeile in die Tabelle ein, die mit Telegrammdefinitions-Daten ausgefüllt werden kann. Insert new Comment fügt eine Kommentarzeile ein, die mit einem Text versehen werden kann Convert to Definition konvertiert Zeile in eine Telegram Definition. Convert to Comment konvertiert Zeile in einen Kommentar. Delete löscht die selektierte Zeile Send Telegram - sendet ein Telegram der ausgewählten Gruppen Adresse. Set Cell Value - setzt nur den Wert der Zelle ohne ein Telegramm zu verschicken. Add to monitor - fügt die Gruppen Adresse dem Cell Monitor hinzu Eine Telegrammdefinitionszeile besteht aus mehreren Spalten. Für detaillierte Informationen siehe Telegram Definitionen: nxatelegramdefinitions.35.dat Gateway Definition Tabelle Alle Gateways, die vom System verwaltet werden sollen, müssen in dieser Tabelle definiert werden. Diese Tabelle wird aus der nxagatewaydefinitions.35.dat Datei herausgelesen, und in dieser Form dem Benutzer zur Verfügung gestellt. Zur Bearbeitung dieser Datei empfiehlt sich das Microsoft Excel Programm (CSV Datei Import) Diese Darstellung ermöglicht die Durchführung kleinerer Anpassungen, bzw. das Erweitern der Tabelle, so können auch eventuelle Fehler leichter korrigiert werden. Das Popup-Menü zum Bearbeiten der Tabelle wird über die rechte Maustaste geöffnet. Insert new Definition fügt eine neue Zeile in die Tabelle ein, die mit Gateway Definitions-Daten ausgefüllt werden kann. Insert new Comment fügt eine Kommentarzeile ein, die mit einem Text versehen werden kann Convert to Definition konvertiert Zeile in eine Telegram Definition. Convert to Comment konvertiert Zeile in einen Kommentar. Delete löscht die selektierte Zeile Eine Gatewaydefinitionszeile besteht aus mehreren Spalten. Für detaillierte Informationen siehe Gateway Definitionen: nxagatewaydefinitions.35.dat Version: 1.0 Seite 30 von 86

31 System Protokolldatei Alle relevanten Informationen werden in einer Datei gespeichert. Diese Datei kann im Studio zur Überprüfung geladen werden. So können auch die älteren Ereignisse analysiert werden. Wenn eine Spaltenüberschrift genommen und auf das Gruppierfeld über der Tabelle losgelassen wird, wird die Überschrift herausgezogen und die Tabelle wird nach dieser Überschrift gruppiert. Wenn man zusätzlich die Strg Taste drückt, whärend des Verschiebens, bleibt die Überschrift in der Tabelle erhalten. Mit dem Mistkübel Icon können alle Systemnachrichten in der Tabellenansicht gelöscht werden. Fehler Nachrichten sind rot gefärbt. Warnungen Nachrichten sind gelb gefärbt. Info Nachrichten sind nicht eingefärbt. Version: 1.0 Seite 31 von 86

32 Link Manager Der NETxLAB Voyager Server kann jetzt die Verwaltung von verlinkten KNX- Gruppenadressen übernehmen. Das Verwalten von verlinkten Gruppenadressen kann jetzt direkt im Voyager Server realisiert werden, und somit können die OPC Clients deutlich entlastet werden. Die Werte der verknüpften Gruppenadressen werden automatisch vom Voyager Server gesetzt und die angeschlossenen OPC Clients darüber informiert. Der Begriff verlinkte Adressen wird an folgendem Beispiel erläutert: Beispiel: Es sind in der ETS zwei Geräte definiert worden, mit den physikalischen Adressen und Die 1/1 und die 10/0 Gruppenadressen sind dem Gerät zugewiesen und die 1/2 und die 10/0 dem Gerät Wird ein 1/1 Telegramm mit dem Wert 1 an KNX verschickt, wird der Wert des Gerätes auf 1 gesetzt. Wird ein 1/2 Telegramm mit dem Wert 2 an KNX verschickt, wird der Wert des Gerätes auf 2 gesetzt. Wird ein 10/0 Telegramm mit dem Wert 3 an KNX verschickt, wird der Wert des Gerätes und des Gerätes auf 3 gesetzt. Die Zellen der Datenbank des NETxLAB Voyager Servers haben aber folgende Werte: 1/1 = 1, 1/2 = 2 und 10/0 = 3 Werden aber die 1/1 und die 1/2 Adressen abgefragt (über KNX Abfrage- Telegramme) wird der Wert 3 zurückgeliefert. In der aktuellen Version des Systems kann definiert werden, dass diese Adressen 1/1 und 1/2 in der Datenbank des Servers automatisch mit dem Wert der Adresse 10/0 aktualisiert werden sollen. Diese Funktionalität kann über die Link-Definitionsdatei erreicht werden. Für das obere Beispiel kann eine Linkdefinition folgendermaßen spezifiziert werden: 10/0;BROADCAST;1/1;1/2 Somit wird definiert, dass wenn sich der Wert der Adresse 10/0 ( Master Link ) ändert, automatisch die Werte der Adressen 1/1 und 1/2 ( Sub Link ) in der Server Datenbank auf den Wert der Adresse 10/0 gesetzt werden - WICHTIG: es werden keine Telegramme mit diesen zwei Adressen versendet. Es werden aber die angeschlossenen OPC Clients über diese Veränderung der OPC Items informiert. Version: 1.0 Seite 32 von 86

33 Der Link-Manager Mechanismus kann nur durch die ankommenden bzw. ausgehenden Telegramme ( WRITE Telegramme) ausgelöst werden. Wird der Wert der Master-Link Adresse durch andere Ereignisse gesetzt (z.b. Set Cell Value Tool im Studio), werden die Werte der Sub-Link Adressen nicht verändert, da der reale Wert (des KNX- Gerätes) sich nicht geändert hat.! Der Link-Manager muss in der System-Konfigurationsdatei des Servers aktiviert werden. Die Systemparameter müssen auf ON gesetzt sein: KNX.SetLinkOnReceive:ON, KNX.SetLinkOnSend:ON. Die Auswirkung kann mit der Angabe gezielter IP-Adressen auf den entsprechenden Bereich beschränkt werden. Beispiel: 10/0; ;1/1;1/2 hier werden nur die Adressen gesetzt, die mit dem Gateway verknüpft sind. Es können bis zu 1000 Sub-Links in einer Zeile definiert werden, da aber ein Master Link in mehreren Zeilen stehen kann, gibt es keine Beschränkung für die Anzahl der Zuweisungen: 10/0; ;1/1;1/2;1/3;1/4 10/0; ;2/1;2/2;2/3;2/4 Mit dieser Definition werden die Werte der Adressen 1/1,1/2,1/3,1/4,2/1,2/2,2/3 und 2/4 automatisch auf den Wert der 10/0 Adresse gesetzt. Eine Bi-direktionale Verknüpfung kann erreicht werden, in dem eine Adresse als Master-Link und als Sub-Link definiert wird: 10/0; ;1/1 1/1; ;10/0 Ändert sich der Wert der Adresse 10/0, wird die Adresse 1/1 auf den gleichen Wert gesetzt. Wird der Wert der Adresse 1/1 geändert und der Wert der Adresse 10/0 wird ebenfalls auf diesen Wert gesetzt. Da diese Änderungen keine realen KNX Telegramme verursachen, kann auch keine unendliche Schleife entstehen. Link Definition Table Diese Tabelle wird aus der nxalinkdefinitions.35.dat Datei herausgelesen, und in dieser Form dem Benutzer zur Verfügung gestellt. Zur Bearbeitung dieser Datei empfiehlt sich das Microsoft Excel Programm (CSV Datei Import). Version: 1.0 Seite 33 von 86

34 Diese Darstellung ermöglicht die Durchführung kleinerer Anpassungen, bzw. das Erweitern der Tabelle, so können auch eventuelle Fehler leichter korrigiert werden. Das Popup-Menü zum Bearbeiten der Tabelle wird über die rechte Maustaste geöffnet. Insert new Definition fügt eine neue Zeile in die Tabelle ein, die mit Link Definitionsdaten ausgefüllt werden kann. Insert new Comment fügt eine Kommentarzeile ein, die mit einem Text versehen werden kann Delete löscht die selektierte Zeile Convert to Definition konvertiert Zeile in eine Link Definition. Convert to Comment konvertiert Zeile in einen Kommentar. Spalte 1 Master Link Die KNX-Gruppenadresse ( Master Link ) deren Wert von den Sub-Link-Adressen übernommen wird. Sie kann mehrmals eingetragen werden. Spalte 2 IP Address Die IP-Adresse des Gateways (Bereiches). Ist hier das BROADCAST Gateway eingegeben, müssen Master Link und alle Sub Links Adressen in der Telegram Definitionsdatei als BROADCAST definiert sein. Nur dann wird die Wertzuweisung auch durchgeführt. Spalte 3 to 1000 Sub Links Die Sub Link KNX-Gruppenadressen. Die Werte dieser Adressen wird von der Master Link Adresse gesetzt.! Die Link-Definitionstabelle kann mit Hilfe des NETxLAB ConvertETS Tools automatisch aus einer (*.esf) ETS Datei erstellt werden. Siehe: NETxLAB ConvertETS Tool. Version: 1.0 Seite 34 von 86

35 Event Processor Der NETxLAB Voyager Server verfügt jetzt über ein neues Sub-System: den Event Processor (Ereignisprozessor). Wie der Name sagt, beschäftigt sich dieses System mit Ereignissen ( Events ). Es gibt drei Arten von Ereignissen, die verwaltet werden: Response Event (die Antwort-Ereignisse) Die Response Events ermöglichen das Realisieren von Router-Funktionalitäten, so können bestimmte KNX-Telegramme automatisch an andere Gateways oder deren Werte an andere Adressen weitergeleitet werden. Sie werden ausgelöst von den ankommenden KNX-Telegrammen. Timer Event (die Schaltuhr-Ereignisse) Die Timer Events sind sehr nützlich um definierte Telegramme zu festgelegten Zeitpunkten zu verschicken. Cyclic Event (die zyklischen Ereignisse) Die zyklischen Events können verwendet werden, um bestimmte Gruppenadressen in definierten Zeitabständen nach den aktuellen Werten abzufragen - (z.b. Stromzähler). Sie werden regelmäßig an KNX versendet, und können als WRITE (Wert setzten) oder als READ (Wert abfragen) Telegramme definiert werden. Alle diese Aufgaben werden unabhängig von den OPC Clients durchgeführt was diese sehr entlastet. Da der Server hauptsächlich für das Datenmanagement konzipiert worden ist, stellen normalerweise diese Aufgaben keine große Belastung für ihn dar. Die OPC Clients werden natürlich über jede Änderung und durchgeführte Aktion informiert, so dass sie auf jeden Fall die aktuellen Daten zur Verfügung haben. Response Event Definition Tabelle Die Response Event Definition Tabelle legt die Antwort-Ereignisse fest. Jede Zeile dieser Datei (ausgenommen die Kommentarzeilen) definiert ein Ereignis. Version: 1.0 Seite 35 von 86

36 Diese Tabelle wird aus der nxaresponeevents.35.dat Datei ( EventFiles Verzeichnis des aktuellen Arbeitsbereiches) herausgelesen, und in dieser Form dem Benutzer zur Verfügung gestellt. Zur Bearbeitung dieser Datei empfiehlt sich das Microsoft Excel Programm (CSV Datei Import). Diese Darstellung ermöglicht die Durchführung kleinerer Anpassungen, bzw. das Erweitern der Tabelle, so können auch eventuelle Fehler leichter korrigiert werden. Das Popup-Menü zum Bearbeiten der Tabelle wird über die rechte Maustaste geöffnet. Insert new Definition fügt eine neue Zeile in die Tabelle ein, die mit Response Event Definitionsdaten ausgefüllt werden kann. Insert new Comment fügt eine Kommentarzeile ein, die mit einem Text versehen werden kann Convert to Definition konvertiert Zeile in eine Response Event Definition. Convert to Comment konvertiert Zeile in einen Kommentar. Delete löscht die selektierte Zeile Spalte 1 Active - Aktivierung Legt fest, ob dieses Ereignis aktiviert ist. Ist der Wert des Feldes auf F ( FALSE Falsch) gesetzt, wird dieses Ereignis nicht berücksichtigt. Spalte 2 Event Name der Name des Events Eine eindeutige Bezeichnung des Ereignisses darf nur einmal vergeben werden. Wird nur für Informationszwecke verwendet. Spalte 3 KNX Group Address to Send die KNX-Gruppenadresse des Telegramms, das als Antwort gesendet wird Wird dieses Ereignis durch ein ankommendes oder ausgehendes Telegramm ausgelöst, versendet der Link-Manager ein KNX-Telegramm an die hier angegebene Adresse. Spalte 4 IP Address to Send die IP-Adresse des Telegramms, das als Antwort gesendet wird Wird dieses Ereignis durch ein ankommendes oder ausgehendes Telegramm ausgelöst versendet der Event-Prozessor ein KNX-Telegramm an die hier angegebene Adresse. Spalte 5 Telegram Type to Send der Typ des Telegramms, das gesendet wird Hier kann die Art des Telegramms festgelegt werden. Zur Auswahl stehen: WRITE (Wert setzen) und READ (Wert abfragen). Ist der Typ auf READ gesetzt, werden die Werte der Spalten Send Received Value und Value to Send nicht berücksichtigt. Spalte 6 Send Received Value Soll der empfangene Wert weiter gegeben werden? In dieser Spalte wird festgelegt, ob ein vordefinierter oder der empfangene Wert an die Zieladresse verschickt wird. Wird der Wert der Spalte auf T ( TRUE Wahr) gesetzt, versendet der Event- Prozessor ein Telegramm mit dem Wert des Telegramms, das dieses Event ausgelöst Version: 1.0 Seite 36 von 86

37 hat, an die Zieladresse. In diesem Fall wird die nächste Spalte der Definition nicht berücksichtigt. Der Wert F ( FALSE Falsch) legt fest, dass der Wert aus der Value to Send Spalte versendet wird. Spalte 7 Value to Send (Optional) der Wert, der verschickt werden soll In dieser Spalte wird der Wert des Telegramms festgelegt. Ist in der Spalte Send Received Value der Wert F gesetzt, wird dieser Wert als KNX-Telegramm an die Zieladresse gesendet. Spalte 8 KNX Group Address to Monitor diese KNX-Gruppenadresse wird überwacht In dieser Spalte wird festgelegt, dass nur Telegramme mit der angegebenen KNX- Gruppenadresse diesen Event auslösen können. Ist hier z.b. die Adresse 1/1 eingetragen, und wird ein KNX-Telegramm mit dieser Adresse empfangen (verschickt), löst das dieses Ereignis aus. Da eine NETxLAB - Adresse immer aus der KNX-Gruppenadresse und der IP- Adresse besteht, wird hier auch die IP-Adresse (Spalte 9) berücksichtigt. Spalte 9 IP Address to Monitor diese IP Adresse wird überwacht Diese Spalte definiert den IP-Adresse -Teil der NETxLAB - Adresse, die überwacht werden soll (siehe: Spalte 8). Spalte 10, 11, 12 Equal Value to Monitor (Optional) Less Value to Monitor (Optional) Greater Value to Monitor (Optional) Die Telegrammwert-Filter Optionen. Die nächsten drei Spalten definieren die Werte, die überwacht werden sollen. Es stehen drei Vergleichsoperationen zur Verfügung: - Equal Value ( Gleicher Wert ) wird ein Telegramm mit genau diesem Wert empfangen, wird dieses Ereignis ausgeführt - Less Value ( Geringerer Wert ) wird ein Telegramm mit kleinerem Wert empfangen, wird dieses Ereignis ausgeführt - Greater Value ( Größerer Wert ) wird ein Telegramm mit größerem Wert empfangen, wird dieses Ereignis ausgeführt Spalte 13 Use Working Time (Optional) Arbeitszeit-Filter verwenden Diese Spalte definiert, ob die Arbeitszeitangaben berücksichtigt werden sollen. Der Wert T legt fest, dass die in den folgenden Spalten definierte Arbeitszeit eingesetzt wird dieses Ereignis wird nur dann ausgeführt, wenn die aktuelle Uhrzeit zwischen Beginn der Arbeitszeit (Spalte 14) und Ende der Arbeitszeit (Spalte 15) liegt. Mit dem Wert F oder wenn dieser Spalte kein Wert zugewiesen wird, ist die Überwachung 24 Stunden am Tag aktiv. Spalte 14 Working Time Begin (Optional) Der Beginn der Arbeitszeit Diese Spalte definiert, ab wann die Arbeitszeit beginnt. Version: 1.0 Seite 37 von 86

38 Spalte 15 Working Time End (Optional) Das Ende der Arbeitszeit Diese Spalte definiert, bis wann die Arbeitszeit gilt. Beispiel: Dieses Ereignis ist zwischen 6:30 (inklusive) und 18:42 (inklusive) aktiv. Spalte 16 Use Calendar (Optional) Jahreskalender-Filter und Wochentag-Filter verwenden Diese Spalte definiert, ob die Jahreskalender- und Wochentagskalender-Filter berücksichtigt werden sollen. Der Wert T legt fest, dass die in den folgenden Spalten definierten Jahreskalender- Filter und Wochentag-Filter eingesetzt werden. Mit dem Wert F oder wenn dieser Spalte kein Wert zugewiesen wird, sind die Filter deaktiviert. Spalte 17 Active Weekdays (Optional) Wochentag-Filter Angaben Diese Spalte legt den Wochentag-Filter fest. Mit diesem Filter kann festgelegt werden, dass dieses Ereignis nur an bestimmten Wochentagen aktiv sein soll. Die Angabe besteht aus sieben Stellen, die jeweils mit F (für FALSE Ereignis nicht aktiv) und T (für TRUE Ereignis aktiv) angegeben werden. Jede Stelle ist für einen Wochentag zuständig. Die Stelle 1 definiert den Filter für Sonntag, Stelle 2 für Montag, bis Stelle 7, die den Filter für Samstag festlegt. Beispiel: FTTTTTF dieser Filter definiert dass dieses Ereignis sonntags und samstags nicht ausgeführt wird. Spalte 18 Month Day Begin (Optional) Der Anfangstag des Jahreskalender-Filters Diese Spalte definiert, ab welchem Tag des Monats (Spalte 19) dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 19. Spalte 19 Month Begin (Optional) Das Anfangsmonat des Jahreskalender-Filters Diese Spalte definiert, ab welchem Monat dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 18. Spalte 20 Month Day End (Optional) Der Endtag des Jahreskalender-Filters Diese Spalte definiert, bis zu welchem Tag des Monats (Spalte 19) dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 21. Spalte 21 Month End (Optional) Das Endmonat des Jahreskalender-Filters Diese Spalte definiert, bis zu welchem Monat dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 20. Version: 1.0 Seite 38 von 86

39 Beispiel: Dieses Ereignis wird jeweils Montag bis Freitag von 10. Januar (inklusive) bis 15. Januar (inklusive) aktiv sein. Spalten Path, Extended Data 1-3 Diese Spalten sind nur für interne Zwecke. Timer Event Definitions Tabelle Die Timer Event Definition Tabelle legt die Zeituhr-Ereignisse fest. Jede Zeile dieser Datei (ausgenommen die Kommentarzeilen) definiert ein Ereignis. Diese Tabelle wird aus der nxatimerevents.35.dat Datei ( EventFiles Verzeichnis des aktuellen Arbeitsbereiches) herausgelesen, und in dieser Form dem Benutzer zur Verfügung gestellt. Zur Bearbeitung dieser Datei empfiehlt sich das Microsoft Excel Programm (CSV Datei Import). Diese Darstellung ermöglicht die Durchführung kleinerer Anpassungen, bzw. das Erweitern der Tabelle, so können auch eventuelle Fehler leichter korrigiert werden. Das Popup-Menü zum Bearbeiten der Tabelle wird über die rechte Maustaste geöffnet. Insert new Definition fügt eine neue Zeile in die Tabelle ein, die mit Timer Event Definitionsdaten ausgefüllt werden kann. Insert new Comment fügt eine Kommentarzeile ein, die mit einem Text versehen werden kann Convert to Definition konvertiert Zeile in eine Timer Event Definition. Convert to Comment konvertiert Zeile in einen Kommentar. Delete löscht die selektierte Zeile Version: 1.0 Seite 39 von 86

40 Spalte 1 Active - Aktivierung Legt fest, ob dieses Ereignis aktiviert ist. Ist der Wert des Feldes auf F ( FALSE Falsch) gesetzt, wird dieses Ereignis nicht in die globale Ereignistabelle des Servers geladen. Spalte 2 Event Name der Name des Events Eine eindeutige Bezeichnung des Ereignisses darf nur einmal vergeben werden. Wird nur für Informationszwecke verwendet. Spalte 3 KNX Group Address to Send die KNX-Gruppenadresse des Telegramms, das gesendet werden soll. Der Link-Manager versendet zyklisch ein KNX-Telegramm an die hier angegebene Adresse. Spalte 4 IP Address to Send die IP-Adresse des Telegramms, das gesendet werden soll. Der Link-Manager versendet ein KNX-Telegramm an die hier angegebene IP- Adresse. Spalte 5 Telegram Type to Send der Typ des Telegramms, das gesendet werden soll Hier kann die Art des Telegramms festgelegt werden. Zur Auswahl stehen: WRITE (Wert setzen) und READ (Wert abfragen). Ist der Typ auf READ gesetzt, wird der Wert der nächsten Spalte ( Value to Send ) nicht berücksichtigt. Spalte 6 Value to Send der Wert, der verschickt werden soll In dieser Spalte wird der Wert des Antwort-Telegramms festgelegt. Spalte 7 Time Point to Send at der Zeitpunkt, in dem das Telegramm verschickt wird. Zu diesem Zeitpunkt wird das Ereignis ausgeführt was im Versenden eines Telegramms resultiert. Spalte 8 Use Calendar (Optional) Jahreskalender-Filter und Wochentag-Filter verwenden Diese Spalte definiert, ob Jahreskalender- und Wochentagskalender-Filter berücksichtigt werden sollen. Der Wert T legt fest, dass die in den folgenden Spalten definierten Jahreskalender- Filter und Wochentag-Filter eingesetzt werden. Mit dem Wert F oder wenn dieser Spalte kein Wert zugewiesen wird, sind die Filter deaktiviert. Spalte 9 Active Weekdays (Optional) Wochentag-Filter Angaben Diese Spalte legt den Wochentag-Filter fest. Mit diesem Filter kann festgelegt werden, dass dieses Ereignis nur an bestimmten Wochentagen aktiv sein soll. Die Angabe besteht aus sieben Stellen, die jeweils mit F (für FALSE Ereignis nicht aktiv) und T (für TRUE Ereignis aktiv) angegeben werden. Jede Stelle ist für einen Wochentag zuständig. Die Stelle 1 definiert den Filter für Sonntag, Stelle 2 für Montag, bis Stelle 7, die den Filter für Samstag festlegt. Version: 1.0 Seite 40 von 86

41 Beispiel: FTTTTTF dieser Filter definiert dass dieses Ereignis sonntags und samstags nicht ausgeführt wird. Spalte 10 Month Day Begin (Optional) Der Anfangstag des Jahreskalender-Filters Diese Spalte definiert, ab welchem Tag des Monats (Spalte 11) dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 11. Spalte 11 Month Begin (Optional) Das Anfangsmonat des Jahreskalender-Filters Diese Spalte definiert, ab welchem Monat dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 9. Spalte 12 Month Day End (Optional) Der Endtag des Jahreskalender-Filters Diese Spalte definiert, bis zu welchem Tag des Monats dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 13. Spalte 13 Month End (Optional) Das Endmonat des Jahreskalender-Filters Diese Spalte definiert, bis zu welchem Monat dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 12. Beispiel: Dieses Ereignis wird jeweils Montag bis Freitag von 10. Januar (inklusive) bis 15. Januar (inklusive) aktiv sein. Cyclic Event Definition Tabelle Die Cyclic Event Definition Tabelle legt die zyklischen Ereignisse des Systems fest. Jede Zeile dieser Datei (ausgenommen die Kommentarzeilen) definiert ein Ereignis. Diese Tabelle wird aus der nxatimerevents.35.dat Datei ( EventFiles Verzeichnis des aktuellen Arbeitsbereiches) herausgelesen, und in dieser Form dem Benutzer zur Verfügung gestellt. Zur Bearbeitung dieser Datei empfiehlt sich das Microsoft Excel Programm (CSV Datei Import). Diese Darstellung ermöglicht die Durchführung kleinerer Anpassungen, bzw. das Erweitern der Tabelle, so können auch eventuelle Fehler leichter korrigiert werden. Das Popup-Menü zum Bearbeiten der Tabelle wird über die rechte Maustaste geöffnet. Version: 1.0 Seite 41 von 86

42 Insert new Definition fügt eine neue Zeile in die Tabelle ein, die mit zyklischen Event Definitionsdaten ausgefüllt werden kann. Insert new Comment fügt eine Kommentarzeile ein, die mit einem Text versehen werden kann Convert to Definition konvertiert Zeile in eine zyklische Event Definition. Convert to Comment konvertiert Zeile in einen Kommentar. Delete löscht die selektierte Zeile Spalte 1 Active - Aktivierung Legt fest, ob dieses Ereignis aktiviert ist. Ist der Wert des Feldes auf F ( FALSE Falsch) gesetzt, wird dieses Ereignis nicht in die globale Ereignistabelle des Servers geladen. Spalte 2 Event Name der Name des Events Eine eindeutige Bezeichnung des Ereignisses darf nur einmal vergeben werden. Wird nur für Informationszwecke verwendet. Spalte 3 KNX Group Address to Send die KNX Gruppenadresse des Telegramms, das gesendet werden soll Der Link-Manager versendet zyklisch, in definierten Zeitabständen ein KNX- Telegramm an die hier angegebene Adresse. Spalte 4 IP Address to Send die IP-Adresse des Telegramms, das gesendet werden soll Der Link-Manager versendet zyklisch, in definierten Zeitabständen ein KNX- Telegramm an die hier angegebene IP-Adresse. Spalte 5 Telegram Type to Send der Typ des Telegramms, das gesendet werden soll Hier kann die Art des Telegramms festgelegt werden. Zur Auswahl stehen: WRITE (Wert setzen) und READ (Wert abfragen). Ist der Typ auf READ gesetzt, wird der Wert der nächsten Spalte ( Value to Send ) nicht berücksichtigt. Spalte 6 Value to Send der Wert, der verschickt werden soll In dieser Spalte wird der Wert des Antwort-Telegramms festgelegt. Ist in der Spalte Send Received Value der Wert F gesetzt, wird dieser Wert als KNX-Telegramm an die Zieladresse gesendet. Spalte 7 Time Interval der Zeitabstand zwischen den Telegrammen In diesem Zeitabstand (Intervall) werden die Ereignisse zyklisch ausgeführt. Spalte 8 Use Working Time (Optional) Arbeitszeit-Filter verwenden Diese Spalte definiert, ob die Arbeitszeitangaben berücksichtigt werden sollen. Der Wert T legt fest, dass die in den folgenden Spalten definierte Arbeitszeit eingesetzt wird dieses Ereignis wird nur dann ausgeführt, wenn die aktuelle Uhrzeit zwischen Beginn der Arbeitszeit (Spalte 9) und Ende der Arbeitszeit (Spalte 10) liegt. Version: 1.0 Seite 42 von 86

43 Mit dem Wert F oder wenn dieser Spalte kein Wert zugewiesen wird, ist die Überwachung 24 Stunden am Tag aktiv. Spalte 9 Working Time Begin (Optional) Der Beginn der Arbeitszeit Diese Spalte definiert, ab wann die Arbeitszeit beginnt. Spalte 10 Working Time End (Optional) Das Ende der Arbeitszeit Diese Spalte definiert, bis wann die Arbeitszeit gilt. Beispiel: Dieses Ereignis wird zwischen 6:30 (inklusive) und 18:42 (inklusive) aktiv. Spalte 11 Use Calendar (Optional) Jahreskalender-Filter und Wochentag-Filter verwenden Diese Spalte definiert, ob der Jahreskalender- und Wochentagskalender-Filter berücksichtigt werden sollen. Der Wert T legt fest, dass die in den folgenden Spalten definierten Jahreskalender- Filter und Wochentag-Filter eingesetzt werden. Mit dem Wert F oder wenn dieser Spalte kein Wert zugewiesen wird, sind die Filter deaktiviert. Spalte 12 Active Weekdays (Optional) Wochentag-Filter Angaben Diese Spalte legt den Wochentag-Filter fest. Mit diesem Filter kann festgelegt werden, dass dieses Ereignis nur an bestimmten Wochentagen aktiv sein soll. Die Angabe besteht aus sieben Stellen, die jeweils mit F (für FALSE Ereignis nicht aktiv) und T (für TRUE Ereignis aktiv) angegeben werden. Jede Stelle ist für einen Wochentag zuständig. Die Stelle 1 definiert den Filter für Sonntag, Stelle 2 für Montag, bis Stelle 7, die den Filter für Samstag festlegt. Beispiel: FTTTTTF dieser Filter definiert dass dieses Ereignis sonntags und samstags nicht ausgeführt wird. Spalte 13 Month Day Begin (Optional) Der Anfangstag des Jahreskalender-Filters Diese Spalte definiert, ab welchem Tag des Monats (Spalte 14) dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 14. Spalte 14 Month Begin (Optional) Das Anfangsmonat des Jahreskalender-Filters Diese Spalte definiert, ab welchem Monat dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 13. Spalte 15 Month Day End (Optional) Der Endtag des Jahreskalender-Filters Diese Spalte definiert, bis zu welchem Tag des Monats dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 16. Version: 1.0 Seite 43 von 86

44 Spalte 16 Month End (Optional) Das Endmonat des Jahreskalender-Filters Diese Spalte definiert, bis zu welchem Monat dieses Ereignis aktiv ist. Gilt nur gemeinsam mit dem Wert der Spalte 15. Beispiel: Dieses Ereignis wird jeweils Montag bis Freitag von 10. Januar (inklusive) bis 15. Januar (inklusive) aktiv sein. Spalten Path, Extended Data 1-3 Diese Spalten sind nur für interne Zwecke. Version: 1.0 Seite 44 von 86

45 Info desk In den beiden Info-Bereichen des Studios wird dem Benutzer eine Reihe von Informationen zur Verfügung gestellt. Der erste Bereich befindet sich im oberen Teil der Studio-Oberfläche. Es wird rot, wenn ein Fehler vom NETxLAB Voyager Server gemeldet wird. Send Interval Der aktuelle Wert (in Millisekunden) des Abstandes, in welchem Telegramme an ein Gateway versendet werden Last Cell Set Die Adresse und der Wert der zuletzt gesetzten Zelle in der Form: <IP Adresse> #<Wert> oder <IP Adresse> # <Wert> Telegrams Received Die Anzahl der empfangenen Telegramme seit der letzten Initialisierung des Servers Telegrams Sent Die Anzahl der gesendeten Telegramme seit der letzten Initialisierung des Servers Status Der aktuelle Status des Servers: Running gestartet Stopped gestoppt Start Date/Time Der Zeitpunkt zu welchem der Server zuletzt gestartet worden ist Mode Zeigt den Ausführungsmodus: ONLINE OFFLINE SIMULATION Version: 1.0 Seite 45 von 86

46 und den Namen des Workspaces. N-Mesh Mode Zeigt den N-Mesh Mode Stand Alone Server Main Server Backup Server und ob der Server aktiv oder passiv ist. Date/Time Die aktuelle Uhrzeit und Datum Version: 1.0 Seite 46 von 86

47 Server Der Server hat die Aufgabe, nicht nur alle empfangenen und gesendeten Telegramme auf optimale Weise zu verwalten, sondern auch die gesamte Anlage ständig auf eventuelle Probleme zu untersuchen und solche, sollten sie auftreten, sofort zu behandeln. Diese Applikation kann entweder als Dienst oder aber als normaler COM-Server installiert werden. Das virtuelle Modell der Anlage wird ständig auf der Festplatte gespeichert, sollte der Server neu gestartet werden, wird automatisch der zuletzt gespeicherte Stand des Modells geladen. Sollte sich ein Gateway vom Hauptserver trennen und wiederverbinden, werden die aktuellen Werte aller definierten KNX-Geräte vom System herausgelesen. So wird gewährleistet, dass der aktuelle Stand der Anlage vollständig in dem virtuellen Model abgebildet ist. Alle Telegramme werden für eventuelle Systemanalysen in einem Ringspeicher ebenfalls auf der Festplatte gesichert.! Es werden keine Telegramme an Gateways im OFFLINE-Status weitergeleitet. Arbeitsweise Dienst/Server Der Unterschied zwischen den beiden Installationsvarianten ist, dass der Dienst automatisch beim Computerstart mitgestartet wird und kein Benutzer auf dem System angemeldet sein muss. Die normale COM-Server Variante wird nicht automatisch gestartet, erst dann, wenn ein OPC Client oder das Studio eine Verbindung zu diesem aufbaut. Die Varianten können auch nach erfolgter Installation gewechselt werden. Server als COM-Server registrieren (im NETxLAB System Verzeichnis ausführen): NETxLAB unregserver und dann: NETxLAB regserver Server als Dienst registrieren (im NETxLAB System Verzeichnis ausführen): NETxLAB unregserver und dann: NETxLAB service Ist der Server als Dienst erfolgreich installiert, wird er in der Diensttabelle unter dem Namen [NXA] NETxLAB.Voyager.Server.1.0. Version: 1.0 Seite 47 von 86

48 Konfiguration Verzeichnisse Die Konfiguration des NETxLAB Voyager Server 1.0 wird beim Starten aus den Konfigurationsdateien herausgelesen. Alle diese Dateien befinden sich in den Unterverzeichnissen des Systems Folgende Verzeichnisse werden bei der Installation erstellt: Das Systemverzeichnis: <Programme>\NETxAutomation\ NETxLAB.Voyager.Server.1.0.KNX hier werden die Applikationsdateien installiert Die Unterverzeichnisse: <NXA_System>\Workspaces\<CurrentWorkspace>\ConfigFiles alle Konfigurationsdateien <NXA_System>\Workspaces\<CurrentWorkspace>\DataFiles Die Telegrammdefinitionsdatei <NXA_System>\Workspaces\<CurrentWorkspace>\EventFiles Alle Event-Definitionsdateien <NXA_System>\Workspaces\<CurrentWorkspace>\LogFiles Alle LOG-Dateien s <NXA_System>\Drivers nur bei Hardlock-Schutz Version vorhanden Version: 1.0 Seite 48 von 86

49 Router configuration: nxaopcrouter.35.cfg Diese Datei beinhaltet die Konfigurationsparameter des Gateway-Treibers. Parametername: UDP.ReceiveOwnTelegrams Gültigkeitsbereich: <ON/OFF> Default Wert: OFF ON legt fest, dass die Telegramme mit lokaler IP-Adresse angenommen werden OFF die lokalen Telegramme werden ignoriert Parametername: UDP.ReceiveBroadcastTelegrams Gültigkeitsbereich: <ON/OFF> Default Wert: ON ON legt fest, dass die BROADCAST -Telegramme angenommen werden OFF die BROADCAST -Telegramme werden ignoriert Wichtig: Das Empfangen von BROADCAST -Telegrammen: Ist eine KNX-Gruppenadresse nur dem BROADCAST -Gateway zugeordnet, werden alle Telegramme mit dieser KNX-Adresse, die von definierten Gateways kommen (!) als BROADCAST -Telegramme interpretiert. Ist aber diese KNX-Gruppenadresse auch noch zu einem anderen Gateway zugeordnet (z.b.: ) und kommt ein Telegramm mit dieser KNX-Adresse von diesem Gateway, wird das Telegramm als Gateway Telegramm interpretiert. Parametername: UDP.SendBroadcastAsMultipleUnicast Gültigkeitsbereich: <ON/OFF> Default-Wert: OFF Legt fest, ob die als BROADCAST definierten Telegramme tatsächlich als IP Broadcast Pakete verschickt werden, oder als Unicast an jedes Gateway einzeln. Parametername: UDP.NetworkCardIPAddress Gültigkeitsbereich: IP Adresse Default-Wert: Keine Legt die Netzwerkkarte fest, über welche die KNX Telegramme versendet und empfangen werden sollen. Version: 1.0 Seite 49 von 86

50 Die Netzwerkkarte wird durch die IP Adresse spezifiziert. Wird keine IP Adresse definiert, werden die gültigen Netzwerkkarten vom System automatisch ermittelt. Für eibnode: Für IG/S 1.1: Parametername: eibnode.sendernetid Gültigkeitsbereich: von 0 bis 255 Default Wert: 0 Legt das NetID für die ausgehenden Telegramme fest. Parametername: eibnode.receivernetidfilter Gültigkeitsbereich: eine Liste von 0 bis 255 Werten mit Komma getrennt (z.b.: 1,2,33,4) Default value: <leer> Legt die NetIDs von Telegrammen, die angenommen werden sollen, fest. Ist der Parameter nicht gesetzt, werden alle Telegramme angenommen. Beispiel: eibnode_receivernetidfilter: 0,2,3,7 Es werden nur die Telegramme angenommen, die die NetID 0,2,3, oder 7 haben. Parametername: IGS.ReceiveMulticastAddress Gültigkeitsbereich: IP Adresse Default Wert: Definiert die Multicastgruppe (Multicast-IP Adresse) des Projektes. Für KNX NETIP: Parametername: NETIP.NetworkCardIPAddress Gültigkeitsbereich: IP Adresse Default-Wert: Keine Legt die Netzwerkkarte fest, über welche die KNX NETIP Telegramme versendet und empfangen werden sollen. Version: 1.0 Seite 50 von 86

51 Parametername: NETIP.NAT Scope: <ON/OFF> Default Wert: OFF ON sollte benutzt werden, wenn ein NAT Router oder Firewall zwischen IP Gateway und NETxLAB.Voyager.Server.1.0.KNX Server ist. OFF der Default Wert Für Direct(KNX) Version: Parametername: Falcon.ConfirmedConnection Gültigkeitsbereich: <On/OFF> Default-Wert: OFF Wenn die Verbindung zum KNX Interface nicht funktioniert, versuchen Sie die Confirmed Connection auf ON zu setzen. Version: 1.0 Seite 51 von 86

52 System configuration: nxaopcsystem.35.cfg Hier werden die für den NETxLAB Server relevanten Parameter festgelegt. Die Parameter, die in dieser Datei definiert werden können, sind in drei Gruppen aufgeteilt: OPC KNX SYSTEM Jeder dieser Parameter wird mit einem Namen identifiziert. Der Name ist nicht casesensitiv (Klein- Großschreibung wird nicht berücksichtigt). Der Gültigkeitsbereich sowie auch der Default-Wert sind im System für jeden Parameter festgelegt, und werden in der Initialisierungsphase mitberücksichtigt. Die OPC- Parametergruppe: Parametername: OPC.GroupAddressType Gültigkeitsbereich: 2level,3level Default-Wert: 3level legt fest, wie die OPC ItemIDs aufgebaut werden. 2Level definiert, dass die ITEM ID den log. KNX Adressen-Teil zweistufig darstellt 3Level oder als dreistufig ACHTUNG: im Gegenteil zu dem im Studio definierbaren Parameter, hat dieser einen entscheidenden Einfluss auf den Aufbau aller OPC ITEM ID. Beispiel: Der gleiche Datenpunkt: OPC_GroupAddressType: 2Level -> ITEM ID = \NETxKNX\ \00/0513 OPC_GroupAddressType: 3Level -> ITEM ID = \NETxKNX\ \00/2/001 Parametername: OPC.PrefixedItemID Gültigkeitsbereich: ON,OFF Default-Wert: ON legt fest, ob die führenden 0 -Zeichen im OPC ITEM ID beigefügt werden sollen. ON definiert, dass die ITEM ID den log. KNX-Adressen-Teil mit führenden 0 - Zeichen darstellen OFF definiert, dass die ITEM ID den log. KNX-Adressen-Teil ohne führende 0 - Zeichen darstellen Version: 1.0 Seite 52 von 86

53 ACHTUNG: Dieser Parameter hat entscheidenden Einfluss auf den Aufbau aller OPC ITEM ID. Beispiel: Der gleiche Datenpunkt: OPC_PrefixedItemID: ON -> ITEM ID = \NETxKNX\ \00/2/001 OPC_PrefixedItemID: OFF -> ITEM ID = \NETxKNX\ \0/2/1 Parametername: OPC.AsyncTimeout Gültigkeitsbereich: von 1 bis 60 Default-Wert: 5 Einheit: Sekunden Legt den Timeout -Wert für die asynchronen OPC Abfragen fest. Kommt innerhalb dieser Zeit keine Antwort auf die OPC Anfrage, wird die Qualität aller abgefragten Datenpunkte auf nicht definiert ( UNCERTAIN ) gesetzt. Parametername: OPC.AsyncReadFromDevice Gültigkeitsbereich: ON,OFF Default-Wert: OFF Legt fest, ob die asynchronen OPC Wert-Lesen Abfragen ( READ ) mit Daten aus der Datenbank, oder über eine Abfrage des Wertes bei dem zugehörigen KNX-Gerät beantwortet werden sollen. ON es werden die KNX-Geräte abgefragt OFF die Werte werden aus der NETxLAB Voyager Server Datenbank gelesen Parametername: OPC.AsyncRefreshFromDevice Gültigkeitsbereich: ON,OFF Default-Wert: OFF Legt fest, ob die asynchronen OPC Wert-Aktualisieren Abfragen ( REFRESH ) mit Daten aus der Datenbank, oder über eine Abfrage des Wertes bei dem zugehörigen KNX-Gerät beantwortet werden sollen. ON es werden die KNX-Geräte abgefragt OFF die Werte werden aus der NETxLAB Voyager Server Datenbank gelesen Version: 1.0 Seite 53 von 86

54 Parametername: OPC.ShowETSStructure Gültigkeitsbereich: ON,OFF Default Wert: OFF Es legt fest, ob eine ETS ähnliche Struktur im Item Baum gezeigt werden soll. ON zeigt eine ETS ähnliche Struktur im Item Baum OFF zeigt eine NxA ähnliche Struktur im Item Baum Parametername: OPC.QualityForValueNotSet Gültigkeitsbereich: UNCERTAIN,BAD,NOT_CONNECTED Default Wert: UNCERTAIN Es legt fest, welche OPC Quality Wert für ungesetzte Werte beim OPC Item gezeigt werden soll. Parametername: OPC.Delimiter Gültigkeitsbereich: eine Zeichenkette, die keine Anführungszeichen haben soll Default Wert: \ Es legt fest, welches Begrenzungszeichen für OPC Item ID Struktur verwendet werden soll. Folgende OPC Parameters sind nur aus Kompatibilitätsgründen verfügbar. In zukünftigen Versionen könnten diese entfernt werden. Parametername: OPC.AsyncWriteConfirmation Gültigkeitsbereich: ON,OFF Default-Wert: OFF Legt fest, ob die asynchronen OPC Wert-Schreiben Befehle ( WRITE ) mit einer Abfrage des Wertes bei dem zugehörigen KNX-Gerät bestätigt werden sollen. ON es werden die KNX-Geräte abgefragt OFF keine Abfrage ACHTUNG: wird der Parameter auf ON gesetzt, wird jeder Schreiben Befehl mit bis zu drei KNX-Telegrammen abgearbeitet. Die Telegrammmenge wird ggf. verdreifacht. Parametername: OPC.RefreshOnEqualValue Gültigkeitsbereich: ON,OFF Default-Wert: ON Legt fest, ob die OnDataChange Ereignisse durch KNX Telegramme mit unveränderten Werten generiert werden. ON es werden die OnDataChange Ereignisse generiert OFF die OnDataChange Ereignisse werden nur bei Wertänderungen generiert Version: 1.0 Seite 54 von 86

55 Beispiel: Empfängt der Voyager Server zwei KNX Telegramme mit gleichem Wert und gleicher Adresse (IP + log. KNX Adresse) und ist die Option OPC.RefreshOnEqualValue auf OFF gesetzt, wird das OnDataChange Ereignis nur für das erste Telegramm generiert, da das zweite Telegramm keine Wertänderungen des Datenpunktes verursacht. Ist diese Option auf ON gesetzt, so werden zwei OnDataChange Ereignisse generiert. Die KNX- Parametergruppe: Parametername: KNX.ServerPhysicalAddress Gültigkeitsbereich: von bis Default-Wert: Legt die physikalische KNX Adresse des Voyager Servers fest. Diese Adresse wird bei den ausgehenden KNX Telegrammen eingetragen. Parametername: KNX.Timeout Gültigkeitsbereich: von 2 bis 60 Default-Wert: 10 Einheit: Sekunden Legt den Timeout -Wert für die System-internen Wert-Lesen KNX-Geräte Abfragen fest. Dieser Wert wird von NETxLAB EventEngine Subsystem für die READ Events und die Wertabfragen in der Initialisierungsphase des Systems verwendet. Parametername: KNX.PhysicalDeviceTimeout Gültigkeitsbereich: von 1 bis 600 Default Wert: 30 Einheit: Sekunden Es legt den Timeout -Wert für die KNX Gerätecheck Telegramme fest. Dieser Wert wird vom " NETxLAB Device Manager" Subsystem verwendet. Parametername: KNX.CyclicEventStartDelay Gültigkeitsbereich: von 10 bis 600 Default Wert: 30 Einheit: Sekunden Es definiert die Startverzögerung für zyklische Events (in Sekunden). Dieser Wert wird vom " NETxLAB Cyclic Event Manager" Subsystem verwendet. Parametername: KNX.CyclicEventTelegramGap Gültigkeitsbereich: von 100 bis 3000 Version: 1.0 Seite 55 von 86

56 Default Wert: 250 Einheit: Millisekunden Es definiert den Zeitabstand zwischen zyklischen Events (in Millisekunden). Wert wird vom " NETxLAB Cyclic Event Manager" Subsystem verwendet. Parametername: KNX.SetLinkOnReceive Gültigkeitsbereich: ON,OFF Default Wert: OFF Das Link-Manager Subsystem des NETxLAB Voyager Servers ermöglicht das Mitverwalten von verlinkten KNX-Gruppenadressen. Dieser Parameter legt fest, ob der Mechanismus von ankommenden KNX-Telegrammen ausgelöst werden soll. ON setzt die verlinkten KNX-Gruppenadressen beim Empfangen von KNX- Telegrammen OFF nicht aktiviert Parametername: KNX.SetLinkOnSend Gültigkeitsbereich: ON,OFF Default-Wert: OFF Das Link-Manager Subsystem des NETxLAB Voyager Servers ermöglicht das Mitverwalten von verlinkten KNX-Gruppenadressen. Dieser Parameter legt fest, ob der Mechanismus von gesendeten KNX-Telegrammen ausgelöst werden soll. ON setzt die verlinkten KNX-Gruppenadressen beim Senden von KNX- Telegrammen OFF nicht aktiviert Parametername: KNX.ShowUndefinedTelegrams Gültigkeitsbereich: ON,OFF Default Wert: OFF Alle undefinierten, ankommenden KNX Telegramme werden im Voyager Studio System Messages Fenster gezeigt. ON zeigt undefinierte KNX Telegramme OFF nicht aktiviert. Folgende KNX Parameters sind nur aus Kompatibilitätsgründen verfügbar. In zukünftigen Versionen könnten diese entfernt werden. Parametername: KNX.RefreshAllValuesOnConnect Gültigkeitsbereich: ON,OFF Default-Wert: OFF Version: 1.0 Seite 56 von 86

57 Verbindet sich ein Gateway zum Server, kann der Server alle Datenpunkte (KNX- Geräte), die für dieses Gateway definiert worden sind, nach den aktuellen Werten abfragen. ON es werden die KNX-Geräte abgefragt OFF keine Abfrage Parametername: KNX.CyclicRefreshAllValues Gültigkeitsbereich: ON,OFF Default value: OFF In der Version 3.0 ist es möglich das System das Aktualisieren der internen Datenbank in definierten Zeitabständen automatisch durchführen zu lassen. Die Updates werden über zyklische READ -KNX-Telegramme realisiert, was natürlich in der max. Belastbarkeit des KNX-Systems berücksichtigen werden muss. Die Konfiguration dieses Subsystems wird mit Hilfe einiger, hier aufgelisteten Parameter realisiert. ON das automatische Aktualisieren ist aktiviert OFF nicht aktiviert Parametername: KNX.CyclicRefreshAllValuesInterval Gültigkeitsbereich: von 5 bis Default-Wert: 10 Einheit: Sekunden Legt fest, in welchen Zeitabständen der Wertabfrage-Prozess gestartet werden soll. Hier muss berücksichtigt werden, dass alle definierten Datenpunkte abgefragt werden. Also je mehr Datenpunkte in einem Update-Prozess abgefragt werden sollen, desto größer muss dieser Wert sein. Wird der Wert zu klein festgelegt, kann das dazu führen, dass sich zwei Update-Prozesse zeitlich überschneiden. Beispiel: Es sind 10 Datenpunkte für Gateway definiert. Das globale System-Sende-Intervall ist auf 1 Sekunde gesetzt worden ( send interval kann nur im Voyager Studio gesetzt werden). D.h.: Ein Update-Prozess dauert in diesem Fall 10 Sekunden. Ist der KNX.CyclicRefreshAllValuesInterval -Parameter auf 5 Sekunden gesetzt, startet der nächste Update-Prozess schon nach 5 Sekunden und versucht die Abfragetelegramme zu senden. Da sie aber nicht sofort verschickt werden können (da ja die Telegramme vom Prozess 1 gerade verschickt werden) bleiben diese in der Warteschlange des Servers stehen. Hier muss auch der KNX.CyclicRefreshAllValuesInterval -Parameter berücksichtigt werden. Parametername: KNX.CyclicRefreshAllValuesStartDelay Gültigkeitsbereich: von 10 bis 600 Default-Wert: 60 Einheit: Sekunden Version: 1.0 Seite 57 von 86

58 Legt fest, in welchem Zeitabstand nach der Initialisierung des Servers, der erste Abfrage-Prozess gestartet werden soll. Parametername: KNX.CyclicRefreshAllValuesTelegramGap Gültigkeitsbereich: von 100 bis 3000 Default-Wert: 250 Einheit: Millisekunden Legt fest, in welchem Zeitabstand die einzelnen Abfrage-Telegramme eines Update- Prozesses verschickt werden sollen. Dieser Wert muss größer sein als der Wert des globalen System Sende-Intervalls ( send interval ). Die SYSTEM-Parametergruppe: Parametername: SYS.UseTelegramDataFile Gültigkeitsbereich: ON,OFF Default-Wert: ON Legt fest, ob zur Laufzeit das virtuelle Abbild der Anlage (die Werte aller definierten Datenpunkte) erstellt und auf der Festplatte geschrieben werden soll. Parametername: SYS.MaxSizeOfTelegramLogFile Gültigkeitsbereich: von 1 bis 1000 Default-Wert: 10 Einheit: Megabyte Legt die Größe der Telegramm-Protokolldatei fest. Parametername: SYS.EnableDeviceManager Gültigkeitsbereich: ON,OFF Default Wert: ON Es aktiviert das physikalische KNX Geräte Management. Parametername: SYS.GenerateRandomValues Gültigkeitsbereich: ON,OFF Default Wert: ON Es generiert Zufallswerte für die OPC Items im Simulationsmodus. Folgende System Parameters sind nur aus Kompatibilitätsgründen verfügbar. In zukünftigen Versionen könnten diese entfernt werden. Parametername: SYS.GatewayConnectionTimeout Gültigkeitsbereich: von 10 bis Version: 1.0 Seite 58 von 86

59 Default-Wert: 500 Einheit: Millisekunden Legt den Timeout-Wert für die Verbindungsüberprüfung der angeschlossenen IP- Gateways fest. Parametername: SYS.GatewayConnectionTimeoutAttemptCount Gültigkeitsbereich: von 1 bis 10 Default-Wert: 3 Legt die Anzahl der Verbindungsversuche für die Verbindungsüberprüfung der angeschlossenen IP-Gateways im Falle einer Unterbrechung fest. Die Database- Parametergruppe: Diese Parameter werden nur verwendet, wenn das Erweiterungsmodul Microsoft SQL Datenbank Interface lizenziert wurde. Parametername: DB.Enabled: Gültigkeitsbereich: ON,OFF Default Wert: OFF Es schaltet des Erweiterungsmodul Microsoft SQL Datenbank Interface ein. Parametername: DB.User: Gültigkeitsbereich: Zeichenkette Default Wert: Es definiert den Datenbank User Namen. Parametername: DB.UserPassword: Gültigkeitsbereich: Zeichenkette Default Wert: Es definiert das Datenbank User Passwort. Parametername: DB.ODBC: Gültigkeitsbereich: Zeichenkette Default Wert: Es definiert den Namen der ODBC Verbindung, die verwendet werden soll, um sich mit der Datenbank zu verbinden. Parametername: DB.Database: Gültigkeitsbereich: Zeichenkette Default Wert: Version: 1.0 Seite 59 von 86

60 Es definiert den Datenbanknamen. Parametername: DB.Table: Gültigkeitsbereich: Zeichenkette Default Wert: Es definiert den Namen der Datenbanktabelle. Parametername: DB.ExpireAfterDays: Gültigkeitsbereich: von 0 bis 600 Default Wert: 0 Die älteren Daten werden automatisch aus der Datenbank gelöscht. Version: 1.0 Seite 60 von 86

61 Telegram Definitionen: nxatelegramdefinitions.35.dat Die wichtigste Datei des Systems ist die Telegrammdefinitionsdatei. Hier werden alle für das System relevanten Telegramme festgelegt. Der Aufbau der Datei: 'Syntax of the Telegram Definition Table: 'log.knx Address;IP Address;Priority;Data Size;EIS Type;Signed/Unsigned;Unit;Description;Path;Control Data;Alias;Read on Reconnect;Read Cyclically Interval;Extended Data ' 1/0;BROADCAST;LOW;1BIT;EIS1;;;Telegram Demo EIS1;;;;F;0; 2/0;BROADCAST;LOW;4BIT;EIS2;;;Telegram Demo EIS2;;;;F;0; 3/0;BROADCAST;LOW;3BYTE;EIS3;;;Telegram Demo EIS4;;;;F;0; 4/0;BROADCAST;LOW;3BYTE;EIS4;;;Telegram Demo EIS4;;;;F;0; 5/1;BROADCAST;LOW;2BYTE;EIS5;; C;Telegram Demo EIS5 1;;;;F;0; 5/21;BROADCAST;LOW;2BYTE;EIS5;;mA;Telegram Demo EIS5 2;;;;F;0; 6/1; ;LOW;1BYTE;EIS6;;%;Telegram Demo EIS6 1 14/1; ;LOW;1BIT;EIS1;;;Telegram Demo EIS1 2 Jede Zeile, ausgenommen sind die Kommentarzeilen ( ), definiert ein Telegramm. Spalte 1 - log. KNX Address Die logische KNX-Adresse des Telegramms. Sie kann in beiden Darstellungsvarianten angegeben werden: z.b.: dreistufig: 0/2/1 oder zweistufig: 0/513, beide werden anerkannt Spalte 2 - IP Address Die IP-Adresse des Gateways, das dieses Telegramm empfangen oder senden kann. Diese beiden Spalten definieren die reale Adresse (wird vom NxA System intern verwendet) des Telegramms. Das System lässt mehrere Telegram Definitionen (up to 1000) mit derselben log. KNX Adressen zu. Voraussetzung ist aber, dass alle eine unterschiedliche IP Adresse haben. Auf diese Weise wird es möglich, dass hinter jedem Gateway ein separater ETS- Adressenraum existieren kann. Es sind also theoretisch bis zu 1000 ETS-Projekte mit gleichen Adressenbereichen in diesem System zugelassen. Spalte 3 - Priority Definiert die Priorität des Telegramms. Mögliche Werte: SYSTEM, HIGH, ALARM und LOW. Standardwert ist LOW und dieser soll, außer in Sonderfällen, immer verwendet werden.! Die Spalten 4 bis 7 legen fest, wie die empfangenen Daten interpretiert werden. Version: 1.0 Seite 61 von 86

62 Der Datentyp eines Telegramms wird mit zumindest zwei dieser Attribute definiert. Alle zugelassenen Datentypdefinitionen (Kombinationen der Attribute) sind in der Datentyp-Tabelle aufgelistet. Spalte 4 Data Size Größe des Datentyps, in dem der Wert des Telegramms übertragen wird. Mögliche Werte: 1BIT, 2BIT, 4BIT, 1BYTE, 2BYTE, 3BYTE, 4BYTE, 10BYTE, 14BYTE Für einfache Schalttelegramme wird der Typ 1BIT verwendet. Spalte 5 EIS Type Hier wird das EIS Datentyp des Telegramms festgelegt. Spalte 6 Signed/Unsigned Hier wird definiert, ob ein Datentyp mit oder ohne Vorzeichen zu interpretieren ist. Dieses Attribut wird nur von wenigen Datentypen verwendet. Für alle anderen Datentypen muss das Feld leer bleiben. Spalte 7 - Unit Die Einheit des Datentyps. Diese kann nicht frei angegeben werden, sonder darf nur aus der Liste ausgewählt werden. Spalte 8 - Description In der letzten Spalte wird der Telegrammtext definiert. Dieser wird auch in der Telegrammliste des Studios angezeigt. Spalte 9 - Path Diese wird für die automatische PDA Visualisierung verwendet, um eine Baumstruktur wie z.b. Home/Level1/living room zu generieren. Spalte 10 - Control Data Diese wird für die automatische PDA Visualisierung verwendet. Spalte 11- Alias Dies definiert einen neuen Alias Namen für das OPC Item. Dieser wird dann im Item Baum an Stelle der ursprünglichen Definition angezeigt. Spalte 12- Read on Reconnect Dies definiert, dass ein READ Telegram gesendet wird, wenn das IP Gateway sich neu verbindet und der aktuelle Wert von KNX empfangen werden soll. Das Read Flag im KNX Gerät muss natürlich gesetzt sein. Spalte 13- Read Cyclically Interval Dies definiert, dass ein READ Telegram periodische gesendet wird und dass der aktuelle Wert vom KNX zyklisch empfangen wird. Das Read Flag im KNX Gerät muss natürlich gesetzt sein. Seien Sie sich bewusst, dass das Bandbreite in der KNX Linie kostet. Spalte 14- Extended Data Dies wird zum Kommentieren verwendet. Die Datei nxatelegramdefinitions.35.dat file kann auch mit Hilfe des Zusatzprogramms NETxLAB ConvertETS weitgehend automatisch aus den exportierten ETS-Projekten erstellt werden. Siehe: Das Konvertierungstool: NETxLAB ConvertETS Version: 1.0 Seite 62 von 86

63 Ein Telegram wird mit der logischen KNX Adresse und der IP Adresse gebildet. Es ist nicht zulässig 2 gleiche Telegrammdefinitionen mit derselben IP Adresse zu haben. Version: 1.0 Seite 63 von 86

64 Gateway Definitionen: nxagatewaydefinitions.35.dat Der Gateway-Manager verwaltet die an das System angeschlossenen LAN-Koppler. Welche Gateways berücksichtigt werden sollen, definiert die Gateway-Definition Tabelle.! Es werden keine Telegramme an Gateways im Offline-Status weitergeleitet. Der Aufbau der Datei: 'Syntax of the Gateway Definition Table: 'IP Address;Type;Port;Name;Locality;Description ;Options ' ;IGS;51000; GATE 1;Room 51;pre-defined Gateway ;NETIP;3671;Gate2;;;;;;; ;EIBNODE;1634;Gate3;;;;;;; Jede Zeile ausgenommen sind die Kommentarzeilen ( ), definiert ein Gateway.! Das virtuelle BROADCAST-Gateway wird vom System angelegt, und kann nicht in der Tabelle definiert werden. Spalte 1 IP Address Die IP-Adresse des Gateways. Sie wird als Schlüsselwort verwendet, und kann nur einmal eingetragen werden. Spalte 2 - Type Der Typ des IP Gateways (IGS, NETIP or EIBNODE) Spalte 3 - Port Die Socket-Portnummer, die beim Gateway eingetragen ist. Spalte 4 - Name Die Bezeichnung des Gateways (frei definierbar). Spalte 5 - Locality Der Standort des Gerätes (frei definierbar). Spalte 6 - Description Beschreibung des Gerätes (frei definierbar). Spalte 7 - Options Wenn der Gateway Typ EIBNODE verwendet wird, wird hier die SenderNetID für dieses Gateway z.b. 1 eingetragen. Version: 1.0 Seite 64 von 86

65 Spalte 8-11 Path, Extended Data 1-3 Diese Spalten sind nur für interne Zwecke gedacht. Device Definitionen: nxadevicedefinitions.35.dat Der Device Manager kann die Verfügbarkeit eines KNX Gerätes überprüfen. Er versucht sich mit dem definierten Gerät zu verbinden, ob es erreichbar ist. Wenn dies fehlschlägt, wird der Wert des OPC Item des Gerätes auf Falsch gesetzt. Dies wird verwendet, um wichtige KNX Geräte zu überprüfen. Natürlich kostet dies Bandbreite in der KNX Linie, so dass es nur verwendet werden sollte, wenn es wirklich notwendig ist. Diese Telegramme sind keine Gruppentelegramme und werden nicht im Telegramm Monitor angezeigt. Die Device Definitionstabelle definiert alle Geräte, die überprüft werden sollen.! Der System Parameter SYS.EnableDeviceManager muss auf ON gesetzt werden. 'Syntax of the Device Definition Table: 'physical EIB Address;IP Address;Polling interval (sec);description;alias ' 1.1.1; ;20;Device 1;Switch ; ;40;Device 2; Die Struktur der Datei Jede Linie ausgenommen der Kommentarzeile (`) definiert ein Gerät. Spalte 1 physical KNX Address Die physikalische KNX Adresse des Geräts, welches kontaktiert werden soll. Spalte 2 - IP - Address Dies definiert die IP Adresse des Gateway, über das das Gerät erreichbar ist. BROADCAST wird in diesem Fall nicht unterstützt. Spalte 3 Polling interval Dies definiert das Abfrageintervall in Sekunden. Spalte 4 Description Diese Spalte definiert den Gerätetext. Dieser wird auch im Item Tree des Studios angezeigt. Spalte 5 Alias Diese definiert einen Alias Namen für das neue OPC Item. Dieser wird auch im Item Tree des Studios angezeigt. Version: 1.0 Seite 65 von 86

66 N-Mesh Subsystem Konfigurationsdatei: nxanmesh.35.cfg Das N-mesh Subsystem wird verwendet, um Main und Backup Server und Clustering zu konfigurieren. Main and Backup Server müssen die gleiche Grundkonfiguration haben (d.h. Telegram Definition, Gateway Definition, ). Server für Cluster brauchen die gleiche Telegram und Gateway Definition. Nur Veränderungen bei den Gateway Ports oder eibnet IDs sind erlaubt, um Konflikte beim Verbinden der Gateways zu unterbinden. Parameter: NMESH.UseRedundancy Gültigkeitsbereich: ON,OFF Default Wert: OFF Dies aktiviert die Redundanz Eigenschaft und muss bei Main and Backup Server auf ON gesetzt sein. Parameter: NMESH.EnableSynchronization Gültigkeitsbereich: ON,OFF Default Wert: OFF Dies aktiviert die Synchronisation zwischen Main und Backup Server. So bekommt der Standby Server die Update Information aller Änderungen in der Datenbank. Dies hilft, den anderen Server schnell auf den aktiven Zustand umzuschalten. Parameter: NMESH.MainServerIPAddress Gültigkeitsbereich: IP Adresse Default Wert: Dies legt die IP Adresse des Main Servers fest. Parameter: NMESH.BackupServerIPAddress Gültigkeitsbereich: IP Adresse Default Wert: Dies legt die IP Adresse des Backup Server fest. Parameter: NMESH.NetworkCardIPAddress Gültigkeitsbereich: IP address Default Wert: Dies definiert die IP Adresse der Netzwerkkarte, die verwendet werden soll, um mit allen N-Mesh Servern zu kommunizieren. Version: 1.0 Seite 66 von 86

67 Parameter: NMESH.NetworkPortNumber Gültigkeitsbereich: Default Wert: Dies definiert die Port Nummer, über welche zu dem N-Mesh Server kommuniziert werden soll. Parameter: NMESH.StartDelay Gültigkeitsbereich: von 0 bis 60 Default Wert: 10 Einheit: Sekunden Dies definiert die Verzögerung während des Hochfahrens. Parameter: NMESH.ConnectionTimeout Gültigkeitsbereich: von 10 bis Default Wert: 500 Einheit: Millisekunden Dies definiert das Timeout der Verbindung, nach der der Backup Server entscheidet, dass der Main Server nicht mehr da ist und sich zu den Gateways verbinden muss, um die Redundanz des System sicherzustellen. Parameter: NMESH.EnableRouting Gültigkeitsbereich: ON / OFF Default Wert: OFF Dies aktiviert das N-Mesh Routing der OPC Items, die in der N-Mesh Routing Definitionsdatei konfiguriert sind. Parameter: NMESH.Node Gültigkeitsbereich: IP Adresse Default Wert: fehlt Dies wird für das Clustering der NETxLAB Voyager Servers verwendet. Wenn sie vorhanden ist, werden alle Update Informationen zu dieser N-Mesh Node eines NETxLAB Voyager Servers gesendet. Der andere N-Mesh Node muss ebenfalls diesen Eintrag mit der anderen gegenüberliegenden IP Adresse haben. Dabei sind keine N-Mesh Routing Definitionen notwendig. N-Mesh Nodes brauchen die gleiche Telegram Definition, um die empfangenen Informationen zu speichern, anderenfalls wird sie ignoriert. Version: 1.0 Seite 67 von 86

68 N-Mesh Routing Definitionen: nxanmeshroutingdefinitions.35.dat Der N-Mesh Routing Manager verwendet diese Definitionen, um die Update Informationen der OPC Items an andere NETxLAB Voyager Server weiterzuleiten.! Der N-Mesh Routing Parameter NMESH.EnableRouting muss auf ON gesetzt sein. 'Syntax of the N-Mesh Routing Definition Table: 'OnReceive;OnSent;OnSetValue;KNX Address to Monitor;IP Address to Monitor;KNX Address to Send;IP Address to Send;Destination IP Address;Send Telegram Remotely T;T;T;14/1;BROADCAST;14/1;BROADCAST; ;F Die Struktur der Datei Jede Linie ausgenommen der Kommentarzeile (`) definiert ein N-Mesh Routing. Spalte 1 OnReceive Dies definiert, ob es routen soll, wenn ein Telegram empfangen wird. Spalte 2 OnSent Dies definiert, ob es routen soll, wenn ein Telegram gesendet wird. Spalte 3 OnSetValue Dies definiert, ob es routen soll, wenn ein Wert gesetzt wird. Spalte 4 KNX Address to Monitor Dies definiert die KNX Adresse, die überwacht werden soll. Spalte 5 IP Address to Monitor Dies definiert die IP Adresse des Gateways, das überwacht werden soll. Spalte 6 KNX Address to Send Dies definiert die KNX Adresse, an die gesendet werden soll. Spalte 7 IP Address to Send Dies definiert die IP Adresse des Gateways, an das gesendet werden soll. Spalte 8 Destination IP Address Dies definiert die IP Adresse des NETxLAB Voyager Servers, der die Update Informationen empfangen soll. Version: 1.0 Seite 68 von 86

69 Spalte 9 Send Telegram Remotely Dies definiert, ob der NETxLAB Voyager Server das Telegramm auch an das KNX IP Gateway senden soll. Dies ermöglicht ein Routing zwischen den KNX Linien über unterschiedliche NETxLAB Voyager Servers. Version: 1.0 Seite 69 von 86

70 System - Protokolldatei: nxaopcsystem.35.log Beispiel: Alle Ereignisse die Relevanz besitzen werden in dieser Datei mitprotokolliert, es sind die gleichen Informationen, die im Studio in der Event List angezeigt werden, mit dem Zweck, dass sie für spätere Systemanalysen auf der Festplatte gespeichert werden. Sollte ein Problem das Starten des Studios verhindern, können in dieser Datei die aktuellen Systeminformationen überprüft werden. Bei Wartung des Systems sollte diese Datei immer überprüft werden, wird sie größer als 1 MB, wird empfohlen diese in einem anderen Verzeichnis zu sichern und zu löschen. Sie wird beim Systemstart automatisch neu erzeugt. Diese Datei kann direkt im Studio3 geladen und überprüft werden (Menü File -> System Log File -> Open ). INFO;05/03/09 08:11:35.234;SERVER_ENGINE;Licensed Gateway Number: 32;0 INFO;05/03/09 08:11:35.249;SERVER_ENGINE;Option 'OPC.GroupAddressType' = '2Level';0 INFO;05/03/09 08:11:35.249;SERVER_ENGINE;Option 'OPC.AsyncReadFromDevice' = 'FALSE';0 INFO;05/03/09 08:11:35.249;SERVER_ENGINE;Option 'OPC.AsyncWriteConfirmation' = 'FALSE';0 INFO;05/03/09 08:11:35.249;SERVER_ENGINE;Option 'OPC.AsyncRefreshFromDevice' = 'FALSE';0 INFO;05/03/09 08:11:35.249;SERVER_ENGINE;Option 'OPC.AsyncTimeout' = '10';0 INFO;05/03/09 08:11:35.249;SERVER_ENGINE;Option 'KNX.Timeout' = '3';0 Datenaufzeichnung: nxaopcdata.35.log Die gesamte KNX-Anlage wird in einem virtuellen Modell im Serverspeicher abgebildet. Dieses Prozessbild wird auch auf der Festplatte gesichert. Wird der Server hochgefahren, sucht er nach dieser Datei, und lädt sie automatisch. Die Daten werden in binärer Form gespeichert und können nicht außerhalb des Systems verwendet werden. Der System Parameter SYS.UseTelegramDataFile:ON schaltet dies ein. Version: 1.0 Seite 70 von 86

71 Telegram-Protokolldatei: nxaopctelegram.35.log Die Telegrammaufzeichnung wird mit Hilfe dieser Datei realisiert. Hier werden alle ankommenden und gesendeten Telegramme mit Zusatzinformationen versehen gespeichert, was eine spätere Systemanalyse ermöglicht. Erreicht diese Datei im laufenden Betrieb die max. Größe von 10 MB, wird sie wieder von vorne überschrieben, dabei gehen die ältesten Aufzeichnungen verloren. Wird der Server gestartet, wird die alte Datei umbenannt und eine neue erstellt. Der System Parameter SYS.MaxSizeOfTelegramLogFile definiert die maximale Größe. Die OPC ITEM Eigenschaften Ein OPC ITEM verfügt über eine Reihe von Eigenschaften ( Properties ). Das NETxLAB Voyager System 1.0 unterscheidet zwischen zwei Typen von OPC ITEMs. - Das OPC ITEM, das einen Datenpunkt (KNX-Gruppenadresse) darstellt, besitzt folgende Eigenschaften: - Das OPC ITEM, das ein Gateway definiert, wird mit folgenden Eigenschaften beschrieben: Version: 1.0 Seite 71 von 86

72 Der Aufbau der OPC Strukturen Die OPC ITEM Struktur schaut folgendermaßen aus: Root Branch der Datenstruktur des Servers: \NETxKNX\ für jedes Gateway wird ein Zweig in der OPC Struktur angelegt: \NETxKNX\BROADCAST\ \NETxKNX\ \ \NETxKNX\ \ Jeder Datenpunkt wird mit dem vollständigen Pfad eindeutig spezifiziert: \NETxKNX\BROADCAST\00/2/001 \NETxKNX\BROADCAST\00/2/002 \NETxKNX\ \14/0/001 Unter jedem IP-Adresse -Zweig befindet sich jetzt auch das OPC ITEM mit der Bezeichnung GATEWAY. Version: 1.0 Seite 72 von 86

73 Der Wert des ITEMs wird nach dem Istgleich Zeichen gezeigt, wenn die Item Quality good ist. Der Wert des ITEMs eines Gateways zeigt die Verfügbarkeit des LAN- Kopplers (ist das Gateway OFFLLINE wird der Wert des ITEMs auf Falsch gesetzt, ONLINE auf Wahr ) Auch Geräte können gesehen werden, wenn sie definiert und der Device Manager aktiviert ist. Anbindung von OPC Clients Der NETxLAB Voyager Server wird unter dem Namen: NETxLAB. Voyager.Server.1.0 angemeldet. Jeder OPC Client stellt auf eigene Weise die Auswahl des Servers zur Verfügung. Die meisten listen alle auf dem Rechner vorhandenen Voyager Server auf, und lassen den Benutzer den gewünschten auswählen. Der NETxLAB Voyager Server 1.0 kann mehrere OPC Clients gleichzeitig verwalten, die parallel mit Daten versorgt werden. Jede Verbindung bzw. Trennung eines OPC Clients wird im NETxLAB System mitprotokolliert. Version: 1.0 Seite 73 von 86

74 Mögliche Datentypen Jede Zeile der untenstehenden Tabelle (die Spalte Beschreibung ausgenommen) definiert einen Datentyp. Es werden nur folgende Datentyp-Definitionen unterstützt: - EIS Datentypen Data size EIS Type (S)igned / (U)nsigned Unit Meaning 1BIT EIS1 Switch 4BIT EIS2 3BYTE EIS3 Time Dim object Bit 0=Up/Down Bit 1..3=Speed, if Bit1..4=0 Stop 3BYTE EIS4 Date( Attention: century 2-digits) 2BYTE EIS5 C Temperature 2BYTE EIS5 K Temperature difference 2BYTE EIS5 K/h Temperature gradient 2BYTE EIS5 Lux Light intensity 2BYTE EIS5 m/s Wind velocity 2BYTE EIS5 Pa Air pressure 2BYTE EIS5 s Time difference 2BYTE EIS5 ms Time difference 2BYTE EIS5 mv Voltage 2BYTE EIS5 ma Current 1BYTE EIS6 % Relative Luminance ( ) 1BYTE EIS6 % Relative Humidity ( ) 1BYTE EIS6 Wind direction ( ) 1BYTE EIS6 U 8-Bit unsigned (unofficial Type) 1BYTE EIS6 S 8-Bit signed (unofficial Type) 1BIT EIS7 Motor Motion 2BIT EIS8 Priority Control 4BYTE EIS9 m/s² Acceleration 4BYTE EIS9 rad/s² 4BYTE EIS9 J/mol 4BYTE EIS9 1/s 4BYTE EIS9 mol 4BYTE EIS9 4BYTE EIS9 rad 4BYTE EIS9 4BYTE EIS9 Js 4BYTE EIS9 rad/s 4BYTE EIS9 m² 4BYTE EIS9 F Version: 1.0 Seite 74 von 86

75 4BYTE EIS9 C/m² 4BYTE EIS9 C/m³ 4BYTE EIS9 m²/n 4BYTE EIS9 S 4BYTE EIS9 S/m 4BYTE EIS9 kg/m 4BYTE EIS9 C 4BYTE EIS9 A 4BYTE EIS9 A/m² 4BYTE EIS9 Cm 4BYTE EIS9 C/m² 4BYTE EIS9 V/m 4BYTE EIS9 C 4BYTE EIS9 C/m² 4BYTE EIS9 C/m² 4BYTE EIS9 V 4BYTE EIS9 V 4BYTE EIS9 Am 4BYTE EIS9 V 4BYTE EIS9 J 4BYTE EIS9 N 4BYTE EIS9 1/s 4BYTE EIS9 rad/s 4BYTE EIS9 J/K 4BYTE EIS9 W 4BYTE EIS9 J 4BYTE EIS9 Ohm 4BYTE EIS9 m 4BYTE EIS9 J 4BYTE EIS9 cd/m² 4BYTE EIS9 lm 4BYTE EIS9 cd 4BYTE EIS9 A/m 4BYTE EIS9 Wb 4BYTE EIS9 T 4BYTE EIS9 Am 4BYTE EIS9 T 4BYTE EIS9 A/m 4BYTE EIS9 A 4BYTE EIS9 kg 4BYTE EIS9 kg/s 4BYTE EIS9 N/s 4BYTE EIS9 rad 4BYTE EIS9 4BYTE EIS9 W 4BYTE EIS9 Version: 1.0 Seite 75 von 86

76 4BYTE EIS9 Pa 4BYTE EIS9 Ohm 4BYTE EIS9 Ohm 4BYTE EIS9 Ohm m 4BYTE EIS9 H 4BYTE EIS9 sr 4BYTE EIS9 W/m² 4BYTE EIS9 m/s 4BYTE EIS9 Pa 4BYTE EIS9 N/m 4BYTE EIS9 C 4BYTE EIS9 K 4BYTE EIS9 K 4BYTE EIS9 J/K 4BYTE EIS9 W/mK 4BYTE EIS9 V/K 4BYTE EIS9 s 4BYTE EIS9 Nm 4BYTE EIS9 m³ 4BYTE EIS9 m³/s 4BYTE EIS9 N 4BYTE EIS9 J 2BYTE EIS10 U 16-Bit unsigned 2BYTE EIS10 S 16-Bit signed 4BYTE EIS11 U 32-Bit unsigned 4BYTE EIS11 S 32-Bit signed 4BYTE EIS12 Access control 1BYTE EIS13 ASCII Character 1BYTE EIS14 ASCII Character 14BYTE EIS15 14 * EIS13 10BYTE EIS15 10 * EIS13 (unofficial Type) 14BYTE EIS15A 14 * EIS13 as BYTE ARRAY (VT_UI1 VT_ARRAY) 8BYTE EIS29 Wh data type for power meter 8BYTE EIS29 VARh data type for power meter - kanonische Datentypen Data size Type (S)igned / (U)nsigned Unit Meaning 4BYTE UI4 Unsigned Integer 3BYTE UI4 Unsigned Integer only 3 of 4 bytes used 8BYTE UI8 Unsigned Integer! Wollen Sie einen dieser Datentypen in einem Telegramm verwenden, müssen alle angegebenen Datentypattribute in der Telegrammdefinitionstabelle eingetragen werden. Version: 1.0 Seite 76 von 86

77 Beispiele: Richtig: ;2BYTE;EIS10;U;; Richtig: ;1BIT;EIS1;;; NETxLAB Voyager Server Direct(KNX) Version Falsch: ;2BYTE;EIS10;;; hier fehlt das Signed/Unsigned Attribut Falsch: ;1BIT;EIS1;; C; EIS 1 besitzt keine Einheiten Diese Version des Voyager Servers unterstützt alle KNX Protokolle wie in ETS, aber nur für ein Gateway. Die Konfiguration der Direct(KNX) Schnittstelle kann mit Hilfe des ETS Connection Manager Programms durchgeführt werden. Der Voyager Server verwendet die "NETxLAB Voyager Server 1.0" Verbindung. Derzeit stehen folgende Schnittstellentypen zur Verfügung: Version: 1.0 Seite 77 von 86

78 - RS.232 Standard - RS.232 FT1.2 - USB - KNXnet/IP Tunneling - KNXnet/IP Routing - IP(EIBlib/IP) Nach jeder Änderung der Verbindungsparameter muss der Voyager Server neu gestartet werden. Version: 1.0 Seite 78 von 86

79 Das Konvertierungstool: NETxLAB ConvertETS Die Datenübernahme aus dem ETS kann erleichtert werden, in dem die exportierten OPC Daten (ab der Version ETS2 1.3) mit Hilfe eines Tools in eine Telegramm- und Linkdefinitionsdatei konvertiert werden.! Es handelt sich hier um einen Zwischenschritt, die erzeugte Datei muss an das Projekt angepasst werden, da die Gateway-Verknüpfung nicht in der OPC Datei vorhanden ist. Alle erzeugten Telegrammdefinitionen werden dem angegebenen Default Gateway zugeordnet, die exakte Gateway-Verknüpfung muss durch den Systemintegrator durchgeführt werden Es ist möglich die alte Telegramm Definitionen zu überschreiben, mit den neuen Definitionen zusammenzufassen oder sie zu aktualisieren. Die konvertierten Definitionsdateien können im Microsoft Excel direkt bearbeitet werden (als CSV Datei). Version: 1.0 Seite 79 von 86

80 Die Konvertierung basiert auf der Datentyp-Konvertierungstabelle (nxaconvtrans.ctf). Beispiel der nxaconvtrans.ctf Datei: 'NETxKNX ETS OPC Converter Translation File ' 'Syntax: 'ETS OPC DataType Entry;NETxKNX DataSize;NETxKNX EIS Type;(S)igned/(U)nsigned;Unit; ' EIS 1 'Switching' (1 Bit);1BIT;EIS1;; Uncertain (1 Byte);1BYTE;EIS6;U;; Uncertain (2 Byte);2BYTE;EIS5;; C; EIS 2 'Dimming - control' (4 Bit);4BIT;EIS2;;; Hier ist die Datentypumwandlung festgelegt, und kann projektspezifisch abgespeichert werden. Jede Definition kann nur einmal in der Tabelle eingetragen werden und besteht aus vier Spalten. Spalte 1 - ETS OPC DataType Entry Der Datentypdefinitionsteil, der in der ETS OPC Datei eingetragen ist ( EIS 1 'Switching' (1 Bit) ). Dieser Wert wird gleichzeitig als Schlüsselwort für die Definition verwendet, kann also nur einmal vorkommen. Spalte 2 bis 4 Die Spalten 2 bis 4 definieren den Datentyp, der von NETxLAB OPC System interpretiert wird.! Es werden nur jene Datentypen unterstützt, die in der Datentyp-Tabelle aufgelistet sind. Ein NETxLAB OPC Datentyp besteht aus zumindest zwei Teilen, z.b.: EIS 1 'Switching' (1 Bit) = 1BIT;EIS1;;; Diese Einträge werden als Datentyp mit Größe 1 bit und als EIS1 interpretiert. Ein unspezifizierter Datentyp kann ebenfalls konvertiert werden: Uncertain (2 Byte) = 2BYTE;EIS5;; C; Alle diese Einträge werden auf den Datentyp EIS5 der Größe 2 Byte und der Einheit C konvertiert. Version: 1.0 Seite 80 von 86

81 Lizenzierungsvarianten: Softwareschutz Softlock Die Lizenzierung des Systems bezieht sich auf die Anzahl der angeschlossenen Gateways. Sie ist unabhängig von der Anzahl der definierten Grupentelegrammen, aber wir empfehlen die KNX Liene, an die das IP Gateway angeschlossen ist, so zu plannen, dass ein Maximum von 10 Telegrammen pro Sekunde nicht übeschritten wird, um Telegramverlust zu vermeiden. Es gibt folgende Varianten: 1 Gateway 3 Gateways 5 Gateways 10 Gateways 20 Gateways 32 Gateways 50 Gateways 100 Gateways 200 Gateways 500 Gateways Bis zu 1000 Gateways Zwei Softwareschutzarten stehen zur Verfügung: Softlock Softwarebasierendes Schutzsystem Hardlock Hardwarebasierendes (Dongle) Schutzsystem Software Registrierung: Die Software wird durch Vergabe einer Softwarelizenz, die an die lokale Hardware gebunden ist, freigeschaltet. Die Lizenzierung wird während des Setup-Vorganges durchgeführt, indem das RegisterSystem Tool gestartet wird. Version: 1.0 Seite 81 von 86

82 Die Lizenz besteht aus vier Teilen: - License Type der Lizenztyp ist nach der Anzahl der Gateways gestaffelt. - License ID die Bezeichnung der Lizenz (beliebiger Text) - Licensed Extensions Zusatzmodule, die lizenziert werden sollen Folgende beiden Einträge müssen an NETxAutomation weitergegeben werden, als Antwort wird die Freigabenummer (Local code) geliefert: : - Local System ID der lokale Hardware-Schlüssel (wird automatisch generiert) - License Code der Lizenzkode (wird automatisch generiert) - Unlock Code hier wird der Unlock Code, den man von NETxAutomation erhält, eingegeben. Sollte nach der Registrierung eine Fehlermeldung erscheinen, sind die angegebenen Daten zu überprüfen, und die Registrierung muss noch einmal durchgeführt werden.! Der bearbeitende Benutzer muss Administrator-Rechte besitzen. Version: 1.0 Seite 82 von 86