MDT Netzteil zeigt häufig "Bus Error"

[gbglace]

Gibt es nicht ein weitergehendes Handbuch zu diesem Basalte Server? Es scheint so daß er Saubere Tunnelverbindungen kann, aber dein Szenario 2 scheint dann eher eine Art Routingfunktion zu sein und dann ist die ETS als quasi Teilnehmer auf einer IP-Linie, hier dann der Bereichslinie oberhalb der Hauptlinie unterwegs. Dann schickt der Basalte in dieser Funktion alles mögliche von TP auf die IP-alinie und dort landen die natürlich alle im nichts und der Server wiederholt die fleißig.

Wie sehen denn die ETS Schnittstellen Anzeigen im Szenario 2 genau aus? Ist sie dann über das Symbol Netzwerkkarte verbunden?


Und ansonsten wenn Du die Außenlinie auch wegen der galvanischen Trennung der Linien wegen erhöhtem Ausfallpotential wegen Klima usw. Baust, dann setze auch ein separates Netzteil für die Hilfsspannung. Mit dem einen baust dir da ne ungesunde Brücke von der Wetterstation an die ISE Schnittstelle.

[boomerangman]

Wie sehen denn die ETS Schnittstellen Anzeigen im Szenario 2 genau aus? Ist sie dann über das Symbol Netzwerkkarte verbunden?

Bin nicht sicher, wo genau ich danach suchen soll. In sämtlichen Screens ist der Server mit dem gleichen Symbol verbunden, wie das ISE Interface (Symbol "T-Stück auf dem Kopf", so würde ich es beschreiben).

Aber noch einmal ganz ohne den Server gedacht - der scheint nicht das Problem zu sein, wenngleich die Unklarheit bzgl. des Busmonitors schon unbefriedigend ist. Ich habe den Bus Error auch, wenn ich die Anlage ganz ohne den Server laufen lasse. Hier würde ich gern noch einmal ansetzen...

[Beleuchtfix]

Jein... Wenn der Router an der 1.0 sitzt, kann nur das ins IP-Netz geroutet werden, was auf der 1.0 landet.

aber der IP Router lässt doch alles von IP nach 1.x, auch mit normaler Filterung. Der Homeserver kann doch auch vom Backbone oder der Hauptlinie alle Geräte erreichen.

[mumpf]

Hi Florian,

ich hoffe, wir reden hier über das selbe... Ich meine Gruppentelegramme, also normale Kommunikation, und nicht Programmiertelegramme, also physikalische Adressierung.

Eine GA kann von IP auf die 1.0, wenn der Router sie durchlässt und dann weiter auf die 1.1, wenn der LK die durchlässt.

Der Homeserver kann doch auch vom Backbone oder der Hauptlinie alle Geräte erreichen.

Nur wenn Du passende Dummies vorgesehen hast, damit die Filtertabellen korrekt gefüllt werden.

Gruß, Waldemar

[Beleuchtfix]

Nur wenn Du passende Dummies vorgesehen hast, damit die Filtertabellen korrekt gefüllt werden.

Ja klar, davon bin ich ausgegangen, prohylaktisch, bloss weil ich es gerne sehen würde, lässt weder Router noch LK etwas durch.

[fabian82]

So ganz habe ich das Thema in Verbindung mit einer Visu bzw. HS in meinem Fall noch nicht verstanden.
1. In meinem System gibt es logischerweise KO's die von KNX TP gesendet und KNX TP sowie auch vom HS empfangen werden.
2. Dann gibt es KO's die von KNX TP gesendet und nur vom Homeserver empfangen werden (Für die QC-Visu und/oder Logik)
3. Dann gibt es KO's die von KNX TP gesendet und nur vom Homeserver empfangen werden aber nicht verwendet werden. Ich versuche die Objekte sowohl in der ETS sowie im HS gleichermaßen zu pflegen. Es gibt also jede Gruppen Adresse der ETS auch im HS.

Bei Punkt 1 dürfte es zu keinem Error bzw. Wiederholungen kommen.
Wird bei 2. und 3. auch ein ACK gesendet, so dass es zu keinen Wiederholungen kommt?

Die Lösung mit Flags setzen bzw. entfernen finde ich für mich persönlich nicht so schön, da ich bei einer Änderung normal nicht daran denke dort etwas zu verstellen. Eher würde ich das KO dann beim Sender raus löschen, hätte es dann aber nicht mehr "jederzeit" verfügbar.
Gibt es im HS die Möglichkeit mit eine Häkchen ein ACK auf die betreffenden KO's schicken zu lassen

[mumpf]

Hi,

ich bleibe dabei: Wenn man keine Wiederholungen haben will, einfach den LK auf "Alle Gruppentelegramme bestätigen" stellen. Und schon sind alle Wiederholugen weg .

Gruß, Waldemar

[gbglace]

In meinem System gibt es logischerweise KO's die von KNX TP gesendet

KO sind die Dinger die senden und GA ist das was gesendet wird.

Dann gibt es KO's die von KNX TP gesendet und nur vom Homeserver empfangen werden (Für die QC-Visu und/oder Logik)

klassischer Kandidat für einen Dummy in der IP-Linie

Dann gibt es KO's die von KNX TP gesendet und nur vom Homeserver empfangen werden aber nicht verwendet werden.

Klassischer Kandidat von gehört deaktiviert auf dem Bus, wer braucht denn bitte Telegramme auf dem Bus die nirgends verwendet werden, weder in einer Logik noch in einem Logging noch in einem KNX-Gerät zur Bedienung von Aktionen oder zur Anzeige.

[gbglace]

Eher würde ich das KO dann beim Sender raus löschen

Und nochmal das KO ist der Sender.

Gibt es im HS die Möglichkeit mit eine Häkchen ein ACK auf die betreffenden KO's schicken zu lassen

warum sollte der HS was senden was nicht via einem KO bei ihm ankommt? Der HS ist an der Stelle kein sauberes KNX-Gerät sondern eine Software die einfach den Bus abhorcht und dann für sich selber was aus den Telegrammen macht. Ansonsten hätte der ne Applikation für die ETS, in der man KOs hat, an denen man sauber GA dran verbindet.

[fabian82]

Hi,
einfach den LK auf "Alle Gruppentelegramme bestätigen" stellen.

Ich habe keinen LK drin, somit scheidet die Möglichkeit aus.

[fabian82]

KO sind die Dinger die senden und GA ist das was gesendet wird.

sorry, dann eben GA's

klassischer Kandidat für einen Dummy in der IP-Linie

das wären aber verdammt viele Dummy's und ein Dummy ist meiner Meinung doch nur in der ETS virtuell und würde kein Telegramm bestätigen.

Klassischer Kandidat von gehört deaktiviert auf dem Bus, wer braucht denn bitte Telegramme auf dem Bus die nirgends verwendet werden, weder in einer Logik noch in einem Logging noch in einem KNX-Gerät zur Bedienung von Aktionen oder zur Anzeige.

In der Tat ein berechtigter Einwand, allerdings habe ich so die Daten wenn ich Daten mir in der ETS anschauen möchte (Fehlersuche) oder wenn ich die Daten dann doch in der Visu oder Logik brauche sofort griffbereit.

[gbglace]

Ich habe keinen LK drin, somit scheidet die Möglichkeit aus.

Ist der HS per USB oder per IP-Router angebunden, letzteres ist auch ein LK, weil er neben Medienkoppler TP<>IP eben auch von einer Linie TP zu einer übergeordneten Linie IP koppelt.

das wären aber verdammt viele Dummy's und ein Dummy ist meiner Meinung doch nur in der ETS virtuell und würde kein Telegramm bestätigen.

Wieso viele Dummy, ein Dummy = HS und viele Ga dran verbunden. Und ACK sendet dann der LK weil er sieht das Telegramm ist da jetzt auf der anderen Linie unterwegs und gehört dort hin.

habe ich so die Daten wenn ich Daten mir in der ETS anschauen möchte (Fehlersuche)

Da musst ja auch erst die ETS starten. Ich habe da nen anderen Server der speichert wenigstens alles was an Telegrammen auf der Linie bei ihm vorbei kommt. Den kann ich wirklich aufrufen und nach den Ursachen des Fehlers im Busprotokoll suchen was irgendwann in der Nacht oder die letzten Monate irgendwann mal komisches passiert ist. Wenn Du eh erst die ETS starten musst und den Busmonitor und dann hoffen das das reproduzierbar wird. wozu dafür sinnlosen Traffic produzieren. Keine Ahnung wie viele nur einseitige GA-Verbindungen in Deinem Projekt sind und wie viele KO dann womöglich auf zyklisches und sonstiges Senden gestellt sind. Aber sowas kann halt auch einfach Fehler by Design dann sein.

dann eben GA's

Ich würde das nicht so leichtfertig betrachten. Wir haben hier nicht das Problem mit der Anlage, wir wollen nur helfen es zu lösen und wie sollen wir das gut tun wenn man wegen falscher Worte, Symptome beschrieben bekommt die so gar keinen Sinn ergeben und dann auch gar nicht existieren.

[fabian82]

Ja, stimmt. Der HS ist mit einem IP-Router verbunden. Dieser steht auf alles weiterleiten, da ich jedes Telegramm auch im HS haben möchte. Ich bin jetzt nicht in der Nähe der ETS, müsste mal schauen, ob bzw. wie es eingestellt habe.

[mumpf]

Um nochmal zu motivieren, warum man alle Telegramme bestätigen lassen kann:

Die ACKs bei KNX sind sowieso keine Point-To-Point-ACKs (wäre ja bei einem Broadcasting-System irgendwie sinnlos), sondern "optimistisch": Wenn ein Gerät das Telegramm empfangen hat, und bestätigt hat, geht man davon aus, dass alle es empfangen haben. Deswegen bestätigen alle Geräte exakt zur gleichen Zeit mit einem bestimmten Signal auf dem Bus.
Wenn der LK also das Telegramm empfangen hat und es bestätigt hat, haben alle anderen das Telegramm auch empfangen.
Falls ein (oder mehrere) Gerät(e) beim Emfpang einen Fehler feststellt (z.B. weil die Prüfsumme nicht stimmt), dann sendet es statt dem ACK ein NACK (exakt zu der selben Zeit, zu der es einen ACK geschickt hätte). Da das NACK elektrisch gegenüber einem ACK gewinnt, merkt der Sender, dass zumindest einer nicht korrekt empfangen hat und wiederholt dann. Das sind dann aber Wiederholungen, die man haben will.
Die Wiederholungen aber, die durch eine Nicht-Bestätigung gemacht werden, entfallen bei der Bestätigung durch den LK.

Ich mach das jetzt seit 7 Jahren so und kann mich nicht beklagen.

Gruß, Waldemar

[fabian82]

Vielen Dank für die (für mich) stimmige Erklärung.