Bestimmung APDU Länge

[Wunk]

Hallo zusammen,

ich stehe mal wieder vor einem Rätsel und finde auch mit der Suchfunktion keine hilfreichen Beiträge.

Kann ich irgendwie festlegen, mit welcher Telegrammlänge "APDU" ich kommunizieren will, wenn ich ein KNX Gerät programmieren möchte?
Laut meiner Recherche wird ja in der ETS automatisch die größte Telegrammlänge verwendet, die von allen Teilnehmern unterstützt wird.
Habe ich da irgendeinen Einfluss darauf? Sehe ich irgendwo, welche APDU Länge aktuell verwendet wird, oder welche Längen unterstützt werden?

Mein Problem ist folgendes:
Ich versuche einen Gira G1 zu programmieren. Physikalische Adresse ist kein Problem, Applikationsprogramm fängt auch an zu laden, bricht aber regelmäßig ab mit der Meldung
"ADPU length 15 does not allow sending property elements with size 20 (Parametername: propertyDataType)"

In einem anderen Gebäude habe ich bereits solche Geräte ohne Probleme programmiert. Die KNX IP Schnittstelle war dort auch das gleiche Modell (Busch Jäger 6186/31).
Wenn die gleichen Teilnehmer dort die Telegrammlänge unterstützt haben, sollten sie es hier ja immer noch tun?


Im Changelog der ETS Version 5.7.2 habe ich etwas von einem Fehler der APDU Längenermittlung gelesen, der nun behoben sei, und gleich mal das Update durchgeführt in der Hoffnung dass das helfen könnte. Leider keine Änderung.

Gira G1 Version 2.2.60
Programmversion (in ETS) 2.3

Kennt irgendjemand diese Fehlermeldung und weiß Abhilfe?

Gruß,
der verzweifelte Wunk

[Klaus Gütter]

Da fallen mir drei Dinge ein:

1. Vielleicht hast du in den Projekt-Optionen die Kompatibilitätsoption "Verwende reduzierte Buskommunikation" angewählt? Dann reduziert die ETS nämlich auch die maximale APDU-Länge auf 15.
2. Wenn du über ein IP-Interface programmierst, ist zwischen dem und dem G1 ja auch noch ein IP-Router. Vielleicht beschränkt der die max. APDU-Länge? Oder die Schnittstellenadresse ist falsch, so dass die ETS bei der Ermittlung der max. APDU-Länge entlang des Kommunikationspfads durcheinanderkommt?
3. Wenn die Kommunikationsoption "Direkte IP-Verbindung verwenden" angehakt ist und dein PC im gleichen Netzwerk wie das G1 sitzt, müsste sich die ETS eigentlich direkt mit dem G1 verbinden können; dann gibt es keine Beschränkungen durch Interfaces oder Router entlang des Pfads.

Gruß, Klaus

[Wunk]

Hallo Klaus!
Ich habe diese Einstellungen kontrolliert.
1. "Verwende reduzierte Buskommunikation" ist nicht gesetzt.

2. Was den Router angeht weiß ich leider nicht welche Telegrammlängen hier unterstützt werden. Ich finde dazu auch keine Angaben. Aber woher weiß die ETS das eigentlich? Kann man das irgendwie online ermitteln?

3. Option "Direkte IP-Verbindung verwenden" ist aktiv und ich bin auch im gleichen Netzwerk.
Ich weiß aber nicht wie ich der ETS sage dass ich ohne den Umweg über IP Interface verbinden möchte.

Inzwischen hatte ich das Glück, dass nach mehrfacher fehlgeschlagener Programmierung zumindest der Teil übertragen wurde, den ich geändert hatte. D. h. momentan kann ich mit dem G1 die gewünschten Funktionen bedienen. Wenn ich jetzt aber noch Änderungen habe und nie weiß ob die relevanten Punkte durchgekommen sind bevor die Verbindung mit obiger Fehlermeldung abbricht ist das ziemlich doof.

EDIT: Ich muss korrigieren, ich erreiche den G1 zwar übers Netzwerk, bin aber nicht im gleichen Subnetz.
PC: xxx.xxx.1.10
G1: xxx.xxx.200.16
Subnetzmaske 255.255.255.0

Bedeutet das nochmal einen APDU Flaschenhals?

[Klaus Gütter]

2. Steht in der Geräteinfo der Routers

Wenn du nicht im gleichen Subnetz bist, hängt das von der Konfiguration des Routers (im IP-Sinn, nicht dem KNX-IP-Router) zwischen den Subnetzen ab. Speziell muss der die KNX/IP Multicasts weiterleiten. Kannst du den PC vielleicht in das 200.16-Subnetz schieben?

[Wunk]

Oh, es klappt
Ich dachte immer wenn ich das Gerät von meiner IP aus anpingen und auch programmieren kann sollte das ja passen, aber für die extended frames scheint das nicht zu reichen. Gut dass wir noch einen Port für das .200er Subnetz freihatten.

Vielen Dank!

[Klaus Gütter]

Schön, dass es geht!

Ich dachte immer wenn ich das Gerät von meiner IP aus anpingen und auch programmieren kann sollte das ja passen, aber für die extended frames scheint das nicht zu reichen

Das hat mit extended frames nichts zu tun. Was passiert ist folgendes:

• Wenn die ETS ein Gerät programmieren will, das laut Produktdaten IP unterstützt, versucht sie das Gerät zunächst mal mit einen KNX/IP SearchRequest im IP-Netzwerk zu finden. Der läuft über Multicast (und das wird bei dir nicht geklappt haben). Dadurch erhält die ETS weitere Informationen vom Gerät, vor allem erst mal die IP-Adresse, aber auch, ob das Gerät eine direkte IP-Verbindung unterstützt.
• Sollte das funktioniert haben, geht der Rest blitzschnell und ohne Längeneinschränkungen durch dazwischenliegende KNX-Infrastruktur über direktes IP-DeviceManagement
• Sollte das nicht funktioniert haben, geht die ETS über das KNX-TP-Netzwerk. Das ist sehr viel langsamer (9600bit/s) und die APDU-Länge wird von der Schnittstelle und den zwischen ETS und Gerät befindlichen Kopplern begrenzt.

[Axel]

Wo finde ich den die Reduzierte Buskommunikation in der ETS6?

[Axel]

Habs gefunden.... unter Details und dann nochmal auf Details...

[GLT]

Habs gefunden.... unter Details und dann nochmal auf Details...

Das sind dann detailiertere Details - kann man ja nochmal x Ebenen runterbrechen

[Axel]

Versteckter geht es nicht mehr.... Hätte es eigentlich an der Schnittstelle erwartet 😕