KNX/EIB Wie verhält sich der Linienkoppler bei NACK, BUSY und unbeantworteten Telegrammen?

[klaus]

Hallo,

ich beschäftige mich gerade intensiver mit Buslast bzw. Laufzeiten von Telegrammen und mir stellt sich die Frage wie sich ein Linienkoppler verhält, wenn ein Telegramm mit NACK, BUSY oder garnicht quittiert wird:

1) Werden zuerst die bis zu 3 Wiederholungen für dieses Telegramm abgearbeitet, bevor andere Telegramme im Puffer weitergeleitet werden?

2) Werden zunächst die restlichen Telegramme im Puffer weitergeleitet, bevor eine Wiederholung durchgeführt wird? Wohl eher nicht denke ich ...

3) Bei Telegrammen mit BUSY: Wird hier noch eine zeitliche Verzögerung vor dem nächsten Versuch eingefügt bevor die Wiederholung gesendet wird? Wie lange ist diese Verzögerung typischerweise? Warten auch hier allfällige andere Telegramme im Puffer so lange, bis das BUSY Telegramm maximal 3 x probiert wurde?

Hintergrund meiner Frage: Wenn innerhalb kurzer Zeit mehrere Telegramme über den Liniekoppler weitergeleitet werden und keines dieser Telegramme von einem Gerät beantwortet wird (z.B. weil der Linienkoppler nicht filtert und sich in der Linie kein Gerät angesprochen fühlt), dann kommt da inklusive 3-maliger Wiederholung schnell eine ziemliche Buslast zusammen und reguläre Telegramme werden ziemlich verzögert.

Ich habe im Moment das Problem dass gelegentlich Read-Telegramme der Alarmzentrale nicht oder zu spät (nach mehr als 1,3 Sekunden) beantwortet werden. Ich denke dass dies möglicherweise an dieser Problematik liegen könnte ...

Schöne Grüsse,
Klaus

[Michel]

Es gibt dafür eine Spezifikation, die ich aber leider gerade nicht zur Hand habe.
Aber wenn du es empirisch ermitteln willst: Bus-Monitor der ETS fleissig mitlaufen lassen

weil der Linienkoppler nicht filtert und sich in der Linie kein Gerät angesprochen fühlt), dann kommt da inklusive 3-maliger Wiederholung schnell eine ziemliche Buslast zusammen

Wenn das so ist, dann ist "Durchzug" bei den Linienkopplern nicht mehr empfehlenswert. Genau dafür sind die Filtertabellen ja da.
Nur muss man sich halt Gedanken darüber machen, welche Telegramme über den Koppler hinweg geroutet werden dürfen/sollen; z.B. für Visualisierungen, HS&Co. etc...

Und für letztere empfiehlt sich dann auch die Auswahl des am besten geeigneten "Platzes" in der Anlage.

[tbi]

Hallo Klaus,

Da gibt es ein Baustein, den kannst Du auf die Linie Klemmen:

Buslastreduzierung

Gruß Tbi

[klaus]

Da gibt es ein Baustein, den kannst Du auf die Linie Klemmen:

Ja, den Ack-Baustein von B+B habe ich ebenfalls bereits gesehen. Ich halte es persönlich für keine so gute Idee auf Verdacht hin einfach alles quittieren zu lassen, weil es ja wirklich mal passiren kann, dass ein Teilnehmer ein Telegramm nicht mitbekommt und daher auch kein NACK senden kann. Dann lieber doch alles sorgfältig parametrieren, damit jedes Telegramm auch eine Gegenstelle hat die sich dafür interessiert und ein ACK sendet.

[klaus]

Aber wenn du es empirisch ermitteln willst: Bus-Monitor der ETS fleissig mitlaufen lassen

Die ETS ist mir dafür dann doch etwas zu sperrig. Werde das aber mal austesten, sobald ich den EIB-Analyzer habe. Der kann das wohl besser.

Wenn das so ist, dann ist "Durchzug" bei den Linienkopplern nicht mehr empfehlenswert. Genau dafür sind die Filtertabellen ja da.

Hab den "Durchzug" auf den Kopplern auch bereits deaktiviert. Und für die noch kommende Visualisierung werde ich halt mit Dummy-Applikationen arbeiten. Ist zwar etwas mehr Aufwand, dafür aber sauber gelöst.

[atlatus]

Der ETS Monitor protokolliert ab etwa 60% Buslast nicht mehr alles mit. Deshalb kann er auch zu einer "getrübten Wahrnehmung" der tatsächlichen Verhältnisse auf dem Bus führen. Wenn du wirklich sehen willst, was auf dem Busl los ist, kommst du um den Analyzer nicht herum.

Übrigens ist so ein EIB Doctor auch sehr gut geeignet, andere Buslastfallen als nur den Linienkoppler zu identifizieren und zu beheben. Ich bin mit wenigen Änderungen von teilweise 70% Buslast mit vielen Störungen auf 3% runtergekommen. Interessanterweise waren falsch programmierte Logik-Bausteine eine der Hauptverursacher.

[atlatus]

EIBAnalyzer, EIBDoctor

Hallo, weil es gerade so schön passt, habe ich eine Beschreibung mit Erfahrungsbericht zum EIBDoctor geschrieben:

EIB Doctor, EIBAnalyzer, EIBWeiche, Analyse des EIB Bus, Störungen, Überlastung

gruss peter

[Gamma]

ACK Baustein

Ich halte es persönlich für keine so gute Idee auf Verdacht hin einfach alles quittieren zu lassen, weil es ja wirklich mal passiren kann, dass ein Teilnehmer ein Telegramm nicht mitbekommt und daher auch kein NACK senden kann.

Hallo Klaus,
das darf NICHT passieren. Basta.
Wenn irgendein Teilnehmer ein ganzes Telegramm nicht mitbekommen
würde hätte er am KNX Bus nichts verloren.
Wenn er aber beschäftigt ist überschreibt er mit seinem "BUSY" das "ACK"
des Acknowledge Bausteins.
Genauso verhält es sich mit "NACK".
Daher werden die Wiederholungsfunktionalitäten des Bussystems durch den
Acknowledge Baustein in keinster Weise "ausgehebelt".
Lediglich die sinnlosen Wiederholungen von Telegrammen (==Buslastvervierfachung) werden vermieden.

Grüsse von Gamma!

[makki]

Und noch ergänzend: ein LK ACKed immer alles, was er weitergeleitet hat. So steht es in der Spec und nein: das macht bei Lichte betrachtet evtl. nicht wirklich Sinn
Der ACK ist also keine Bestätigung ob ein Telegramm an irgendeinem Ziel ankam, sondern nur der fehlende Ack ein Indikator für ein eventuelles Problem.

Bei einem sauberen Bus mit funktionierenden Geräten.. Nein ich sage es nicht

Makki