Brauche Hilfe...extreme Buslast

[Haui1982]

Hallo liebe Community,

ich habe einen Kunden (Bank) in der unser Unternehmen vor knapp 12 Jahren eine Siemens EIB Anlage verbaut hat. Zusätzlich wurde diese Anlage mit einem GLT Rechner ausgestattet welcher über Digitalcontroler (mit Übersetzungsliste) und Gateways in den Bus kommuniziert und damit die Heizungssteuerung kontrolliert. Die Heizungssteuerung wird zum einen über Thermostate in den Räumen direkt geregelt zum anderen gibt es die Möglichkeit der Fernregelung über den GLT Rechner.

Seit ein paar Monaten reagiert der Bus extrem langsam. Schaltbefehle von Anwendungsmodulen werden erst nach längerer Zeit (1-2 Minuten) ausgeführt. Der GLT Rechner kann lediglich die Technik im DG steuern die anderen Geschosse lassen sich über ihn nicht mehr ansprechen bzw. reagieren nicht.

Ich habe dann mal eine Logdatei anfertigen lassen. Der Bus generiert pro 30 sec. ca. 500-600 Protokolle müllt also quasi zu.

Nun muss ich dazu sagen das mein Schwiegervater es seinerzeit programmiert hat und das nach einem 1 tägigen EIB Grundkurs. Dementsprechend sieht natürlich die Programmierung bzw. Topologie aus.

Außer das ich befürchte das einiger der Linienkoppler im Bus defekt sind habe ich keinerlei Ansatz wie ich diesen Fehler angehen soll.

Ich hoffe jemand von euch kann mir helfen. Bei einer Möglichen "Neuprogrammierung" der Anlage müsste es jemand sein der so Fit ist das wir die Programmierung an einem Wochenende durch bekommen, da man mich sonst erschlägt wenn der Laden ne Woche nicht aufmachen kann weil kein Licht brennt und die Bude dunkel ist.

Ich hoffe man kann mir helfen und antwortet mir. Für ein Telefonat bin ich offen. Anfragen bezüglich Kontakt bitte per PN an mich.


Vielen Dank im Voraus...

Gruß

Hauke

[ets3-user]

Wenn du schon weist das der Bus zugemüllt wird , schau doch einfach mal welches Gerät die Fehler produziert und klemm es ab/tausch es aus und dann schau weiter

[Haui1982]

Problem

Das Problem ist das ich genau das nicht weiß. Ich habe mehrere Geräte die den Bus vermüllen kann jedoch nicht aus dem Protokoll ersehen welche es sind bzw. welche Adressen dahinter stecken.

Wahrscheinlich fehlt mir für eine solche Fehleranalyse die Erfahrung...


Gruß

Hauke

[MatthiasS]

Dann poste doch mal einen Screenshot vom Busmonitor der ETS.

[Haui1982]

hier mal ein direkter Auszug aus den Logs:

BC 13 FA 40 15 C1 00 00 3E ,20.09.2010 - 08:43:36 (0) +045748 µs
9C 13 FA 40 15 C1 00 00 1E ,20.09.2010 - 08:43:36 (1) +019976 µs
9C 13 FA 40 15 C1 00 00 1E ,20.09.2010 - 08:43:36 (2) +018648 µs
9C 13 FA 40 15 C1 00 00 1E ,20.09.2010 - 08:43:36 (3) +020342 µs
BC 13 02 40 15 C2 00 40 0D 88 ,20.09.2010 - 08:43:36 (4) +020752 µs
9C 13 02 40 15 C2 00 40 0D A8 ,20.09.2010 - 08:43:36 (5) +000000 µs
9C 13 02 40 15 C2 00 40 0D A8 ,20.09.2010 - 08:43:36 (6) +037220 µs
9C 13 02 40 15 C2 00 40 0D A8 ,20.09.2010 - 08:43:36 (7) +021304 µs
BC 13 FA 40 1F C1 00 00 34 ,20.09.2010 - 08:43:36 (0) +023478 µs
9C 13 FA 40 1F C1 00 00 14 ,20.09.2010 - 08:43:36 (1) +021726 µs
9C 13 FA 40 1F C1 00 00 14 ,20.09.2010 - 08:43:36 (2) +019944 µs
9C 13 FA 40 1F C1 00 00 14 ,20.09.2010 - 08:43:36 (3) +000000 µs
BC 13 FA 40 29 C1 00 00 02 ,20.09.2010 - 08:43:37 (4) +098534 µs
9C 13 FA 40 29 C1 00 00 22 ,20.09.2010 - 08:43:37 (5) +019964 µs
9C 13 FA 40 29 C1 00 00 22 ,20.09.2010 - 08:43:37 (6) +000000 µs
9C 13 FA 40 29 C1 00 00 22 ,20.09.2010 - 08:43:37 (7) +024778 µs
BC 13 04 40 29 C2 00 40 00 BF ,20.09.2010 - 08:43:37 (0) +021020 µs
9C 13 04 40 29 C2 00 40 00 9F ,20.09.2010 - 08:43:37 (1) +021314 µs
9C 13 04 40 29 C2 00 40 00 9F ,20.09.2010 - 08:43:37 (2) +022968 µs
9C 13 04 40 29 C2 00 40 00 9F ,20.09.2010 - 08:43:37 (3) +021432 µs

[timov]

Hi Hauke!

Ich versuch mich mal:

Im Protokoll sind 5 Sendeversuche zu sehen, jede weist vier Zeilen auf: Zeile 1 ist jeweils der erste Versuch (Byte 0: 0xBC), danach kommen drei Wiederholungen (Byte 0: 0x9C). Allen Zeilen fehlen die positiven Quittungen, weshalb die Wiederholungen erfolgen.

1. Block:
Sender: 13 FA, also: Bereich 0x1, Linie 0x3, Gerät 0xFA (250) -- 1.3.250
Gruppenadresse: 40 15, also: Hauptgruppe 0x4, Untergruppe 0x015 (21) -- 4/21
Routingzähler: 0xC?, also: 4 (nur die untersten 3 Bits betrachten) -- das Telegramm wurde 2x geroutet
Längenfeld 0x?1, also: 2 Bytes (immer +1)
Daten: 0x00, 0x00

2. Block: ...

Vielleicht hilft dir das zum Start etwas weiter.

Gruß,
Timo

P. S.: first post Hätte nicht gedacht, dass das eine Antwort und keine eigene Frage werden würde...

[Michel]

Wenn du das Projekt in der ETS geöffnet hast und dann den Gruppenmonitor anwirfst, gibt es auch die Gruppen- und physikalischen Adressen in "lesbar"

So wie du das beschreibst, tippe ich mal auf eine unterbrochene Busleitung, defekte Linienkoppler oder eine defekte Spannungsversorgung.

[Klaus Gütter]

Hallo Hauke,

Außer das ich befürchte das einiger der Linienkoppler im Bus defekt sind

Das könnte es sein. Wie Timo schön gezeigt hat, sind die Telegramme schon durch zwei LK durchgegangen. Sie haben aber offenbar in der Linie, wo aufgezeichnet wird, nichts verloren (lkeine Bestätigung, daher 3*Wiederholung).

Die alten Kinienkoppler hatten für die Filtertabelle (statisches RAM) eine Lithium-Batterie. Die kann nach 12 Jahren hinüber sein, die Linienkoppler lassen dann einfach alles durch.

Gruß, Klaus

[swiss]

Hallo Hauke

Wenn ich das Telegramm richtig lese, Steht da, dass das erste Telegramm vom Teilnehmer 9.15.212 ausgeht, und dabei 4 Linienkoppler passiert. Schau mal ob das hinkommt. in der ETS müsste der Teilnehmer 9.15.212 vorhanden sein.

Kann es sein, dass du irgend wo einen Ring gebildet oder sogar 2 Linien direkt kurzgeschlossen hast?

[Gaston]

Angesichst der Logdatei, der "12-Jahre" und "Linienkoppler" leuten bei mir die Alarmglocken.

Ich gehe mal davon aus dass die Liniekoppler noch "alte" breite LKs sind (6TE glaube Ich).

In vilen dieser geräten (alle?) sind die Filtertabellen über Baterrie gepuffert. Fällt diese aus schaltet der LK je nach parametrierung auf "Linienverstärker-Modus" umd, lässt also alles durch. Dies führt dann in grossen Anlagen zu genau diesen problemen.

Diagnose: ETS Busmonitor laufen lassen und prüfen ob die GAs die durch die LKs kommen (Routingzähler<6, bzw. andere Linie als Quelladresse) auch "Zuhörer" auf dem Bus haben.

Ich biun mir leider nicht ganz sicher wie sich das mit der Filtertabelle beim Laden (Reset) verhält ohne dass die Spannungaufällt. Man könnte versuchen die LKs mit der Filtertabelle neuzuladen. Wenn es dann besser ist, LK für ein paar Minuten abtrennen und wieder anhängen. Ist das Problem wieder da dürfte es an der Batterie liegen (sprich neuer LK).

Gruss,
Gaston

[Gaston]

Wenn ich das Telegramm richtig lese, Steht da, dass das erste Telegramm vom Teilnehmer 9.15.212 ausgeht, und dabei 4 Linienkoppler passiert. Schau mal ob das hinkommt. in der ETS müsste der Teilnehmer 9.15.212 vorhanden sein.

Quelladresse beginnt bei Byte 1 (Byte0=Kontrolbyte), als 13 FA = 1.3.250

Gruss,
Gaston

[swiss]

Hää?

aber 13 FA wäre in Binär 1 0011 1111 1010 das würde bei mir 9.15.212 geben oder nicht?

oO habs gerade gesehen. Ich habe die führende 1 als adressanfang genommen. Jetzt bekomme ich 3.15.10

[timov]

Das erste Telegramm BC 13 FA 40 15 C1 00 00 3E ist binär:

1011 0xB
1100 0xC

0001 0x1
0011 0x3

1111 0xF
1010 0xA

...

Gruß,
Timo

[swiss]

Ach sooo. Danke Timo

Ich habe immer 13 umgewandelt danach FA usw...

aber wenn ich jede Stelle einzeln nehme, kommt es wohl besser

[StefanW]

Dürfte ich den geschätzten Treadersteller bitten, eine griffigeren Betreff für diesen Tread anzugeben, weil Hilfe brauchen fast alle und wenn jeder Tread so heißen würde findet man nichts mehr. Ist nämlich ein sehr interessanter Tread und es wäre schade, wenn andere sich den dann nicht ansehen...

LG

Stefan