Herstellerkennung falsch

[eibandi]

Wieso sollte die iETS dran schuld sein. Ich denke eher an andere Dinge: zu große Leitungslängen, Spannungsspitzen oder -abfälle während der Übertragung....
Mit der FT1.2 plus einer KNX-IP-Schnittstelle "spare" ich halt ein zwischengeschaltetes Gerät.

Andi

[MatthiasS]

Tja, es war bei uns halt besonders ärgerlich, weil es die erste Programmierung eines Gerätes über die iETS war. Die Programmierungen vorher direkt aus der ETS heraus hatten problemlos geklappt.
Besonders als KNX-Anfänger fängt man da an zu zweifeln.
Aber offensichtlich kommt sowas wirklich nur selten vor...

Also ich mache das jetzt fast seit Beginn der EIB-Zeitrechnung und höre das das erste mal.

Ich frage mich, ob es ohne definitive Ursachenfeststellung "zulässig" ist, das auf die iETS zu schieben.

[eibandi]

Tja, es war bei uns halt besonders ärgerlich, weil es die erste Programmierung eines Gerätes über die iETS war. Die Programmierungen vorher direkt aus der ETS heraus hatten problemlos geklappt.
Besonders als KNX-Anfänger fängt man da an zu zweifeln.
Aber offensichtlich kommt sowas wirklich nur selten vor...

[cixx]

manchmal ist es halt verflucht....

hatte ja neulich erst das Problem, das das USB Kabel zur Schnittstelle ne Macke hatte. Busmonitor ging, Werte auf den Bus senden auch, nur programmieren nicht mehr und jedes Gerät bei dem ich es versuchte war danach out-of-order....
Ich dachte schon ich schrotte in dem Moment ein Gerät nach dem anderen....
Bis ich zufällig auf das USB Kabel kam, hatte ich schon einige graue Haare mehr...

[3dmartist]

Wow, wenn wircklich beim "in betrieb nehmen" vom HS oder beim anklemmen irgendwas passiert ist (kann ich mar zwar nicht vorstellen aber naja) was dann sämtliche geräte verrückt spielen lässt - na prost......

stell dir mal vor das passiert dir beim kunden oder bei einem selber zuhause und du kannst alle geräte vom gesamten EFH einschicken.......

möchte ich gar ned drann denken......


ich glaub ich kauf mir noch ein paar Überspannungsableitungsklemmen mehr.....

grüße martin

[harryhirsch3]

Hi,

es gibt halt leider Fehler, die man nicht wirklich haben muss

MfG

Daniel

[eibandi]

ERLEDIGT: Defekte Bausteinprogrammierung

Es ist schon eine Weile her, aber ich wollte doch noch berichten, wie es mit diesem Problem weitergegangen ist.

Es ist immer noch nicht klar, wie es zu den Fehlern innerhalb der Geräte kam, aber nach langer Zeit hat sich alles erledigt:
- Rücksendung an den Händler
- der hat die Bausteine (leider in Etappen) zum Hersteller eingesendet.
- von Siemens kam das Gerät zurück mit dem Verweis: Ist doch gar nicht defekt (vielleicht hat sich ja wirklich in den vier Wochen, die die Geräte unterwegs waren, irgendwas wieder geradegebogen; das Abziehen von der Busspannung hatte bei uns aber nix genutzt...).
- von Gira kamen beide Geräte als Austauschgeräte zurück - seitdem keine Probleme mehr!
- inzwischen zusätzlich zur FT 1.2 eine KNX-IP-Schnittstelle gekauft - Programmierung also nicht mehr über die iETS erforderlich


Nochmal Dank an alle für die schnellen Tipps und Hilfsangebote!

Andi

[S. De Bruyne]

Aah ?!?
I thought the protocol was robust enough and could cope with such incidents.
I thought, if a telegram has been corrupt (for any reason, including power glitch), it should be discarded and resend, especially in such critical operations as device programming.

Maybe my understanding is wrong ? if so, thank you for putting me right.

No, of course not, the protocol is more than sufficiently robust.
I guess that the writer of this statement was not referring to the protocol or datagrams sent on the bus, but to bits changing inside the device itself. This can indeed happen. Though KNX devices typically withstand better EMC (Electromagnetic Compatibility) conditions than many other electronic systems, bits in memory (EEPROM, flash, ...) may change due to high voltage transitions, electromagnetic radiations, etc. This happens in very rare cases, kn KNX devices, your computer, your mobile phone, one of the microcontrollers in your car, ... If this happens in memory locations that cannot be accessed from the bus (e.g. stack), then the device has indeed to be replaced. (If this is really the cause.)
Telegrams are protected by a parity bit and a checksum; for memory, there are checksums as well.

[eibandi]

I thought so, too, but obviously it happens - albeit infrequently, since we can´t program the affected devices anymore with ETS3. At least that is the information given by GIRA.

Andi

[Warichet]

In wenigen Ausnahmefällen kann es schon einmal vorkommen, dass "mal ein Bit verrutscht", falls im falschen Moment ein Spannungsabfall auf dem Bus erfolgt.

Aah ?!?
I thought the protocol was robust enough and could cope with such incidents.
I thought, if a telegram has been corrupt (for any reason, including power glitch), it should be discarded and resend, especially in such critical operations as device programming.

Maybe my understanding is wrong ? if so, thank you for putting me right.

[eibandi]

@MarkusS

Hä??????

Ich habe nur zitiert. Für mich heißt das, das die Programmierung in den Geräten zerschossen ist und nur vom Hersteller wieder erstellt werden kann...

@Ralf Engels
Der Siemens ist ein Taster, der praktisch nur aus einem Busankoppler besteht, und weiß gar nicht mehr, was er ist.
Der Busankoppler vom TS2+ wird doch ignoriert??? Man programmiert nur den TS2+. Der TS2+ behauptet von sich, er sei ein Siemens4fach-Taster. Das Applikationsprogramm sieht auch so aus, wie das, das bei Siemens dabei war.
Oder meinst Du die FT1.2 mit BCU? Das hatte ich hier
schon gepostet.

Inzwischen hat sich auch EIBmarkt gemeldet: "Sie erhalten heute im Laufe des Tages, spätestens jedoch bis morgen eine genaue Rücksendeanschrift zur Garantiereparatur durch den Hersteller!"
Heißt dann wohl, dass wir die Geräte selber an den Geräteherstellerschicken müssen .
Naja, dauert die endgültige Installation eben noch etwas länger...

Gruß
Andi

[Ralf Engels]

was sagt den die ETS wenn Du den Hersteller der BCU ausliest?

Gruß
Ralf

[MarkusS]

In wenigen Ausnahmefällen kann es schon einmal vorkommen, dass "mal ein Bit verrutscht", falls im falschen Moment ein Spannungsabfall auf dem Bus erfolgt. Dadurch könne dann schonmal die Programmierung durcheinanderkommen.
Die Geräte müssen zurück zum Hersteller, um neu programmiert zu werden, das müsse über die normale Garantie abgedeckt sein.

Hä??????

Gruss
Markus

[eibandi]

Gira hat heute morgen zurückgerufen, nachdem wir die komplette Konfiguration zu ihnen geschickt hatten. Im Prinzip war wohl alles in Ordnung, aber:
In wenigen Ausnahmefällen kann es schon einmal vorkommen, dass "mal ein Bit verrutscht", falls im falschen Moment ein Spannungsabfall auf dem Bus erfolgt. Dadurch könne dann schonmal die Programmierung durcheinanderkommen.
Die Geräte müssen zurück zum Hersteller, um neu programmiert zu werden, das müsse über die normale Garantie abgedeckt sein.
Bin mal gespannt, was eibmarkt dazu sagt...

Grüße von
Andi

[eibandi]

Herstellerkennung falsch

@HartmutB: Überprüft, das war es aber (leider!) nicht.

@marc.keynejad: Der Homeserver ist zur Zeit wieder abgeklemmt, die physikalischen Adressen der betroffenen Geräte lassen sich mit der ETS3 umprogrammieren, bei den Geräte-Infos steht aber beim TS2+ nur Murks drin beim Siemenstaster kommt zurück "nicht implementiert". Die Applikationsprogramme lassen sich in der ETS3 aufrufen und ändern, aber nicht in das Gerät hochladen.

Siemenstaster inzwischen komplett aus dem Projekt rausgenommen und neu eingelesen, versucht, zu resetten, ging alles nicht.

@Ralf Engels: Heute wird noch ein Hilfeanruf an GIRA abgesetzt, danach komme ich vielleicht darauf zurück (meinst Du, es hat die FT1.2 gehimmelt?). Danke!



Grüße
Andi