ich wollte Euch einen aktuellen "Zustandsbericht" zum Thema TWS Applikation & ETS geben:
Sachstand zur Timberwolf Server ETS Applikation
Der KNX Stack des Timberwolf Servers ist bereits zertifiziert, die Applikation aber noch nicht. Der Grund liegt darin, dass die KNX Association seit bald einundeinhalb Jahren nicht in der Lage ist, eine Toolchain zu liefern, mit der wir eine Applikation schreiben können, die es erlaubt, alle Möglichkeiten unseres KNX Stacks auch ausnutzen zu können. Avisierte Verbesserungen erweisen sich als Schlag ins Wasser.
Für alle die etwas später eingestiegen sind, hier eine (kurze) Zusammenfassung um was es hier nun eigentlich geht:
Aufgabenstellung:
Bei der Entwicklung des TWS stand steht die Aufgabenstellung "Robust" und "no Limits" und "Einfach" im Vordergrund. Hinsichtlich KNX hatten wir uns damit auch etwas vorgenommen:
- Der TWS muss KNX zertifiziert sein! Keiner der vielen Smarthome Server auf dem Markt ist KNX zertifiziert. Damit entgehen dem Kunden viele Möglichkeiten für eine komplette Integration in KNX-Projekte. Zum einen hat man ein unvollständiges ETS-Projekt, denn der Server ist nicht als Gerät mit aufgeführt. Dies hat dann auch ungünstige Auswirkungen auf das Berechnen der Filterlisten von Linien- und Bereichskopplern. Zudem kann die Macht der Flags nicht genutzt werden. Mit anderen Worten: Es ist eigentlich ein Unding wenn in einem KNX-Projekt ein wichtiger Server enthalten ist, der weder zertifiziert noch Bestandteil des ETS Projektes ist. Darum haben wir uns die Mühe auferlegt, einen zertifizierten KNX Stack für den Timberwolf Server zu entwickeln.
- 8.000 Objekte! Gemäß unserem Wunsch nach "No Limtis" wollen wir den Kunden auch etwas bieten. Also sollten 8000 Objekte möglich sein. Das macht einen KNX Stack nach dem Gerätemodell "System B" erforderlich.
- 64.000 Assoziationen (GA)! Diese 8000 Objekte lassen sich jeweils mit bis zu 16 GAs verknüpfen, insgesamt unterstützt unser Stack 64.000 solcher Assoziationen
- 32 / 64 BitUnser Stack unterstützt 32 und 64 Bit Prozessorarchitekturen.
- DPT der Objekte in der ETS wählbarDie 8.000 Objekt sind Universalobjekte. Diese können beliebig genutzt werden. Damit das funktioniert, kann in unserer Applikation der DPT festgelegt und mit programmiert werden.
- Mehrere Stacks parallel!Prinzipiell kann unser Stack in mehreren Instanzen gestartet werden - jeweils einer pro Interface - womit eine Ausweitung leicht möglich ist. D.h. die 8000 Objekte sind nicht die Grenze. Mit dem mehrfachen Loggen geht das jetzt schon.
Die KNX Toolchain:
Wir haben nicht nur Neuland betreten, sondern sind damit an die Grenzen der ETS Toolchain geraten.
- Manufacturer Tool: Das Manufacturer Tool, kurz "MT", ist das Gegenstück zur ETS. Hiermit legt der Hersteller die Applikation an.
- Engineering Tool Software: Die "ETS" ist die von den Kunden / Anwendern genutzte Software, um die Einstellungen zu tätigen und diese zu "programmieren".
Die Probleme mit der KNX Toolchain:
Leider stellte sich heraus, dass unsere Entwicklungsziele zwar innerhalb des KNX Standards "Modell B" lagen, aber, da es vor uns noch niemand gemacht hatte, die Toolchain der KNX Association das gar nicht vollständig unterstützte.
Das Hauptproblem: Das MT basiert auf einer älteren Version des Visual Studio und ist eine 32 Bit Applikation. Was nicht mehr in den damit adressierbaren Speicher passt, hat eben Pech gehabt.
Bei der Herstellung der Applikation für den Timberwolf Server kam es dann auch bei 2400 Objekten zum Absturz des MT, mehr ging nicht.
==> Daher haben wir die Applikation zunächst nur für 2000 Objekte herausgegeben können, weil mehr schafft das MT nicht.
==> Und weil die ETS4 / ETS Inside auch damit nicht zurecht kam, gibt es auch eine Applikation mit 500 Objekten.
Die avisierte Problemlösung: Die ETS 5.7:
Mit unseren Problemen konfrontiert bekamen wir von der KNX Association die Antwort, dass man an einem neuen Feature arbeitet, dass den Speicherplatzbedarf einer Applikation massiv reduzieren sollte. Davon sollten alle Strukturen profitieren, die irgendwie mehrmals auftreten.
Das kann ein achtfach Dimmer sein, bei dem es achtmal die selben Einstellungen gibt oder - vor allem bei uns - ein Projekt, bei dem mehrere tausendmal die gleiche Struktur vorkommt. Die Lösung dabei: Es wird nicht mehr 8fach (oder 2000 fach) das gleiche in der Datei der Applikation gespeichert (und geladen und gelesen) sondern nur noch EINMAL (mit der Info, dass es das 8 mal gibt, oder 2000 fach). Das soll den Speicherbedarf erheblich reduzieren.
Das ist nun über ein Jahr her. Diese Problemlösung sollte mit der Version 5.7 des MT und der ETS verfügbar sein.
Das Desaster mit der ETS 5.7.0. bis 5.7.2:
Leider war die ETS 5.7 ein ziemlicher Schlag ins Wasser, den für einige Projekte was es ein einziges Desaster. Mehr kann man hierzu hier nachlesen: https://knx-user-forum.de/forum/%C3%B6f ... ffentlicht
Wir haben dann auch mit dem neueren MT die Applikation neu erstellt, allerdings zeigten die Tests durch uns und auch der User dann keine wirkliche Verbesserung.
Wir waren allerdings ein wenig überrascht, dass die Kritik der Kunden so deutlich angestiegen war. Daher haben wir zwei Integratoren um einen neutralen Test gebeten. Bei diesen Tests bekamen wir als Antwort, dass die ETS ab 5.7 (bis 5.7.2) insgesamt sehr langsam und träge geworden war. Die umfangreiche TWS Applikation machte das zwar nicht besser, aber auch nicht signifikant schlechter. Die ETS selbst war erheblich langsamer geworden.
Hinweis: Dieses Thread wurde eröffnet ab Verfügbarkeit der ETS 5.7.2. Bei manchen Anwendern war der Update auf die ETS 5.7.x und die Installation der TWS App in etwa zeitgleich, daher entstand der - für uns ungute - Eindruck, dass unsere Applikation alleine Ursächlich wäre für die teils heftig gewordenen "Antwortzeiten" der ETS und unserer Applikation.
Die avisierte Problemlösung hat einen Namen: "Modulare Applikationsprogrammierung" ("MAP"):
Vor etwa einem Monat habe ich mich erneut an die Führungsetage bei der KNX Association gewendet, zumal am nächsten Tag die Chance auf ein persönliches Treffen anhand einer Veranstaltung (ZVEI) bestand.
Wie immer war die Reaktion schnell und professionell. Ich bekam sofort Antwort und am nächsten Tag wurde ich auch von allen Verantwortlichen bei der Veranstaltung aufgesucht und angesprochen. Man ist sich des Problems bewusst, aber es wäre lange schon gelöst, wir sollten eben einfach das MAP Feature benutzen und erstmal prüfen, ob wir das MAP-Feature überhaupt benutzen würden in unserer Applikation.
Wenn nicht, dann sollten wir dieses Feature aktivieren und dann würden wir einen Turbo erleben, man sei sich da ganz sicher und sehr entspannt.
Ok, dann gehen wir eben wieder zurück auf Los und ziehen nicht 4.000 DM ein. Äh Euro.
Zum ersten Mal haben wir damit den Namen für diese Entwicklung bekommen: "Modulare Applikationsprogrammierung" ("MAP").
Nachgeforscht und festgestellt, dass dies genau die schon länger avisierte Problemlösung sein sollte, also eine immer wieder vorkommende Struktur wird als Template angelegt und dieses kann dann mehrfach benutzt werden, wird aber nur einmal gespeichert. Hurra, endlich DER Wegweiser.
Damit bei unserer KNX Entwicklung aufgeschlagen. Das Stichwort MAP kannte man noch nicht, weil leider, entgegen wie man sich das vorstellt, gibt es zum MT keine umfassende Doku und auch keine Erklärungen oder Feature Listen. Dafür gibt es das MT schon in der Version 5.7.4.
Tja, in der Dokumentation fand sich nichts. Also alle Verzeichnisse durchgewühlt und im zigsten Unterverzeichnis fand sich dann ein Beispiel für MAP. Das wurde dann genutzt um darauf unsere Applikation mit MAP auszuführen.
Das war eine wesentliche Erleichterung, weil vormals hat es gut eine Woche an Rechenzeit gedauert, bis das alte MT das erste Objekt 2000 mal in sich kopiert hatte. Eine Woche!. Das brauchte es jetzt nicht mehr, weil das Template wird nur noch einmal erstellt und dann die Information dazu, wie das 2000 mal durch die ETS genutzt und dargestellt werden soll. Das Projekt ist dann auch sehr klein und dieser Teil ging recht schnell. Auch wenn es bis dahin wieder eine Woche dauerte, das alles zu testen und herauszufinden.
Der Unterschied in der Applikationsgröße ist brachial:
- In der "alten" Programmierweise "Multi-Channel Architektur" war das Projekt über 6 MByte groß
- In der neuen Version mit "Modulare Applikationsprogrammierung" dagegen nur noch 95 kB!
Weil dann kam der große Test der neuen Applikation mit diesem sagenumwobenen Turbo MAP-Feature in der ETS:
Aus dem Desaster wird eine Katastrophe: Mit "MAP" dauert ein Klick nun Minuten:
Was für eine Ernüchterung. Da wartet man ein Jahr (oder ist es mehr), da wurde uns der Turbo versprochen und tatsächlich ist es eine Katastrophe. Die mit viel Aufwand unter Nutzung des MAP Features erstellte Applikation ist eine DOS-Attacke auf die ETS. Sobald man in der neuen Applikation irgendwo hin klickt, geht einer der Prozessorkerne auf 100 Prozent und bleibt dort für Minuten bis sich was bewegt.
Mit anderen Worten: Wir sind unserem Ziel, eine Applikation für alle 8000 Objekte zu erstellen, keinen Schritt näher. Mit dem "alten" Verfahren geht es nicht, weil das MT an seine Speichergrenzen kommt. Die Problemlösung funktioniert leider auch nicht, so dass wir hier nochmal eine Runde mit der KNX Assoc. drehen müssen.
Derzeit ist ein Ticket offen, wir haben alles hingemeldet und warten nun, dass man mit der nächsten Version der ETS auch dieses Problem lösen möchte.
Der Workaround: ETS 5.7.3 mit unserem 2000er Projekt
Der derzeitige - und absolut zufriedenstellende Workaround - ist die Nutzung der ETS 5.7.3 mit unserem bisherigen Projekt (als Applikation).
Mit der ETS 5.7.3 wurde die ETS offenbar massiv überarbeitet. Alles funktioniert so schnell (oder "normal") bei der ETS wie zuvor auch. Eine wichtige Verbesserung, an der man auch sieht, dass die Probleme mit der ETS nicht an unserer Applikation lagen, sondern bei der ETS selbst.
Auch wenn noch kein Kunden - soweit uns bekannt - an die Grenze der 2000 Objekte gestoßen ist, arbeiten wir daran, das volle Potential unseres KNX Stacks zu erreichen. Mit allen 8.000 Objekten. Und eines Tages, dies auch pro Instanz.
Wir sind also weiterhin dran. Das sind wohl offenbar die Schmerzen die man erleiden muss, wenn man den besten KNX Stack der Welt bauen will.
mg
Stefan