massive programmierprobleme mit ETS3

[Thomas Rombach]

in meiner EIB installation sind plötzlich erhebliche schwierigkeiten beim programmieren mit der ETS3 aufgetreten. aus meiner sicht von heute auf morgen und aus heiterem himmel.

so begann es:
ich habe eine änderung an einem ling und janke eibDUO aktor vorgenommen und den button applikations-programm zum programmieren verwendet. es kam der blaue fortschrittsbalken in der ETS, der dann irgendwann stehen blieb mit der Statusmeldung: Das Gerät antwortet nicht.
Über partiell programmieren konnte ich einen zweiten L&J duo aktor problemlos programmieren. dann der versuch über "applikations-programm" ergebnis: auch dieser aktor lässt sich nicht wiederbeleben. das gleiche bei einem aktor eines anderen herstellers.
mittlerweile gehen wichtige sachen in meinem haus nicht mehr. keine klingel, kein garagentor, wichtige leuchten....

hatte bisher mit der ETS 3.0c gearbeitet. dieses problem zum anlass genommen auf die ETS 3.0f umzusteigen. gleiches verhalten. den ganzen mit der EIBA in brüssel kommuniziert. ETS 3.0f zweimal neu installiert. ohne erfolg.

jetzt habe ich den kompletten bus abgehängt und nur den gira homeserver zum programmieren für die iETS und den L&J aktor dran. geht auch nicht.
probleme in der bustopologie, die man der EIBA vermutet hat, lassen sich damit also ausschließen.

alles andere auf dem bus funktioniert tadellos.

so ein heftiges, rätselhaftes problem hatte ich in all den jahren noch nie.

hat jemand eine idee, wie man da weiter vorgeht?

ich bin kurz vorm nervenzusammenbruch ;-)

[Klaus Gütter]

Wenn du in der Fehlermeldung auf Details klickst, kommt eine Liste der letzten Telegramme. Manchmal hilft das bei der Analyse; also bitte hier posten.

Hast du noch einen andere Möglichkeit, auf den Bus zu kommen (USB-Schniitslle, ...); dass versuche das einmal.

Gruß, Klaus

[tbi]

Hallo Thomas,

ich hatte vor kurzem eine ähnlichen Fall mit dem selben Fehlerverhalten. Balken bleibt stehen und Gerät anwortet nicht.

Ich habe ein Linie mit zwei Linienverstärkern. Ich habe dann nach und nach mein system immer kleiner gemacht und festgestellt, dass wenn ich die Linienverstärker ab hatte wieder Geräte programmieren konnte. Ich habe dann bei dem Linienverstärkern (Gira), wieder die Option "Wiederholen bei Hardware Adressierung" deaktiviert. Dann ging es wieder. Dann konnte ich auch wieder hinter dem Linienverstärker und vor der Linienverstärker Geräte programmieren.

Rausgekriegt habe ich das nur, weil ich alles abgeklemmt habe. Und dann nur den IP Router und Spannungsversorgung dran. Dann klappte die Programmierung des IP Routers. Und dann Gerät nach Gerät reinnehmen und neu Programmieren.

Irgendwann weist Du welches schuld ist.

Vielleicht kommst Du so weiter.

Viel Erfolg

Tbi

[Thomas Rombach]

hier kommen erst mal die details aus ETS fehlermeldung:

----------------------------------
EDI: EIBlib/IP EDI
Params: Server=192.168.10.80;Protocol=TCP;ConfigPort=50000 ;ReadPort=50001;WritePort=50002;COM=1
Last messages (EMI2):
19:37:41.578 R 0E L_DATA.ind (NDT-1/PropertyValue_Response) B0 1121 113C 66 47 D6 00 0E 10 01 00
19:37:41.578 S 08 L_DATA.req (ACK-1) 90 0000 1121 60 C6
19:37:41.703 R 08 L_DATA.con (ACK-1) B0 113C 1121 60 C6
19:37:41.765 S 17 L_DATA.req (NDT-2/Memory_Write) 90 0000 1121 6F 4A 8C 02 00 00 10 00 00 00 00 00 00 00 00 00 00
19:37:41.859 R 17 L_DATA.con (NDT-2/Memory_Write) B0 113C 1121 6F 4A 8C 02 00 00 10 00 00 00 00 00 00 00 00 00 00
19:37:41.875 R 08 L_DATA.ind (ACK-2) B0 1121 113C 60 CA
19:37:41.875 S 0B L_DATA.req (NDT-3/Memory_Read) 90 0000 1121 63 4E 0C 02 00
19:37:41.953 R 08 L_DATA.ind (ACK-3) B0 1121 113C 60 CE
19:37:41.984 R 0B L_DATA.con (NDT-3/Memory_Read) B1 113C 1121 63 4E 0C 02 00
19:37:42.062 R 17 L_DATA.ind (NDT-2/Memory_Response) B0 1121 113C 6F 4A 4C 02 00 00 10 00 00 00 00 00 00 00 00 00 00
19:37:42.062 S 08 L_DATA.req (ACK-2) 90 0000 1121 60 CA
19:37:42.234 R 08 L_DATA.con (ACK-2) 90 113C 1121 60 CA
19:37:42.250 S 17 L_DATA.req (NDT-4/Memory_Write) 90 0000 1121 6F 52 8C 02 0C 18 18 18 18 18 18 0A 05 05 05 05 05
19:37:42.343 R 17 L_DATA.con (NDT-4/Memory_Write) B0 113C 1121 6F 52 8C 02 0C 18 18 18 18 18 18 0A 05 05 05 05 05
19:37:42.375 R 08 L_DATA.ind (ACK-4) B0 1121 113C 60 D2
19:37:42.375 S 0B L_DATA.req (NDT-5/Memory_Read) 90 0000 1121 63 56 0C 02 0C
19:37:42.500 R 0B L_DATA.con (NDT-5/Memory_Read) B0 113C 1121 63 56 0C 02 0C
19:37:42.531 R 08 L_DATA.ind (ACK-5) B0 1121 113C 60 D6
19:37:42.578 R 17 L_DATA.ind (NDT-3/Memory_Response) B0 1121 113C 6F 4E 4C 02 0C 18 18 18 18 18 18 0A 05 05 05 05 05
19:37:42.578 S 08 L_DATA.req (ACK-3) 90 0000 1121 60 CE
19:37:42.703 R 08 L_DATA.con (ACK-3) B0 113C 1121 60 CE
19:37:42.703 S 17 L_DATA.req (NDT-6/Memory_Write) 90 0000 1121 6F 5A 8C 02 18 05 05 05 05 05 05 00 00 4F AE 05 EA
19:37:42.796 R 08 L_DATA.ind (ACK-6) B0 1121 113C 60 DA
19:37:42.843 R 17 L_DATA.con (NDT-6/Memory_Write) B1 113C 1121 6F 5A 8C 02 18 05 05 05 05 05 05 00 00 4F AE 05 EA
19:37:42.843 S 0B L_DATA.req (NDT-7/Memory_Read) 90 0000 1121 63 5E 0C 02 18
19:37:42.921 R 08 L_DATA.ind (ACK-7) B0 1121 113C 60 DE
19:37:43.000 R 17 L_DATA.ind (NDT-4/Memory_Response) B0 1121 113C 6F 52 4C 02 18 05 05 05 05 05 05 00 00 4F AE 05 EA
19:37:43.031 R 0B L_DATA.con (NDT-7/Memory_Read) 91 113C 1121 63 5E 0C 02 18
19:37:43.031 S 08 L_DATA.req (ACK-4) 90 0000 1121 60 D2
19:37:43.031 R 09 L_DATA.ind (UDT/GroupValue_Write) BC 113C 0963 E1 00 80
19:37:43.109 R 08 L_DATA.ind (NAK-7) B0 1121 113C 60 DF
19:37:43.312 R 08 L_DATA.con (ACK-4) 90 113C 1121 60 D2
19:37:43.312 S 17 L_DATA.req (NDT-8/Memory_Write) 90 0000 1121 6F 62 8C 02 24 D9 48 5A 2A FA AE FD CD 50 3F 4F AE
19:37:43.406 R 08 L_DATA.ind (ACK-8) B0 1121 113C 60 E2
19:37:43.453 R 17 L_DATA.con (NDT-8/Memory_Write) B1 113C 1121 6F 62 8C 02 24 D9 48 5A 2A FA AE FD CD 50 3F 4F AE
19:37:43.453 S 17 L_DATA.req (NDT-8/Memory_Write) 90 0000 1121 6F 62 8C 02 24 D9 48 5A 2A FA AE FD CD 50 3F 4F AE
19:37:43.546 R 08 L_DATA.ind (NAK-8) B0 1121 113C 60 E3
19:37:43.625 R 08 L_DATA.ind (NAK-8) B0 1121 113C 60 E3
19:37:43.656 R 17 L_DATA.con (NDT-8/Memory_Write) 91 113C 1121 6F 62 8C 02 24 D9 48 5A 2A FA AE FD CD 50 3F 4F AE
19:37:43.671 S 17 L_DATA.req (NDT-8/Memory_Write) 90 0000 1121 6F 62 8C 02 24 D9 48 5A 2A FA AE FD CD 50 3F 4F AE
19:37:43.750 R 17 L_DATA.con (NDT-8/Memory_Write) B0 113C 1121 6F 62 8C 02 24 D9 48 5A 2A FA AE FD CD 50 3F 4F AE
19:37:43.750 S 17 L_DATA.req (NDT-8/Memory_Write) 90 0000 1121 6F 62 8C 02 24 D9 48 5A 2A FA AE FD CD 50 3F 4F AE
19:37:43.765 R 08 L_DATA.ind (NAK-8) B0 1121 113C 60 E3
19:37:43.859 R 08 L_DATA.ind (NAK-8) B0 1121 113C 60 E3
19:37:43.890 R 17 L_DATA.con (NDT-8/Memory_Write) B1 113C 1121 6F 62 8C 02 24 D9 48 5A 2A FA AE FD CD 50 3F 4F AE
19:37:43.890 S 17 L_DATA.req (NDT-8/Memory_Write) 90 0000 1121 6F 62 8C 02 24 D9 48 5A 2A FA AE FD CD 50 3F 4F AE
19:37:43.984 R 08 L_DATA.ind (NAK-8) B0 1121 113C 60 E3
19:37:44.046 R 08 L_DATA.ind (NAK-8) B0 1121 113C 60 E3
19:37:44.078 R 17 L_DATA.con (NDT-8/Memory_Write) 91 113C 1121 6F 62 8C 02 24 D9 48 5A 2A FA AE FD CD 50 3F 4F AE
19:37:44.093 S 08 L_DATA.req (CLR) 90 0000 1121 60 81
---------------------

derzeit kann ich nur über den homeserver iETS programmieren. vorher ging auch mal RS232. aber nachdem ich die ETS auf anraten der EIBA zweimal neu installiert habe, ist irgendwas mit den treibern passiert. RS232 geht also im moment nicht.

@tbi:
ich habe einen linienverstärker in der anlage.
ich hatte die anlage schon soweit reduziert, dass ich nur den homeserver und den bockigen L&J aktor am bus hatte. auch das ging nicht.
es ist zum haare raufen.

[EIB-Freak]

Welche Phys. Adressen sind im Projekt
-bei den Geräten (Bereich.Linie)
-Im Homeserver (Bereich.Linie.Teilnehmer)
-in der ETS (bereich.linie.Teilnehmer)
-und im ip-Router (Bereich.Linie.0) eingestellt ?

[Thomas Rombach]

so jetzt habe ich ein zweites mal den linienverstärker abgehängt. sowie tbi das auch gemacht.
und plötzlich geht die programmierung.
dann wieder den LV angehängt und genau wie tbi das auch gemacht hat die "Wiederholung bei Übertragungsfehlern" rausgenommen.
dann die nicht mehr funktionsfähigen aktoren jenseits des LV wieder erfolgreich programmieren können. uff.

warum es beim ersten mal nicht geklappt hat....ist mir ein rätsel.
vielen herzlichen dank für die unterstützung.

schaukelt sich da im LV im laufe des betriebs irgendetwas auf? hat jemand eine erklärung für das verhalten?

[tbi]

@Thomas: Ich hatte damals auch beobachtet, wenn ich eine Gruppen Adresse mit der ETS auf den Bus "Schreibe", das diese dann doppelt zu sehen war. Hast Du das mal versucht ?

Im Busmonitor in der ETS kannst Du ja eine GA auswählen und direkt auf den BUS "schreiben" oder "lesen". Ich hatte es bei "Schreiben" gesehen.

Gruß Tbi

[tbi]

so jetzt habe ich ein zweites mal den linienverstärker abgehängt. sowie tbi das auch gemacht.
und plötzlich geht die programmierung.
dann wieder den LV angehängt und genau wie tbi das auch gemacht hat die "Wiederholung bei Übertragungsfehlern" rausgenommen.


Ich habe nun die standard Einstellung im LV.



vielen herzlichen dank für die unterstützung.

Gern geschehen :Prost:


schaukelt sich da im LV im laufe des betriebs irgendetwas auf? hat jemand eine erklärung für das verhalten?

Ich vermute, dass hat was mit den doppelten GA auf dem Bus zu tun hat. Danach war das Phänomen auch weg.

Gruß Tbi

[EIB-Freak]

Meine Vermutung aus erfahrung: Falsche Phys. Adresse der Schnittstelle - dadurch kommt der Routing-Zähler durcheinander.

[Klaus Gütter]

19:37:42.843 S 0B L_DATA.req (NDT-7/Memory_Read) 90 0000 1121 63 5E 0C 02 18
19:37:42.921 R 08 L_DATA.ind (ACK-7) B0 1121 113C 60 DE
19:37:43.000 R 17 L_DATA.ind (NDT-4/Memory_Response) B0 1121 113C 6F 52 4C 02 18 05 05 05 05 05 05 00 00 4F AE 05 EA
19:37:43.031 R 0B L_DATA.con (NDT-7/Memory_Read) 91 113C 1121 63 5E 0C 02 18
19:37:43.031 S 08 L_DATA.req (ACK-4) 90 0000 1121 60 D2
19:37:43.031 R 09 L_DATA.ind (UDT/GroupValue_Write) BC 113C 0963 E1 00 80
19:37:43.109 R 08 L_DATA.ind (NAK-7) B0 1121 113C 60 DF

Das ist ziemlich schräg: Das MemoryRead mit TL-Sequenznummer 7 wird vom Gerät erst positiv bestätigt (ACK-7) und später nochmal negativ (NAK-7); das deutet darauf hin, dass das gleiche Telegramm vom HS zweimal auf den Bus gesendet wurde. Mitten in dieser Sequenz ist noch ein GroupValueWrite zu sehen, mit der Quelladresse = 1.1.60 (Adresse des HS) und Zieladresse 1/1/99, allerdings als L_DATA.ind (also so als ob das vom Bus empfangen worden wäre).
Entweder gibt es diese Adresse nochmal auf dem Bus, oder die iETS-Funktion des HS kommt durcheinander, wenn der HS selbst ein Telegram sendet.

Gruß, Klaus

[EIB-Freak]

Dieses Problem hatte ich auch schon, wenn der HS an einer Fritz!Box hängt.

[tbi]

@Michael: Das ist nun ein anderes Problem mit der Fitzbox. Vermute ich jedenfalls. Ich nehme an Du hattest Dich über WLAN an der Fritzbox mit der ETS angeschlossen und da die Fritzbox ja nicht viele Ports hat, dahinter einen Switch dran an dem der EIB IP Router dran war.

Dann passiert folgendes: Da beide, der Switch, wie die Fritzbox kein MULTICAST können. Zumindest einer nicht. Werden die Packete nicht weiter geroutet. Bei IP-Protokoll gibt es auch ROUTING-COUNTER und wenn das Gerät kein IGMP (MULTICAST) kann, werden die Packete nicht weitergeroutet. Sonst würde das NETZ ersaufen:rolleyes:.

Was kann man dann machen:
1.) Direkt mit einem IP Kabel die ETS an den selben Switch anschliessen, an dem auch der EIB IP Router angeschlossen ist.
2.) Im IP Router auf IP Tunneling umstellen und in der ETS die Schnittstelle mit Tunneling (IP UNICAST, also punkt zu punkt) verwenden.

Dann sollte die Programmierung der EIB Geräte wieder gehen.

Dieses Problem mit dem MUTICAST, sowie das Problem mit dem Linienverstärker müssen in die FAQ aufgenommen werden. Michael, kannst Du dich darum kümmern ?

Viele Grüsse

Tbi

[EIB-Freak]

Nöö, ich hatte mich immer per Kabel an den Switch gehängt - an den gleichen, wo alle anderen Geräte auch hingen.

Die Idee mit dem FAQ-eintrag begrüße ich, kann jedoch auch von dir erfolgen, wir kontrollieren das dann nur noch und dann passt es.

[tbi]

Hallo Michael,

.. und dieser Switch war die Fritzbox von der Du sprachst?

Dies in nun so, mein Switch DES 1526 von D-Link regiert beim Empfang von Multicast paketen so, dass er diese an alle "flutet" (bei D-Link Hotline nachgefragt), somit geht es gerade eben über diesen Switch. Um eine Route über mehrere hin zukriegen müssen eben alle IGMP (Multicast) unterstützen.

Es kann nun sein, das die Fritzbox dieses "fluten" an die anderen Ports aus Sicherheitsgründen erst gar nicht macht. Dann versacken die Packete sofort.

Das mit dem FAQ werde ich dann machen. Danke.

Gruß Tbi

[EIB-Freak]

Nein, das war ein separater Switch, dahinter hing eine ältere Fritzbox mit einem LAN-Port an der DSL-Welt.

Hatte die Probleme auch schon mit den Geräte des Magenta riesen.

War dann aber mit aktuellen Release-Ständen der IP-Router verschwunden.