Hilfe wegen sporadischer Telegrammverluste gesucht.

[Klaus Gütter]

vermutlich bekommt die USB-Schnittstelle auf der Hautplinie das ACK auf der 2.2 manchmal nicht mit

Nochmal: ein ACK ist nur lokal auf dem Liniensegment. Du kannst auf der Linie 2.0 nicht sehen, ob es auf der 2.2. ein ACK gab oder nicht. Das wird alles vom Linienkoppler entkoppelt.

[Klaus Gütter]

Würde der Homeserver, wie auch die Wetterstation, auf der Hauptlinie hängen, dann hätte ich bei den Wetterdaten jeden Menge Telegrammwiederholungen weil diese nur in der Visu verwendet werden.

Warum das denn? Die Schnittstelle, an der die Visu hängt, sollte ACKen.

[bambam]

Nochmal: ein ACK ist nur lokal auf dem Liniensegment. Du kannst auf der Linie 2.0 nicht sehen, ob es auf der 2.2. ein ACK gab oder nicht. Das wird alles vom Linienkoppler entkoppelt.

In dem Fall gab es für die GA ja Teilnehmer auf der 2.2 und auf der 2.3. Ansonsten würde ich die Telegramme die nur auf den Liniensegmenten sind bei Filterung auf der Hauptlinie auch gar nicht sehen. Bei Telegrammen von 2.0 -> 2.2 oder 2.3->2.0->2.2 wird das ACK vom LK doch auf die 2.0 weitergeleitet?

[gbglace]

Bei Telegrammen von 2.0 -> 2.2 oder 2.3->2.0->2.2 wird das ACK vom LK doch auf die 2.0 weitergeleitet?

Und nochmal NEIN.

2.3.x sendet ein Telegramm potentieller Empfänger ist ein Gerät auf 2.2.x.

Alle Koppler sind sauber eingestellt also geht das Telegramm von 2.2.x durch 2.2.0 durch 2.3.0 auf 2.3.x.

Da alle ACK nur innerhalb einer Linie kursieren wird bereits LK 2.2.0 ein ACK senden, damit 2.2.x keine Ersatztelegramme sendet. Danach wird auch Koppler 2.3.0 ein ACK senden damit je nach Parameter 2.2.0 keine Ersatztelegramme auf der HL sendet (das Senden der Wiederholungstelegramme lässt sich aber glaube bei den LK deaktivieren als Parameter). Das ACK von 2.3.x bewirkt dann wiederum auch nur das 2.3.0 keine Ersatztelegramme sendet. Ein ACK von 2.3.x kommt niemals auf 2.2.x an da diese Telegrammtypen nicht durch LK durchgereicht werden. Das ist auch nicht einstellbar in den LK.

Insofern bei Transfer über mehrere Linien hinweg kommt niemals eine direkte Antwort des "echten" Empfängers beim Absender an.
Warum?
Weil es für die Gruppentelegramme in dem Sinne keinen spezifischen Empfänger gibt. Alle Geräte hören alles auf dem Bus. Insofern ist es ausreichend für eine Telegrammquelle das das gesendete Telegramm quasi elektrisch überhaupt den Bus erreicht hat. Und das kann im Prinzip jedes Gerät auf dem angeschlossenen Liniensegment bestätigen. Es gibt auch welche die das tun ohne überhaupt mit der GA eine KO Verbindung zu haben.

Ist ein Gerät kaputt welches eine gesendete GA empfangen sollte, dann ist es eben kaputt und es funktioniert etwas nicht, da wird es nicht besser wenn da noch 4 weitere Telegramme kommen. Wichtig ist, dass das Telegramm auf dem Bus gelandet ist und allgemein verfügbar war.

Damit das alles funktioniert müssen die Filtertabellen in den LK alle stimmen.

[mumpf]

Hi,

2.3->2.0->2.2 wird das ACK vom LK doch auf die 2.0 weitergeleitet?

das hab ich früher auch gedacht. Aber wenn man sich klar macht, dass der Bus ja wirklich langsam ist und man Telegramme sparen will, und dass LK ja gerade dazu gedacht sind, die Liniensegmente zu entkoppeln, also weniger (anstatt mehr) Buslast produzieren sollen, wird einem klar, dass das so nicht laufen kann.

Ein Telegramm, dass auf 2.3 los geht und bis zur 2.2 soll, wird vom LK 2.3.0 empfangen und von diesem Bestätigt (ACK). Dann schickt der LK dieses Telegramm auf die 2.0-Linie. Der LK 2.2.0 merkt, dass er das Telegramm auf die 2.2 weiterleiten soll und bestätigt es auf der 2.0-Linie (ACK). Dann schickt er es auf der 2.2-Linie weiter und bekommt vom Emfpänger eine Bestätigung (ACK).

Ein NACK oder BUSY auf dem Weg führt dazu, dass der jeweilige Sender das Telegramm wiederholt, und zwar nur auf dem zugehörigen Segment. Also würde der LK 2.3.0 das Telegramm 3 mal auf der 2.0-Linie wiederholen, wenn es dort nicht bestätigt wurde.

Kurz gesagt: Nein, die ACK werden nicht weitergeleitet.

Gruß, Waldemar

P.S.: Göran war schneller...

[bambam]

Ok, ok! Dann habe ich das jetzt wirklich verstanden. Vielen Dank für die zweifache ausführliche Erklärung

Was ich oben aber meinte war ja auch nur, dass meine USB-Schnittstelle auf der 2.0 ein ACK bekommt. Nur bekommt sie das ACK nicht wie ich schrieb von der 2.2 sondern vom LK 2.2.0, was aber nicht heißt, dass es auf der 2.2 überhaupt ein ACK gab.

[bambam]

Guten Morgen,

es gab zwar noch keine Fehlermeldung, aber ich sehe auf dem Busmonitior 3-4 mal am Tag ungültige Frames. Was könnte die Ursache dafür sein? Könnte das der Grund für die sporadisch nicht ausgeführten Telegramme sein?

Grüße André


Ungültiger Frame_3.jpg Ungültiger Frame_2.jpg Ungültiger Frame.jpg

[makki]

Also ich würde ja Klaus nie widersprechen (meistens verliere ich da eh )
Aber als ERSTES brauchst du m.E. eine zuverlässige Schnittstelle, keinesfalls USB!!, die auch richtig aufzeichnen kann und wird, die USB sind allesamt, naja, m.E. bestenfalls überforderte Schätzeisen/Schrott, die kacheln bei hohem Telegrammverkehr schon "by Design" weg. das war vor 10J so und hat sich vermutlich leider nicht geändert. Goto TP-UART, IP, 50 tps+
Werf die USB einfach weg

Edit: du wirst dich wundern was so eine TP-UART sogar mit einem uralten eibd auf so einem KNX-TP plötzlich alles "sieht", auch die ganzen Fehler der überforderten USB-SS..

Makki

[makki]

Und die Diskussion führe ich auch gerne viele Jahre später nochmal: die USB-SS als HID waren und sind eine komplette Fehlkonstruktion..

[makki]

Und de USB-SS kann weder lokal auf derselben Linie ein echtes PHY-ACK (dafür ist sie vieeel zu langsam) noch gar ein auf einer anderen Linie (das müsste der LK IP oder TP-UART machen..)

Edit: Bis die mind. 64byte da durch das USB HID durch sind, ist es längst viel zu spät für ein ACK..

[hjk]

Aber als ERSTES brauchst du m.E. eine zuverlässige Schnittstelle, keinesfalls USB!!, die auch richtig aufzeichnen kann und wird, die USB sind allesamt, naja, m.E. bestenfalls überforderte Schätzeisen/Schrott, die kacheln bei hohem Telegrammverkehr schon "by Design" weg. das war vor 10J so und hat sich vermutlich leider nicht geändert. Goto TP-UART, IP, 50 tps+
Werf die USB einfach weg

Das trifft nur auf alte USB Schnittstellen mit altem Protokoll zu.
Modernere USB Schnittstellen wie unsere MDT USB haben damit null Probleme. Da geht nichts verloren ...
Alte USBs sollte man wirklich erneuern.

[makki]

Das trifft nur auf alte USB Schnittstellen mit altem Protokoll zu.
Modernere USB Schnittstellen wie unsere MDT USB haben damit null Probleme. Da geht nichts verloren ...
Alte USBs sollte man wirklich erneuern.

Mit Verlaub, meine ziemlich intensiven, wochenlangen Tests damals mit "modernen USB Schnittstellen" (ich will und werde keine Hersteller oder so nennen) haben anderes ergeben: die taugen für den Normalbetrieb halbwegs - im Gegensatz zu den alten, die eigentlich nur unbrauchbar waren und IMHO wirklich nur für die Mülltonne taugen.
Wenn man sich jetzt jedoch etwas "neues" kauft, bitte keine USB..

Aber auch die "neuen USB": sie sind halt nicht "Vollgasfest" nach immernoch aktuellem KNX-Standard.
Schon gleich garnicht mit der ETS oder ihrem Falken der sie ansteuert, daher als "Busmonitor" völlig ungeeignet, richtige, moderne Schnittstellen wie IP und ihren Chips (um nur einen zu nennen, sogar den "alten" TPUART1)
-> Können die locker mit 50tps+ einfach "überfahren", ohne das es holpert oder man es als Absender mitbekommt

Und mit sowas (USB) sollte man daher m.E. nicht versuchen die Buslast zu analysieren..

(ja ich meine USB = failure-by-design, sie werden das mit dem HID Profile nie hinbekommen, dafür braucht man nur einen Rechenschieber: waren es 12MBit bei 64byte Framegrösse aufm USB, aufm KNx warens noch gleich wieviel? und kann ich da einen (i)ACK rechtzeitig für ein korrekt empfangenes Telegramm rausschicken? Nein -> .geht technisch halt nicht..) Nichtmal mit nem RTOS.
Oder wurden "die neuen" auf USB 3.x (auch das würde beim HID-Profil nicht helfen) aufgerüstet?
Finger weg von USB-SS für solche Aufgaben, der KNX hat ein ziemlich kritisches Timing, das mit dieser Aufgabe via USB1/HID halt nicht vereinbar ist.

Makki

[Klaus Gütter]

Hallo Makki,

das Argument mit dem LL-ACK kann ich nicht nachvollziehen. Für (Bus-)Monitoring ist das sowie nicht relevant. Und ansonsten wird die Schnittstelle so konfiguriert, dass sie selber alles ACKed. Ein spezifisches ACK wäre nur interessant, wenn man mit der Schnittstelle versuchen wollte, ein KNX-Endgerät zu bauen.

Theoretisch lassen sich über USB-HID 64.000 Byte/s übertragen (full speed interrupt transfer: 64 Byte/Packet, 1 ms polling rate), in der Praxis sicher etwas weniger. Ich verstehe nicht, wie man das mit max. 1kB/s von TP1 oder < 4kB/s von RF auch nur ansatzweise "überfahren" können soll.
Wenn du mit deinen Tests schlechte Erfahrungen gemacht hast - was ich dir selbstverständlich abnehme -, spricht das meiner Meinung nach für Design- oder Implementierungsfehler und nicht prinzipiell gegen USB.

Gruß, Klaus