mehrere Geräte im Programmiermodus?

[S. De Bruyne]

What would be interesting to know now is:
1. Which RS232 has been used (manufacturer, order number, application program).
2. Is the problem "back again" when a similar, but unloaded RS232 is used (i.e. is the solution deterministic, or could something else have caused the problem to disappear).
3. What was the "history" of this RS232?
Before it was loaded, did somebody load it with another application before? Or was is, since delivery from factory, maybe already "unloaded"?

As this problem appears more, I would highly appreciate your help if you could giev as much information as possible ... In the benifit of all.

Thanks !

[Dirk Beyer]

Hi,

ich hatte vor ca. 2 Wochen (mal wieder) dieses Problem. Allerdings in einem Gebäude, in dem das vorher noch nie aufgetreten war.

Außerdem hat mein Dongle zum Fkt-Modul verrückt gespielt. (Er wurde nicht erkannt). Zuhause hat der Dongle am gleichen Notebook übrigens wieder funktioniert.

Am nächsten Tag war ich wieder im Gebäude und alles hat funktioniert!

Nun habe ich längere Zeit darüber nachgedacht und festgestellt, daß die einzige Veränderung gegenüber "früher" war, daß das Dach seit einiger Zeit mit D-Netz-Antennen gespickt ist!

Ich habe natürlich keine Beweise oder Messungen etc., aber vielleicht ist das ja ein Ansatz den Ihr auch mal bei Euren Problemgebäuden beobachten solltet.

Gruß


Dirk

[S. De Bruyne]

Dear Mr. Beyer,

könnten Sie genauere Information zu diesem Dongle geben? Ggf. per e-mail an support@eiba.com.

Mfg.

[EIB-Doktor]

Servus, Mike,

also, was beim Download einer x-beliebigen Appliaktion so abläuft, solltest du eigentlich wissen : Die ETS macht nach dem Abschluss einen Reset.

Das Gleiche hättest du haben können, wenn du die RS232 mal komplett abgezogen hättest, sowohl vom PC als auch vom Bus.

Ich erlebe diese Fälle immer häufiger, wenn meine "Kunden" verzweifelt anrufen, das sie nicht mehr programmieren können. Das betrifft dann nicht mehr nur die phys. Adr., sondern alle Zugriffe. Einmal die Linie kurz abgeschaltet (=Hardware Reset); zusätzlich noch RS232 vom PC weg, und schon geht es wieder.

Und noch was: Ich weiß nicht, ob ich da hier schon darauf hingewiesen habe, aber egal: Mehrere RS232 auf derselben Linie können sich ganz schön "grätig" verhalten . Und zwar dann, wenn sie zwar am Bus hängen, und am PC, der PC aber gerade nicht mit einer EIB-Anwendung darauf zugreift. Eine RS232 hat nur einen Eingangstelegrammpuffer. Meist ist sie in der Einstellung "alles durchlassen". In so einem Fall wird der Puffer beschrieben, aber nicht mehr geräumt. Es kommt zu "Busies" (nicht Bussys !). Auch das habe ich schon erlebt. Die Betroffenen wussten das teilweise gar nicht. Kann z.B. passieren, wenn 'ne abgestürzte Visu auf der Linie "hängt".

Also , du / ihr seht, es gibt viele Fehlermöglichkeiten, man kann sie aber immer (und ich wiederhole das ! Immer !) erklären und die Ursachen finden und beseitigen.

Im Zweifelsfall, welche Maßnahme Erfolg hat, sollte man grundsätzlich mit einem 2. PC Telegramme aufzeichnen, und die ETS im Logging=Enabled Mode (Stufe 4) betreiben. Mit den LOG-Daten kommt man echt weiter !

So, und nun genug "doziert" für heute. Geh'n wir wieder an die Arbeit.

Grüße

[Meudenbach]

Huhu Doktor.....

.... und danke noch mal für die prompte Lieferung.

zu Thema:

Also Herr Doktor....

Wenn das Problem mit einem banalem Reset gelöst worden wäre, dann hätte ich es bestimmt nicht ins Forum gesetzt.

".... unter Verwendung verschiedener Schnittstellen" bedeutet, dass wir dieses Phänomen an Geräten verschiedener Hersteller (Standard RS232 REG von ABB und die neue RS232 von MERTEN) und bei den Versuchen, wurde die RS232 immer wieder vom Bus genommen.

LG

Mike

[Dieter Koch]

Gestern, im schön klimatisierten Keller, sitzt der Koch vor einer EIB-Anlage und muß ca. 400 physikalische Adressen ändern.
Vorgehensweise: Standad RS232 (SIEMENS REG), 4 Jahre alt, an die entsprechende Linie gehängt.
Den Linienkoppler durch drücken der Prg-Taste umaddressiert, die restlichen Geräte mit dem Befehl "Phys. Adresse überschreiben". Alles klappte zuerst super, dann aber der Mist. Plötzlich meldete die ETS mehrere Geräte im Programmiermodus. Es war beim Auslesen mit der ETS 5x die gleiche Adresse.
Auch mit viel Geduld trat dieser Fehler bis zu dem Zeitpunkt auf, bis ich ich die komplette Linie zurückgesetzt habe. Dies ist in meinen Augen der Super-GAU. Auch den Linienkoppler hatte ich ausgebaut. Dann hat wieder alles wunderbar funktioniert.

Hat die EIBA schon etwas wegen diesem Phänomen veranlaßt/Fehler gesucht??

Dann noch ein Vorschlag für zukünftige ETS-Versionen/EIB-Doktor:
Es sollte einen Befehl geben "Alle PrgLED's aus". Begündung:

Es gibt ja mal von Zeit zu Zeit ein fehlerhaftes Gerät, das seine PrgLED selbstätig einschaltet. Dieses passiert z.B bei der Adresse 2.4.5.
Wenn ich nun die Adresse 1.3.8 programmieren will, versetze ich die ETS in Prg-Modus und begeb mich zu dem Gerät 1.3.8. Die ETS fragt ja nun nach, bei welchem Gerät die Prg-Taste gedrückt ist und schickt die gewünschte Adresse dorthin. Da aber die Adresse 1.3.8 nicht zu der Linie des Fehler-Gerätes 2.4.5 passt, gibt die ETS die Meldung raus "Schalten Sie die PrgLed mit der Hand aus" Dies ist ein echt gelungender Witz, denn wo in dem Gebäude mit hunderten Teilnehmern sitzt dieses Gerät, das jetzt die Adresse 1.3.8 hat.
So lange man dieses Gerät nicht lokalisiert hat. frißt es jede phys. Adresse oder man hat immer tatsächlich mehrere Gerät im PrgModus. Deshalb der o.a. Befehl.

Weitere Frage: Warum kann man nicht linienübergreifend eine phys. Adresse mit einer anderen überschreiben, die Linienkoppler haben schon ihre richtigen Adressen, so das der Weg zu dem Gerät eindeutig ist?


Gruß
Dieter Koch

[gamma]

Hallo Dieter,
das mit dem alle Prg Leds aus ist eine gute
Idee.
Die geb ich sofort an die EIBdoktor Entwickler weiter.

Gruss, Gamma

[Meudenbach]

Original geschrieben von Dieter Koch
Wenn ich nun die Adresse 1.3.8 programmieren will, versetze ich die ETS in Prg-Modus und begeb mich zu dem Gerät 1.3.8.

... also Dieter, dass sollte einem aber nur einmal im Leben passieren..... (hab ich auch hinter mir)

immer erst zu Gerät begeben... Knöpfsche drügge ... und dann Programmieren !!!

Besser noch: vor dem Programmieren, den Bus abscannen.

... dann klappt´s auch mit dem Nachbarn.

Original geschrieben von Dieter Koch

Weitere Frage: Warum kann man nicht linienübergreifend eine phys. Adresse mit einer anderen überschreiben, die Linienkoppler haben schon ihre richtigen Adressen, so das der Weg zu dem Gerät eindeutig ist?

... geht doch, oder verstehe ich da was falsch ????

@Gamma

wenn´st das schaffst, dann bring ich Dir persönlich nen EIB Oskar....

evtl. würde es ja helfen, wenn man den TLN zurück auf 15.15.255 adressieren könnte... aber dann weiss man ja immer noch nicht, wo sich der Teilnehmer befindet. Ein polling Tool, welches den gesamten Adressbereich abfragt, wäre denkbar dauert aber zu lange.... man könnte zwar die Linie ermitteln in dem sich der Teilnehmer befindet, aber ich denke klassische Suchmethoden sind da effektiver.

LG

[MarkusS]

Die Sache mit dem Programmierknopf halte ich für einen Anachronismus.

Das mag ja noch angehen im EFH mit einer Handvoll EIB-Komponenten - aber im Gewerbebau ist das doch ein schlechter Witz.

Es ist IMHO Zeit dass sich die EIBA da was einfallen lässt. Z.B. etwas in der Art von DHCP im IP-Netz. Da kann ich per (auf Netzwerkkartenebene eindeutiger MAC-Adresse) IP-Adressen zuweisen die sich die jeweilige Netzwerkkarte beim booten am Server abholt.

Vielleicht auf Ebene der Linienkoppler, dann könnte man den Traffic für die Adressvergabe auch auf die jeweilige Linie begrenzen. Erfordert kaum Rechenleistung und Speicher.

Allerdings müsste jeder Busankoppler eine eindeutige, unveränderbare Hardwarekennung haben die man über den Bus auslesen kann - und diese Kennum sollte am besten auf die jeweilige Komponente aufgedruckt sein damit man sie leicht ablesen und in die ETS übertragen kann.

Gruss
Markus

[Dieter Koch]

Mach ich doch:

[QUOTE]Original geschrieben von Meudenbach
[B]... also Dieter, dass sollte einem aber nur einmal im Leben passieren..... (hab ich auch hinter mir)

immer erst zu Gerät begeben... Knöpfsche drügge ... und dann Programmieren !!!

Besser noch: vor dem Programmieren, den Bus abscannen.


Vor dem ersten Programmieren einer Linie schalte ich zuerst die EIB-Stromversorgung aus, weil die Elektriker den Bus ja am besten kontrollieren können, wenn sie die Programmier-LED drücken und dann sehen, ob der Bus anliegt oder nicht.

Wenn ich dann aber eine ganze Reihe von Räumen hintereinander programmieren will, stelle ich das beim Rechner einmal ein und gehe dann von Raum zu Raum (Alternative WLan wie von Peter Pan in anderem Thread beschrieben).
Wenn Du dann ein Gerät hast, das sich regelmässig nach 1 Minute die PrgLED einschaltet, ist die Kacke am dampfen.

Man kann natürlich den Linienkoppler abrasten, oder sich auch einen Knopf an die Backe nähen, aber das ist ja nicht Sinn der Sache. Es muss ja nur so funktionieren, wie es entwickelt worden ist.


Es ist IMHO Zeit dass sich die EIBA da was einfallen lässt. Z.B. etwas in der Art von DHCP im IP-Netz. Da kann ich per (auf Netzwerkkartenebene eindeutiger MAC-Adresse) IP-Adressen zuweisen die sich die jeweilige Netzwerkkarte beim booten am Server abholt.

Vielleicht auf Ebene der Linienkoppler, dann könnte man den Traffic für die Adressvergabe auch auf die jeweilige Linie begrenzen. Erfordert kaum Rechenleistung und Speicher.


@Markus


Allerdings müsste jeder Busankoppler eine eindeutige, unveränderbare Hardwarekennung haben die man über den Bus auslesen kann - und diese Kennum sollte am besten auf die jeweilige Komponente aufgedruckt sein damit man sie leicht ablesen und in die ETS übertragen kann.


Das ist dann wie beim LON und sehr viel aufwendiger. Bitte so nicht.

Überschreiben einer physikalischen Adresse:
Ich hänge mit ETS in der Linie 2.4. RS232 hat die 2.4.200. In der Linie 1.3 möchte ich ein Gerät mit der Adresse 1.3.8 überschreiben, das vorher die Adresse 4.3.6 hatte.
Linienkoppler, Verdrahtung ist ok.
ETS meldet dann "Prüfen Sie, ob ein Gerät mit dieser Adresse existiert" oder so ähnlich. Wahrscheinlich läuft die Abfrage in die Linie 4.3., und hier ist das Gerät ja nicht mehr, da es jetzt woanders eingebaut ist.

Das Überschreiben funktioniert bei mir nur innerhalb einer Linie unproblematisch.

Gruß
Dieter

[582roman]

Hallo Herr Leidenroth,
wenn Sie das Problem wieder haben
lassen Sie doch bitte mal von der
ETS die Geräte mit "gedrückter Programmiertaste"
suchen.
Vielleicht hilft diese Information dann weiter.

Grüsse von Gamma!

Hallo!

Habe gerade Ihren Beitrag gelesesn
Das mit der Gedrückter Programmiertaste kenne ich bereits von der ETS 2 - in der ETS 3 bin ich noch nicht fündig geworden
Haben sie vieleicht eine Antwort

[Dieter Koch]

Das mit der Gedrückter Programmiertaste kenne ich bereits von der ETS 2 - in der ETS 3 bin ich noch nicht fündig geworden
Haben sie vieleicht eine Antwort

Bei der ETS3 in der oberen Menüleiste unter Diagnose - Physikalische Adressen

Gruß
Dieter

[582roman]

Danke!
mfg
Roman