ElabNET Technik Forum

Mir ist da auch etwas nicht klar:

StefanW hat geschrieben: ↑Di Nov 03, 2020 10:46 pm ALLE Chips der 2. TP-UART Generation erzeugen die LL-ACKs bzw. bei deren Ausbleiben die Telegrammwiederholungen SELBSTTÄTIG bei allen PA-zu-GA Telegrammen. Das passiert also schon im Chip, nicht in Software im Stack.
Es wird dabei auf ALLE PA-zu-GA Telegramme reagiert, UNABHÄNGIG davon, ob eine GA auf ein Objekt bei dem mit einem solchen Chip gebauten KNX Gerät assoziert ist.

Das 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?
Theoretisch würde es dann ja gar keine Telegrammwiederholungen mehr geben, wenn das Telegramm nicht von einem Tunnel kommt oder?

StefanW hat geschrieben: ↑Di Nov 03, 2020 10:46 pm Alle PA-zu-PA-Telegramme werden vom KNX-Stack (bei uns im Co-Prozessor) acknowledged

PA zu PA wäre dann eine Geräte-Programmierung oder?

gbglace hat geschrieben: ↑Mi Nov 04, 2020 4:04 am Wenn 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.

Das 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.

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

Das ist interessant, das würde dann bedeuten, dass alle meine KNX-Geräte vom Jahr 2016 einen alten Chip benutzen.

Hallo zusammen!

Beim schnellen Mitlesen ist mir das etwas Zuviel.
Was ich aber nicht verstehe: Warum hab ich das Problem nicht?

=> Hab ich es nicht oder sehe ich sie nicht? Weder mit Telegrammen von NodeRed oder WG-Container am TWS.
Wobei ich mit Bus- und Gruppenmonitor und TWS-Busmonitor nachgesehen habe.

Ich habe aber keinen Linienkoppler und nur den TWS als Schnittstelle im Einsatz (plus das WG am TPUART).
Ich könnte mir der ETS auch noch über eine USB-Schnittstelle nachsehen - bringt das was?

lg
Robert

Bei dir wird es höchstwahrscheinlich so sein, dass du irgendwo auf deiner KNX-Linie ein Gerät mit neuem Chip schon hast (außer dem TW), sodass sowieso alle PA-zu-GA-Telegramme bestätigt werden.

starwarsfan hat geschrieben: ↑Sa Okt 31, 2020 3:11 pm ETS Gruppenmonitor laufen lassen, Timberwolf Busmonitor ebenfalls und dann Finger über den Scanner.
Im TW-Busmonitor sieht das so aus ...
Im ETS-Gruppenmonitor jedoch so ...
Dort kommt also offenbar nur ein Telegram an. Damit bin ich jetzt völlig verwirrt und habe den Faden verloren...

@starwarsfan
du hast das gleiche Symptom wie bei mir, kein anderes Gerät bestätigt die Telegramme und der TW kann sie nicht bestätigen, weil sie von ihm sind.
Die unterschiedlichen Anzeigen bei dir resultieren daraus, dass der TW-KNX-Busmonitor auch die wiederholten Telegramme anzeigt, der Gruppenmonitor der ETS hingegen nur das erste. Wenn du stattdessen den Busmonitor an der ETS beobachten würdest, dann kriegst du dort auch die 4 Telegramme angezeigt.

Zusatz:

starwarsfan hat geschrieben: ↑Sa Okt 31, 2020 2:59 pm Meine Edomi Instanz läuft als LXC-Container auf einem ProxMox-Cluster. Alles andere passt aber soweit.

Läuft dieser ProxMox-Cluster auf dem TW oder auf einer gänzlich anderen Hardware?

-) Wenn am TW, dann stimmt meine Aussage oben, dass wir das gleiche Problem haben.
-) Wenn auf einer separaten Hardware, aber verwendet einen Tunnel vom TW, dann stimmt die Aussage auch.
-) Wenn auf einer separaten Hardware und kein Tunnel vom TW, dann ist da wo der Wurm drin und das Edomi-Gerät sendet kein ACK.

Hi

Eraser hat geschrieben: ↑Mi Nov 04, 2020 2:36 pm Läuft dieser ProxMox-Cluster auf dem TW oder auf einer gänzlich anderen Hardware?

Proxmox-Cluster heißt in dem Fall wirklich Cluster auf separater Hardware. Konkret zwei HP ProLiant DL380p Gen8 Server, auf welchen all meine Container laufen. Unter anderem auch Edomi. Verbindung zum KNX-Bus über den TW.

OK dann ist es klar, warum du auch die Telegrammwiederholung hast so wie ich.

Eraser hat geschrieben: ↑Mi Nov 04, 2020 2:28 pm Bei dir wird es höchstwahrscheinlich so sein, dass du irgendwo auf deiner KNX-Linie ein Gerät mit neuem Chip schon hast (außer dem TW), sodass sowieso alle PA-zu-GA-Telegramme bestätigt werden.

Ehrlich gesagt - keine Ahnung. Meine KNX Basis ist 10 Jahre alt, allerdings sind später noch ein paar Aktoren dazugekommen (zB MDT Wetterstation und MDT Analogaktor).

Finde ich irgendwie in der ETS heraus, welche Geräte welchen Chip haben?

lg
Robert