ElabNET Technik Forum

Hallo Leute,
ich bräuchte bitte mal Beistand. Kurz und knapp, da ich eigentlich schon auf der Arbeit sein müsste.

Heute Nacht ist irgendwas passiert auf meinem KNX Bus passiert. Im Busmonitor sehe ich das seitdem viele Telegramme 4-fach aufgezeichnet werden. Timberwolf und Loxone habe ich schon mal neu gestartet.

KNX Taster scheinen zu funktionieren.

Befehle die man mit dem KNX Busmonitor (über die KNX Schnittstelle des TWS) sendet, bewirken auch nichts.

Wo könnte ich noch den Fehler suchen? Evtl. kann Elabnet mal einen kurzen Blick drauf werfen, das wäre sehr nett und ich bin gerade völlig ratlos.

Erster Verdacht, die Wetterstation könnte kaputt sein und stört den Bus!

Die Wetterstation sollte abgeklemmt sein, bin mir gerade aber nicht sicher. Dennoch habe ich weiterhin 4-fach Telegramme auf dem Bus .

4-fach Telegramm bedeutet, der Sender des Telegramm bekommt kein ACK und wiederholt daher das Ganze.

Ab 22:16 ist da also irgendetwas kaputt, allerdings finde ich auch die Grundeinstellung, den Messwert alle 30-Sekunfen auf den KNX zu senden mehr als übertrieben. Kein Regler der Welt benötigt so häufig den Messwert, geschweige das er sich so schnell ändert im Heizungssystem. Sich den Messwert in der Zyklizität in eine Timesries zu schreiben kann ja jeder für sich entscheiden, der Mehrwert an Informtionsgewinn bleibt aber auch dort gering. Und im TWS lässt sich das ja getrennt gestalten, oft in die Timesries aber nur selten auf den Bus, das solltest.grundsätzlich Mal korrigieren.

Zur weiteren Analyse Mal bitte auch die weiteren Häkchen im Busmonitor aktivieren.

Welches Gerät müsste denn das ACK senden? Wenn in der gleichen Linie halt ein Taster oder Regler, wenn in einer anderen Linie ggf der LK. Ist ein solcher LK ggf Busy? Was sagen Diagnoseangaben der Spannungsversorgung des Busses?

Wie hoch war die allgemeine Buslast bis 22:16?

Hallo Göran,
wenn ich ACK im Busmonitor aktiviere wird nichts weiter angezeigt, sonst war alles angehakt. (Ich nutze den 8-fach TP-UART).

Die 1.0.200 ist der Timberwolf selbst. Die 6/1/16 (nur exemplarisch gewählt) ist eigentlich erstmal mit nichts weiter verbunden (höchstens die Loxone fragt den noch ab).

Die Buslast war davor immer so 1.200 bis 1.300 Telegramme.

Edit: Loxone mal vom Bus genommen. Immer noch 4-fach Telegramme.

Spannungsversorgungen hatte ich gecheckt, keine Auffälligkeiten!

ich würde in der ETS mal nachschauen wer das ACK senden soll
und den mal versuchen neu über die ETS zu programmiren
hatte bei mir 1998 einen ähnlichen fall
ein versuch ists alle mal wert

Hallo Dominik,

Ein Ack wird geschickt von allen Geräten, die mit einem TP-Uart 2 Chip ausgestattet sind, sowie allen Segment und bereichskopplern. Also von allen moderneren Geräten, damit auch vom TWS. Es sollte also am Bus nicht an Acks mangeln.

Ein solches ACK kann man im Bus Monitor nur dann sehen, wenn dieser im Real Bus Monitor Mode arbeitet, was nicht möglich ist, wenn das KNX Interface gleichzeitig auch für die Kommunikation mit dem Bus genutzt wird. Du müsstest also entweder den Applikationsmodus von der KNX Schnittstelle abschalten , wodurch der Server dann nicht mehr mit dem Bus kommuniziert (nur noch aufzeichnet), oder eine zweite Schnittstelle bei uns kaufen und anschließen.

Liebe Grüße

Aha, die GA 6/1/16 hat auf dem TP Medium keinen Empfänger, warum sendet man einen solchen Sensorwert dann auf den Bus und dann auch noch in solcher Telegrammdichte?

Bitte tut sowas nicht. Was nicht auf dem Bus benötigt wird gehört da auch nicht drauf gesendet, der KNX ist gut und stabil aber er ist kein Reservespeichermedium.

1200-1300 in welchem Zeitraum? Tag Stunde Minute?

Schau doch mal unter KNX - Physikalische Objekte - und da auf PA Statistiken. Da siehst du links in der Liste, welche Geräte was auf dem Bus treiben, sollte dir die Top Talker zeigen um die du dich ggf. mal näher kümmern kannst?

Und diese Statistiken mit Scope auf GA absteigend sortiert, dazu einen Abgleich mit dem ETS Projekt wo es nur einseitig verbundene GA gibt.

Hallo Dominic,

1. Im KNX Standard ist festgelegt, dass jedes Telegramm dreimal zu wiederholen ist (mit dem ersten Aussenden sind es dann vier Telegramme), wenn ein LL_NACK empfangen wird oder KEIN LL_ACK empfangen wird

2. LL_ACK (für LinkLayer_Acknowledge = Bestätigung der Datensicherungsschicht) werden von den Systemgeräten "Linienkoppler" oder "Bereichskoppler" gesendet UND seit einigen Jahren von JEDEM ANDEREN GERÄT in der jeweiligen Linie auf jedes Telegramm gesendet, das vom Buskoppler empfangen wird, soweit das Gerät dazu fähig ist. Das LL_ACK auf jedes empfangende Gerät wird hierbei unabhängig davon gesendet, ob das empfangende Telegramm überhaupt für das eigene Gerät gedacht ist (auswertung von Ziel-PA oder Ziel-GA, weil das passiert erst in höheren Schichten).

3. Ein solches LL_ACK darf nicht vom eigenen Gerät auf eigene Telegramme gesendet werden

4. Der TWS ist ein solches modernes Gerät, das LL_ACK auf jedes Telegramm sendet, das von ihm empfangen wird (unabhängig ob das Telegramm für den TWS "adressiert" ist).

5. Der Auszug aus dem Busmonitor zeigt, dass der TWS jedes Paket viermal sendet. Dies ist dann konform zum KNX Standard, wenn der TWS kein LL-ACK empfangen hat. Es erscheint mir unwahrscheinlich, dass der TWS ohne Probleme an der Buskommunikation teilnimmt, jedoch ausgerechnet LL_ACK nicht erhalten sollte.

6. Der Busmonitor kann diese LL-Telegramme der Sicherungsschicht im Busmonitor nur dann anzeigen, wenn der KNX Busankoppler im "Real-Busmonitor-Mode" befindet. Das geht nur dann, wenn dieser KNX Busankoppler sich nicht gleichzeitig im Applikationsmodus befindet. Wenn man an einem Timberwolf Server "nur" einen KNX Busankoppler angeschlossen hat und diesen auch für die Kommunikation über Gruppenadressen nutzt, dann ist dieser TWS im Applikationsmodus (das ist der betriebliche Standard) und dann befindet sich der KNX Busankoppler nur noch im "Virtual-Busmonitor-Modus" und hierbei werden die LL nicht vom CHip hochgereicht und sind damit nicht im Busmonitor sichtbar. Wenn man LL Pakete messen möchte, dann muss man den Applikationsmodus abschalten bzw. einen weiteren KNX Busankoppler bei uns kaufen.

7. Weitere Interpretationen und Annahmen zu Deinem Problem sind uns nicht möglich, wenn wir die Topologie Deiner Installation nicht kennen. Es wäre also wichtig zu wissen, wie die Linie aufgebaut ist, an welcher der Timberwolf Server installiert ist.


Vorschläge:

A: KNX Busankoppler des TWS vom Bus trennen und wieder anschließen (damit der aus dem KNX Bus versorgte Chip "gebootet" wird)

B: Alle anderen Geräte am Bus einzeln vom Bus trennen und wieder anschließen (und nach jedem Gerät prüfen, wann der Fehler weg ist, damit man das Gerät kennt, welches die ACKs hätte senden sollen und es nicht getan hat).

In einer KNX Linie mit modernen Geräten sollte eigentlich JEDES Gerät ein LL_ACK senden. Ich vermute, dass entweder der Busankoppler vom TWS defekt ist oder es nicht sehr viele moderne Geräte in der gleichen Linie gibt, welche kein ACK mehr senden. Alternativ kann auch ein Gerät zu Busfehlern führen, so dass NACK erzeugt werden.


Wir wünschen viel Glück bei der Fehlersuche


lg

Stefan