Hallo Göran & Wolfgang,
gbglace hat geschrieben: ↑Mi Nov 04, 2020 4:04 amDas musste ich jetzt mehrfach lesen.
Sorry, wenn ich es schlecht beschrieben habe
gbglace hat geschrieben: ↑Mi Nov 04, 2020 4:04 amDann jetzt noch eine Frage, sofern du das Innenleben des TP-UART Chip kennst, wie denn der Chip erkennt das Telegramme auf dem Bus seine eigenen sind?
Der Chip hat sowohl Sender als auch Empfänger parallel auf dem Bus. Damit "sieht" der Empfänger, was jeder (auch der eigene) Sender auf den Bus schreibt. Damit kann die interne Chip-Logik jedes empfangene Bit im Empfangspuffer vergleichen mit den Bits die sich im Sendepuffer befinden. Sind beide Puffer gleich dann hat der Chip das Paket selbst auf den Bus gegeben.
Das ist vergleichbar mit einem Rundfunksender, bei dem der Tontechniker mit einem Radioempfänger die eigene Ausstrahlung checkt.
gbglace hat geschrieben: ↑Mi Nov 04, 2020 4:04 amDenn meine Annahme wäre bisher gewesen, das der TP-UART Chip als PA nur die des TWS Host kennt und die daran angedockten KO und GA Verlinkungen, um effektiv ACK zu produzieren.
Das selbständige Acknowlege macht er nur für den Typ "PA-zu-GA" Telegramm.
Bei "PA-zu-PA" Telegramm sendet unser KNX-Koprozessor das ACK, weil im TP-UART passen nicht alle 25 PAs des TWS rein.
gbglace hat geschrieben: ↑Mi Nov 04, 2020 4:04 amKennt er hingegen auch alle Tunnel-PA als seine eigenen, würde dies zwar die Unterdrückung des ACK bei Wolfgang seinem Problem erklären
Es handelt sich hier um "PA-zu-GA" Telegrammen (letztlich einem Multicast an eine Gruppe). Diese werden von TP-UART2-Chips GRUNDSÄTZLICH acknowledged. EGAL von welcher PA und egal ob die GA überhaupt mit einem lokalen Objekt assoziiert ist. Ausnahme: Das Paket wurde vom Chip selbst auf den Bus gelegt.
gbglace hat geschrieben: ↑Mi Nov 04, 2020 4:04 amda er die hinter dem Tunnel assoziierten GA nicht kennen kann und somit nicht in der Lage ist selbständig ein ACK zu senden, was ja nur ein Stack im Container selbst entscheiden kann (Taster am TP an EDOMI im Container).
Doch, JEDER am Bus angeschlossene TP-UART2 acknowledged einfach JEDES "PA-zu-GA" Telegramm.
Hinweis: Dieses Default Acknowledge-Verhalten des Chips lässt sich laut Datenblatt auch abschalten. Es könnte in anderen Produkten auch anders laufen.
gbglace hat geschrieben: ↑Mi Nov 04, 2020 4:04 amWenn dem wirklich so ist, das der TP-UART Chip auch die Tunnel-PA Telegramme als seine eigenen erkennt und ACK unterdrückt, dann wäre ja im Umkehrschluss die Verfügbarkeit von 25 Tunnel am TWS eher kontraproduktiv, da alles darüber angeschlossene mit GA Ziel anderer Tunnel oder TWS selbst zu enormer Buslast führt.
Eine KNX-TP Linie besteht mindestens aus zwei TP-Geräten (plus der Spannungsversorgung). Wenn nun eines davon ein IP Interface ist und einen eigenen Stack hat (wie der Timberwolf Server) dann liegt es an dem anderen KNX Gerät den ACK zu generieren. Im Normalfall sind eher Dutzende KNX Geräte angeschlossen. Die TP-UART2 werden mindestens seit 2013 angeboten. Normalerweise hat man wenigstens ein KNX Gerät im System, das einen solchen Chip hat und alle "PA-zu-GA" Telegramme acknowledged.
Eraser hat geschrieben: ↑Mi Nov 04, 2020 6:24 amDas heißt dann also, dass so ein neuer Chip, wie er in allen ausgelieferten TW verbaut ist, automatisch alle Telegramme von extern kommend bestätigt?
Nicht alle, sondern nur "Gruppentelegramme" also von einer beliebigen PA an eine beliebige GA.
(Die PA-zu-PA-Telegramme werden vom CoProzessor betätigt)
Eraser hat geschrieben: ↑Mi Nov 04, 2020 6:24 amTheoretisch würde es dann ja gar keine Telegrammwiederholungen mehr geben, wenn das Telegramm nicht von einem Tunnel kommt oder?
Im Prinzip Ja (sofern es keine Kommunikationsfehler gibt). Darum geht es ja, unnötige Telegrammwiederholungen zu vermeiden. Dadurch, das das ACK im Chip produziert wird, wird es auch schneller gesendet, womit der Bus schneller frei ist.
Eraser hat geschrieben: ↑Mi Nov 04, 2020 6:24 amPA zu PA wäre dann eine Geräte-Programmierung oder?
Richtig. Typischerweise von der ETS zum KNX-Gerät.
Eraser hat geschrieben: ↑Mi Nov 04, 2020 6:24 amDas geht mir auch durch den Kopf, da theoretisch dann alle nur mit dem TW verknüpften Telegramme von Containern, IP-Geräten, der ETS oder sonstigen "Devices" welche einen Tunnel des TW verwenden, automatisch immer 4-fach gesendet werden.
Wie gesagt, sehr theoretisch, weil normalerweise wird ein KNX-TP Bus auch als solcher betrieben, also mit dutzenden KNX-Geräten an der gleichen Linie, die sich untereinander unterhalten und die dann auch für die aus dem Tunnel kommenden Telegramme den ACK auslösen. Daher tritt es ja auch im Labor und bei Robert_Mini nicht auf. Wir hören von dem Problem auch nur in Deinem Fall, daher ist das nicht wirklich kein typisches Szenario.
Für die Kommunikation mit dem TWS wird es dann ohnehin demnächst eine MQTT-Schnittstelle geben, die einen hundertfach höheren Durchsatz ermöglicht, ohne über den langsamen KNX-TP gehen zu müssen.
lg
Stefan