Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

Einführung

...

ZUVOR müssen diese Universalobjekte in der Timberwolf Server Applikation in der ETS parametriert und der Timberwolf Server damit programmiert werden.

Info

Programmierung mit der ETS vs. “nur Projektimport”

Viele “KNX Server” am Markt nutzen lediglich einen Projektimport aus der ETS und kommunizieren anschließend über die aus dem Import gelernten GAs mit dem KNX Bus und müssen nicht programmiert werden. Warum ist dies beim Timberwolf Server anders?


KNX Zertifizierung des Timberwolf Servers

Zertifizierte KNX Produkte MÜSSEN den KNX Standard einhalten. Dieser KNX Standard verlangt - unter anderem - dass ein KNX Gerät über Objekte verfügt, die mit Gruppenadressen zu verknüpfen sind und dieses durch die ETS zu programmieren ist.

Daher sind die KNX Objekte des Timberwolf Servers mit der ETS zu programmieren.

”KNX Server” die nur auf Basis von Projektimport / Gruppenadressen kommunizieren ohne vorherige Programmierung mit der ETS entsprechen NICHT dem KNX Standard, wurden nicht auf Einhaltung der Spezifikation geprüft und tragen auch KEIN KNX-Logo.

Berechnung von Filterlisten durch die ETS

KNX erlaubt die Errichtung sehr umfangreiche Anlagen mit über 60.000 KNX Geräten in einem System. Damit Kommunikation hier noch möglich ist, wird die Anlage in Segmente unterteilt, die als Linien bezeichnet werden. Solche Linien werden über Linienkoppler und Bereichskoppler (sowie IP Routern, die Bereichskoppler zwischen KNX-TP und KNXnet/IP sind) miteinander verbunden. Um nur die notwendigen Telegramme über mehrere Linien hinweg zu transportieren, berechnet die ETS entsprechende Filterlisten und lädt diese beim Programmieren der Anlage in die LK und BK.

Damit die ETS diese Filterlisten berechnen kann, muss die ETS die Topologie kennen, das bedeutet, welches KNX Gerät befindet sich in welcher Linie (ergibt sich aus der PA) und welche Gruppenadressen sind mit den Objekten des Gerätes assoziiert. Damit kann die ETS berechnen, welche Gruppenadressen gefiltert werden dürfen und welche nicht (wenn zwei Geräte in zwei verschiedenen Linien die gleiche GA benutzen, dann müssen die LK und BK zwischen diesen beiden Linien diese GA weiterleiten).

Durch die Einbindung der Applikation des Timberwolf Servers in die ETS, der Aktivierung der Objekte des Servers und dem Assoziieren mit Gruppenadressen kann die ETS die Berechnung der Filtertabellen auch für die vom Timberwolf Server genutzten Gruppenadressen korrekt vornehmen.

Für “KNX Server”, die NICHT über die ETS programmiert werden, sondern irgendwo am Bus angesteckt sind und irgendwelche Gruppenadressen benutzen, kann die ETS die Filtertabellen nicht berechnen (hier wäre der ETS nicht bekannt, WO in der Topologie der Server angeschlossen wäre und kennt auch nicht die von diesem Server genutzten Gruppenadressen).
Bei Projekten mit mehreren Linien müssen deshalb “Dummy-Applikation” in der ETS gepflegt werden, mit denen die Parametrisierung solcher nicht zertifizierten “KNX Server” vom Errichter in der ETS simuliert wird, wobei die nötige Sorgfalt einen hohen Aufwand erfordert. Bei Diskrepanzen zwischen den Parametern in einer solchen Dummy Applikation und den tatsächlichen Einstellungen solcher Server können schwer nachvollziehbare Probleme auftreten. Dies wird beim Timberwolf Server vermieden.

Wir sind der Meinung, dass ein KNX Server, der mit vielen tausenden Objekten ausgestattet ist und über mehrere tausend Gruppenadressen mit dem KNX Bus austauscht, vollständig in die ETS eingebettet sein muss, damit die KNX Projektdokumentation diesen Server auch auf korrekte Weise miteinbezieht und damit Filtertabellen korrekt berechnet werden können.

Deshalb ist der Timberwolf Server konform zum KNX Standard ausgelegt, verfügt über eine Applikation für die ETS und ist wie jedes andere konforme KNX Gerät zu parametrisieren.


Berücksichtigung der mit der ETS gesetzten Objekt Flags

Die Art und Weise, wie Objekte in KNX Geräten kommunizieren, wird über Flags der Objekte gesteuert. Diese Flags werden in der ETS angezeigt und verwaltet.

Bei den meisten KNX Geräten sind diese Flags für die jeweiligen Objekte fertig vorgegeben, beim Timberwolf Server sind diese für jedes Objekt einzeln einstellbar. Damit kann das Verhalten im Detail gesteuert und damit können wichtige Funktionen, z.B. für das Hochfahren einer Anlage (z.B. nach Stromausfall) granular gesteuert werden.

Dies ist nur möglich, weil der Timberwolf Server entsprechend dem KNX Standard mit KNX Objekten operiert, die mit der ETS parametriert werden.

Bei den “KNX Servern” die nur über GA kommunizieren, gibt es diese Funktionalität der Flags nicht, da diese zu Objekten zugehörig ist und nicht zu Gruppenadressen.

Wir wollten den Nutzern des Timberwolf Servers keine Kompromisse mit KNX zumuten, daher haben wir die Funktionalität entsprechend dem KNX Standard umgesetzt und deshalb sind die KNX Objekte mit der ETS zu parametrieren und der Server damit zu programmieren. Damit sind diese Objekte auch im Projekt dokumentiert, die Nutzung der Gruppenadressen ebenfalls, die ETS kann die Filtertabellen ordentlich berechnen und das Verhalten der Objekte kann granular über die Flags bestimmt werden.

Das Projekt können Sie trotzdem zusätzlich importieren, das dient dazu, dass der Timberwolf Server auch die Bezeichnungen kennt und die Datenpunkttypen aller Gruppenadressen im System (dies nutzt der Logger für die Dekodierung der Daten).

...