Wie kommuniziert die ETS mit KNX-Geräten (z.B. beim partiellen Programmieren)

[thewhobox]

Also mir ist nur die Abfrage nach dem MCB bekannt. Wenn der noch gleich ist, wird differentiell übertragen, ansonsten eben voll.
Kannst ja mal das Programmieren Aufzeichnen und dann den MCB den die ETS vor dem Programmieren ausliest, noch der gleiche ist wie der beim vorherigen Programmieren.


Gruß Mike

[mumpf]

Hi Mike,

scheint an Deinem CRC-Algorithmus zu liegen , Oder an dem Speicherbereich, den ich dem Algorithmus gebe... Ich hatte einen nachvollziehbaren Fall gefunden:

• Ich ändere einen Parameter von 1 auf 3 -> es wird partiell programmiert, nur ein Byte übertragen
• Ich ändere zurück von 3 auf 1 -> es wird alles übertragen

Die CRC usw. muss ich noch prüfen, bin jetzt nicht mehr frisch genug dafür. Hab aber mal testweise bei PID_MCB_TABLE wieder konstanten rausgegeben -> schon klappt das Delta in beide Richtungen. Morgen teste ich genauer und schaue mir die CRC-Ergebnisse mal an.

Gruß, Waldemar

[thewhobox]

Hi Waldemar,

Das kann natürlich sein, dass mein Code nicht genau passt (Hab den auch aus der Webseite von Javascript umgewandelt). Da es leider nur ein Beispiel in der Spec gibt ist es schwer das genauer zu verifizieren...
berechnest du den CRC bei jeder Abfrage neu?
Laut Spec soll er immer nur bei Änderung des LoadStateMachine von Loading zu Loaded berechnet werden.
Screenshot 2021-04-03 105855.png


Dan würde es auch keine Probleme mehr geben, da der MCB immer nach dem Programmieren und bei der Abfrage vor dem Programmieren gleich ist.


Gruß Mike

[mumpf]

Hi Mike, das mit dem Algorithmus war nicht ernst gemeint (deswegen auch der Smiley). Ich bin dir sehr dankbar, das du dir die Mühe gemacht hast, den zu finden und zu testen.
Es liegt sicherlich an mir. Ich berechne den jedesmal. Für die Speicherung muss ich da tiefer reinschauen, denn der gespeicherte Wert muss ja auch in den Flash.

Ich probier Mal heute und werde berichten.

Wenn man Mal in den Genuss von Delta-Programmierung gekommen ist (sprich: 7 Sekunden), dann nervt es tierisch, wenn es wieder 90 Sekunden werden! Vor allem, wenn füll eigentlich auch nur noch 21 bis 30 Sekunden dauert... Den Teil verstehe ich immer noch nicht.

Gruß, Waldemar

[mumpf]

Hi Mike,

hab das jetzt mal nach Spec implementiert, der CRC wird jetzt nur noch beim Übergang von loading nach loaded berechnet - was auch viel effizienter ist. da diese Stelle wirklich nur nach dem erfolgreichen Laden aufgerufen wird. Ich hab wohl auch die richtige Stelle erwischt, um den CRC im Flash zu speichern und hab hoffentlich die ganzen Metadata-Berechnungen angepasst. Auf jeden Fall läuft das jetzt wieder und ich konnte das gestern zu 100% reproduzierbare Verhalten nach der Änderung nicht mehr reproduzieren.

OutOfSync: Julius, ich teste jetzt noch ne Weile, dann würde ich meinen Change auf github pushen und dann kannst Du Dir das Delta ja mal ansehen (ich sag hier Bescheid, wenn es verfügbar ist), dann kannst Du das vielleicht auch noch übernehmen? Ist nicht so viel, ist nur etwas verteilt. Aber alles im table_object.

Gruß, Waldemar

[thewhobox]

Hallo Waldemar,

Das klingt doch super
Ja das muss man sich immer an vielen Stellen zusammen suchen^^
Aber super, dass es jetzt klappt.

Gruß Mike

P. S. : das kam auch so bei mir rüber, war vorher nur kurz online und konnte da nicht viele smileys machen

[OutOfSync]

OutOfSync: Julius, ich teste jetzt noch ne Weile, dann würde ich meinen Change auf github pushen und dann kannst Du Dir das Delta ja mal ansehen (ich sag hier Bescheid, wenn es verfügbar ist), dann kannst Du das vielleicht auch noch übernehmen? Ist nicht so viel, ist nur etwas verteilt. Aber alles im table_object.

Hi Waldemar,

war viel im Garten bei dem schönen Wetter... Ja klar das gucke ich mir gerne an. Ich berechne das momentan auch bei jedem Abruf, das wird dann wohl auch nicht stimmen. Meine Applikationen sind aber nicht so gross und per IP geht das Programmieren auf dem ESP32 auch recht schnell. Daher fällt eine volle Programmierung nicht so sehr auf...

Viele Grüße und schöne Ostertage!
Julius

[mumpf]

Hi Julius,

mein change ist der hier: https://github.com/mumpf/knx/commit/...53a73d75dd1845.

Meine Applikationen sind aber nicht so gross...

Ich wollte Dich zu nichts drängen, Du hast nur das andere schon portiert, da wollte ich Dich nur über die weiteren Korrekturen informieren. Ich hab allerdings auch beim Original nachgeschaut, der Bereich ist da auch komplett anders. Wo man da den crc speichern kann, kann ich Dir ehrlich gesagt nicht sagen. Kannst ja mal schauen und selber entscheiden. Ich dachte nur, wenn Du so erfolgreich bist mit der Portierung, dann könnte man ja Thomas mal einen pull request schicken.

... und per IP geht das Programmieren auf dem ESP32 auch recht schnell. Daher fällt eine volle Programmierung nicht so sehr auf...

Ich hab die ersten ungefähr 1000 Tests meines Logikmoduls auch so gemacht, dass ich eine Linux-VM mit dem Stack gestartet habe und mit der ETS dagegen programmiert habe. Da fallen 8-10 kByte Parameter wirklich nicht auf. Aber jetzt arbeite ich auf dem SAMD direkt am TP (ist ja auch die Zielanwendung) und da dauert das eben ewig. Deswegen freue ich mich ja so riesig, dass da noch so viel rauszuholen war.

Auch Dir noch ein Frohes Osterfest,
Gruß, Waldemar

[OutOfSync]

Hi Waldemar,

ich gucke mir sehr gerne an. Danke fürs Bescheid geben! Den crc zu speichern wird kein Problem sein, nur das mit dem LoadState muss ich mal genauer gucken. Und ja, ein pull request wäre doch eine tolle Sache

Gruß, Julius

[OutOfSync]

Hi Waldemar,

...Für die Speicherung muss ich da tiefer reinschauen, denn der gespeicherte Wert muss ja auch in den Flash.

ist das sicher? Muss der CRC wirklich über einen Neustart hinweg im Flash gespeichert werden? Nach dem Neustart gibt es doch nochmal loading->loaded und dann wird der Wert eh wieder berechnet. Sollte es daher nicht ausreichen den _crc einfach beim Übergang zu berechnen und dann im Speicher zu haben? Vielleicht übersehe ich etwas, habe den Code nur angeguckt und noch nichts getestet. Ein Problem wäre wenn der CRC angefordert wird bevor es den loading->loaded Übergang gab. Ist das der Grund? Das würde dann ja Sinn machen denn vorherigen Wert zu speichern. Schaden tut es nicht, 16bit bekommt man noch ins Flash

Der Code kann aber ganz einfach in den neuen Stack eingebaut werden, denn TableObject::loadEventLoading gibts da auch. Mit oder ohne Flash, beides geht

Viele Grüße, Julius

[thewhobox]

Guten Morgen,

Der Crc darf nur im Loaded Zustand gültig sein.
Mit meinem Code zum berechnen gab es anscheinend Probleme, wenn man den crc zwei mal mit dem gleichen Speicher berechnen hat.
Deswegen war es überhaupt erst notwendig ihn zu speichern (und weil es so in der Spec steht).

Du kannst es gerne mal ausprobieren ihn beim Neustart des Gerätes zu berechnen und uns dann das Ergebnis mitteilen. Das Problem trat glaub bei jedem 5. Mal neu berechnen auf.


Gruß Mike

[mumpf]

Hi Julius,

ist das sicher? Muss der CRC wirklich über einen Neustart hinweg im Flash gespeichert werden?

Sicher ist gar nichts bzw. immer diskussionswürdig! Aber ich kann mal die Beobachtungen aus meinen Tests ausführen und warum ich zu dem Schluss komme:

Das Problem trat glaub bei jedem 5. Mal neu berechnen auf.

Ich bin mir nicht sicher, ob es bei jedem 5. mal auftrat. Aber das neu berechnen war nicht stabil. Das mag an dem Algorithmus gelegen haben (glaube ich nicht) oder an dem Speicherbereich, den ich für die Neuberechnung genommen habe (glaube ich eher), aber ich hatte wie gesagt am Ende einen Fall gefunden, bei dem ich einen Parameter von 1 auf 3 geändert habe, da hat die partielle Programmierung geklappt, wenn ich aber wieder von 3 auf 1 gegangen bin, wurde immer komplett programmiert. Deswegen war jedes mal neu berechnen nicht zielführend.

Wenn man die Beobachtung noch mit berücksichtigt, ist ein neu Berechnen beim Neustart potentiell auch nicht zielführend, da - wenn man Pech hat - auch hier unterschiedliche Werte rauskommen. Hier wäre Arbeit notwendig, um herauszufinden, warum das Ergebnis der Neuberechnung nicht stabil ist. Die Arbeit wollte ich mir nicht machen, deswegen habe ich es erstmal mit Konstanten versucht.

Mit Konstanten hat die partielle Programmierung immer geklappt (ok, ich habe es nur ca. 20 mal probiert, aber mit verschiedenen Kombinationen und vor allem auch mit meinem reproduzierbaren 1-3-1 Fall). Konstanten funktionieren aber nicht, wenn man ein Gerät in verschiedenen Projekten haben will (ein Randfall, aber wenn schon, dann macht man es richtig). Deswegen die Idee von Mike (und auch in der Spec beschrieben), dass man nur beim Übergang von Loading->Loaded berechnet. Da es gleich danach einen Neustart gibt, muss der Wert in den Flash.

Nach dem Neustart gibt es doch nochmal loading->loaded und dann wird der Wert eh wieder berechnet.

Das habe ich nicht beobachten können. Ich hatte Debugausgaben drin, um die Stabilität der Werte zu verifizieren. Die haben ganz klar gezeigt, dass Loading->Loaded nur nach dem Programmieren passiert. Zumindest in meinem Stack-Fork. Nach einem Neustart passiert da gar nichts, Vor dem Neuprogrammieren wird dann der Wert über PID_MCB_TABLE abgefragt und nach dem Programmieren wird er beim Loading->Loaded neu berechnet.

An sich ist meine Implementierung jetzt ein table_object mit CRC, das den CRC nur einmal berechnet und ihn beliebig oft abfragbar macht. Aus Schnittstellen-Sicht macht das auch richtig Sinn.

Ich habe gestern im Rahmen meiner Tests zu meinem Sensormodul bestimmt 100 mal mit der ETS verschiedenste Parameterkombinationen programmiert, immer partiell. Es hat mit dem aktuellen Verfahren (CRC im Flash) immer funktioniert, die ETS hat immer das Richtige gemacht und das Ergebnis war auch immer korrekt (also die partiell übertragenen Parameter sind auch an der Richtigen Stelle im Speicher gelandet).

Ich habe sogar den Update-Fall getestet (also eine neuere Applikationsversion in die ETS gespielt und dann über partiell programmiert). Daraus hat die ETS faktisch eine full-Programmierung gemacht, aber dann auch mode=1 mit fill=0 genutzt und so nur 21 Sekunden gebraucht (statt der 90, wenn auch alle 0x00 übertragen werden).

In meinem Setup (MDT-IP-Schnittstelle, Longframe-Support mit APDU=56) klappt das geradezu perfekt. Ich werde meine heutigen Tests mit dem eibd machen und ich hoffe, das das auch alles so gut läuft. Morgen dann noch eine Telko mit einem Kumpel, der noch 2 weitere Schnittstellen hat und wenn das klappt, gehe ich davon aus, dass es relativ stabil ist.

Julius, wenn Du mich fragst, würde ich den Wert in den Flash packen und nur einmal berechnen. Das ist die getestete und meiner Meinung nach auch zuverlässigste Methode. Und 2 Byte mehr pro table_object kann man schon spendieren , auch wenn ich sonst sehr für speichersparen bin.

Gruß, Waldemar

P.S.: Ich danke euch fürs mitdiskutieren und mitmachen! Ich hatte es echt vermisst, solche Sachen auch mal durchzusprechen, bevor man "irgendwas" macht.

[thewhobox]

mumpf super Erklärung!

Nach dem Neustart gibt es doch nochmal loading->loaded und dann wird der Wert eh wieder berechnet.

Das stimmt so nicht. Den Status einer StateMachine wird explizit nur über die ETS und den Prozeduren geändert.

Gruß Mike


P.s.: ja mir hat der Thread auch viel gebracht. Finde es immer wieder toll, wenn man solche Fragen mit einer guten Community wie hier teilen kann.

[OutOfSync]

Moin zusammen!

Danke für die Erklärung, das macht alles viel Sinn so. Ich nutze den Stack zwar schon länger, habe mich aber mit den Interna der KNX Spec noch nicht so sehr auseinandergesetzt. Jetzt lerne ich richtig viel, das macht Spass! Und auch mit git komme ich immer besser klar. Ich fand es auch Schade dass sich nicht mehr so viel getan hat - jetzt kommt mal wieder etwas Schwung rein

Ich habe den Code jetzt in den aktuellen Stack eingebaut https://github.com/OutOfSync1/knx/co...27d3e78d42d4ba. Es scheint soweit zu funktionieren, es wurden immer nur die geänderten Parameter übertragen und ich habe keinen vollen Download beobachten können. Vielleicht guckt ihr mal drüber, dann kann ich einen pull request erstellen - wäre der erste den ich mache...

Viele Grüße
Julius

[thewhobox]

mumpf Mir stellt sich aktuell eine Frage und glaube du hast da schon die Antwort^^
Woran erkennt die ETS, dass eine Applikation geupdated werden kann und die Parameter/KOs übernommen werden können?
Ansonsten werden ja beim Ändern der Applikation auch die Parameter und verbundenen KOs zurückgesetzt.

Gruß Mike