CTLON1AMX and NetLinx go LON

Bedienungsanleitung für das Comm-Tec LON-GatewayCTG-LON und der Ansteuersoftware CTLON1

Version 1.01Stand: 5.8.2003

© COMM-TECSiemensstr. 14, 73066 UhingenTel.: +49/7161/3000-0Fax: +49/7161/3000-400

2

Inhaltsverzeichnis

INHALTSVERZEICHNIS ................................ ................................ ................................ ......... 2

VORWORT................................ ................................ ................................ .......................... 4

ZIELSETZUNG ..........................................................................................................................4DIE ROLLE DES LON-INTEGRATORS .............................................................................................4LON AUS DER SICHT DES AMX-INTEGRATORS................................................................................4LON-BESONDERHEITEN BEIM EINSATZ DES GATEWAYS ......................................................................5VORWORT ZUR REVISION 1.XX.....................................................................................................6

WICHTIGE INFORMATION ZU DEN COMM-TEC LON-GATEWAYS AUS DER VORSERIE ............... 7

EIN BLICK ÜBER DEN ZAUN - LON TECHNOLOGIE UND TERMINOLOGIE ................................ ..8

WAS IST LON? ........................................................................................................................8WIE FUNKTIONIERT LON?...........................................................................................................8

ZUSAMMENGEFASST NOCH EINMAL DIE WICHTIGSTEN BEGRIFFE MIT KURZER ERKLÄRUNG .........................9

SYSTEMBESCHREIBUNG ................................ ................................ ................................ .....10

HARDWAREKOMPONENTEN .......................................................................................................10SOFTWAREKOMPONENTEN ........................................................................................................11VERSIONSÜBERSICHT DER GATEWAYKONFIGURATIONEN....................................................................12

INSTALLATION UND INBETRIEBNAHME................................ ................................ ............... 16

INSTALLATION DES GATEWAYS...................................................................................................16VERKABELUNG DER SERIELLEN SCHNITTSTELLE(N) ...........................................................................18

DIE AMX SOFTWARE................................ ................................ ................................ .......... 19

ALLGEMEINE HINWEISE.............................................................................................................19ZUSAMMENSPIEL AMX SOFTWARE UND GATEWAY-KONFIGURATION ...................................................19

KOMMUNIKATION MIT DEM MODUL ................................ ................................ .................. 20

EINBINDEN DES MODULS ..........................................................................................................20VERSORGUNG DES MODULS AUS DEM HAUPTPROGRAMM..................................................................20PARAMETER UND FUNKTIONEN ..................................................................................................21RÜCKMELDUNGEN ..................................................................................................................22SYSTEM_CALLS......................................................................................................................22ABFRAGEN VON WERTEN ..........................................................................................................23SETZEN VON WERTEN ..............................................................................................................23

BEFEHLSSATZ DES MODULS................................ ................................ ............................... 27

ZUSÄTZLICHE KOMMANDOS UND FUNKTIONEN ................................ ................................ .29

ANHANG A................................ ................................ ................................ ....................... 30

DIE INCLUDE-DATEI CT_LON1_FB_HANDLING.AXI ...................................................................30

ANHANG B ................................ ................................ ................................ ....................... 32

BEISPIEL: HAUPTPROGRAMM .....................................................................................................32BEISPIEL: CT_LON1_FB_HANDLING.AXI .................................................................................36

ANHANG C................................ ................................ ................................ ....................... 38

3

DEBUG- UND FEHLERMELDUNGEN ..............................................................................................38

4

Vorwort

ZielsetzungDas Softwarepaket CTLON1 dient der Ankopplung von AMX NetLinx-Steuerungen an LONNetzwerksysteme. Es stellt eine einfach zu verwendende Schnittstelle für den Entwickler zurVerfügung.

Die Rolle des LON-IntegratorsAnders als zum Beispiel bei EIB, wo das Gateway passiv im EIB-System hängt und grundsätzlich demgesamten Kommunikationsverkehr abbekommt, muss bei LON das Gateway explizit in das Netzwerkintegriert werden. Der LON-Integrator muss die vom Gateway angebotenen Kommunikationstypen insein Netzwerk einbinden, damit das Gateway Änderungen auf LON-Seite durchführen und aufnehmenkann.

Das Gateway ist also eine aktive Komponente im LON-Netzwerk, dem LON-Integrator kommt dietragende Rolle bei der Implementation des Gateways zu. Dazu später mehr.

LON aus der Sicht des AMX-IntegratorsFür den AMX-Integrator ist das LON-Gateway eine recht statische Sache. Das LON-Gateway gibt festdefinierte Kommunikationstypen vor, über die man auf dem LON etwas ausführen oder Meldungenvom LON empfangen kann. Eine Beeinflussung der Gateway-Konfiguration ist nicht möglich. Wird einKommunikationstyp angesprochen, den der LON-Integrator nicht in sein System eingebunden hat,dann ist dieser ohne Funktion.

Es obliegt also dem LON-integrator zu definieren, welche Kommunikationstypen in das LON-Netzwerkintegriert werden - sei es nun das Steuern einer LON-Komponente oder eine Rückmeldung einersolchen.

Zur Ansteuerung und Auswertung von LON-Komponenten stehen dem AMX-Integrator eine Reihe vonSystembibliotheken (SYSTEM_CALLs) zur Verfügung, die Rückmeldungen werden in Werte-ARRAYsabgebildet.

5

LON-Besonderheiten beim Einsatz des Gateways

Eines sollte man sich immer vor Augen halten:Der größte Vorteil von LON ist gleichzeitig auch sein größter Nachteil: seine Flexibilität.

Pinzipiell ist ein LON-Netzwerk ähnlich strukturiert wie ein Computernetzwerk. Es gibt beim LON zumBeispiel ebenfalls Hardware wie Router, Switches, Repeater, etc., aber auch Subnets, Domänen, usw.auf Softwareebene. Das LON-Netzwerk kann also auf Hardware- und Softwareebene strukturiertwerden.

Je nach Strukturierung des Netzwerkes muss das LON-Gateway (oder auch mehrere Gateways) ander richtigen Stelle innerhalb dieser Netzwerkstruktur auf Hardware- und Softwareebene plaziertwerden. Hier kann der AMX-Integrator dem LON-Integrator allerdings nicht viel helfen.

Im Gegenteil: vom Aufbau dieser LON-Netzwerkstruktur hängt es ab, wo (physikalisch) das LON-Gateway plaziert wird - und wo der AMX-Integrator folglich eine COM-Schnittstelle bereitstellen muss.

Desweiteren kann es zu gewissen Reaktionszeiten kommen, speziell bei Rückmeldungen. Hier ist dasGateway (nahezu) unschuldig. Es kann einfach etwas dauern, bis die (Rückmelde)Informationen dasGateway erreicht haben. Es kann noch eine gewisse Verzögerung durch die Art des AMX-Programmablaufs kommen, da bis zu 10 Gateways an einer COM-Schnittstelle hängen und dieGateways nacheinander auf Änderungen hin abgefragt werden. Dieser Ablauf wird im Kapitel xxxgenauer beschrieben.

6

Vorwort zur Revision 1.xx

Mit dem Gateway CTG-LON bietet COMM-TEC erstmalig für AMX eine einfache und komfortableAnbindung an das LON-System an.

Um von Anfang an mit möglicht wenig Limitationen arbeiten zu müssen, hat sich COMM-TEC dazuentschieden, nur eine NETLINX-Version des LON-Gatewaytreibers zu entwickeln.

Dies hat mehrere Gründe:- NetLinx hat die Performance um ohne Zusatzhardware (zB AXB-232++) auszukommen- NetLinx kann Werte die das LON-Netzwerk sendet und erwartet, wie zum Beispiel Fliesskomma-

oder negative Werte, direkt verwalten- NetLinx hat genügend Speicher um mehrere Gateways zu verwalten- Die Implementation des Treibers in das AMX-Programm ist sehr einfach

Uhingen, Mai 2003

7

Wichtige Information zu den COMM-TEC LON-Gateways aus derVorserie

Bei den Gateways mit der Bezeichnung

XFM-RS232-FTT10

handelt es sich um eine Vorabversion der COMM-TEC LON-Gatewaylösung.

Man erkennt diese Serie anhand eines handgeschriebenen Labels mit folgenderBeschriftung (exemplarisch):

COMM-TECLON Gateway RS232Firmware 14.3.03CTGLON1_V1_00.xif

Diese Gateways arbeiten bereits mit demselben Protokoll wie die Gateways, dieunter dem Namen CTG-LON in Serie produziert werden. Dadurch sind dieFunktionsaufrufe (SYSTEM_CALLs) prinzipiell gleich, es ergeben sich aber aufgrundder unterschiedlichen Hardware folgende Abweichungen:

- Die Gateways arbeiten über RS232, Belegung:LON Gateway,Schnittstelle X7(Flachbandkabel,rote Ader =1)

NXI NXC-/NXM-COM2, Port 1

NXC-/NXM-COM2, Port 2

3 - RX 3 - TX 3 - TX 13 - TX5 - TX 2 - RX 2 - RX 12 - RX9 - GND 1 - GND 1 - GND 11 - GND

Der 25pol Dsub Stecker des beim Gateway mitgelieferten X7-Kabels wirdabgeschnitten und das Flachbandkabel direkt auf die Mini-Phoenix von NetLinxaufgelegt- Es kann nur ein (1) Gateway je NetLinx COM-Schnittstelle angeschlossen werden- Die Gateways sind fest auf Adresse 0 eingestellt- Das NetLinx Treibermodul muss für jedes Gateway eingebunden werden

(virtuelles und Hardware-Device, Arrays, etc)- Beim Einbinden muss der Modul-Parameter PROTOKOLLTYP auf 1 gesetzt

werden (RS232 Betrieb)

Ansonsten unterscheidet sich die Einbindung nicht gegenüber einem einzelnenGateway aus der Serienproduktion.

Die nachfolgende Dokumentation bezieht sich auf die Gateways ausSerienproduktion mit RS485 Schnittstelle!

Uhingen, 18.3.2003COMM-TEC

8

Ein Blick über den Zaun - LON Technologie und Terminologie

Was ist LON?Die Bezeichnung LON ist die Abkürzung für Local Operating Network. Daraus definiert sich diegrundsätzliche Funktionsweise - ein räumlich begrenztes Funktionsnetzwerk.

Die Basis hierfür ist der NEURON-Chip, der ursprünglich von der Firma ECHELON entwickelt wurdeund zwischenzeitlich von anderen Chipherstellern ebenfalls produziert wird. Dieser Chip hat einintegriertes Kommunikationsprotokoll, so dass sich ein Entwickler nicht um den grundsätzlichenDatentransport kümmern muss, sondern nur um die eigentlichen Nutzdaten.

Ein weiterer Ansatz dabei ist die Verteilung der Aufgaben auf viele Einzelintelligenzen, die man alsKNOTEN bezeichnet. Der Datenaustausch zwischen den Knoten erfolgt ereignisgesteuert. Da eskeine zentrale Intelligenz gibt, ist das LON System sehr betriebssicher.

Große LON Systeme können aus mehreren kleinen Netzwerken bestehen, die dann untereinanderwiederum Daten austauschen. So könnten zum Beispiel mehrere Stockwerke eines Gebäudes in sichautark arbeiten und trotzdem Daten untereinander austauschen.

Die Kommunikation zwischen den Knoten und den LON Netzwerken wird über das LON-eigeneProtokoll LONTALK realisiert, welches das OSI/ISO Schichtmodell anwendet. Dieses Protokoll kannüber verschiedene physikalische Medien transportiert werden wie zum Beispiel Zweidrahtleitungen,230V Netze, Fiberoptik oder Ethernet-Netzwerke.

Wie funktioniert LON?Während der LON-Standard grundsätzlich die Hardware-, Software- und Transportbasis festlegt,wurde für die Gebäudeautomation ein weiterer definiert: der LONMARK-Standard. LONMARK schreibtvor, wie Funktionsbausteine verschiedener Hersteller untereinander mit Hardware und Softwarevernetzt werden müssen.

Als Hardware für den Transport der Daten (Layer 1 des OSI-Modells) sind bei LONMARK neunverschiedene Übertragungsmedien erlaubt. Am meisten verbreitet ist dabei die FTT-10 Topologie(FTT = Free Topology Transceiver), die bis zu 64 Knoten erlaubt und bei klassischem Bus-Design biszu 2700m oder bei freier Topologie bis 400m Länge zulässt. Werden weitere Knoten oder längereStrecken gebraucht, kommen sogenannte Repeater zum Einsatz.

Neben der Festlegung eines Hardwarestandards beschreibt LONMARK auch einenKommunikationsstandard, um die Interoperabilität zwischen Geräten verschiedener Hersteller zugewährleisten. Dieser basiert auf sogenannten SNVTs (Standard Network Variable Types), alsovorgeschriebenen Variablen-Objekten, in denen festgelegt ist, welche Inhalte übertragen werden. Esgibt zwischenzeitlich rund 140 vorgeschriebene SNVTs.

Typische Anwendungen für ein SWITCH Objekt sind zum Beispiel Licht ein- und ausschalten.

Beispiel: SWITCH ObjektSNVT #95

typedef struct {unsigned value;signed state;

} SNVT_switch;

Field Definitions

Field Units Valid Range Notesvalue 8 bit percentage 0 .. 100% intensity as percentage of full scale,resolution 0.5%state state 0 .. 1, 0xFF 0 means off, 1 means on, 0xFF meansundefined

9

Jeder LonWorks-Knoten kann nun solche Variablen zum Senden oder Empfangen zur Verfügungstellen. Welche Kommunikationsobjekte der Knoten genau zur Verfügung stellt (SNVT Typ, Eingangs-oder Ausgangsvariable), legt der Hardwarehersteller anhand einer Konfiguration fest, die entweder inden Knoten geladen wird oder schon geladen ist.

Damit nun die Knoten untereinander kommunizieren und damit ihre Funktionen weitergeben können,müssen die Variablen der Knoten untereinander verbunden und damit das System insgesamt zurFunktion gebracht werden. Diesen Vorgang nennt man BINDING (engl., "bainding" gesprochen).Hierbei wird, im einfachsten Fall, eine Knoten-Ausgangsvariable mit einer Knoten-Eingangsvariableneines anderen Knotens verbunden, wobei diese Variablen vom gleichen Typ sein müssen. DiesesBinding geschieht durch eine LON Manager Software, die auf einem PC installiert ist und direkt mitdem LON verbunden ist. Erst danach ist das System funktionsfähig.

Zusammengefasst noch einmal die wichtigsten Begriffe mit kurzer ErklärungBegriff Erklärung(LON-)Knoten, Node Eine Applikation mit einer LON-SchnittstelleSNVT (gesprochen "Sniwit") Standard-Network-Variable-Type, durch

LONMARK fest vorgegebene Variablenstruktur für dieKommunikation zwischen Knoten

Netzwerkvariable Allgemeiner Begriff für die Variablen, über die die Kommunikationerfolgt , nachfolgend NV bezeichnet

Echelon Hardwarebasis über die LON kommuniziertNeuron-ID Weltweit einmalige Hardware-Identifikationsnummer eines Echelon-

ChipsLonTalk® Das Basis-Protokoll, das im LON-System benutzt wirdLONMaker, LonBuilder,LonManager

Tools des LON-Integrators um das Netzwerk zu erstellen

Binding (engl.) Der Prozess welcher die Verbindung zwischen den Knotendefiniert

LON Bus Durch die Firma Echelon definierter Feldbus, welcher mittels mittelsNeuron-Chips angesteuert werden kann.

LONMARK Ein Zertifizierungsprogramm, welches die Kompatibilität der Produkteveschiedener Hersteller garantiert

XIF Datei Eine XIF-Datei beschreibt die Konfiguration eines LON-Knotens.Diese Datei braucht der LON-Integrator, um einen Knoten in dasLON-System zu integrieren.

LON Local Operating NetworkSNVT-Nummer Jede SNVT hat eine eigene Nummer, die von LONWORKS

festgelegt wird

10

Systembeschreibung

Hardwarekomponenten

Zur Anbindung eines AMX-Systems an LON sind mehrere Hardware-Komponenten notwendig:

• ein AMX-Master der NetLinx Generation (ab Ver. 2.10.85), in dem das HauptprogrammSteueranweisungen erzeugt und Rückmeldungen vom LON entgegennimmt (nachfolgend„Master“ genannt).

• eine RS485-Schnittstelle• auf einem integrierten Controller (NXI-<xy>) (ab Ver. 1.0.20) oder• eine NXC-COM2 (Einschubkarte) in einem Kartenträger (NXF-<xy>) (ab Ver. 1.0.9) oder• eine NXC-COM2 (Einschubkarte) in einem Busdevice (NXM-COM2) oder• auf einem Paket-Controller der NI-Serie

zur Übertragung von Meldungen und –Befehlen zwischen Gateway und Master• ein LON-Gateway CTG-LON (ab Ver. 1.00), zur physikalischen Verbindung mit dem LON,

welches die Kommunikationspunkte zum LON zur Verfügung stellt.

Das LON-Gateway enthält eine feste Konfiguration von Kommunikationspunkten zum Senden undEmpfangen von LON-Anweisungen. Die Anzahl, der Typ und die Reihenfolge der NVs kann nichtgeändert werden.

Ob und welche Funktion(en) die NV hat, muss der LON-Integrator während seines System-Setupsfestlegen.

11

Das Programmpaket CTLON1 umfaßt das eigentliche Modul und mehrere Programmbibliotheken(System_Calls), die in eigene Programme eingebunden werden können.

Das Modul ist fertig übersetzt (kompiliert), und muß zur Installation nur noch ins Hauptprogrammeingebunden werden. (siehe Beispiel im Anhang B)AMX-seitig stellt sich das Gateway durch die Verwendung des Moduls als "ganz normales" Busdevicedar, man könnte sich also auch "ganz normal" über Send_Command/Send_String-Befehleunterhalten.

Durch die Vielfalt der möglichen Meldungen und Befehle, sowie deren unterschiedlicher Inhalt sindjedoch die Anforderungen an die Empfangs- und Sendelogik inklusive Paket-Verarbeitung relativhoch. Die mitgelieferten Bibliotheksfunktionen vereinfachen die Kommunikation mit dem Modul, daman sich nicht mit der dahinter liegenden Syntax befassen muss.

Sie stellen eine Reihe von Funktionen bereit, die einfach - per System_Call-Aufruf - in eigeneProgramme eingebunden werden können. Durch einen modularen Aufbau werden nur die wirklichbenötigten Programmteile eingebunden, um die Ressourcen des Masters (Speicher, Rechenzeit,Buslast) möglichst zu schonen.

Der Gateway-Treiber ist auf mögliche zukünftige Erweiterungen der Gateway-Funktionen ausgelegt.Wenn das NetLinx-System gestartet wird (Strom anstecken oder Reboot), arbeitet der Treiber zuersteine Initialisierungsroutine ab, die etwas 20 Sekunden dauert. Danach nimmt der Treiber seineeigentliche Funktion auf.

Alle 30 Sekunden wird erneut eine kurze Routine verarbeitet, durch die für etwa 1,5 Sekunden keinKommando zum LON geschickt werden kann, oder Rückmeldungen nicht ausgewertet werdenkönnen. Im der Praxis fällt dies jedoch nicht auf.

Die maximale Dauer bis zur automatischen Erkennung eines Gateways ist etwa 5 Minuten, derProzess kann aber manuell beschleunigt werden (siehe Terminalkommando SCANGW ).

12

Versionsübersicht der Gatewaykonfigurationen

Version XIF-Datei Unterstützte Variablentypen (Anzahl IN/OUT)V1.00 CTGLON1_V1_00.XIF # 95 SWITCH (64/64),

#83 STATE (16/16),#117 SETTING (64/64),#105 TEMPP (32/32),94 PRESET (32/32),8 COUNT (32/32),84 TIMESTAMP (1/1),115 SCENE (32/32)

V1.01 CTGLON1_V1_01.XIF Typen und Anzahl wie v1.00, zusätzlich#109 OCCUPANCY (32/32)

13

Datenmodell

Immer wenn zwei Gewerke aufeinander treffen, ist eine aktive Kommunikation zwischen den beidenLeuten oder Firmen notwendig, die diese Gewerke installieren, konfigurieren oder programmieren. Beider Verbindung zwischen AMX und LON sind das normalerweise die Firma für die Medientechnik (imfolgenden AMX-Integrator genannt), und die Firma, die für LON verantwortlich ist (LON-Integrator).

Um eine Verbindung zwischen dem LON System und der Aussenwelt herzustellen, gibt es mehrereWege, angefangen von Kontakt-Interfaces bis hin zu Webservern mit LON Interface. Für dieAnbindung von LON an ein Steuerungssystem werden jedoch meist serielle Interfaces eingesetzt.

Das COMM-TEC Interface CTG-LON zur Anbindung von AMX-Systemen an LON setzt das LonMarkProtokoll in ein serielles Protokoll um, damit eine Ansteuerung und Auswertung von LON Meldungenrealisiert werden kann.

Das CTG-LON ist mit einer festen Konfiguration geladen, die eine Reihe der wichtigsten SNVTs ingenügender Anzahl zur Verfügung stellt:Lfd Nr. SNVT Nummer Richtung Anzahl NV-Namen0 .. 63 #95 SWITCH IN

(Daten vonLON zumGateway)

64 "nviSWITCH1" .. "nviSWITCH64"

64 .. 127 #95 SWITCH OUT(Daten vomGateway zuLON)

64 "nvoSWITCH1" .. "nvoSWITCH64"

128 .. 143 #83 STATE IN 16 "nviSTATE1" .. "nviSTATE16"144 .. 159 #83 STATE OUT 16 "nvoSTATE1" .. "nvoSTATE16"160 .. 223 #117 SETTING IN 64 "nviSETTING1" .. "nviSETTING64"224 .. 287 #117 SETTING OUT 64 "nvoSETTING1" .. "nvoSETTING64"288 .. 319 #105 TEMP_P IN 32 "nviTEMPP1" .. "nviTEMPP32"320 .. 351 #105 TEMP_P OUT 32 "nvoTEMPP1" .. "nvoTEMPP32"352 .. 383 #94 PRESET IN 32 "nviPRESET1" .. "nviPRESET32"384 .. 415 #94 PRESET OUT 32 "nvoPRESET1" .. "nvoPRESET32"416 .. 447 # 8 COUNT IN 32 "nviCOUNT1" .. "nviCOUNT32"448 .. 479 # 8 COUNT OUT 32 "nvoCOUNT1" .. "nvoCOUNT32"480 #84 TIMESTAMP IN 1 "nviTIMESTAMP1"481 #84 TIMESTAMP OUT 1 "nvoTIMESTAMP1"482 .. 513 #115 SCENE IN 32 "nviSCENE1" .. "nviSCENE32"514 .. 545 #115 SCENE OUT 32 "nvoSCENE1" .. "nvoSCENE32"546 .. 577 #109

OCCUPANCYIN 32 "nviOCCUP1" .. "nviOCCUP32"

578 .. 609 #109OCCUPANCY

OUT 32 "nvoOCCUP1" .. "nvoOCCUP32"

Die genaue Konfiguration steht dem LON-Integrator als Dateien im XIF und XFB Format zurVerfügung, die in die verschiedenen LonWorks-Tools (zum Beispiel LonMaker) übernommen werdenkönnen. Die LON-seitig benötigten Variablen des Gateways werden vom LON-Integrator mit denentsprechenden Knoten verbunden, alle nicht verbundenen Variablen des Gateways sind automatischinaktiv.

Der AMX-Integrator programmiert die LON Funktionen anhand einer Aufstellung des LON-Integratorsin der aufgelistet ist, welche Variablen benutzt werden und was diese genau melden oder auslösen

14

Was verbirgt sich hinter einer SNVT?Jede SNVT ist eigentlich eine Struktur, die mehrere Elemente enthalten kann.Exemplarisch hierzu die Details einer recht einfachen SNVT - dem SWITCH

Eine SWITCH Netzwerkvariable (kurz: NV) besteht auf LON-Seite aus 2 Elementen

unsigned value - 0%..100% in 0.5% Schrittensigned state - 0..1, oder $FF als undefiniert

StolperstellenDie SNVT Definition schreibt zwar vor, welche Werte in den Elementen enthalten sind. Was die Werteaber genau darstellen ist nicht festgelegt.Typische Werte für SWITCH (zB bezogen auf einen Lichtkreis):value = 0%; state = 0 -> AUSvalue = 100%; state = 1 -> ANvalue = 50%; state = 1 -> AN auf 50% des Regelbereichesvalue = 78.3%; state = 1 -> AN auf 78.3% des Regelbereiches

Für einen Deckenlift könnte es aber auch bedeuten:value = 100%; state = 0 -> 100% hochvalue = 100%; state = 1 -> 100% runter

Damit die Implementation seitens AMX möglichst reibungslos funktioniert, sollte vom LON-Integrator(!)eine Funktionstabelle erstellt werden. Nachfolgend ein Vorschlag:

Funktion GatewayAdresse

NV-Name NVIndex

Richtung NV Typ Werte TouchpanelAdresse*

Button, var.Text, Level*

Bemerkungen

JalousieRaum 1STOP

0 NvoSETTING_O12

34 Senden SETTING Function = 4,Setting =100%,Rotation = 0

JalousieRaum 1AUF

0 nvoSETTING_O12

34 Senden SETTING Function = 3,Setting =100%,Rotation = 0

* trägt der AMX Integrator nach

Die Angaben unter WERTE sind, wie bereits oben erwähnt, besonders wichtig, da LON hier ja keinefeste Vorgabe macht was diese Werte nun tatsächlich bewirken.

Setzen einer NetzwerkvariablenDas Setzen einer NV wird über SYSTEM_CALLs realisiert, von denen es für jede SNVT eineneigenen Aufruf gibt. Syntax:SYSTEM_CALL '<SysCall Name>'(<Virtual LON Device>,<Gateway Address>,<TableIndex>,<Parameter1>,<Parameter 2>,...<Parameter n>)

<SysCall Name> - Name des SYSTEM_CALLs. zB 'LON1_NX Set Switch'<Virtual LON Device> - virtuelles Device, über das mit dem LON Treiber kommuniziert wird<Gateway Address> - Adresse des Gateways auf dem RS485, momentan immer Adresse 1<Table Index> - Welches Element innerhalb der NV-Tabelle, zB der Switcher<Parameter 1>,<Parameter 2>,..<Parameter n> - weitere Parameter, abhängig vom SNVT

Das Setzen einer SWITCH NV könnte also folgendermaßen aussehen:SYSTEM_CALL 'LON1_NX Set Switch'(vdvLON,1,14,45.5,1)Setze auf Gateway 1 SWITCH 14 auf Value 45.5% und den State auf 1

Ein 'Set Value' System_Call bezieht sich immer auf die NVs die für OUT definiert sind, die also Wertein das LON Netzwerk schicken können.

15

Rückmeldung einer NetzwerkvariablenWerden Werte über eine NV vom LON-Netzwerk empfangen, bildet der LON Gatewaytreiber diese inArrays ab. Für jeden SNVT Typ ist ein eigenes Array vorhanden, und weist entsprechend der SNVTElemente auf: Für SWITCH NVs sieht das Rückmeldearray folgendermaßen aus:

<Array Type> <Array Name>[<Gateways>][<Table Lines>][<Elements>]

<Array Type> - Datentyp des Arrays, zB FLOAT, INTEGER,...<Array Name> - Name des Arrays<Gateways> - Anzahl der möglichen Gateways an der COM Schnittstelle (momentan 1)<Table Lines> - Anzahl der NVs für diesen Typ<Elements> - Anzahl der Elemente je NV, abhängig vom Typ

Für SWITCH Rückmeldungen sieht das folgendermaßen aus:FLOAT fLON_SWITCH_RM[1][64][2]

Keine Panik - es sieht komplizierter aus als es ist.- SWITCH sieht für den value einen Unsigned Float Datentyp voraus (s. oben, 0.5% Schritte).

Deshalb muss das gesammte Array als FLOAT definiert werden.- Je COM Schnittstelle der NetLinx kann momentan 1 Gateway verwaltet werden. Dieser Wert ist

fest vorgegeben.- In jedem Gateway stehen 64 SWITCH-Rückmeldungen zur Verfügung- Jeder SWITCH hat 2 Elemente, nämlich value und state

Die einzelnen SNVTs werden später noch genauer beschrieben.

16

Installation und Inbetriebnahme

Installation des GatewaysDas Gateway besitzt ein 6TE breites Tragschienengehäuse nach DIN 43880. Die Einbaulage istbeliebig. Das Gerät besitzt Halterungen zur Rastmontage auf Tragschienen nach DIN 46277 und DINEN 50022.

17

18

Verkabelung der seriellen Schnittstelle(n)Die Verbindung zwischen NetLinx und LON wird mit 3 Leitungen (RS485) realisiert. Auf Gateway-Seite ist die Belegung immer gleich, auf der NetLinx Seite kommt es auf die verwendete Schnittstellean.

NI - Serie, alle RS232/422/485 PortsDas mitgelieferte Kabel mit der Beschriftung "RS485" ist bereits fertig konfektioniert für den Anschlussan die NI-Controller.NI Pinnummer Leitung Gateway Anschluss X6,

Flachkabel (rot: Ltng 1)Leitung

1 RX-, Brücke auf Pin 94 TX+, Brücke auf Pin 6 6 Data A5 Masse 9 Masse6 RX+, Brücke auf Pin 49 TX-, Brücke auf Pin 1 5 Data B

NXI und NXC-/NXM-COM2Zum Anschluss des Gateways an die Controller mit Phoenix-Schraubklemmen muss das mitgelieferteKabel umkonfektioniert werden. Hierzu kann entweder der 9pol Stecker abgeschnitten und dieLeitungen direkt auf die Phoenix-Klemmen aufgelegt werden, oder es wird ein Adapterkabelhergestellt.

Direkt geschraubt: NXI - alle Ports, NXC-COM2 - Port 1 (Port 2)NetLinxPinnummer

Leitung Gateway Anschluss X6,Flachkabel (rot: Ltng 1)

Leitung

1 (11) Masse 9 Masse6 (16) TX+, brücken auf Pin 8 6 Data A7 (17) TX-, brücken auf Pin 9 5 Data B8 (18) RX+, brücken auf Pin 69 (19) RX-, brücken auf Pin 7

Adapter: 10 Pol Phoenixklemme auf 9pol DSub SteckerNetLinxPinnummer

Leitung 9pol Dsub Male

1 Masse 56 TX+ 47 TX- 98 RX+ 69 RX- 1

19

Die AMX Software

Allgemeine Hinweise• Die AMX Software ist bereits mit Funktionen für zukünftige Erweiterungen versehen. Bei einigen

LON Softwareteilen muss eine Gateway-Adresse angegeben werden (SYSTEM_CALLs) bzw beider Definition von Rückmeldearrays muss die Größe der Arrays immer auf 10 gesetzt werden.

Bei der Revision 1 der Software wird immer die Gateway-Adresse 1 angesprochen, bzwwird immer auf die Arrays für Gateway 1 referenziert.

• Das NetLinx Software-Modul richtet automatisch ein zusätzliches Device im Bereich > 36863 ein.Deviceadressen in diesem Bereich werden vom NetLinx-Master automatisch so verwaltet, dasskein Devicekonflikt auftreten kann. Dieses Device ist für die interne Verarbeitung des Software-Moduls notwendig und wird vom Hauptprogramm nicht angesprochen.

Zusammenspiel AMX Software und Gateway-Konfiguration

Wir empfehlen grundsätzlich, immer die AMX-Softwareversion zu benutzen, die dem Gatewaybeiliegt.

Gatewaykonfiguration und AMX Softwaretreiber sind so aufeinander abgestimmt, dass keinelementarer Schaden auftritt, jedoch sind gewisse Einschränkungen möglich:

• Wird eine aktuelle Gatewaykonfiguration mit einer älteren AMX Gatewaytreibersoftware benutzt,lassen sich unter Umständen einige Funktionen des Gateways nicht nutzen.

• Wird eine ältere Gatewaykonfiguration mit einer neueren AMX Gatewaytreibersoftwareangesteuert, erhält das Gateway unter Umständen Kommandos, die nicht unterstützt sind, unddas Gateway wird diese Kommandos ignorieren.

20

Kommunikation mit dem Modul

Einbinden des ModulsDie Kommunikation zwischen dem NetLinx-System und dem(den) Gateway(s) erfolgt über einSoftware-Modul. Dieses Modul liegt in compilierter Form vor und wird vom NetLinx Compiler in dieApplikation eingebunden. Datei: CT_LON1_UI1_mod.tkoDiese Datei muss in das Verzeichnis kopiert werden, in dem der Compilerlauf durchgeführt wird.

Versorgung des Moduls aus dem HauptprogrammDurch Einbinden der mitgelieferten System_Calls in das Hauptprogramm werden Steuerfunktionen amLON ausgelöst, und Meldungen über Zustandsänderungen in die entsprechenden Variablen verteilt.

Damit der NetLinx-Compiler die System_Calls auch einbinden kann, müssen sie vor Benutzung in einVerzeichnis auf der Festplatte kopiert werden. In welches Verzeichnis sie kopiert werden müssen,hängt davon ab, wie der Compiler installiert wurde.Bei einer Standardinstallation der AMX-CD unter Windows98 oder NT liegen sämtliche System_Callsim Verzeichnis „C:\Programme\Gemeinsame Dateien\AMXShare\SYCs“.Es sollten also alle *.LIB Dateien aus dem Verzeichnis xxxl der mitgelieferten Diskette dort hineinkopiert werden.

Sollten Sie bei der Installation ein anderes Unterverzeichnis zur Ablage der SYSTEM_CALLsangegeben haben, stellen Sie bitte sicher, dass der Compiler die System_Calls auch finden kann.Desweiteren liegt noch eine INCLUDE-Datei (.AXI) bei, die für die Anzeige der Rückmeldungenzuständig ist.Datei: CT_LON1_FB_HANDLING.AXIAuch diese Datei muss in das Verzeichnis kopiert werden, in dem der Compilerlauf durchgeführt wird.

21

Parameter und FunktionenDas Modul verlangt eine Reihe von Parametern, die beim Einbinden übergeben werden müssen:

DEFINE_MODULE 'CT_LON1_UI1_mod' <Instance Name>(<Virtual LON Device>, <COM Hardware Device>, <SWITCH Value Table>, <STATE Value Table> <SETTING Value Table>, <TEMPP Value Table>, <PRESET Value Table>, <COUNT Value Table>, <TIMESTAMP Value Table>, <SCENE Value Table>, <OCCUPANCY Table>, <Protocol Type>)

Parameter Typ Beschreibung<Instance Name> Eindeutiger Instanzname<Virtual LON Device> Device Virtuelles Device (33001:1:0 - 36863:1:0) über

das mit dem Modul kommuniziert wird<COM Hardware Device> Device Hardware-Adresse, der COM Schnittstelle<SWITCH Value Table> FLOAT ARRAY[1][64][2] Elemente: Value (0.0%..100.0%), State (0..1)<STATE Value Table> INTEGER ARRAY[1][16][16] Elemente: Bit15..Bit0<SETTING Value Table> FLOAT ARRAY[1][64][3] 3 Elemente:

Function (0..5, s. SystemCall SET SETTING),Setting (0%..100%)Rotation (-259.98 .. 360.0°)

<TEMPP Value Table> FLOAT ARRAY[1][32][1] Element: Temperatur (-273.17 .. 327.66°C)<PRESET Value Table> INTEGER ARRAY[1][32][11] 11 Elemente:

<COUNT Value Table> INTEGER ARRAY[1][32][1] 1 Element: 16bit Wert<TIMESTAMP Value Table> INTEGER ARRAY[1][1][6] 6 Elemente:

Jahr, Monat, Tag, Stunde, Minute Sekunde<SCENE Value Table> INTEGER ARRAY[1][32][2] 2 Elemente: Function, Scenenumber<OCCUPANCY Table> INTEGER ARRAY[1][32][1] 1 Element: 8bit Wert<Protocol Type> INTEGER Alle Werte RS485 Kommunikation,

ausser 1 = RS232

22

RückmeldungenDie Rückmeldungen werden in Tabellen festgehalten und können von dort direkt ausgelesen werden.Da die SNVTs unterschiediche Anzahlen und Typen von Rückmeldeelementen haben, unterscheidensich die Tabellen etwas voneinander.

Grundsätzlicher Aufbau:<Arraytype> NAME[<no. of Gateways>][<no. of NVs>][<no. of Elements of NV>]

SVNT Typ <Arraytype> <no. ofGateways>

<no. of NVs> <no. of Elements of NV>

SWITCH FLOAT 10 64 2 - Value (0.0%..100.0%), State(0..1)

STATE INTEGER 10 16 16 - Bit0..Bit15 Binär (0..1) *1)SETTING FLOAT 10 64 3 - Function (0..5, s. SystemCall

SET SETTING),Setting (0%..100%)Rotation (-259.98 .. 360.0°)

TEMPP FLOAT 10 32 1 - Temperatur (-273.17 ..327.66°C)

PRESET INTEGER 10 32 11 - *2)COUNT INTEGER 10 32 1 - 16Bit WertTIMESTAMP INTEGER 10 1 6 - Jahr, Monat, Tag, Stunde,

Minute SekundeSCENE INTEGER 10 32 2 - Function (0..23),

Scenenumber(1..255)OCCUPANCY INTEGER 10 32 5 – 8bit Wert (0..3)*1) Die Abbildung der Bits im Rückmeldungs-Array ist invertiert, d.h. Bit15 steht an Stelle 1 im Array,Bit0 an Stelle 16.*2) Bei der PRESET Rückmeldung sind insgesamt 11 Elemente vorhanden. Die wichtigsten Elementesind:[1] Learn Mode (üblicherweise 0 - Aufruf)[2] Selector (Presetnummer)

System_CallsDem Paket CTLON1 liegen insgesamt 16 System_Calls bei, die ins Hauptprogramm zur Ansteuerungeingebunden werden.

Für jeden der sieben SNVT gibt es jeweils einen Call zum Setzen von Werten, z.B. System_Call'LON1_NX Set Switch', sowie einen zum erneuten Auslesen einer NV aus dem Gateway, z.B.System_Call 'LON1_NX Read Switch'

Auf der Diskette liegen im Verzeichnis xxx folgende Dateien:

Dateiname Klartextname Bedeutung

CTLON1R008_NX.LIB 'LON1_NX Read Count' Switch-NV auslesenCTLON1R083_NX.LIB 'LON1_NX Read State' State-NV auslesenCTLON1R084_NX.LIB 'LON1_NX Read TimeStamp' TimeStamp-NV auslesenCTLON1R094_NX.LIB 'LON1_NX Read Preset' Preset-NV auslesenCTLON1R095_NX.LIB 'LON1_NX Read Switch' Switch-NV auslesenCTLON1R105_NX.LIB 'LON1_NX Read Tempp' Tempp-NV auslesen

CTLON1R109_NX.LIB 'LON1_NX Read Occupancy' Occupancy-NV auslesenCTLON1R115_NX.LIB 'LON1_NX Read Scene' Szenen-NV auslesenCTLON1R117_NX.LIB 'LON1_NX Read Setting' Setting-NV auslesen

CTLON1S008_NX.LIB 'LON1_NX Set Count' Switch-NV setzenCTLON1S083_NX.LIB 'LON1_NX Set State' State-NV setzenCTLON1S084_NX.LIB 'LON1_NX Set TimeStamp' TimeStamp-NV setzenCTLON1S094_NX.LIB 'LON1_NX Set Preset' Preset-NV setzenCTLON1S095_NX.LIB 'LON1_NX Set Switch' Switch-NV setzenCTLON1S105_NX.LIB 'LON1_NX Set Tempp' Tempp-NV setzenCTLON1S109_NX.LIB 'LON1_NX Set Occupancy' Occupancy-NV setzenCTLON1S115_NX.LIB 'LON1_NX Set Scene' Szenen-NV setzenCTLON1S117_NX.LIB 'LON1_NX Set Setting' Setting-NV setzen

23

Abfragen von WertenDas Gateway meldet seine Werte nur dann an die AMX, wenn eine Nachricht vom LON-Systemempfangen wurde. In manchen Situationen ist es daher notwendig, manuell einen Wert aus demGateway auszulesen.

SYSTEM_CALL 'LON1_NX Read Switch' (<vdvDEV>,<GWADR>,<IDX>)SYSTEM_CALL 'LON1_NX Read State' (<vdvDEV>,<GWADR>,<IDX>)SYSTEM_CALL 'LON1_NX Read Setting' (<vdvDEV>,<GWADR>,<IDX>)SYSTEM_CALL 'LON1_NX Read Tempp' (<vdvDEV>,<GWADR>,<IDX>)SYSTEM_CALL 'LON1_NX Read Preset' (<vdvDEV>,<GWADR>,<IDX>)SYSTEM_CALL 'LON1_NX Read Count' (<vdvDEV>,<GWADR>,<IDX>)SYSTEM_CALL 'LON1_NX Read TimeStamp' (<vdvDEV>,<GWADR>,<IDX>)SYSTEM_CALL 'LON1_NX Read Scene' (<vdvDEV>,<GWADR>,<IDX>)SYSTEM_CALL 'LON1_NX Read Occupancy' (<vdvDEV>,<GWADR>,<IDX>)

<vdvDEV> - Adresse der virtuellen Schnittstelle<GWADR> - Gatewayadresse 1<IDX> - Indexnummer auf die anzusprechende NV:

SWITCH - 1..64STATE - 1..16SETTING - 1..64TEMPP - 1..32PRESET - 1..32COUNT - 1..32TIMESTAMP - 1SCENE - 1..32OCCUPANCY - 1..32

Wird eine NV abgefragt, werden alle Elemente dieser NV erneut aus dem Gateway ausgelesen. EineAusnahme hiervon ist STATE, da hier je NV eigentlich nur 1 Element zurückgeliefert wird, in diesemElement jedoch binär 16 Stati verschlüsselt sind.

WICHTIG: Das Abfragen von Werten bezieht sich NICHT auf die Abfrage eines anderen LON-Knotens, sondern nur auf das erneute Auslesen einer NV im angegebenen Gateway!

Setzen von WertenDas Setzen von Werten wird ebenfalls über SYSTEM_CALLs realisiert. Der prinzipielle Aufbau istderselbe wie beim Auslesen, es kommen allerdings je nach NV-Typ noch weitere Parameter hinzu.

SWITCHSYSTEM_CALL 'LON1_NX Set Switch'(<vdvDEV>,<GWADR>,<IDX>,<VALUE>,<STATE>)

<vdvDEV> - Adresse der virtuellen Schnittstelle<GWADR> - Gatewayadresse - 1<IDX> - Indexnummer auf die NV - 1..64<VALUE> - 0.0 .. 100.0 (in %)<STATE> - 0 .. 1

Beispiel:SYSTEM_CALL 'LON1_NX Set Switch'(vdvLON,1,13,75.6,1)

Je nach LON-Systemdesign kann es vorkommen, dass nur <VALUE> oder nur <STATE> übertragenwerden müssen oder dürfen. Hierzu wird der Parameter, der nicht zum Gateway gesendet werdensoll, auf einen Wert ausserhalb seines gültigen Bereiches gesetzt:

Beispiel:SYSTEM_CALL 'LON1_NX Set Switch'(vdvLON,1,23,200,1)

Hier wird auf Gateway 1 die SWITCH-Variable 23 auf STATE 1 gesetzt, ohne dass <VALUE> mitübertragen wird.

24

STATESYSTEM_CALL 'LON1_NX Set State'(<vdvDEV>,<GWADR>,<IDX>,<ELEMENT>,<STATE>)

<vdvDEV> - Adresse der virtuellen Schnittstelle<GWADR> - Gatewayadresse - 1<IDX> - Indexnummer auf die NV - 1..16<ELEMENT> - 1 .. 16<STATE> - 0 .. 1

Beispiel:SYSTEM_CALL 'LON1_NX Set State'(vdvLON,1,3,12,1)

Beim SNVT STATE sind 16 Binärinformationen innerhalb der NV verschlüsselt. In der Summe ergibtdas 16x16 Binärinformationen, also 256.

Der SYSTEM_CALL ist so ausgelegt, dass jedes Bit einzeln gesetzt wird.Dabei ist zu beachten, dass Bit15 der NV als Element 1, Bit0 der NV als Element 16 angesprochenwird.

SETTINGSYSTEM_CALL'LON1_NX Set Setting' (<vdvDEV>,<GWADR>,<IDX>,<FUNCTION>,<SETTING>,<ROTATION>)

<vdvDEV> - Adresse der virtuellen Schnittstelle<GWADR> - Gatewayadresse - 1<IDX> - Indexnummer auf die NV - 1.. 64<FUNCTION> - 0 .. 5

0 = SET OFF (aus)1 = SET ON (ein)2 = SET DOWN (abwärts, dunkler)3 = SET UP (aufwärts, heller)4 = SET STOP (UP oder DOWN stoppen)5 = SET STATE (sollte nicht benutzt werden)

<SETTING> - 0 .. 100 (in % des vollen Bereiches)<ROTATION> - -359.98 .. 360.00 (in °, zB Jalousie schwenken)

Beispiel:SYSTEM_CALL 'LON1_NX Set State'(vdvLON,1,44,4,75,0)

Je nach LON-Design oder LON-Knoten kann es vorkommen, dass <ROTATION> nicht Richtung LONübergeben werden muss oder darf. In diesem Fall wird für <ROTATION> ein Wert > 360.00 in denSystem_Call übergeben.

TEMPPSYSTEM_CALL 'LON1_NX Set Tempp'(<vdvDEV>,<GWADR>,<IDX>,<VALUE>)

<vdvDEV> - Adresse der virtuellen Schnittstelle<GWADR> - Gatewayadresse - 1<IDX> - Indexnummer auf die NV - 1..32<VALUE> - -273.17..327.66 (°C)

Beispiel:SYSTEM_CALL 'LON1_NX Set Tempp'(vdvLON,1,3,-25.22)

Bei positiven Temperaturwerten muss kein '+' angegeben werden.Die Nachkomma-Stellen müssen ebenfalls nicht angegeben werden. Falls sie angegeben wird, musssie in amerikanischer Notierung mit einem '.' (Punkt) angegeben werden.

25

PRESETSYSTEM_CALL 'LON1_NX Set Preset'(<vdvDEV>,<GWADR>,<IDX>,<LEARN>,<SELECTOR>)

<vdvDEV> - Adresse der virtuellen Schnittstelle<GWADR> - Gatewayadresse - 1<IDX> - Indexnummer auf die NV - 1..32<LEARN> - Funktionsmodus - 0 = RECALL (Preset abrufen)<SELECTOR> - Presetnummer 1..65535

Beispiel:SYSTEM_CALL 'LON1_NX Set Preset'(vdvLON,1,14,0,3456)

Der PRESET System_Call unterstützt nur den LEARN-Mode 0, also das Aufrufen eines Presets.Es gibt weitere LEARN-Modi und Parameter bei PRESET-NVs, es macht jedoch keinen Sinn, dieseseitens AMX zu benutzen.

COUNTSYSTEM_CALL 'LON1_NX Set Count'(<vdvDEV>,<GWADR>,<IDX>,<VALUE>)

<vdvDEV> - Adresse der virtuellen Schnittstelle<GWADR> - Gatewayadresse - 1<IDX> - Indexnummer auf die NV - 1..32<VALUE> - 16Bit Wert - 0..65535

Beispiel:SYSTEM_CALL 'LON1_NX Set Count'(vdvLON,1,30,46888)

Über die COUNT-NV lässt sich ein beliebiger 16Bit-Wert Richtung LON übergeben. Was dieser Wertim LON-System bewirkt liegt in den Händen des LON-Integrators.

TIMESTAMPSYSTEM_CALL 'LON1_NX Set Count' (<vdvDEV>,<GWADR>,<IDX>,<YEAR>,<MONTH>,<DAY>,<HOUR>,<MINUTE>,<SECOND>)

<vdvDEV> - Adresse der virtuellen Schnittstelle<GWADR> - Gatewayadresse - 1<IDX> - Indexnummer auf die NV - 1..1<YEAR> - Jahr 1..3000; 0 = nicht spezifiziert, 65535 = "Jahr 0"<MONTH> - Monat 1..12; 0 = nicht spezifiziert<DAY> - Tag 1..31; 0 = nicht spezifiziert<HOUR> - Stunde 0..23<MINUTE> - Minute 0..59 <SECOND> - Sekunde 0..59

Beispiel:SYSTEM_CALL 'LON1_NX Set TimeStamp'(vdvLON,1,1,2003,3,12,14,54,0)

Dieser CALL wird wohl eher selten gebraucht werden, da es auf LON-Seite diverse Uhren alsNetzwerk-Komponenten gibt.

26

SCENESYSTEM_CALL 'LON1_NX Set Scene'

(<vdvDEV>,<GWADR>,<IDX>,<FUNCTION>,<SCENENUMBER>)

<vdvDEV> - Adresse der virtuellen Schnittstelle<GWADR> - Gatewayadresse - 1<IDX> - Indexnummer auf die NV - 1..32<FUNCTION> - Funktionsmodus - 0 = Szenenaufruf<SCENENUMBER> - 1..255

Beispiel:SYSTEM_CALL 'LON1_NX Set Scene'(vdvLON,1,23,0,44)

Der SCENE System_Call unterstützt nur den FUNCTION-Mode 0, also das Aufrufen einer Szene.Es gibt weitere FUNCTION-Modi bei SCENE-NVs, es macht jedoch keinen Sinn, diese seitens AMXzu benutzen.

OCCUPANCYSYSTEM_CALL 'LON1_NX Set Occupancy'(<vdvDEV>,<GWADR>,<IDX>,<VALUE>)

<vdvDEV> - Adresse der virtuellen Schnittstelle<GWADR> - Gatewayadresse - 1<IDX> - Indexnummer auf die NV - 1..32<VALUE> - 8Bit Wert - 0..3

0 - Occupied (Bereich belegt)1 - Unoccupied (Bereich nicht belegt)2 – Bypass (Bereich ist belegt für eine Durchlassfunktion)3 – Standby (Bereich ist temporär unbelegt)

Beispiel:SYSTEM_CALL 'LON1_NX Set Occupancy'(vdvLON,1,30,0)

Die OCCUPANCY Funktion gibt an, ob ein Bereich belegt ist. Dies wird bei Mehrraumlösungeninteressant. Hier sollte der LON-Integrator genauer angeben, was die Funktion tatsächlich bewirkt.

27

Befehlssatz des Moduls

Zur Inbetriebnahme einer AMX-Installation mit LON-Anbindung ist es manchmal unabdingbar,einzelne Befehle abzusetzen oder Debug-Meldungen über ein Terminal zu visualisieren.

Grundsätzlich wird über ein Terminal (NetLinx Studio Terminal, Telnet, etc) mit SEND_COMMANDAnweisungen zum virtuellen LON-Device kommuniziert:

SEND_COMMAND <vdvDEV>,'<COMMAND>'

Sofern in der folgenden Beschreibung nicht besonders beschrieben, braucht die Groß-/Kleinschreibung nicht berücksichtigt werden. Zur korrekten Anzeige muss die Firmware des Netlinx-Master mindestens die Version 2.10.80 sein.

Als erstes Kommando sollte DEBUGON (Funktion siehe dort) an das Modul gesendet werden.

HELP - Liste aller Befehle anzeigen

Terminalkommando: SEND_COMMAND vdvLON,'HELP'

Listet alle verfügbaren Befehle des LON-Moduls auf.

LISTGW - Auflisten der Gateways

LISTGW gibt die Hardware-Adressen der Gateways zurück, die an der NetLinx COM-Schnittstelleerkannt wurden.

Terminalkommando: SEND_COMMAND vdvLON,'LISTGW'Rückmeldung zB: LON GATEWAYS PRESENT - Address(es) 0 1 2 3 4 5 6 7 8 9

Aus dieser Rückmeldung erkennt man, dass alle 10 möglichen Gateways an der COM-Schnittstelleerkannt wurden. *)

Fehlen eine oder mehrere Adressen, so sind diese Gateways beim letzten Scan (siehe SCANGW)noch nicht erkannt worden, oder sie sind gar nicht an der COM vorhanden.

SCANGW - nach Gateways suchen

SCANGW unterbricht den normalen Betrieb des Moduls und sucht an der NetLinx COM-Schnittstellenach Gateways.

Terminalkommando: SEND_COMMAND vdvLON,'SCANGW'Rückmeldung: LON SCAN FOR GATEWAYS - Finished

Vor der obigen Rückmeldung wird zuerst eine Information über die gefundenen Gatewaysausgegeben: *)LON GATEWAYS PRESENT - No Gateways present! --- keine Gateway gefundenLON GATEWAYS PRESENT - Address(es) x x --- Liste der Gatewayadressen (siehe LISTGW)

Danach wird der normale Betrieb wieder aufgenommen.

*) Es wird zur Zeit nur Gateway 0 gemeldet!

28

LOOPON / LOOPOF - Mainline-Schleifenzähler

Mit LOOPON und LOOPOF lässt sich eine Geschwindigkeitsauswertung des Systems ein- bzw.ausschalten.

Terminalkommando: SEND_COMMAND vdvLON,'LOOPON' --- einschaltenTerminalkommando: SEND_COMMAND vdvLON,'LOOPOF' --- ausschalten

Die erste Anzeige erfolgt nach 10 Sekunden, dann alle 10 Sekunden. Es wird letztendlichausgewertet, wie oft in einer Sekunde die Mainline (DEFINE_PROGRAM) durchlaufen wird. Ein Wertunter 100 Loops/sek. ist allgemein bedenklich.

VERSION - Anzeige der Modulversion

VERSION gibt diverse Informationen zum Modul ins Terminal zurück.

Terminalkommando: SEND_COMMAND vdvLON,'VERSION'Rückmeldung (exemplarisch):

NETLINX_SYSTEM- 1NETLINX_FIRMWARE_VERSION- v2.10.85NETLINX_COMPILE_DATE- 03/12/2003NETLINX_APPLICATION_NAME- COMM-TEC LON Gateway ModuleNETLINX_APPLICATION_VERSION- 1.0.1NETLINX_APPLICATION_DATE- 17/02/2003NETLINX_APPLICATION_COMMENT- visit us at: www.comm-tec.deNETLINX_APPLICATION_FILE- CT_LON1_UI1_mod.axs

Die Angabe bei der NETLINX_APPLICATION_VERSION von Modul und Core (sieheCOREVERSION) müssen nicht zwangsläufig identisch sein.

COREVERSION - Version des Treiberkerns

Die COREVERSION zeigt diverse Informationen zum eigentlichen Treiber an.

Terminalkommando: SEND_COMMAND vdvLON,'COREVERSION'Rückmeldung (exemplarisch):

NETLINX_APPLICATION_NAME- COMM-TEC LON Gateway CoreNETLINX_APPLICATION_VERSION- 1.1.0NETLINX_APPLICATION_DATE- 05/03/2003NETLINX_APPLICATION_COMMENT- visit us at: www.comm-tec.de

Die Angabe bei der NETLINX_APPLICATION_VERSION von Core und Modul (siehe VERSION)müssen nicht zwangsläufig identisch sein.

DEBUGON - Ausgabe von Debug-Informationen aktivieren

Terminalkommando: SEND_COMMAND vdvLON,'DEBUGON'

Wird dieser Befehl an das Modul geschickt, wird zuerst intern das Kommando 'MSG ON 2' an denMaster geschickt, damit grundsätzlich alle Terminalmeldungen ausgegeben werden können.Zusätzlich wird innerhalb des Moduls die Ausgabe von Debug-Meldungen beim Betrieb des Modulaktiviert.

DEBUGOF - Ausgabe von Debug-Informationen deaktivieren

Terminalkommando: SEND_COMMAND vdvLON,'DEBUGON'

Hiermit wird die Ausgabe von LON-Debugmeldungen wieder abgeschaltet.

29

Zusätzliche Kommandos und Funktionen

Neben den vorher aufgeführten Kommandos, die hauptsächlich der Initialisierung und Fehlersuchedienen, sind im Modul weitere Funktionen implementiert, die das Zusammenwirken von LON und AMXkomfortabler machen.

TSTAMP2AMX - Setzen von Datum und Uhrzeit der AMX mit TimeStamp

Terminalkommando: SEND_COMMAND vdvLON,'TSTAMP2AMX'

Durch dieses Kommando wird die Rückmeldung der TIMESTAMP-NV benutzt, um Datum und Uhrzeitim NetLinx-Master zu setzen.

Achtung: Voraussetzung hierzu ist natürlich eine TIMESTAMP-Rückmeldung seitens LON.Ansonsten könnten Datum und Uhrzeit des NetLinx-Master auf ungewollte Werte gesetzt werden.

TSTAMP2AMX-TIME - Setzen der Uhrzeit der AMX mit TimeStamp

Terminalkommando: SEND_COMMAND vdvLON,'TSTAMP2AMX-TIME'

Durch dieses Kommando wird die Rückmeldung der TIMESTAMP-NV benutzt, um die Uhrzeit imNetLinx-Master zu setzen.

Achtung: Voraussetzung hierzu ist natürlich eine TIMESTAMP-Rückmeldung seitens LON.Ansonsten könnte die Uhrzeit des NetLinx-Master auf ungewollte Werte gesetzt werden.

TSTAMP2AMX-DATE - Setzen des Datums der AMX mit TimeStamp

Terminalkommando: SEND_COMMAND vdvLON,'TSTAMP2AMX-DATE'

Durch dieses Kommando wird die Rückmeldung der TIMESTAMP-NV benutzt, um das Datum imNetLinx-Master zu setzen.

Achtung: Voraussetzung hierzu ist natürlich eine TIMESTAMP-Rückmeldung seitens LON.Ansonsten könnte das Datum des NetLinx-Master auf ungewollte Werte gesetzt werden.

Anzeige "Modul in Betrieb / Modul beschäftigt"

Das Software-Modul arbeitet zum Systemstart und im laufenden Betrieb eine Vielzahl von internenProzessen ab. Während bestimmter Prozesse ist eine Kommunikation zwischen AMX-Programm undModul bzw. Gateway nicht möglich (u. A. Initialisierung beim Systemstart und bei SCANGW). Dieswird über Channel 1 des virtuellen LON-Devices angezeigt:

[vdvLON,1] -> OFF = Beschäftigt, ON = Normalbetrieb

Anzeige "Gateway Erkannt"

Das Software-Modul prüft beim Systemstart, alle ca. 5 Minuten zwischendurch und auf dasKommando SCANGW hin, ob ein Gateway angeschlossen ist. Wird das Gateway erkannt, wirdChannel 10 des virtuellen LON-Devices gesetzt.

[vdvLON,10] -> OFF = kein Gateway erkannt, ON = Gateway erkannt

30

Anhang A

Die Include-Datei CT_LON1_FB_HANDLING.axiDie COMM-TEC LON-Gateway Lösung besteht aus den System_Calls zum Absetzen von Wertensowie aus dem eigentlichen Treibermodul. Dabei werden die Rückmeldungen aus LON in dieWertetabellen geschrieben, die beim Modulaufruf angegeben werden müssen.

Mit diesen 3 Grundelementen ist der LON-Treiber grundsätzlich lauffähig, allerdings kann dieAuswertung der Werte in den Tabellen recht aufwändig sein.

Als Option steht hierzu zusätzlich die Include-Datei CT_LON1_FB_HANDLING.AXI zur Verfügung.Die Funktionen, die in dieser Include hinterlegt bzw vorbereitet sind, erleichtern die Auswertung derzurückgemeldeten Werte der Gateways.

Grundlage hierzu ist eine TIMELINE, die für die zyklische Aktualisierung von Rückmeldungen an dasoder die Panel(s) zuständig ist:

DEFINE_CONSTANT// Timeline identifierLONG lTL_LON_FB = 65001 // eindeutige ID im gesammten Code

DEFINE_VARIABLE// das Zeitintervall, um die Rückmeldungen zu aktualisierenLONG lTL_LON_FB_TIMES[] = { 500 } // in Millisekunden

DEFINE_START// Endlos-TimelineTIMELINE_CREATE(lTL_LON_FB,lTL_LON_FB_TIMES, LENGTH_ARRAY(lTL_LON_FB_TIMES), TIMELINE_RELATIVE,TIMELINE_REPEAT)

Diese Timeline wird beim Systemstart eingerichtet und gestartet, und läuft dann endlos weiter(TIMELINE_REPEAT).

Alle Rückmeldungen werden dann in einem TIMELINE_EVENT notiert:

DEFINE_EVENTTIMELINE_EVENT[lTL_LON_FB]{ //*** Alle LON Rückmeldefunktionen kommen hier hinein *** // Feedback aus STATE1, Element 1 [dvPANEL,11] = (nLON_STATE_RM[1][1][1]) //Feedback aus STATE1, Element 16 [dvPANEL,12] = (nLON_STATE_RM[1][1][16])

// Feedback aus STATE16, Element 1 [dvPANEL,13] = (nLON_STATE_RM[1][16][1]) // Feedback aus STATE16, Element 16 [dvPANEL,14] = (nLON_STATE_RM[1][16][16])}

Damit werden alle 500ms (Zeit definiert durch lTL_LON_FB ) die Rückmeldungen an das Panelaktualisiert.

31

Zusätzlich finden sich in dieser INCLUDE noch einige Funktionen, die für die Auswertung dergemeldeten Werte hilfreich sind.

DEFINE_FUNCTION LON_UPDATE_FEEDBACK(<Time Until Refresh in ms>)

Aufruf: LON_UPDATE_FEEDBACK(<Zeit>)Funktion:BUTTON_EVENT[dvPANEL,0]{ PUSH: { LON_UPDATE_FEEDBACK(5) }}

Diese Funktion setzt im Beispiel die Timeline auf 5 Millisekunden vor Ausführung desTIMELINE_EVENTs vor, um die Aktualisierung an das Touchpanel zu beschleunigen.

Durch die Channelnummer 0 beim angegebenen Device werden alle PUSHes registriert. Dabei ist zubeachten, dass PUSH Anweisungen dieses Devices in DEFINE_PROGRAM dann allerdings nichtmehr funktionieren! Andere BUTTON_EVENTs auf dieses Devices funktionieren weiterhin wiegewohnt.

DATA_EVENT[<Virtual LON Device>]

TEMPP-RückmeldungenNeben der Speicherung der empfangenen Temperaturwerte im TEMPP-Array (s. Rückmeldungen)werden vom Modul diese Werte bei einer Änderung zusätzlich noch als ASCII-String zurückgemeldet.Die Überprüfung auf Änderung erfolgt im Modul alle 500ms, es werden nur geänderte Werteausgegeben. Mit dieser Funktion lassen sich Anzeigen auf Touchpanels leicht realisieren.

Format: " TEMPP.VALUE'<Gateway Adr>'/'<TEMPP Index>':<Temperature>'' "

Beispiel: 'TEMPP.VALUE1/1:-123.45' // Gateway1, nviTEMPP1, Wert -123.45 (°C)

Die Temperaturwerte werden immer mit 2 Stellen hinter dem Komma ausgegeben. Eine möglicheAnwendung geht aus der Beispieldatei hervor.

Weitere FunktionenDiese INCLUDE-Datei wird von COMM-TEC ständig um weitere Funktionen erweitert. Updates undInformationen hierzu sind im "Treiber und Tools" Bereich unter www.comm-tec.de zu finden.

32

Anhang B

Beispiel: Hauptprogramm

Das CTG-LON ist bei Auslieferung mit einer kleinen Applikation geladen, welche die Werte der jeweilsersten NVO-Variablen jeden Typs auf die erste NVI-Variable des gleichen Typs wieder zurückgibt - einkleines LON-System!Das Beispielprogramm basiert auf dieser Applikation.

PROGRAM_NAME='CT_LON1_Beispiel_nx,Rev 0'(*{{PS_SOURCE_INFO(PROGRAM STATS) *)(***********************************************************)(***********************************************************)(* ORPHAN_FILE_PLATFORM: 1 *)(***********************************************************)(***********************************************************)(* AB HIER: GERAETE - DEFINITIONEN *)(***********************************************************)DEFINE_DEVICE

dvLON = 5001:1:0 // COM PortvdvLON = 33001:1:0 // Virtuelles Device zur Kommunikation

dvPANEL = 128:1:0 // Touchpanel

(***********************************************************)(* AB HIER: VARIABLEN - DEFINITIONEN *)(***********************************************************)DEFINE_VARIABLE// Arrays für RückmeldungenFLOAT fLON_SWITCH_RM[10][64][2] // 10 Gateways a 64 SWITCHer mit 2 WertenINTEGER nLON_STATE_RM[10][16][16] // 10 Gateways a 16 STATEs mit 16 WertenFLOAT fLON_SETTING_RM[10][64][3] // 10 Gateways a 64 SETTINGs mit 3 WertenFLOAT fLON_TEMPP_RM[10][32][1] // 10 Gateways a 32 TEMPPs mit 1 WertINTEGER nLON_PRESET_RM[10][32][11] // 10 Gateways a 32 SETTINGs mit 11 WertenINTEGER nLON_COUNT_RM[10][32][1] // 10 Gateways a 32 COUNTs mit 1 WertINTEGER nLON_TIMESTAMP_RM[10][1][6] // 10 Gateways a 1 TIMESTAMP mit 6 WertenINTEGER nLON_SCENE_RM[10][32][2] // 10 Gateways a 32 SCENEs mit 2 Werten

VOLATILE INTEGER nGW_PROTOKOLL = 0 // 1=RS232, Anderer Wert = RS485

(***********************************************************)(* AB HIER: DEFINITION VON UNTERPROGRAMMEN *)(***********************************************************)

#INCLUDE 'CT_LON1_FB_HANDLING.axi'

(***********************************************************)(* AB HIER: INITIALISIERUNG DES SYSTEMS *)(***********************************************************)DEFINE_START

(***********************************************************)(* AB HIER: Module *)(***********************************************************)

DEFINE_MODULE 'CT_LON1_UI1_mod'LON (vdvLON, // Virtuell dvLON, // Hardware fLON_SWITCH_RM, nLON_STATE_RM, fLON_SETTING_RM, fLON_TEMPP_RM, nLON_PRESET_RM, nLON_COUNT_RM, nLON_TIMESTAMP_RM, nLON_SCENE_RM, nGW_PROTOKOLL) // Protokolltyp

33

(***********************************************************)(* AB HIER: DIE EVENTS *)(***********************************************************)DEFINE_EVENT

// nviSWITCH 1BUTTON_EVENT[dvPANEL,1] // EIN{ PUSH: { // typisch für EIN: Value 100(%) State 1 SYSTEM_CALL 'LON1_NX Set Switch'(vdvLON,1,1,100,1) }}BUTTON_EVENT[dvPANEL,2] // AUS{ PUSH: { // typisch für EIN: Value 0(%) State 0 SYSTEM_CALL 'LON1_NX Set Switch'(vdvLON,1,1,0,0) }}

// nvoSTATE1// Die einzelnen Bits werden invertiert angesprochen, d.h.// Bit15 ist Stelle 1, Bit0 ist Stelle 16BUTTON_EVENT[dvPANEL,11] // Bit 0{ PUSH: { SYSTEM_CALL 'LON1_NX Set State'(vdvLON,1,1,16,1) } RELEASE: { SYSTEM_CALL 'LON1_NX Set State'(vdvLON,1,1,16,0) }}

BUTTON_EVENT[dvPANEL,19]{ PUSH: { SYSTEM_CALL 'LON1_NX Set State'(vdvLON,1,1,8,0) } RELEASE: { SYSTEM_CALL 'LON1_NX Set State'(vdvLON,1,1,8,1) }}

BUTTON_EVENT[dvPANEL,26] // Bit 15{ PUSH: { SYSTEM_CALL 'LON1_NX Set State'(vdvLON,1,1,1,1) } RELEASE: { SYSTEM_CALL 'LON1_NX Set State'(vdvLON,1,1,1,0) }}

// nvoSETTING1BUTTON_EVENT[dvPANEL,31]{ PUSH: // typisch für SETTING ON { // nur SET ON, kein <SETTING> und <ROTATION> SYSTEM_CALL 'LON1_NX Set Setting'(vdvLON,1,1,1,1000,1000) }}BUTTON_EVENT[dvPANEL,32]{ PUSH: // typisch für SETTING ON { // nur SET OFF, kein <SETTING> und <ROTATION> SYSTEM_CALL 'LON1_NX Set Setting'(vdvLON,1,1,0,1000,1000) }}

34

BUTTON_EVENT[dvPANEL,33] // aufwärts/heller{ PUSH: // typisch für SET UP { // 100% SET UP, kein <ROTATION> SYSTEM_CALL 'LON1_NX Set Setting'(vdvLON,1,1,3,100,1000) } RELEASE: // typisch SET STOP { // 100% SET STOP, kein <ROTATION> SYSTEM_CALL 'LON1_NX Set Setting'(vdvLON,1,1,4,100,1000) }}

BUTTON_EVENT[dvPANEL,34] // abwärts/dunkler{ PUSH: // typisch für SET DOWN { // 100% SET DOWN, kein <ROTATION> SYSTEM_CALL 'LON1_NX Set Setting'(vdvLON,1,1,2,100,1000) } RELEASE: // typisch SET STOP { // 100% SET STOP, kein <ROTATION> SYSTEM_CALL 'LON1_NX Set Setting'(vdvLON,1,1,4,100,1000) }}

// vnoTEMPP1BUTTON_EVENT[dvPANEL,41] // ein Grad wärmer{ PUSH: { TO[BUTTON.INPUT] SYSTEM_CALL 'LON1_NX Set Tempp'(vdvLON,1,1,(fLON_TEMPP_RM[1][1][1] + 1)) } HOLD[10,REPEAT]: { SYSTEM_CALL 'LON1_NX Set Tempp'(vdvLON,1,1,(fLON_TEMPP_RM[1][1][1] + 1)) }}BUTTON_EVENT[dvPANEL,42] // ein Grad kälter{ PUSH: { TO[BUTTON.INPUT] SYSTEM_CALL 'LON1_NX Set Tempp'(vdvLON,1,1,(fLON_TEMPP_RM[1][1][1] - 1)) } HOLD[10,REPEAT]: { SYSTEM_CALL 'LON1_NX Set Tempp'(vdvLON,1,1,(fLON_TEMPP_RM[1][1][1] - 1)) }}BUTTON_EVENT[dvPANEL,43] // Temperatur manuell abfragen{ PUSH: { TO[BUTTON.INPUT] SYSTEM_CALL 'LON1_NX Read Tempp'(vdvLON,1,1) }}

// nvoPRESET1BUTTON_EVENT[dvPANEL,51] // Preset Baustein 1, Preset-Nummer 1{ PUSH: { SYSTEM_CALL 'LON1_NX Set Preset'(vdvLON,1,1,0,1) }}BUTTON_EVENT[dvPANEL,52] // Preset Baustein 1, Preset-Nummer 2{ PUSH: { SYSTEM_CALL 'LON1_NX Set Preset'(vdvLON,1,1,0,2) }}

35

// nvoCOUNT1BUTTON_EVENT[dvPANEL,61]{ PUSH: { SYSTEM_CALL 'LON1_NX Set Count'(vdvLON,2,1,0) }}BUTTON_EVENT[dvPANEL,62]{ PUSH: { SYSTEM_CALL 'LON1_NX Set Count'(vdvLON,2,1,44444) }}

// nvoTIMESTAMP1BUTTON_EVENT[dvPANEL,71]{ PUSH: { TO[BUTTON.INPUT] // Uhrzeit setzen: 6.2.2003, 12:45:00 SYSTEM_CALL 'LON1_NX Set TimeStamp'(vdvLON,1,1,2003,2,6,12,45,0) }}BUTTON_EVENT[dvPANEL,72]{ PUSH: { TO[BUTTON.INPUT] // Uhrzeit setzen: 23.1.2004, 00:00:00 SYSTEM_CALL 'LON1_NX Set TimeStamp'(vdvLON,1,1,2004,1,23,0,0,0) }}

BUTTON_EVENT[dvPANEL,73]{ PUSH: { TO[BUTTON.INPUT] // Uhr des Masters aktualisieren SEND_COMMAND vdvLON,'TSTAMP2AMX' }}

// nvoSCENE1BUTTON_EVENT[dvPANEL,81]{ PUSH: { SYSTEM_CALL 'LON1_NX Set Scene'(vdvLON,1,1,0,15) }}BUTTON_EVENT[dvPANEL,82]{ PUSH: { SYSTEM_CALL 'LON1_NX Set Scene'(vdvLON,1,1,0,111) }}

(***********************************************************)(* AB HIER: DAS EIGENTLICHE PROGRAMM *)(***********************************************************)DEFINE_PROGRAM

(***********************************************************)(* PROGRAMMENDE *)(***********************************************************)

36

PROGRAM_NAME='CT_LON1_FB_HANDLING'(*{{PS_SOURCE_INFO(PROGRAM STATS) *)(***********************************************************)(***********************************************************)(* FILE_LAST_MODIFIED_ON: 05/26/2003 AT: 17:35:56 *)(***********************************************************)(***********************************************************)(* ORPHAN_FILE_PLATFORM: 1 *)(***********************************************************)DEFINE_CONSTANT

CHAR CT_LON1_FB_HANDLING_VERSION[] = '1.0.0'

// Timeline identifierLONG lTL_LON_FB = 65001 // eindeutige ID im gesammten Code

(***********************************************************)DEFINE_VARIABLE// das/die Zeitintervall(e), um die Rückmeldungen zu aktualisierenLONG lTL_LON_FB_TIMES[] = { 500 } // in Millisekunden

(***********************************************************)

// Dieser CALL setzt die Timeline kurz vor den TriggerDEFINE_FUNCTION LON_UPDATE_FEEDBACK(MS){ // Timeline auf 5ms vor Trigger setzen TIMELINE_SET(lTL_LON_FB,(lTL_LON_FB_TIMES[1]- MS))}

(***********************************************************)DEFINE_START// Endlos-TimelineTIMELINE_CREATE(lTL_LON_FB,lTL_LON_FB_TIMES,LENGTH_ARRAY(lTL_LON_FB_TIMES),TIMELINE_RELATIVE,TIMELINE_REPEAT)

(***********************************************************)DEFINE_EVENT// Alle Panels hier auflistenBUTTON_EVENT[dvPANEL,0] // Channel 0 sammelt alle Button Funktionen auf{ PUSH: { // Wenn ein Button gedrückt wird, wird die Timeline auf kurz vor Ausführung gesetzt LON_UPDATE_FEEDBACK(5) }}

// Das Modul gibt die empfangenen Temperaturen als String vom virtuellen Device zurück.// Syntax 'TEMPP.VALUE<GatewayNr>/<Index>:<Temperatur>'// Beispiel: 'TEMPP.VALUE1/13:-123.45' (Gateway 1, nviTEMPP 13, -123.45 °C)DATA_EVENT[vdvLON]{ STRING: { STACK_VAR CHAR sSCHROTT[30],sTMP[10] STACK_VAR INTEGER nGW,nIDX SELECT { ACTIVE(FIND_STRING(DATA.Text,"'TEMPP.VALUE'",1)): // Temperaturrückmeldung { //SEND_STRING 0,"DATA.Text,13,10" Ausgabe zum Terminal sSCHROTT = REMOVE_STRING(DATA.Text,"'TEMPP.VALUE'",1) // Schlüsselwort entfernen;DATA.Text= '1/13:-123.45'' sTMP = REMOVE_STRING(DATA.Text,"'/'",1) // sTMP= '1/', DATA.Text= '13:-123.45' nGW = ATOI("sTMP") // Gateway number ermitteln; nGW= "1" sTMP = '' // sTMP freimachen sTMP = REMOVE_STRING(DATA.Text,"':'",1) // sTMP= '13:' DATA.Text= '-123.45' nIDX = ATOI("sTMP") // TEMPP Index ermitteln; nIDX= "13"

// weiter nächste Seite

37

{ CASE 1: // eine TEMPP Rückmeldung von Gateway 1 { SWITCH(nIDX) // Welche nviTEMPP? { CASE 1: // nviTEMPP1 { SEND_COMMAND dvPANEL,"'@TXT',1,DATA.Text" // zum Panel schicken; DATA.Text= '-123.45' } CASE 2: // nviTEMPP2 { } // ...32 } } (* für zukünftige Features CASE 2: { } // ...10 *) } } } }}

TIMELINE_EVENT[lTL_LON_FB]{ //*** Alle LON Rückmeldefunktionen kommen hier hinein *** // nviSWITCH1 [dvPANEL,1] = (fLON_SWITCH_RM[1][1][2] = 1) // Feedback aus STATE Element von SWITCH [dvPANEL,2] = (fLON_SWITCH_RM[1][1][2] = 0) // Feedback aus STATE Element von SWITCH

// nviSTATE1 // die Bits werden invertiert abgebildet, d.h. Stelle 1 ist Bit15, Stelle 16 ist Bit0 [dvPANEL,11] = (nLON_STATE_RM[1][1][16] = 1) // Bit 0 [dvPANEL,19] = (nLON_STATE_RM[1][1][8] = 1) // Bit 8 [dvPANEL,26] = (nLON_STATE_RM[1][1][1] = 1) // Bit 15

//nviSETTING1 [dvPANEL,31] = (fLON_SETTING_RM[1][1][1] = 1) // Function SET ON [dvPANEL,32] = (fLON_SETTING_RM[1][1][1] = 0) // Function SET OFF [dvPANEL,33] = (fLON_SETTING_RM[1][1][1] = 3) // Function SET UP [dvPANEL,34] = (fLON_SETTING_RM[1][1][1] = 2) // Function SET DOWN

// nviTEMPP1 siehe DATA_EVENT[vdvLON]

// nviPRESET1 [dvPANEL,51] = (nLON_PRESET_RM[1][1][2] = 1) // Preset Selector 1 [dvPANEL,52] = (nLON_PRESET_RM[1][1][2] = 2) // Preset Selector 2

// nviTIMESTAMP1 siehe Beispiel, Buttons 73

// vniSCENE1 [dvPANEL,81] = (nLON_SCENE_RM[1][1][2] = 15) // Scenenumber 15 [dvPANEL,82] = (nLON_SCENE_RM[1][1][2] = 111) // Scenenumber 111

[dvPANEL,101] = [vdvLON,1] // gesetzt wenn Modul im Normalbetrieb

[dvPANEL,102] = [vdvLON,10] // gesetzt wenn Gateway gefunden}

38

Anhang C

Debug- und FehlermeldungenIn einigen Situationen erzeugt das Modul Meldungen, die ins Terminalfenster umgeleitet werdenkönnen. Vorraussetzung zur Ausgabe dieser Fehlermeldungen ist, dass im Terminal als erstesfolgendes Kommando an das LON-Modul gesendet wird:

Terminalkommando: SEND_COMMAND vdvLON,'DEBUGON'

Wird dieser Befehl an das Modul geschickt, wird zuerst intern das Kommando 'MSG ON 2' an denMaster geschickt, damit grundsätzlich alle Terminalmeldungen ausgegeben werden können. Zusätzlichwird innerhalb des Moduls die Ausgabe von Debug-Meldungen beim Betrieb des Modul aktiviert.

Die Meldungen werden als Klartext dargestellt und erklären von sich aus die Ursache, wobei dasFehlerelement in <..> dargestellt wird.Folgend nun die häufigsten Meldungen

Allgemein:• "NV-BUFFER: <received Data>" Es wird der vom Gateway empfangene String angezeigt.

Eventuell "kryptische" Symbole sind Steuerzeichen (Startbyte, Endbyte, etc) innerhalb derRückmeldung.

• "LON COMMAND - Gateway <..> not present, Command ignored!" Das gesendete Kommandowurde an das vorab nicht erkannte Gateway <Adresse 0..9> geschickt.

• "LON ERROR - Unknown command" Das Treibermodul hat ein unbekanntes Kommandoerhalten.

• "LON COMMAND - Gateway scan in progress, Command hold in Queue!" Das Modul prüftnach angeschlossenen Gateways. In dieser Zeit können keine Kommandos zum LON geschicktwerden. Die Kommandos werden in der Sendeschlange gehalten bis die Überprüfungabgeschlossen ist.

• " SysCall CTLON1 SET <NV Type: Gateway <Number> out of range!" Die Gatewaynummer istzu groß (>10) oder zu klein (<1)

• " SysCall CTLON1 SET <NV Type>: Device number <Device.Number> out of range!" Dieübergebene Devicenummer ist zu groß (>36863) oder zu klein (<33001).

• " SysCall CTLON1 READ <NV Type>: Gateway <Number> out of range!" Die Gatewaynummerist zu groß (>10) oder zu klein (<1)

• " SysCall CTLON1 READ <NV Type>: Device number <Device.Number)> out of range!" Dieübergebene Devicenummer ist zu groß (>36863) oder zu klein (<33001).

Switch:• "SysCall CTLON1 SET SWITCH: NV-Index <Index> out of range!" NV-Index bei Switch ist 1..64• "SysCall CTLON1 READ SWITCH: NV-Index <Index> out of range!" NV-Index bei Switch

ist 1..64State:• "SysCall CTLON1 SET STATE: NV-Index <Index> out of range!" NV-Index für State ist 1..16• "SysCall CTLON1 SET STATE: State <State> out of range!" <State> ist 0..1• "SysCall CTLON1 SET STATE: Pointer <Pointer> out of range!" <Pointer> zeigt auf das Bit

innerhalb der State-NV; Pointer kann nur 1..16 sein• "SysCall CTLON1 READ STATE: NV-Index <Index> out of range!" NV-Index für State ist 1..16Setting:• "SysCall CTLON1 SET SETTING: NV-Index <Index> out of range!" NV-Index für Setting ist 1..64• "SysCall CTLON1 SET SETTING: Function <Function> unknown!" Unbekannte

Funktionsnummer; gültige Funktionsnummern sind 0..5• "SysCall CTLON1 SET SETTING: Setting <Setting> out of range!"

Gültige Werte für Setting sind 0..100(%)• "SysCall CTLON1 SET SETTING: Rotation <Rotation> out of range!"

Gültige Werte für Rotation sind -359.98 .. +360.00 (°), oder >360.00, wenn kein Rotation-WertRichtung LON gesendet werden muss oder darf

• "SysCall CTLON1 READ SETTING: NV-Index <Index> out of range!" NV-Index für Settingist 1..64

Tempp:• "SysCall CTLON1 SET TEMPP: Temp <Value> out of range!" NV-Index für Temp ist 1..32• "SysCall CTLON1 SET TEMPP: Temp <Value> out of range!"

Gültige Werte sind -273.17 .. 327.66 (°C)• "SysCall CTLON1 READ TEMPP: Temp <Value> out of range!" NV-Index für Temp ist 1..32

39

Preset:• "SysCall CTLON1 SET PRESET: NV-Index <Index> out of range!" NV-Index für Preset ist 1..32• "SysCall CTLON1 SET PRESET: Learn mode <Learnmode> not supported!"

Als Learn-Mode wird seitens der AMX nur 0 (Null) unterstützt (Recall)• "SysCall CTLON1 SET PRESET: Selector <Selector> out of range!"

gültige Selector-Werte sind 1 .. 65535• "SysCall CTLON1 READ PRESET: NV-Index <Index> out of range!"

NV-Index für Preset ist 1..32Count:• "SysCall CTLON1 SET COUNT: NV-Index <Index> out of range!" NV-Index für Count ist 1..32• "SysCall CTLON1 SET COUNT: Value <Value> out of range!" gültige Value-Werte sind 0..65535• "SysCall CTLON1 READ COUNT: NV-Index <Index> out of range!" NV-Index für Count ist 1..32TimeStamp:• "SysCall CTLON1 SET TIMESTAMP: NV-Index <Index> out of range!"

NV-Index für Timestamp ist 1• "SysCall CTLON1 SET TIMESTAMP: Year <Year> out of range!"

Gültige Werte für Year sind 0, 1..3000, und 65535• "SysCall CTLON1 SET TIMESTAMP: Month <Month> out of range!"

Gültige Werte für Month sind 0 sowie 1..12• "SysCall CTLON1 SET TIMESTAMP: Day <Day> out of range!"

Gültige Werte für Day sind 0 sowie 1..31• "SysCall CTLON1 SET TIMESTAMP: Hour <Hour> out of range!"

Gültige Werte für Hour sind 0..23• "SysCall CTLON1 SET TIMESTAMP: Minute <Minute> out of range!"

Gültige Werte für Minute sind 0..59• "SysCall CTLON1 SET TIMESTAMP: Second <Second> out of range!"

Gültige Werte für Second sind 0..59• "SysCall CTLON1 READ TIMESTAMP: NV-Index <Index> out of range!"

NV-Index für Timestamp ist 1Scene:• "SysCall CTLON1 SET SCENE: NV-Index <Index> out of range!" NV-index für Scene ist 1..32• "SysCall CTLON1 SET SCENE: Function <Function> unknown!"

Es werden nur Function 0 (Recall) und 1 (Learn) unterstützt• "SysCall CTLON1 SET SCENE: SCENE <Scenenumber> out of range!"

gültige Szenennummern sind 1..255• "SysCall CTLON1 READ SCENE: NV-Index <Index> out of range!" NV-index für Scene ist 1..32Occupancy:• "SysCall CTLON1 SET OCCUPANCY: NV-Index <Index> out of range!" NV-index für

Occupancy ist 1..32• "SysCall CTLON1 SET OCCUPANCY: Value <Value> out of range!" gültige Value-Werte sind

0..3• "SysCall CTLON1 READ OCCUPANCY: NV-Index <Index> out of range!" NV-Index für

Occupancy ist 1..32

Das Modul beinhaltet weitere Debug- und Fehlermeldungen, die aber im Normalbetrieb nicht auftretenkönnen und deshalb hier nicht weiter dokumentiert sind.