mehrere Geräte im Programmiermodus? [Archiv] - KNX-Professionals Deutschland e.V. Forum

H. Leidenroth

04.11.02, 15:42

Das RS232-Kabel ist kurz und gehört zur EIB-Weiche von Schlaps & Partner. Mit einer "normalen" seriellen EIB-Schnittstelle habe ich es nicht versucht, weil ich ungerne zwei Schnittstellen transportieren will (ich nutze die EIB-Weiche als serielle Schnittstelle). Wenn es dieses Problem bei Verwendung "normaler serieller EIB-Schnittstellen" nicht gibt, dann müssen wir uns evtl. an Schlaps & Partner wenden. Danke für die Antworten. Übrigens: entfernt man den übergeordneten Linienkoppler (Sekundärlinien-Anschluss), ist das Problem auch nicht mehr vorhanden. Es sollte aber natürlich auch mit Linienkoppler funktionieren.

S. De Bruyne

04.11.02, 17:13

If the problem dissapears when removing the line coupler, could it be there is some wiring error in the installation (a line connected to both the main line as the sub line). This indeed leads to message duplication by the line coupler.

Please let us know what you have found.

G.Stenneken

04.11.02, 18:02

Dieses Problem habe ich auch öfter gehabt.
Das ich keine weitere Programmierung vornehmen konnte, weil angeblich mehrere Geräte im Progr. Modus sind.

Da habe ich einfach alle Spg.-Versorgungen resetet und anschl. ging alles wieder oder die Linie wo angeblich ein Gerät mit gedrückter Taster ist kurzzeitig entfernt und schnell prog. anschl. wieder die Linie eingebunden.

Gruß Gerrit

H. Leidenroth

05.11.02, 07:24

Danke für die Antworten. Ein Schluss zwischen Haupt- und Sekundärlinie lag nicht vor. Das haben wir natürlich zuerst kontrolliert. Normale Telegramme werden auch nicht mehrmals geroutet.

Meudenbach

05.11.02, 08:44

Auch ich kenne dieses Problem...

Schau mal in der Geräte info des Linienkopplers und schau, ob Fehlerflags gesetzt sind.

Gruss

Mike

H. Leidenroth

05.11.02, 09:25

Wenn es wieder einmal vorkommt, werde ich an die Geräte-Info (LK) denken - danke!

Dirk Beyer

05.11.02, 12:31

Hochinteressant!

In letzter Zeit häufen sich bei mir auch derartige Probleme bei mehreren Projekten! Bei meinem nächsten Besuch bei der "Problembaustelle" werde ich wohl auch mal den Linienkoppler checken"

Anmerkung für die Leser der IT bzw. EIBA: Könnte es wohl sein, daß dieser vermehrt auftretende Fehler mit dem schnelleren LK-Download der ETS (gegenüber früher) zusammenhängt?

Gruß

Dirk Beyer

S. De Bruyne

07.11.02, 17:30

The reason why ETS2 only now has the problem has nothing to do with the fast download of the Line Coupler. Only, since ETS2 v1.2 however, ETS2 now accepts multiple answers if coming from "the same" physical address. Former versions of ETS filtered this and showed only one response.

(*) This is also from two or more devices having the same physical address, like the default physical address 15.15.255.

The question now is:
- are there multiple answers?
- or are there repetitions of a single answer?

The Line Coupler situation seems to point to repetitions (due to BUSY or NACK), but this has to be investigated and may depend on the installation... A trace of the bus traffic would be nice to have.

Meanwhile, we try to reproduce it.

H. Leidenroth

07.11.02, 18:18

Hallo Mr. De Bruyne!

Beim letzten Problem waren es DREI Wiederholungen, sodass insgesamt 4 x ein (Response) von 15.15.255 zu sehen war. Das war verbunden mit Busy-Meldungen, die wahrscheinlich der Linienkoppler generierte. Eine Aufzeichnung habe ich leider nicht.

Das Problem ist aber nicht immer mit drei Wiederholungen vorhanden. In anderen Anlagen erscheinen z. B. nur "2 Geräte im Programmiermodus".

MfG / Leidenroth

EIB-Doktor

28.11.02, 02:38

Hallo, zusammen,

das diskutierte Problem gibt es immer häufiger. Auch ohne Likos übrigens. Linienreset funzt in so einem Fall (fast) immer.

Was passiert beim Programmieren der IA ( = phys. Adr.; KONNEX: individual Address) ? Zuerst wird eine Broadcast Meldung auf die GA 0/0/00 gesendet. Der Empfänger (= lokale BA; RS 232) muss dabei ACK generieren können, dann gibt es bei nur einer gedrückten Taste auch nur eine Antwort.

Nun hat der Busankoppler im seriellen Modus aber mindestens 2 verschiedene Betriebsarten (eigentlich 3) : Busmonitor und Link-Layer-Betrieb. Steht er (wodurch auch immer) auf Busmon-Betrieb, ist er transparent und gibt eben kein ACK. In dieser Betriebsart "lauscht" er nur am Bus, und soll auch z.B. NACK's und BUSY's anderer BA's nicht verfälschen. Der antwortende BA wiederholt demzufolge. Bis zu 3 mal.

Die ETS stellt den jeweils benötigten Modus ein - könnte sein, es klappt mal nicht , und statt Link-Layer wirds (oder bleibts) eben Busmon. Dann kracht es schon.

Durch Reset (Spannung unterbrechen) renkt sich der Fehler wieder ein, da die ETS nun erneut den Modus "Link Layer " wieder einzustellen versucht.

Warum aber der falsche Modus durch die ETS nicht erkannt wird, das sollte IT mal prüfen...

H. Leidenroth

28.11.02, 07:17

Danke für die Antworten. Übrigens: ich habe noch nie in meinem Leben ein "NACK" erlebt. Kann dieses praktisch/theoretisch überhaupt vorkommen?

Gruß
Hannes Leidenroth

S. De Bruyne

28.11.02, 13:07

Dear gentlemen,

* ETS does not use its RS232 device is Busmonitor mode when programming the Physical Address of a remote device.
- It needs to send out the request, and sending is not possible in Busmonitor mode.
- It does also not switch back to Busmonitor Mode for receiving the answer, as this is not necessary (Broadcast messages are received also in normal Link Layer Mode) and takes that much time for the BCU that the response from the remote device would not be noted.

So, ETS is in Normal Operation mode of the Data Link Layer.

* ETS also properly acknowledges the messages.
Actually, it is the RS232 device that does this. So, NACK's or BUSY's can only be due to the RS232 device, not due to the ETS.
But ... in the cases we have analysed ... ETS gets the repetitions... (see (!) below) An RS232 device will not pass the messages up in its message stack if it has sent NACK or BUSY.

So, also the RS232 device does not cause the BUSY or NACK.

* The cases we have analysed all show BUSY acknowledges to both the request (by ETS) as the response (by the device with the pressed programming button). So, some ... )&ç!'( ... device is sending BUSY. This causes the repetition of the response by the answering device, but also of the request by ETS. This is fully in line with the EIB specifications.

=> Find the BUSY sending device (decouple one after the other from the bus).

(!) The NETTO effect is that ETS gets multiple answers on its read request. But ETS shall not program the physical address when more than one device is in programming mode. So, ETS brings this message...

Some aspects:
- All answers come from the same device. ETS can detect this.
- All answers indicate Link Layer repetitions. ETS can detect this.

==> The rule for ETS could thus be to ignore multiple answers from the same remote physical address if all or all-but-one have the repeat flag set.

This could be a solution.

Please note however: devices that have not been programmed yet (have been unloaded) all have the same physical address. if when trying to program these, more than one such device is in programming mode and there are Link Layer repetitions, ETS will - according the above rule - ignore this and set the same physical address to all devices.

This is one solution, based on the assumption that the above is quite unlikely.

Another solution would be to change the error message from "More than one device in programming mode" to "ETS received multiple identical responses when searching for devices in programming mode. There may be more than one device in programming mode, or the request cycle has been corrupted." "Continue Yes/No"

Under discussion.

Drs. EIB

Jochen Bergmann

08.12.02, 16:18

[QUOTE]Original geschrieben von Meudenbach
[B]Auch ich kenne dieses Problem...

Schau mal in der Geräte info des Linienkopplers und schau, ob Fehlerflags gesetzt sind.

Leider habe ich das selbe Problem - allerdings in der einen Anlage ist es da und in der nächsten vergleichbaren wieder nicht !
Leider kann ich als EIB- "Anfänger" mit der Antwort nicht ausreichend das Problem lösen.

Was soll ich denn in den Geräteinfos finden und dann verändern ?
Oder soll die ETS nur die Flags geändert bekommen ?
Also einmal abfragen und gut ?

Grüße

H. Leidenroth

09.12.02, 07:25

Hallo Herr Bergmann!

Bei der Inbetriebnahme gibt es einen Button "GerInfo", darüber wird das Auslesen des Busankoppler-Status veranlasst. Ändern kann man dadurch aber nichts.

Gruß
H. Leidenroth

Meudenbach

10.12.02, 10:37

Fehler Flag´s....

... das Problem mit den Linienkopplern tritt in Verbindung mit der ETS 1.2 auf. Wie sich dies letztendlich auf den Koppler auswirkt, dass weiss ich auch nicht.

Fakt ist, die Geräte lassen sich teilweise nicht mehr ansprechen.

Um dies zu beheben, haben wir alle Koppler mit der ETS 1.1 "übergebügelt" Nach dem Download waren keine Fehlerflags mehr gesetzt und alles lief wie gewohnt.

.... ich frag mich nur immer wieder.... wieso fällt das der EIBA nicht auf ?????????

Gruss

S. De Bruyne

10.12.02, 10:50

Dear gentlemen,

I can inform you that we do have quite some reports like "programming across Line Couplers" not possible.

However,
*the KONNEX System Department has done some "worst case" downloads (multiple line couplers, 50 % bus load) without being able to artificially reproduce the effect.
* some error cases reported to us could be brought back to either installation errors (wrong physical addresses) or device errors (causing BUSY acknowledges)
* the EIBA (our membe companies) did not report any bugs in Line Couplers or proven malfunction in ETS yet.

So, where's smoke, there may be a fire, but so far, we did not point the problem down.

Would it be possible to provide (confidential - Vertraulich) information on the project (a pr2 file, with ETS log-file for instance)?

Mfg

Dirk Müller

31.12.02, 14:39

In den vorstehenden Beiträgen wurden zwei Probleme aufgeworfen:
1. Linienkoppler lassen sich nicht programmieren.
2. Mehrere Geräte im Programmiermodus

Zu beiden Problemen möchte ich meine Erfahrungen/Praxisberichte darlegen. Ich gehe mit meinen Erläuterungen immer von der ETS 2 V1.2a aus.

Zu 1. :

Die Meldung, dass sich Linienkoppler/Bereichskoppler (nachfolgend Koppler) nicht programmieren lassen, kann drei Ursachen haben:

a) Ein oder mehrere Koppler sind falsch angeschlossen (Primär- und Sekundäranschluss verwechselt, Koppler überbrückt, Koppler in Reihe). Die Meldung tritt also auf, wenn die EIB-Topologie nicht konsequent eingehalten wurde und die Programmierschnittstelle sich in der Hauptlinie befindet und eine physikalische Adresse der Hauptlinie hat. Dies gilt unabhängig der verwendeten Schnittstelle (BCU 1, BCU 2 von ABB/BJE – kein FT1.2 - oder der EIB-Weiche im Standard-Mode mit nichtblinkender grüner LED von Schlaps & Partner).
Hier hilft nur die Überprüfung der EIB-Struktur und Beseitigung aller Fehler.
Bei Auftreten eines solchen Problems von der Unterlinie zu programmieren, also dem Problem auszuweichen, rate ich ab.
Ich vertrete die These, dass zur Behebung dieser Fehlermeldung die Ursache mit 95%iger Wahrscheinlichkeit in der nichteingehaltenen „EIB-Struktur“ zu suchen ist.

b) Versucht man einen Koppler aus der Unterlinie zu programmieren, so kann dies ebenfalls zu einer Fehlermeldung führen, wenn die physikalische Adresse der Programmierschnittstelle nicht mit der Linie übereinstimmt (z.B. Koppler 01.01.000 und Schnittstelle 01.05.001). Abhilfe: Adresse der Schnittstelle auf z.B. 01.01.001 ändern.

c) Sollen Koppler via ISDN fernparametriert werden (im speziellen Fall, den ich nur beurteilen kann) mit Hilfe des SLink EIB bricht die ETS bei ca. 1% des Downloads ab.
Abhilfe: steht ab 07.01.2003 im internen Forum

Zu 2.:
Dieses Problem trat bzw. tritt bei uns mit einigen Phänomenen ebenfalls auf. Ich habe versucht es unter Berücksichtigung der vorherigen Beiträge zu analysieren. Nachdem ich wieder in der Anlage war, werde ich meine kompletten Beobachtungen am 08.01.2003 in dieses Forum stellen und hoffe auf Hilfe.

Dirk Müller

mailto: gepro.mv@t-online.de
http://www.GePro-mv.de

EIB-Doktor

05.01.03, 17:41

Liebe "Gemeinde",

die Diskussion droht, in allgemeine Probleme um Linienkoppler auszuufern. Deshalb komme ich wieder zurück auf den Anfang der Geschichte:

Trotz aller Versuche, einen Busankoppler zu adressieren (auch ohne Vorhandensein eines Kopplers !) meldet die ETS (egal, welche Ausführung): mehrere Geräte im Progr.-modus.

Ich bestätige erneut, dass dies vorkommt. Allerdings weiß auch ich leider immer noch nicht, wie es dazu kommt Wenn es allerdings einmal soweit ist, kann man mit einem zweiten Monitor-PC die Telegramme am Bus beobachten und auch aufzeichnen, da es dann reproduzierbar ist. Und ich hatte dabei festgestellt, dass es eben überhaupt keine Antwort (weder BUSY noch NACK) gegeben hatte. Die ETS brachte besagte Fehlermeldung, und merkte auch nicht, dass die Wiederholungen vom selben Busankoppler kamen.

Sehr geehrter Herr de Bruyne, sobald ich dieses Phänomen das nächste Mal feststelle, werde ich Ihnen Telegrammfiles aufzeichnen und zusenden. Das sollte auch jeder andere tun, dem das demnächst wieder passiert. Bitte senden an support@eiba.com . Vielleicht bekommt die EIBA dann einen Anhaltspunkt, woran das liegt.

Das Problem wird natürlich gravierender, sobald mehrere Linien beteiligt sind; letzten Endes geben aber alle im Übertragungspfad befindlichen Koppler brav ihr ACK; nur eben in der Linie der RS232 geht das manchmal nicht. Befindet sich die RS232 z.B. in einer Hauptlinie, und sind die LiKo's auf "immer ACK geben" eingestellt, sollte das Problem eigentlich nie auftreten.

A. Großmann

Dirk Müller

17.01.03, 15:03

Hallo EIB-Doktor,

stimmt nicht, bitte meinen Beitrag genau lesen.

zu 2.

Mehrere Geräte im Programmiermodus

Diese Meldung hatte ich auch in einer Anlage, obwohl keine Programmier-LED ge-drückt war.
Allerdings meldete sich eine physikalische Adresse die es wirklich in der Anlage gab. Ein- bzw. Ausschalten der LED über die ETS war nicht möglich (Es kam aber auch keine Fehlermeldung). Ein Einschalten der LED mit der ETS war möglich und ein anschließendes Ausschalten auch. Die Meldung „Ein Gerät im Programmiermodus“ blieb erhalten.
Anschließend wurde das Gerät mit dieser Adresse vom Bus getrennt. Die Meldung blieb erhalten. Ich muss dazu sagen, dass dieses Gerät defekt war, allerdings nur die Schaltkontakte mechanisch.
Danach habe ich die Koppler ausgelesen. Viele Koppler meldeten „Slavefehler nach Reset entdeckt“. Die Koppler wurden komplett (Applikation) überspielt, so dass die-ser Koppler-Fehler beseitigt war. Das betreffende Gerät wurde aber immer noch im Programmiermodus angezeigt.
Jetzt wurde das defekte Gerät aus der Anlage entfernt und Linien getrennt, bis die Fehlermeldung weg war. Anschließend wurde das Austauschgerät in der Hauptlinie, wo sich auch die Schnittstelle befand, programmiert.
Als letzter Schritt wurden alle Linien wieder verbunden und das Gerät an der richti-gen Stelle installiert. Die Fehlermeldung war verschwunden, die ETS meldete bei: Geräte mit gedrückter Programmiertaste auflisten „keine Geräte gefunden“.

Nach einigen Wochen trat die gleiche Situation noch einmal auf, nur mit einem ande-ren EIB-Gerät.
Ich führte die gleichen Handlungen bis einschließlich Programmierung der Koppler aus. Danach habe ich ein neues Gerät bei uns im Labor programmiert und es zum Einbau vor Ort geschickt.
Nachdem dem Einbau war die Fehlermeldung noch vorhanden.

Beim nächsten Auftreten werden ich Aufzeichnungen starten, um die Situation bes-ser analysieren zu können.

EIB-Doktor

21.01.03, 22:43

Hi, Dirk,

es mag ja sein, das mal was nicht stimmt ! Aber was ?

Bis dann

Dirk Müller

22.01.03, 07:24

Tja, wenn ich das wüsste.
Wie gesagt ich forsche noch. Wenn ich etwas weiß, schreibe ich es hier.

Dirk Müller

Ralf Engels

30.01.03, 10:16

Jetzt bin ich auch davon betroffen!
Reset des EIB hilft nicht.
Rechner neu Starten hilft nicht.
2 verschiedene PC getestet Win 98 bzw. XP das gleiche.
2 Datenschnittstellen klappt auch nicht.
2 verschieden ETS Versionen versucht 2.12a und 2.13 RC7
alles ohne erfolg.

Gibt es von euch hierzu etwas Neues?

Gruß
Ralf
http://www.eib-userclub.de/tmp/physadr.gif

S. De Bruyne

30.01.03, 10:54

Dear Mr. Engels,

would it be possible for you to send some log-files?
- ETS log-files (activated in ets2.ini, please set level=4)
- Bus telegrams
Could you with another PC simultaneously log the bus traffic, preferably without filtering the ACKs and BUSY's?
- Now, we would need to know what happens.
- Does it happen if ETS and target device are on the same line? Please decouple line coupler if any, and work on the same line.
- Then, you could try decoupling one device after another, and see when the problem does no longer appear.

I'm very interested in your findings. You can also contact me directly via sdebruyne@eiba.com.

Dirk Müller

31.01.03, 14:45

Hallo Ralf,

ich habe ein Logfile erstellt und es von Dr. Gütter von der IT analysieren lassen.
Er wettet, daß ich zwei Geräte mit der gleichen Adresse in der Anlage habe. Das kann ich momentan nicht überprüfen, da die Anlage weit entfernt ist und ein Abtrennen von Linien über eine Fernwartung nicht möglich ist.
Kannst Du feststellen, ob diese Diagnose für Deine Anlage zutrifft?

Dirk Müller

Meudenbach

31.01.03, 14:56

Ich kenn die Thematik...... und die Wette verliert Herr Dr. Gütter !!! :D

Selbe Thematik habe ich des öfteren in meinem Büro feststellen können und dort sind definitiv keine doppelt adressierten Teilnehmer vorhanden. (5 Linien, ca. 100 TLN) Testanlage eben ....

... allerdings kann ich ja nicht wissen, wie das bei Dir aussieht lieber Dirk :D

Gruss

Meudenbach

14.05.03, 07:47

Hi Leute,

ich wollte mal wieder auf dieses Problem zurückgreifen, da ich kürzlich wieder mit diesem Phänomen konfrontiert wurde....

Ein Kollege einer Elektrofirma hat eine von mir parametrierte Anlage in Betrieb nehmen wollen. Bei der Programmierung der physikalischen Adressen trat vor beschriebene Problematik (mehrere Geräte im Programiermodus) auf. Auch unter Verwendung verschiedener Schnittstellen.

Da das meine 1. IB mit der ETS 1.3 war, habe ich mit IT gesprochen und gefragt, ob dies Problem nun geklärt bzw. bekannt ist. Die liebe Frau Keim konnte mir allerdings nicht weiterhelfen und verwies auf diesen Thread.

... jetzt aber kommt es !!!!

Der Programmierer Vorort fragte mich, ob er für die Programmierung die Applikation der RS232 in die BCU laden soll...
Ich natürlich, mit meiner doch so reichaltigen Erfahrung :rolleyes: erklärte Ihm ausführlich, wie die BCU reagiert wenn eine RS232 darauf gesteckt wird.... und erleuterte, dass das Laden der Applikation für diese Anwendung (Programmieren) eigentlich wenig Sinn macht weil bei Verwendung der RS232 die BCU den Betriebsmodus wechselt und die geladene Applikation abschaltet. (so hab ich es zum. mal gelernt).

... aber... Versuch macht klug !!!

Applikation der RS232 geladen und die physikalischen Adressen konnten ohne Probleme programmiert werden :confused:

Da hab ich mich mal schön blamiert :(

... und jetzt seit Ihr drann. :D

Gruss

S. De Bruyne

14.05.03, 08:42

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

14.05.03, 08:54

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

14.05.03, 09:09

Dear Mr. Beyer,

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

Mfg.

EIB-Doktor

14.05.03, 10:57

Servus, Mike,

also, was beim Download einer x-beliebigen Appliaktion so abläuft, solltest du eigentlich wissen :rolleyes: : 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:mad: . 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

16.05.03, 15:40

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

05.08.03, 10:20

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??:confused:

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?:confused: :confused:

Gruß
Dieter Koch

gamma

05.08.03, 12:04

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

05.08.03, 23:36

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..... :rolleyes: (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?:confused: :confused:

... 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

06.08.03, 09:06

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

07.08.03, 08:01

Mach ich doch:

[QUOTE]Original geschrieben von Meudenbach
... also Dieter, dass sollte einem aber nur einmal im Leben passieren..... :rolleyes: (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

[B]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