ElabNET Technik Forum

Hab jetzt noch probiert, dass wenn ich den empfangenen Wert dann in einer TW-Logik verwende, ob es da einen Unterschied gibt dass nun ein ACK gesendet wird.
Ist aber auch nicht der Fall.

Mir ist gerade was anderes aufgefallen:

Nach dem Neustart des TW war der Dok-Mode bei den persistenten Logiken wieder automatisch aktiv. Ich war der Meinung dass das schon behoben wurde oder irre ich mich? Nicht dass da bei meinem Server was durcheinander geraten ist...

Hallo Wolfgang,

Eraser hat geschrieben: ↑So Nov 01, 2020 11:25 amHab jetzt noch probiert, dass wenn ich den empfangenen Wert dann in einer TW-Logik verwende, ob es da einen Unterschied gibt dass nun ein ACK gesendet wird. Ist aber auch nicht der Fall.

Das dürfte auch nicht so sein.

Ein ACK muss binnen 20 µs wieder auf dem Bus liegen (damit er - zusammen mit einer möglichen Entfernung von 700 m - was weitere 3,5 µs kostet - rechtzeitig den Absender erreicht) . Das passiert im Link Layer des KNX-Stacks, weit bevor Daten dekodiert und an den Dispatcher und von dort zur Logik gekommen sind.

Eraser hat geschrieben: ↑So Nov 01, 2020 11:31 amNach dem Neustart des TW war der Dok-Mode bei den persistenten Logiken wieder automatisch aktiv. Ich war der Meinung dass das schon behoben wurde oder irre ich mich? Nicht dass da bei meinem Server was durcheinander geraten ist...

Ich würde meinen, das wir da was behoben haben. Aber wenn kein Update mehr möglich ist und ein Neustart durchgeführt wurde, halte ich es für unwahrscheinlich, dass ein Update nicht funktioniert hat. Ausgeschlossen ist es nicht, weil der Status der Logik in einer Datenbank festgehalten ist und die werden beim Update i.d.R. nicht berührt.

Danke für die Screenshots, ich kann daran nichts falsches sehen.

lg

Stefan

StefanW hat geschrieben: ↑So Nov 01, 2020 12:37 pm Ich würde meinen, das wir da was behoben haben.

War es vielleicht das?

Changelog 1.6.0 Release Candidate 4

Logic Editor
• Bugfix: Restarting the Timberwolf Server does not interfere with set doctor mode (WD-1720)

Hallo Wolfgang,

ich müsste jetzt für Details ins Ticket sehen, aber ich denke, das ist schon behoben worden.

Wenn es da noch Probleme gibt, bitte einen separaten Thread mit nachvollziehbaren Hinweisen, dann gebe ich das morgen an die Entwickler, wenn das noch zu beheben ist.

lg

Stefan

Habe NodeRed nun per Recreate des Containers auf Version 1.2.2 aktualisiert.
Leider keine Änderung.

Danke Wolfgang,

ich denke nicht das es an Node Red liegt, weil bei Robert Mini gibt es das Problem ja auch nicht.

Ich muss mich mit den Entwicklern beraten und habe auch schon eine eMail in der Sache geschrieben und wir werden das morgen beraten

lg

Stefan

StefanW hat geschrieben: ↑So Nov 01, 2020 9:46 am Das beobachtete Verhalten bei Wolfgang hat also mit einem oder mehreren unbekannten Parametern zu tun, die wir bislang nicht miteinbezogen haben in die Betrachtung, weil diese eigentlich keine Rolle spielen sollten.
Wolfgang und Robert, vergleichen wir strukturiert:

1. Programmierung und Projekt-Upload.
- Bei beiden der TWS auf aktuellen Stand
- Verwenden beide die gleiche ETS?
- Haben beide die gleiche Reihenfolge angewendet, also erst Programmierung, dann Projekt-Upload. Gab es Fehler?

- Bei mir derzeit noch die 1.6RC4, denke das sollte aber nichts ausmachen. Update dann morgen.
- ETS 5.7.3
- Reihenfolge bei mir auch immer programmieren, dann Upload.

2. TWS & Schnittstelle
- Beide das gleiche Modell oder Unterschiede?
- Beide den gleichen Versionsstand?
- Beide gleiche EInstellungen, Anzahl Schnittstellen, gleiche Ports?

- TWS2500, 1.6RC4
- Schnittstellen, siehe Screenshot

3. Tunnel-PAs
- Beide gleiche Anzahl vergebener Tunnel-PAs?
- Folgen die Tunnel-PAs eine nummerischen Reihenfolge, keine Unterbrechung der Zahlenfolge der PAs?
==> Bitte Screenshots von der gesamten KNX Schnittstellen-Seite, inkl. Statusleiste oben

- Alle 25 Tunnel vergeben, direkt nach den PA des TWS selber ohne Leernummer o.ä.

lg
Robert

Hallo zusammen,

ich habe mich mit den Entwicklern besprochen und wir haben das Detail zu den LL_ACK und den Telegrammwiederholungen besprochen.

• Der Timberwolf Server nutzt für KNX-TP den zertifizierten Chip "TP-UART2+" von Infineon
  
• 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 (!)
  
• ALLE KNX-Geräte in einer Linie mit einem solchen modernen TP-UART2 Chip lösen ein Acknowledge aus, der schnellste gewinnt. Bei älteren Chips passiert dies im Stack, hierbei dann - je nach Alter - nur wenn die GA auch auf ein Objekt gebunden ist.
• Das Acknowlege-Verhalten hat also auch mit der verbauten Generation zu tun und verhält sich je nach Alter der Geräteentwicklung unterschiedlich
  
• Ein TP-UART 2 Chip bestätigt NICHT seine eigenen Telegramme
• Alle PA-zu-PA-Telegramme werden vom KNX-Stack (bei uns im Co-Prozessor) acknowledged
• Alle Pakete die von einem Tunnel kommen, werden IMMER ERST auf die TP-Schnittstelle gesendet. Dort wird das selbst gesendete Telegramm wieder eingelesen und an den Stack hochgereicht. Da dieses (per KNXnet/IP empfangene) Telegramm vom eigenen Chip ausgesendet wird, kann er es selbst nicht acknowledgen. Wenn kein LL_ACK ankommt, wiederholt es der Chip also selbsttätig.

Ich denke, wir können davon ausgehen, dass der verwendete TP-UART-Chip seine Arbeit richtig macht, Da die Software hier nicht beteiligt ist, kann sie auch keinen Fehler machen.

Das Auftreten der Telegrammwiederholungen bei Wolfgang dürfte deshalb auftreten, weil keiner der anderen TP-Busteilnehmer ein ACK sendet.

lg

Stefan

Hi Stefan,

Das musste ich jetzt mehrfach lesen.

Dann 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?

Denn 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. Kennt er hingegen auch alle Tunnel-PA als seine eigenen, würde dies zwar die Unterdrückung des ACK bei Wolfgang seinem Problem erklären, wäre aber technisch inkonsequent, da 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).

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.