Commandline-Tool für "KNX mit ETS"-Projekt

[Bernator]

Bei den Kommentaren meine ich nur ganz was einfaches, z.b. so etwas:

<ParameterRefRef RefId="M-00FA_A-0001-01-0000_P-1_R-1" /><!--Sende intervall-->
<ParameterRefRef RefId="M-00FA_A-0001-01-0000_P-2_R-2" /><!--Status senden Ja/Nein-->
<choose ParamRefId="M-00FA_A-0001-01-0000_P-2_R-2"><!--WENN Status senden Ja/Nein-->
  <when test="0" /><!--JA-->
    <ComObjectRefRef RefId="M-00FA_A-0001-01-0000_O-1_R-1" /><!--Status KO-->
  </when>
</choose>
<ParameterRefRef RefId="M-00FA_A-0001-01-0000_P-3_R-3" /><!--Verhalten Busspannungswiederkehr-->
<choose ParamRefId="M-00FA_A-0001-01-0000_P-3_R-3"><!--WENN Verhalten Busspannungswiederkehr-->
  <when test="0"><!--deaktiviert-->
  </when>
  <when test="1"><!--aktiviert-->
  </when>
  <when test="2"><!--letzer Wert-->
  </when>
</choose>

bzgl. Baggages kann ich leider auch nichts beitragen, weiß nur das es irgendwie geht
Der MDT LED Controler verwendet welche, da könnte man evtl. mal nachschauen.

[mumpf]

Hi,

das mit den Kommentaren hab ich jetzt glaube ich verstanden. Obwohl ich ungerne die Datei, die Input ist, als Output verwende. Ich werde ein "CommentedOutput"-Parameter einführen, und dann ist es dem User überlassen, ob er da als Dateinamen den selben wie die Input-Datei macht oder nicht. Da ich aber derzeit einen größeren Umbau an dem Tool mache (include-Dateien), wird das noch dauern.

Das mit den Baggers ist schade, ich dachte, ich habe jetzt endlich jemanden gefunden, der sich damit auskennt. Ich habe da nämlich schon mal geschaut, als ich die Schema-Version 14 angeschaut habe (ETS 5.6), aber es hat sich mir nicht auf Anhieb erschlossen. Ich kann nichts versprechen, aber ich schau nochmal...



Gruß, Waldemar

[Bernator]

Super die Kommentare würden mir sehr helfen, wenn man sich nach längerem eine xml anschaut ist es sehr mühsam mit den kryptischen ids....

bzgl. Baggages hab ich nochmal kurz geschaut, wenn man im xml den neuen Tag <Baggages> unter <Manufacturer> erstellt dann erzeugt dein Converter bereits das eigene Baggages.xml das nötig ist. Ich denke das macht die ets converter.dll....
1.JPG
Hier wird für jedes Bild ein <Baggage> erstellt, die Attribute sind denke ich selbsterklärend

unter <static> gits dann einen <Extension> Tag wo die Baggages mit den IDs nochmal angeführt werden (warum weiß ich nicht)
2.JPG

dann wird ein Parametertyp und damit ein Parameter definiert:
3.JPG
4.JPG
weiter dann wie gehabt eine Parameter Referenz welche dann im dynamic Teil an entsprechender Stelle eingesetzt wird.

Die Bilder selbst liegen im knxprod im Ordner Baggages, wie man dem converter aber sagt dass er die Bilder mit verpacken soll weiß ich nicht.

[mumpf]

Hi,

ich habe soeben nach längerer Zeit mal wieder ein kleineres Update gemacht. Ist nicht sehr groß, aber es haben sich Kleinigkeiten angesammelt:

• Feature: added "Union" parameter support with correct size calculations
• updated to netcore 3.1
• Feature: debug.xml now contains references to the original objects as comments
• Bugfix: later tests might crash if earlier tests already failed
• New Check: Union has always to have SizeInBit-Attribute
• New Check: The format of an Id is ETS-relevant, Id-Format check added
• Updated version to 1.1.0

die Kommentare würden mir sehr helfen,

Insofern ist das jetzt drin, aber nicht im Input-File, sondern im debug.xml.

Gruß, Waldemar

[Bernator]

super danke

[jeff25]

toll, vielen Dank!

[mumpf]

Hi,

mich hat jetzt von Ing-Dom die Anfrage erreicht, mal das "multiply" in multiply-channels etwas genauer zu beschreiben. Das wird jetzt keine ausführliche Anleitung, sondern eher beispielhafte Erklärungen zu meinem genutzten Projekt knx-sensor.

Mal vorweg: Es gibt 3 Ausbaustufen:

1. Version 1.x: Hat nur aus einem gegebenen xml ein signiertes knxprod erzeugt, das läuft schon lange stabil und ich hab daran nichts mehr geändert außer neue Prüfungen ergänzt.
2. Version 2.x: Vervielfacht EINEN Kanal zu M Kanälen. Gut zu nutzen z.B. bei Schaltaktoren zur Vervielfachung der Schaltkanäle oder in meinem Logikmodul zur Vervielfachung der Logikkanäle. Wurde in den 2.0-Versionen des Sensormoduls genutzt, da gab es die verschiedenen Sensoren (von denen jeder einzeln implementiert wurde, da verschiedenen DPT und Messverfahren, hier also keine Vervielfachung) und die 80 Logikkanäle, die vervielfacht wurden. Auch das ist stabil und läuft schon lange.
3. Version 3.x: Vervielfacht N Kanäle zu N*M Kanälen. Wird im Sensormodul 3.0 genutzt, mit 80 Logikkanälen und 30 bzw. 90 1-Wire Kanälen. Diese Variante ist noch lange nicht perfekt... hier ändere ich immer wieder noch was. Wenn das jemand nutzen will, sollte er mich kontaktieren, damit ich weiß, dass es da noch jemanden gibt und dass ich mit demjenigen eventuell erforderliche inkompatible Änderungen absprechen kann.

Version 3.x kann natürlich auch alle Features von 1.x und 2.x, es ist auch die Version, die wir durchsprechen werden, aber ich werde nochmal an den entsprechenden Stellen darauf hinweisen, was "nur in 3.x" geht und somit potentiell instabil ist.

Soviel zum Vorwort, jetzt noch was zur Grundidee und zum Grundkonzept:

Die Grundidee ist ganz simpel: Ich werte ein spezielles xml-Tag   mc:include  aus. Dieses Tag verweist auf eine weitere xml-Datei, und diese wird vollständig an der Stelle eingefügt, an der das   mc:include  steht. Leider hat sich diese Idee als nicht tragfähig erwiesen, ich hätte sehr viele recht kleine xml-Dateien gebraucht, die includiert werden würden, da hätte man schnell den Überblick verloren. Die Lösung war aber einfach: Neben einer zu includieren Datei kann man auch einen xpath-Ausdruck angeben. Es werden einfach alle xml-Objekte includiert, die dem xpath-Ausdruck entsprechen.

Das Grundkonzept: Man schreibt ein Rumpf-xml, dass all das enthält, was die ETS braucht (KNX-Tag, ManufacturerData, Manufacturer, Catalog, ApplicationPrograms und Hardware), aber innerhalb von ApplicationProgram kann man dann mehrfach mc:include verwenden, um passende Teile auslagern zu können.

Die einzubettenden xml können einfach oder n-fach includiert werden. Mehrfach includierte Dateien können 3 "magic" Literale enthalten:
"%N%" wird mit der maximalen Anzahl der Kanäle ersetzt (bei meinem Logikmodul also immer mit 80)
"%C%" wird mit dem aktuellen Kanal ersetzt (also z.B. mit 32)
"%CCC%" wird mit dem aktuellen Kanal ersetzt, allerdings mit führenden Nullen (also z.B. mit 032)
Es ist eine reine String-Ersetzung von Werten, die magic Literale können somit in jedem xml Attrribut- oder Objektwert stehen, aber nicht im Tag selbst.
(nebenbei: Mehr als 999 Vervielfachungen werden nicht unterstützt ).

Damit kommt man schon recht weit, man muss nur irgendwo notieren, wie oft man den Kanal vervielfachen will. Ich wollte das nicht bei jedem include angeben müssen, da man für einen logischen Kanal mehrere includes braucht. Deswegen gibt es noch ein   mc:define , bei dem man die Anzahl der Kanäle und den Namen des zu erzeugenden Header-Files (.h) angibt. Das Programm gibt nämlich noch für jedes benannte ETS-Objekt (Parameter, KO) noch ein #define aus, das dem Namen die Adresse des Parameters oder die Nummer des KO zuordnet. Für vervielfachte Objekte wird aber nur das #define für das erste Vorkommen ausgegeben, man muss das dann im Applikaitonsprogramm mit Kanal*Blockgröße berechnen. Die Blockgröße gibt es aber auch als #define.

So, das ist erstmal das Grobkonzept, ich mach dann weiter mit dem kommentierten Beispiel. Wird aber vielleicht erst morgen was, muss erstmal wieder was mit der Familie machen...

Gruß, Waldemar

P.S.: Das bisher beschriebene kann man sich in der Rumpfdatei für das Sensormodul ansehen: https://github.com/mumpf/knx-sensor/...ensormodul.xml

[mumpf]

So, jetzt mal das kommentierte Beispiel aus dem Projekt knx-sensor: https://github.com/mumpf/knx-sensor/blob/beta/src/Sensormodul.xml

Nur um es vorweg zu sagen, das Beispiel ist kompliziert, da es nicht nur Kanäle vervielfacht, sondern auch xml-Files aus mehreren Projekten zusammenführt (quasi klassische Include-Funktion). Das liegt daran, dass meine Projekte aufeinander aufbauen, und z.B. das Logikmodul auch für sich alleine compiliert werden kann, aber auch Teil des Sensormoduls ist. Mit den Includes stelle ich sicher, dass Änderungen an dem Logik-XML immer in beiden Projekten automatisch drin sind.

Zeile 16 und 17 (https://github.com/mumpf/knx-sensor/...rmodul.xml#L16):

            <mc:define prefix="LOG" header="Sensormodul.h" NumChannels="80" KoOffset="125" />
            <mc:define prefix="WIRE" header="Sensormodul.h" NumChannels="30" KoOffset="90" />

Die erste Zeile ist für das Logikmodul und macht hier globale Einstellungen:

• header="Sensormodul.h" - das generierte Headerfile heißt "Sensormodul.h"
• prefix="LOG" - im Headerfile werden alle Parameter/KO für das Logikmodul mit dem Präfix LOG_ generiert.
• NumChannels="80" - die includes, die vervielfältigt werden sollen, werden 80 mal vervielfältigt.
• KoOffset="125" - da alle KO-Nummern global sind, wird hier angegeben, dass die KO für die Logikkanäle bei 125 beginnen sollen

Die zweite Zeile macht das entsprechend für die 1-Wire-Kanäle. Das Headerfile muss immer gleich heißen, es wird nur ein Headerfile unterstützt. Und das mit den Präfixen läuft noch nicht so wie es soll, es gibt zu viele Objekte mit LOG. Da das aber deterministisch ist, war es noch nicht notwendig, da nach dem Fehler zu suchen.

Zeile 19-23 (https://github.com/mumpf/knx-sensor/...rmodul.xml#L18):

            <ParameterTypes>
              <mc:include href="../../knx-logic/src/Logikmodul.share.xml" xpath="//ParameterTypes/ParameterType" prefix="LOG" />
              <mc:include href="../../knx-wire/src/WireGateway.share.xml" xpath="//ParameterTypes/ParameterType" prefix="WIRE" />
              <mc:include href="Sensormodul.share.xml" xpath="//ParameterTypes/ParameterType" prefix="SENS" />
            </ParameterTypes>

Hier werden ParameterTypes includiert. Es ist ziemlich klar, dass ParameterTypes nicht 80 mal wiederholt werden müssen bzw. wiederholt werden dürfen. Bei dieser Parametrierung von mc:include wird nur einmal includiert:

• href="..." - includiert die Datei Logikmodul.share.xml aus einem anderen Verzeichnis, dass relativ angegeben ist
• xpath="..." - includiert nur die Kinder vom Tag //ParameterTypes/ParameterType (siehe https://www.w3schools.com/xml/xpath_syntax.asp, um mehr über xpath zu erfahren)
• prefix="LOG" - verweist auf das mc:define mit prefix="LOG", aus dem weitere Informationen bei Bedarf gelesen werden können

Die folgenden mc:include machen das auch entsprechend. Die letzte Zeile mit prefix="SENS" passt nicht ganz ins Schema, da es kein mc:define mit prefix="SENS" gibt. Das liegt daran, dass die Sensormodul-Definitionen nicht vervielfältigt werden und auch ganz normal mit KO=1 anfangen. Und da es nur ein Headerfile angegeben werden kann, sind quasi alle Informationen für prefix="SENS" bekannt. Ist nicht schön, aber so funktioniert es derzeit. Man kann sich vorstellen, dass es dafür ein implizites

            <mc:define prefix="SENS" header="Sensormodul.h" NumChannels="1" KoOffset="1" />

gibt. Wie gesagt, gewachsenes Coding.

Die obigen mc:include includieren die Sachen nur EINMAL, schauen wir uns mal an, wie mehrfach-Includes aussehen. Spoiler: Sie unterscheiden sich durch ein type="template".

Zeile 40-46 (https://github.com/mumpf/knx-sensor/...rmodul.xml#L40):

            <ComObjectTable>
              <mc:include href="../../knx-logic/src/Logikmodul.share.xml" xpath="//ComObjectTable/ComObject" prefix="LOG" />
              <mc:include href="../../knx-wire/src/WireGateway.share.xml" xpath="//ComObjectTable/ComObject" prefix="WIRE" />
              <mc:include href="Sensormodul.share.xml" xpath="//ComObjectTable/ComObject" prefix="SENS" />
              <mc:include href="../../knx-logic/src/Logikmodul.templ.xml" xpath="//ComObjectTable/ComObject" type="template" prefix="LOG" />
              <mc:include href="../../knx-wire/src/WireGateway.templ.xml" xpath="//ComObjectTable/ComObject" type="template" prefix="WIRE" />
            </ComObjectTable>

Hier werden die KO zusammengestellt. Es ist relativ klar, dass man immer ein paar KO hat, die nur einmal vorkommen, und dann ein paar, die wiederholt werden. Das erkennt man in den obigen mc:include-Angaben:

• Die erste Zeile includiert aus der Datei Logikmodul.share.xml alle Kinder des Objektes "//ComObjectTable/ComObject" (das sind KO-Definitionen) nur EINMAL mit dem Prefix "LOG"
• Die zweite Zeile macht das entsprechend aus der Datei WireGateway.share.xml mit dem Prefix "WIRE"
• Die dritte Zeile macht das entsprechend aus der Datei Sensormodul.share.xml mit dem Prefix "SENS"
• Die vierte Zeile includiert aus der Datei Logikmodul.templ.xml alle KO-Definitionen mit dem Prefix "LOG", durch type="template" wird aber im mc:define mit prefix="LOG" nachgeschaut und festgestellt, dass das Tempate 80 mal wiederholt werden soll und die KO ab 125 anfangen sollen.
• Die fünfte Zeile includiert aus der Datei WireGateway.templ.xml alle KO-Definitionen mit dem Prefix "WIRE", durch type="template" wird aber im mc:define mit prefix="WIRE" nachgeschaut und festgestellt, dass das Tempate 30 mal wiederholt werden soll und die KO ab 90 anfangen sollen.

Was passiert beim vervielfachen?

• Der entsprechende XML-Teil wird gelesen (entsprechend der xpath-Anweisung)
• Alle Parameter-Namen (falls im Include vorhanden) werden "normiert", indem jegliche %N%, %C% und %CCC% entfernt werden. Für diese Parameter werden die Adressen berechnet und diese ins Headerfile geschrieben.
• Alle KO-Namen werden normiert und ins Headerfile geschrieben.
• Jetzt werden alle %N%, %C% udn %CCC% an ihren ursprünglichen Stellen mit den passenden Werten ersetzt.
• Das resultierende XML wird an die Stelle vom mc:include eingefügt
• Das Ganze wird so oft wiederholt, wie es im entsprechenden mc:define steht.

Das war es erstmal für heute,
Gruß, Waldemar

[Ing-Dom]

Nachdem erste Versuche mit einer manuell editierten XML ganz vielversprechend waren, hätte ich nun ein paar Fragen zum Kanäle multiplizieren/inkludieren.

Alle Parameter-Namen (falls im Include vorhanden) werden "normiert", indem jegliche %N%, %C% und %CCC% entfernt werden. Für diese Parameter werden die Adressen berechnet und diese ins Headerfile geschrieben.

Was genau bedeuten die N C und CCC und wie verhalten sich diese?
N scheint die jeweilge Kanalnummer zu sein.
C und CCC ?

Und im share xml im git finde ich auch noch ein %K%.


Diese ganze Funktion wird beim MultiplyChannels.exe knxprod (bzw. create) automatisch mit ausgeführt ?

[Ing-Dom]

und was ist eigentlich mit den <CodeSegements> ?

Ich hab mir jetzt mal Parameter aus Wiregateway und Logkmodul templae angesehen - beide enthalten z.B. ein

<Memory CodeSegment="M-00FA_A-0001-01-0000_RS-04-00000" Offset="0" BitOffset="0" />

[mumpf]

Hi,

und was ist eigentlich mit den <CodeSegements>

das ist die einfachere Antwort: Es gilt nur <CodeSegments> des Hauptdokuments. Die includes müssen nur gültige XML-Dokumente sein, die das über xpath adressierte Element enthalten. Alles andere wird sowieso ignoriert. Ich hab einfach die Struktur des Hauptdokuments behalten, damit die Dokumente möglichst ähnlich aussehen, mir fällt es dann leichter, mich da zurecht zu finden. Muss man aber so nicht machen.

Was genau bedeuten die N C und CCC und wie verhalten sich diese?

Da zitiere ich mich selber:

Die einzubettenden xml können einfach oder n-fach includiert werden. Mehrfach includierte Dateien können 3 "magic" Literale enthalten:
"%N%" wird mit der maximalen Anzahl der Kanäle ersetzt (bei meinem Logikmodul also immer mit 80)
"%C%" wird mit dem aktuellen Kanal ersetzt (also z.B. mit 32)
"%CCC%" wird mit dem aktuellen Kanal ersetzt, allerdings mit führenden Nullen (also z.B. mit 032)
Es ist eine reine String-Ersetzung von Werten, die magic Literale können somit in jedem xml Attrribut- oder Objektwert stehen, aber nicht im Tag selbst.

%K hab ich vergessen, sorry. RegEx dafür ist:

%K(\d{1,3})%

also ein %K, gefolgt von 1-3 Ziffern, gefolgt von einem %. Das sind die KO-Nummern. Man muss ja pro multiplizierten Kanal mehr als ein KO angeben können. Die KO-Nummern müssen dann passend hochgezählt werden. Und weil im Stack auch für leere KO ein C++-Objekt angelegt wird, sollte man keine zu großen KO-Lücken lassen (KOs werden im RAM angelegt und brauchen ja immer ein paar Byte - Du erinnerst Dich an unsere Diskussion im Hauptthread).

Ich nutze im Logikmodul immer %K0%, %K1% und %K2%, da ich pro Logikkanal 3 KO habe (2 Eingänge und 1 Ausgang). Im mc:define gibt man ja ein KoOffset mit, von dem an wird dann gezählt. Also bei einem KoOffset von 125:
Kanal1-%K0% = 125, Kanal1-%K1% = 126, Kanal1-%K2% = 127, Kanal2-%K0% = 128, Kanal2-%K1% = 129, Kanal2-%K2% = 130 usw.

Ich rufe das Ganze übrigens immer folgendermaßen auf:

MultiplyChannels.exe create Sensormodul.xml

Neben der Sensormodul.knxprod kommt auch immer ein Sensormodul.debug.xml raus. Das ist das "multiplizierte" xml, das als quelle für die knxprod genommen wird. Da sieht man dann immer die Auswirkungen der "multiplikation", da kannst Du auch sehen, wie sich die jeweiligen %...% Parameter verhalten.

Gruß, Waldemar

[Ing-Dom]

ok Danke, das hilft schonmal viel weiter. Ich werde weiter probieren.

Ich glaube bei der CodeSegments hat du mich falsch verstanden.
Ich meinte die <Memory> Eigenschaft von Parametern. Da wird ja festgelegt,wo der Paramter im Speicher liegt. (Offsett).
Mir fällt auf, dass hier kein % Literale enthalten sind.
Das macht dein Tool dann selbstständig oder?

[Ing-Dom]

Ich rufe das Ganze übrigens immer folgendermaßen auf: Code:

MultiplyChannels.exe create Sensormodul.xml
Neben der Sensormodul.knxprod kommt auch immer ein Sensormodul.debug.xml raus.

sicher? Ohne Angabe der knxprod ? Das gibt bei mir einen Fehler:

D:\Data\Eigene Dokumente\Projekte\EIB\Konnekting\repos\multiply-channels\bin\Debug\netcoreapp3.1>MultiplyChannels. exe create -o SNS-8xTH.xml
MultiplyChannels 3.2.1
Copyright (C) 2021 MultiplyChannels

ERROR(S):
A required value not bound to option name is missing.

fürs debug.xml ist die -d Option wichtig (da hab ich jetzt etwas gebraucht, evtl hilfreich)

[Ing-Dom]

ich bekomme die Fehlermeldung "die Eingabenzeichenfolge hat das falsche Format" beim Import in die ETS.
MultiplyChannels hat nicht gemeckert - hier fehlt ggf. noch eine Abprüfung,

Ich hab auch einen Verdacht - ich bin bei den IDs ggf etwas zu kreativ gewesen und habe die so benannt, dass besser raus kommt welcher Paramter welcher Channelnummer welchen Channeltyps er abgehört.
Auch um die eindeutigkeit bei der Verwendung mehrerer Channeltypen sicherzustellen. z.B. 5 Sensorchannels und 3 Binäreingangchannels...

Wenn das Format aber zwingend _P-<Zahl> lautet muss ich da wohl mit Magicnumbers arbeiten.



Also, so wie es aussieht, dürfen Parameter zwar z.B. die Id _P-SNS05-02 haben(05 Parameter von 2. SNS Channel)

Aber bei <ParameterRef Id ist es strenger - hier muss es _P-<ZAHL>_R-<ZAHL> heißen.

Das wäre nochwas, was man mit abprüfen könnte/sollte.


Was mir außerdem noch aufgefallen ist, %C% wird nicht immer mit der Channelnummer ersetzt, oder?
aus:

<Channel Id="M-00FA_A-0000-00-0000_CH-SNS-%C%" Name="Sensor_%C%" Number="%C%" Text="Sensor %C%">
<ParameterBlock Id="M-00FA_A-0000-00-0000_PB-SNS-%C%" Name="Sensor_%C%" Text="Einstellungen">

<Channel Id="M-00FA_A-0001-01-0000_CH-SNS-1" Name="Sensor_1" Number="1" Text="Sensor 1">
<ParameterBlock Id="M-00FA_A-0001-01-0000_PB-SNS-3" Name="Sensor_1" Text="Einstellungen">

hier wird zusätzlich noch ein Offset dazu gerechnet (wohl weil es 2 PBs im allgemeinen Teil gibt).

[thewhobox]

Aber bei <ParameterRef Id ist es strenger - hier muss es _P-<ZAHL>_R-<ZAHL> heißen.

Das finde ich gut^^

Ich nehme die Zahl am Ende der RefId als einzigartig an.
Wenn es nun statt "_P-SNS05-02" auch "_P-DCD06-02" oder so gibt, müsste ich alles komplett nochmal umbauen..
zusätzlich würde sich der Speicherbedarf der Datenbank deutlich vergößern.

Ein Gedanke der mir grad kam: Ein eigenes Attribute hinzufügen. Sowas wie:

<ParameterBlock Id="M-00FA_A-0001-01-0000_PB-3" Debug="Parameterblock Sensoren" Name="Sensor_1" Text="Einstellungen">
<ParameterRef Id="M-00FA_A-0001-01-0000_P-1_R-1" RefId="M-00FA_A-0001-01-0000_P-1" Debug="Sensor parameter 5 von Channel 2" />

Oder meckert da die ETS?

zusätzlich noch ein Offset dazu gerechnet (wohl weil es 2 PBs im allgemeinen Teil gibt).

Soweit ich weiß braucht auch jeder Parameterblock eine eindeutige ID. Auch wenn sie in anderen Channels sind, darf nicht zwei mal die gleiche ID vorkommen.
(Würde auch mein Importkonzept ruinieren^^)