Problem bei Inbetriebnahme der Mailapplikation SCN-IP000.02

[ponG]

Hallo zusammen,

ich scheitere im Moment an der Mailfunktion des SCN-IP000.02.

Ich habe das Interface in Betrieb genommen, funktioniert soweit auch für seine eigentliche Aufgabe gut. Jetzt möchte ich aber Mail- und Zeitserverfunktion ergänzen.

Das Interface hat die physische Adresse 1.1.250, die Host-Adresse 1.1.251 und sollte damit ja, wie in der MDT-Doku steht, die zusätzlichen Tunneladresse 1.1.252, 1.1.253 und 1.1.254 generieren. Ich habe dann meinem Projekt das IP-Interface mit Mailfunktion hinzugefügt und die Adresse 1.1.255 zugewiesen. Wenn ich nun aber die Programmiertaste lange drücke um physische Adresse und Applikation zu übertragen, schlägt die Programmierung mit "No ConnectResponse Received" fehl. Ich habe es testweise auch schon mit einer anderen PA versucht, gleiches Ergebnis...

Wo liegt mein (Denk-) Fehler? Im Inbetriebnahmekapitel steht da auch keine detailliertere Vorgehensweise.

Danke für eure Hilfe!
Sascha

[hjk]

Das Problem hängt mit der ETS zusammen. Wenn versucht wird die PA und die Applikation zu schreiben gibt es folgenden Effekt:
Die ETS überträgt die PA, das Gerät bekommt einen Reset, dabei geht natürlich die Verbindung verloren (Gerät startet ja gerade neu) und die ETS bricht mit dem Fehler ab.
Wir diskutieren das gerade mit KNX. Das Timing in der ETS muss dazu geändert werden.
Abhilfe: PA schreiben, und danach die Applikation einzeln laden. Dann läuft es ohne Fehlermeldung.

[spassbird]

Ähm ja, stimmt. Darum haben wir im zertifizierungskurs auch immer erst alle PA's gesetzt und erst dann die Application in die Geräte geladen.
Hat den Vorteil, dass man sie im nachhinein nur immer mit der App befeuern kann und nicht jedes mal zwei Resetzyklen warten muss.
Und weiterer Vorteil, alle Geräte auf dem Tisch die PA verpassen, einbauen und dann die App schiessen. Dann sieht man gleich ob der Bus funzt.

[ponG]

Hm, das führt leider auch nicht zum Erfolg. Ich habe das Interface in den E-Mail-Programmiermodus geschickt (Programmiertaste lang drücken, LED blinkt rot) und nur die PA übertragen. ETS und Interface scheinen sich dann kurz zu unterhalten, ETS teilt mit in der Historie auch mit, dass das Gerät neu startet, aber dann wird die Programmierung mit o.g. Fehler beendet. Der Programmiermodus ist dann aber wieder aus... irgendetwas passiert also, aber scheinbar nicht das richtige...

[Bucky2k]

@PonG:

Doch, das ist der Erfolg. PA ist gesetzt (auch in der Weboberfläche einsehbar) und das Interface läuft. Da es aber ein paar Sekunden braucht um zu neu zu starten gibt die ETS den Fehler. Ab jetzt kann die Applikation geladen werden. Oder ist noch ein anderes Problem präsent?

[hjk]

Also hier nochmal der Ablauf:
Progtaste lange drücken
mit der ETS die PA laden (nur PA)
Interface startet neu, es kommt eine Fehlermeldung, da Verbindung weg ist, die PA ist aber gesetzt und funktioniert nach dem Neustart

Nach ein paar Sekunden:
mit der ETS die Applikation ( ohne PA und ohne Progtaste) laden
hier soll kein Fehler kommen

Der Fehler kommt nur wenn mit der ETS "PA und Applikation laden" ausgewählt wird, dann wird das Laden der Appikation abgebrochen
oder die PA geladen wird (hier ohne Auswirkung).
Diese Funktion geht nur, wenn über ein anderes Interface z.B. USB die ETS Verbindung aufgebaut ist.
Oder das Timingproblem in der ETS behoben ist.

Wenn jetzt noch eine Fehlermeldung kommt => goto Support

[ponG]

Hallo zusammen,

danke, das mit dem getrennten Laden von PA und Applikation hat schonmal funktioniert Wie Bucky2k angemerkt hat ist der "Fehler" trotzdem ein Erfolg. Die ETS zeigt zwar nach der PA-Programmierung eine Fehlermeldung und in der Geräteübersicht fehlt der Haken bei der PA, ich kann aber dann die Applikation laden. Danach sind alle Haken grün.

Das Webinterface war eben noch nicht erreichbar, ich konnte aber auch nur kurz testen. Ich setze mich heute Abend nochmal dran und gebe hier nochmal Feedback, ob es nun geklappt hat.

Solang das Timing-Problem mit KNX noch nicht ausdiskutiert ist, wäre es vielleicht hilfreich, das Vorgehen in der Kurzanleitung etwas zu detaillieren und den hier beschriebenen Work-Around einzubauen.

Gruß,
Sascha

[trollvottel]

Idealerweise würde ein Firmwareupgrade dieses Problem beheben sodass es kein Timeout mehr gibt.

[hjk]

Idealerweise würde ein Firmwareupgrade dieses Problem beheben sodass es kein Timeout mehr gibt.

Das Problem liegt nicht in der Firmware sondern im Timing der ETS. Ein Timeout bei einem Reset des Gerätes kann nur in der ETS angepasst werden und nicht in der Firmware.

[trollvottel]

Das Problem liegt nicht in der Firmware sondern im Timing der ETS. Ein Timeout bei einem Reset des Gerätes kann nur in der ETS angepasst werden und nicht in der Firmware.

Warum passiert das dann nur bei diesem MDT-Gerät und nicht generell? Wäre das ein generelles Problem, wäre das von KNX doch längst gefixt! Timeouts werden doch nicht zum Spaß definiert.

[hjk]

Das passiert bei allen Geräten die Interface und eine zusätzliche Applikation haben. Es gibt noch nicht so viele Geräte mit einer solchen doppelten Funktion.
Die kommen gerade erst. Du kannst mir ja mal ein Gerät mit ähnlicher Funktion nennen, wo das nicht passiert...

[ponG]

Hallo zusammen,

danke für eure Hilfe, ich kann mein Webinterface nun erreichen!

Das einzige (kosmetische) Problem, was noch verbleibt: ETS oder das Interface setzt seine phys. Adresse immer auf die 15.15.241 aus der Auslieferung zurück...

In der ETS-Konfiguration habe ich 1.1.250 vergeben, also Host 1.1.251 und die Mail-Applikation hat 1.1.255. Liegt es an der Konstellation? Müsste ich die ersten beiden evtl tauschen? Auf Basis von welcher PA werden die Tunneladressen vergeben, der PA aus den ETS-Kommunikationseinstellungen oder der PA aus dem Projekt?

Gruß,
Sascha

[hjk]

Die "Host Physikalische Adresse" entspricht der Adresse der IP-Schnittelle (Grundapplikation) im ETS-Projekt (wird nur in der ETS5 angezeigt).
Die "Physikalische Adresse" entspricht der Tunnelingadresse des aktuellen Tunneling-Slots, der der ETS vom IP-Gerät zugewiesen wurde.
Im Normalfall ist es die erste Adresse der 4 Tunneling-Slots, wenn keine andere Tunnelingverbindung aufgebaut ist.
Die "Physikalische Adresse" der Tunnelingverbindung wird also vom IP-Gerät an die ETS geliefert und kann in der ETS geändert werden (Verbindung->Schnittstelle: „Physikalische Adresse“).
Wird die „Physikalische Adresse“ in der ETS geändert, wird die neue Adresse im IP-Gerät für diesen Tunneling-Slot übernommen.
In deinem Fall soll die "Host Physikalische Adresse" auf 1.1.250 gesetzt werden und die „Physikalische Adresse“ auf 1.1.251.

[ponG]

Vielen Dank, so klappt es!