selfbus.org

Hallo zusammen,
bin gerade dabei eine eigene App
https://www.heliosventilatoren.de/de/co ... -09416-002
zu entwickeln und habe festgestellt, dass beim Programmieren der Applikation mit der ETS die Adresse der ComObjectTable falsch gesetzt wird. In der ETS Diagnose habe ich folgende Zeile gefunden:
248 01.03.2021 10:53:27,809 zum Bus System 1.1.254 - - 1.1.64 KWL-EB 6 ObjectIndex=3, PropertyId=5, Count=1, StartIndex=1, Data=03 02 45 30 00 01 12 00 01 10
Dies führt dazu, dass in der ARM Library properties.cpp Zeile 121
userEeprom.commsTabAddr = addr;
die commsTabAddr falsch auf 0x4530 gesetzt wird, obwohl die laut .knxprod auf 0x43FE stehen muss.
<ComObjectTable CodeSegment="M-0112_A-0001-10-C995_AS-43FE" Offset="0">
Das führt dann dazu, dass die Kommunikationsobjekte nicht ansprechbar sind, da die Lib auf die falschen Adressen zugreift. Ich habe mir jetzt eine private Version der ARM Lib mit einem quick fix gebaut, die in der bcu_base.h eine zusätzliche Methode
void begin(int manufacturer, int deviceType, int version, word commsTabAddr);
und ein neues Attribut
word commsTabAddr;
enthält. In der properties.cpp wird der Wert dann der Tabelle übergeben.
userEeprom.commsTabAddr = bcu.commsTabAddr;
Damit bin ich jetzt in der Lage alle Objekte korrekt anzusprechen und kann mit der Programmierung der eigentlichen App beginnen. Nach meinen bisherigen Untersuchungen stellt sich mir die Frage warum die Adressen der einzelnen Tabellen überhaupt aus den ETS Daten von der Lib ermittelt werden. Wäre es nicht besser diese Adressen grundsätzlich selbst aus der .knxprod zu lesen und dann über bcu.begin(...) der Lib zu übergeben ? Würde da gerne zu einer kleinen Diskussion mit den Entwicklern der ARM Lib beitragen.
Liebe Grüße

Hallo Luckychild,

ich habe mal versucht die Sache mit Hersteller 0x112, Hardware 0x1, Version 0x10 nachzustellen.
Kann es sein, dass du zusätzlich die MASK_VERSION auf 0x0705 in der bcu_base.h geändert hast? Zumindest konnte ich erst danach bei mir die phys. Adresse programmieren.

luckychild hat geschrieben: ↑3. Mär 2021, 18:38 die commsTabAddr falsch auf 0x4530 gesetzt wird, obwohl die laut .knxprod auf 0x43FE stehen muss.

Bei mir wird commsTabAddr durch die sblib auf 0x3000 gesetzt.

luckychild hat geschrieben: ↑3. Mär 2021, 18:38 <ComObjectTable CodeSegment="M-0112_A-0001-10-C995_AS-43FE" Offset="0">

Wie kommst du zu einer .knxprod? Dein Link führt zu einer *.vd5. Ich habe mir mit knxconv.exe daraus eine .knxprod erstellt, diese hat allerdings <ComObjectTable CodeSegment="M-0112_A-0001-10-B5E1_AS-43FE" Offset="0"> drin

.

Die sblib macht meiner Meinung nach keine Unterscheidung zwischen APciPropertyValueWrite und APciMemoryWrite.

Hier mal ein "Aufrufstack-Log" mit der Helios Produktdatenbank (MASK_VERSION 0x0705) und zum Vergleich eine MDT vom rol-jal-bim112 (MASK_VERSION 0x0701).

Code: Alles auswählen

helios ventilatoren -> APciPropertyValueWrite
void BCU::processDirectTelegram(int apci)
bool propertyValueWriteTelegram(int objectIdx, PropertyID propertyId, int count, int start)
int loadProperty(int objectIdx, const byte* data, int len)
03 02 40 00 00 01 12 00 01 10 userEeprom.addrTabAddr  = 0x0000
03 02 41 FF 00 01 12 00 01 10 userEeprom.assocTabAddr = 0xFF00
03 02 45 30 00 01 12 00 01 10 userEeprom.commsTabAddr = 0x3000

rol-jal-bim112 -> APciMemoryWrite
void BCU::processDirectTelegram(int apci)
int loadProperty(int objectIdx, const byte* data, int len)
13 02 00 40 00 01 00 83 00 29 28 userEeprom.addrTabAddr  = 0x4000
23 02 00 42 01 01 00 83 00 29 28 userEeprom.assocTabAddr = 0x4201
33 02 00 44 00 01 00 83 00 29 28 userEeprom.commsTabAddr = 0x4400

Lösung auf die Schnelle hab ich erstmal keine.
Ein manuelles setzen von userEeprom.commsTabAddr = 0x43FE funktioniert bei mir nicht.
Kannst du deinen patch eventuell hier posten?

Viele Grüße
Denis

Hallo,

wenn bei der ComObjectTable der Eintrag
<ComObjectTable CodeSegment="M-0112_A-0001-10-C995_AS-43FE" Offset="0">
ist, dann sollte eigentlich die Adresse passen.
Die letzten Ziffern geben die Adresse in Hex an, also hier 43FE.
Das CodeSegemnt findet man dann ja als AbsoluteSegment wieder.
Da ist folgendes zu finden:
<AbsoluteSegment Id="M-0112_A-0001-10-C995_AS-43FE" Address="17406" Size="316">
Hier ist die Adresse dann in dezimal angegeben (17406 = 43FE)
Also normalerweise sollte die ETS diesen Wert dann auch korrekt übertragen.
Du kannst ja bei dir nochmal kontrollieren, ob das AbsoluteSegment auch so passt.

Btw @luckychild:
Bist du bereits im Slack unterwegs? Schreib mich (Olli) da doch mal an.
Ich habe da noch eine evtl. interessante Neuentwicklung für dich

Grüße,
Olli

Hallo Denis,

danke, dass du da rein schaust. Sorry, ja ich hatte vergessen zu erwähnen dass es sich dabei um eine 0x705 Maske handelt.
Ich schicke im Anhang mal alle von mir geänderten Files, dann wird es am einfachsten

Wie gesagt ... es ist nur ein Quick Fix

.
Ja, die .knxprod habe ich aus der ETS raus exportiert. Die .vd5 in die ETS laden, da wird sie dann als KWL-EB angezeigt und dann einfach auf exportieren gehen. Meine ETS5 speichert sie dann automatisch als KWL-EB.knxprod. Wie bei dir die B5E1 entsteht und was die Nummer bedeutet weiß ich leider nicht. die Adresse 43FE scheint zumindest die gleiche zu sein.
Ich hoffe die angehängten Files helfen bei der Recherche. Wie funktioniert eigentlich der Commit Prozess für die ARM Lib in Github bzw. wo muss man da evtl. Änderungen beantragen ?

Liebe Grüße

Hallo Olli,

ja, von diesen Eckdaten her dachte ich auch, dass alles passen müsste und daher weiß ich auch, dass die ComObjectTable bei 43FE liegen muss. Nur leider legt die ARM LIB diese Adresse auf 4530 da sie aus dem Telegram
248 01.03.2021 10:53:27,809 zum Bus System 1.1.254 - - 1.1.64 KWL-EB 6 ObjectIndex=3, PropertyId=5, Count=1, StartIndex=1, Data=03 02 45 30 00 01 12 00 01 10
interpretiert, dass sie auf 4530 liegen soll. Das ist genau der Punkt wo ich denke, dass die ARM Lib da was falsch macht, da sie die Adresse nach der Signatur 03 02 ... einer Tabelle zuordnet. im Falle von ObjectIndex=3 eben der ComObjectTable.
Genau diese Interpretation der ARM Lib scheint nicht immer zustimmen. Da die App selbst aber genau weiß wo ihre Tabellen liegen müssen, wäre mein Vorschlag diese Adressen fix beim Aufruf der bcu.begin(...) gleich mitzugeben. Wie das jetzt mal nur für die ComObjectTable aussehen kann, habe ich mal in den Files gezeigt, die ich in meiner letzten Nachricht angehängt hatte.. Ich habe mal ein Log der kompletten Daten die von der ETS5 geschickt und empfangen werden hier angehängt.

Ja, in Slack bin ich angemeldet, habe aber noch nichts groß da gemacht. Ich melde mich mal bei dir ...

Liebe Grüße

Hallo Luckychild,

Dein Quickfix funkioniert, ich meine aber die ETS übermittelt durchaus die richtigen Adressen.
Ich habe mal dein log auf die wichtigen Stellen zusammengeschnitten:

Code: Alles auswählen

#	Zeit	Dienst	Flags 	Prio	Quelladresse	Quellname	Quell-Beschreibung	Zieladresse	Zielname	Ziel-Beschreibung	Rout	DPT	Info
60	01.03.2021 10:53:18,656	zum Bus		System	1.1.254	-	-	1.1.64	KWL-EB		6		ObjectIndex=1, PropertyId=5, Count=1, StartIndex=1, Data=03 00 40 00 01 FF F2 03 80 00
100	01.03.2021 10:53:20,636	zum Bus		System	1.1.254	-	-	1.1.64	KWL-EB		6		ObjectIndex=2, PropertyId=5, Count=1, StartIndex=1, Data=03 00 41 FF 01 FF F2 03 80 00
120	01.03.2021 10:53:22,039	zum Bus		System	1.1.254	-	-	1.1.64	KWL-EB		6		ObjectIndex=3, PropertyId=5, Count=1, StartIndex=1, Data=03 00 07 00 00 F8 F2 02 00 00
124	01.03.2021 10:53:22,192	zum Bus		System	1.1.254	-	-	1.1.64	KWL-EB		6		ObjectIndex=3, PropertyId=5, Count=1, StartIndex=1, Data=03 00 43 FE 01 3C F2 03 80 00
236	01.03.2021 10:53:27,247	zum Bus		System	1.1.254	-	-	1.1.64	KWL-EB		6		ObjectIndex=3, PropertyId=5, Count=1, StartIndex=1, Data=03 00 46 00 00 15 22 03 80 00

Jetzt muss das nur noch die sblib richtig machen

.

In der KNX Spec sollte das LoadEvent: AllocAbsDataSeg (segment type 0) sein.
(The KNX Standard v2.1/03 Volume 3 System Specifications/03_05_02 Management Procedures v01.09.02 AS.pdf Seite 114 ff

Nur am Rande, du hast auch PROP_LOAD_OFFSET auf 0 gesetzt, dadurch kommst du auf Adresse 0x4530 anstelle von 0x3000. Interessant ist, dass der Unterschied "C995" in der .knxprod durch die Art und Weise der Generierung der .knxprod kommt, wenn ich es so wie du mache erhalte ich auch C995.

Viele Grüße
Denis
edit: Verweis auf KNX-spec hinzugefügt

Hi Denis,

ja, richtig, PROP_LOAD_OFFSET musste ich auf 0 setzen, da die Lib sonst komplett daneben greift => Adresse 0x3000 ... wobei die 30 das Ende von 0x4530 ist.

Wozu PROP_LOAD_OFFSET normal auf 1 steht habe ich noch nicht untersucht. Keine Ahnung ob bei der MaskVersion 705 PROP_LOAD_OFFSET generell auf 0 stehen muss oder ob das nur bei dieser App so ist.
Ja die Übertragung der Daten durch die ETS an die von dir zusammengefassten Adressen funktioniert einwandfrei und ist so auch korrekt. Nur wenn die Lib später auf ein ComObject zugreifen will, landet sie an der falschen Stelle, da die userEeprom.commsTabAddr auf 0x4530 gesetzt wurde. Das kommt wiederum dadurch, dass die Lib die userEeprom.commsTabAddr nicht über die Sequenz
ObjectIndex=3, PropertyId=5, Count=1, StartIndex=1, Data=03 00 43 FE 01 3C F2 03 80 00
setzt, sondern durch
ObjectIndex=3, PropertyId=5, Count=1, StartIndex=1, Data= 03 02 45 30 00 01 12 00 01 10
Und da behaupte ich mal, liegt wahrscheinlich auch ein systematischer Fehler ... zumindest bei der BIM112_705.
Daher dann auch die Idee, die Adresse der Tabelle aus der .knxprod zu lesen und über die App gleich direkt beim Start festzulegen.
Die .knxprod hatte ich bisher nur immer aus der ETS exportiert. Ehrlich gesagt weiß ich auch nicht wirklich was die Zahl "C995" hier für eine Bedeutung hat.

Liebe Grüße

Hallo,

ich zu diesem Thema noch einen Hinweis gefunden:
Im out-cs-bim112 hat Florian die gleiche Problematik gehabt und mit den Zeilen 292 bis 295 in der Datei https://github.com/selfbus/software-arm ... _main.cpp gelöst:

// Die ETS5.6 programmiert merkwürdigerweise eine ganz andere Adresse,
// das muss korrigiert werden.
if (userEeprom.commsTabAddr != 0x4400)
userEeprom.commsTabAddr = 0x4400;

Also scheint da wohl etwas generell in der sblib für BIM112 nicht zu passen, da der out-cs-bim112 die Maskenversion MV-0701 verwendet.

Grüße,
Olli

Hallo,

genau. Die sblib verarbeitet die APciPropertyValueWrite (loadevents) Telegramme nicht korrekt, wodurch dann manchmal falsche Adressen gesetzt werden. Ich versuch mich da gerade reinzulesen, daher auch meine Nachfrage hier. Florian sein Ansatz ist z.Zt. der bessere Workaround, da Luckychilds Quickfix bei bereits bestehenden funktionierenden Apps eingepflegt werden müsste. Ich hatte die Tage bei Github ein Issue dazu aufgemacht.

Viele Grüße
Denis

Hi zusammen,
prima, mir scheint, wir sind uns in der Erkenntnis des Problems einig

Dann müssen wir uns nur noch über den besten Lösungsweg einig werden

@Denis: Mein Ansatz war schon der, dass bestehende Apps nicht mehr angetastet werden müssen, d.h. habe ich in meinem Quick Fix auch nicht die ursprüngliche bcu_base::begin Methode
void begin(int manufacturer, int deviceType, int version);
ersetzt sondern nur mit einer zusätzlichen Methode überladen:
void begin(int manufacturer, int deviceType, int version, word commsTabAddr);
Zugegeben, in der properties.cpp habe ich noch etwas geschlammpt (Quick Fix

). Da sollte dann konsequenter Weise auch stehen:
if (bcu.commsTabAddr)
userEeprom.commsTabAddr = bcu.commsTabAddr;
else
userEeprom.commsTabAddr = addr;
Und die alte bcu_base::begin Methode sollte natürlich noch um diese Zeile erweitert werden:
this->commsTabAddr = NULL;
Ich habe unten mal den Extended Quick Fix angehängt, so wie er dann vollständig sein dürfte.
Den Vorteil sehe ich darin, dass man so recht flexibel bleibt und über bcu_base::begin bei Bedarf die Adresse der Tabelle beliebig vordefiniert werden kann.

Liebe Grüße

selfbus.org

Bug in der ARM Lib ?

Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?