PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : N148 stabil ?



Toto
03.03.06, 10:41
Ich habe mir ein Testsystem aufgebaut mit einem TPUART-Board, welches selbst entwickelt ist und Nachrichten in unterschiedlichen Geschwindigkeiten und Telegrammformen sowie Reihenfolgen auf den Bus legen kann.
Ich erzeuge meist zwischen 10-50 Nachrichten/s.

Getestet wurde die N148 mit unterschiedlichen EIBnet/IP-Software Stacks
1. Calimero Software
2. eigene EIBnet/IP-Software
3. ETS3
Parallel lasse ich eine BCU2 FT1.2 seriell mit dem C++ Stack von soureforge.net mitloggen.

Zum Ergebnis:
Die BCU2 mit FT1.2 Software loggt alle Nachrichten mit und scheint vollkommen stabil zu arbeiten.

Die Schnittstelle N148 reagiert in allen drei Fällen nach einigen Stunden, manchmal auch erst nach einigen Tagen, mit einem Abbruch, teilweise und öfter auch mit Aussetzern in denen eine unregelmässige Zeit keine Nachrichten empfangen bzw. verworfen wurden.

Ich möchte das Gerät in einer Anlage einsetzen, allerdings erwarte/benötige ich möglichst 100% Stabilität und es dürfen keine Nachrichten verloren gehen.

Wie sind Ihre/Eure Erfahrungen ?

Eigentlich habe ich Vertrauen in Siemens und Ihre QS. Natürlich schliesse ich auch einen Fehler meinerseits nicht aus, bin auch nur Entwickler :-)

so long

Meudenbach
03.03.06, 11:12
Eigentlich habe ich Vertrauen in Siemens und Ihre QS....

Dieser Glaube hätte mich fast in den Ruin getrieben :cool:.
Ich teste grad eine Anlage mit dem sehr vielen N148, die erheblich Probleme macht. Ich suche noch...

Gruss

???
03.03.06, 12:00
>>Getestet wurde die N148 mit unterschiedlichen
>>EIBnet/IP-Software Stacks
>>1. Calimero Software

Umgebung:
N148/21, Calimero, selbsgeschriebene Visu, EFH mit 80 EIB Geräten

nachgewiesene Verfügbarkeit (ich steuere auch die Alarmanlage damit):
mehr als 99,99 %

Um das zu erreichen, mußte ich aber eine Logik einbauen, die die N148/21 überwacht. D.h. timed die Kommunikation aus, dann wird die IP Verbindung getrennt und neu aufgebaut. Das funktioniert zu 100% (empirische Beweisführung). Im Schnitt timed die Schnittstelle etwa 2 bis 3 mal pro Woche aus. Bis der Timeout erkannt wird und die Connection erneut initiert vergehen ca. 1,5 - 2 min.

Damit kann ich leben. Besser wäre es natürlich 100% Verfügbarkeit zu haben.

Roland

Toto
03.03.06, 13:01
Scheint der Heartbeat zu sein der ja jede min die Verbindung testet.

@???:
Erkennst Du den Verbindungsabruch durch den Heartbeat ?

Bei einer zyklischen Versendung des Alarms könnte dies akzeptabel sein, allerdings müssten z.b. bei einer Visualisierung alle Zustände neu abgefragt werden, da ansonsten Inkonsistenzen der Daten drohen.
Was machst Du wenn der Bewohner gerade in dieser Minute schaltet ?

Wir verlieren auf jeden Fall mind. 1min alle Nachrichten, dies für den gewerblichen Gebrauch sicher nicht akzeptabel.

???
04.03.06, 01:11
>>Erkennst Du den Verbindungsabruch durch den Heartbeat ?

Habe einen Watchdog implementiert. Wenn innerhalb einer Minute keine Botschaft über den Bus ging, sendet der Watchdog einen EIB Request (Leseanforderung auf eine GA) auf den Bus. Kommt Antwort, OK. Kommt keine, eben nicht.

>>allerdings müssten z.b. bei einer Visualisierung
>>alle Zustände neu abgefragt werden,

Nein, nicht alle. SollTemp, IstTemp, AussenTemp, Sonnenstand und Heizungsaktoren interessieren dabei nicht. Ich gehe einfach mal davon aus, dass innerhalb von 1 bis 2 min diese Zustände sich nicht signifikant ändern. (Zumindest ist bisher auch die Sonne noch nie schlagartig ausgefallen).

Alle anderen Zustände (Fenster-, Türkontakte, Licht etc.) muß ich natürlich neu einlesen. Etwas kniffelig ist dabei die Rekalibrierung der Jalousiezustände, da ich leider keine Aktoren mit Zustandsobjekten verwende. Habe das aber mittlerweile auch im Griff.

>>Was machst Du wenn der Bewohner gerade in dieser Minute schaltet ?

Der Bewohner bin ich. Und ich bin tolerant. Ausserdem ist es, glaube ich, auch noch nie passiert. Habe es zumindest nicht bemerkt. Bei einer Verfügbarkeit von > 99,99 wäre es aber auch ein gigantischer Zufall.

Roland

Meudenbach
05.03.06, 18:25
Wir verlieren auf jeden Fall mind. 1min alle Nachrichten, dies für den gewerblichen Gebrauch sicher nicht akzeptabel.

... naja, ich würde das als katastrophal bezeichnen.

Gruss

JoergA
19.05.06, 10:28
Im Schnitt timed die Schnittstelle etwa 2 bis 3 mal pro Woche aus.


Heißt dies im Umkehrschluß, das diese Schnittstelle nicht für eine Visu Anbindung geeignet wäre?? Dies ist derzeit meine Intension :o



Um das zu erreichen, mußte ich aber eine Logik einbauen, die die N148/21 überwacht. D.h. timed die Kommunikation aus, dann wird die IP Verbindung getrennt und neu aufgebaut. Das funktioniert zu 100% (empirische Beweisführung).


Wie hast Du dies gelöst??

Besten gruß aus dem Neandertal,
Jörg

???
20.05.06, 01:17
>>Heißt dies im Umkehrschluß, das diese Schnittstelle nicht
>>für eine Visu Anbindung geeignet wäre??

Heißt es nicht zwingend. Einfacher wäre es natürlich mit einem fehlerfreien Betrieb. S.u.

>>Wie hast Du dies gelöst??

Empfange ich auf der Schnittstelle vom Bus Telegramme ist alles grün. Empfange ich aber länger als ein konfigurierbarer Zeitraum (akt. 1 min), auf der Schnittstelle nichts vom Bus, sende ich einen Read Telegramm auf eine beliebige GA über die Schnittstelle auf den Bus. Antwortet das angesprochene Gerät, ist ebenfalls alles grün. I.d.F. ist einfach nichts los auf dem Bus. Antwortet das Gerät aber nicht, dann disconnecte ich die IP Connection zur Schnittstelle und baue sie neu auf. Nach dem Disconnect benötigt die Schnittstelle einige Zeit (vermutlich wartet sie auf einen Timeout) bis sie sich resetet. Der Reconnect läuft deswegen in einer Schleife. In Summe kommen damit die 1,5 bis 2 min Totzeit pro Auftreten zustande.

Ich kann mit einer durchschnittlichen Ausfallzeit von 5 min / Woche ganz gut leben. Aber nochmals: Eine fehlerfreie Schnittstelle wäre mir natürlich lieber.

Roland

babel
30.05.06, 13:19
Weiss jemand ob dieses Problem mit den IP Router N146 auch auftritt?

Toto
12.12.06, 10:39
Weitere Nachforschungen haben ergeben, dass die N148 stabil ist.

Leider scheint es bei Calimero Probleme mit der Heartbeat-Implementierung zu geben. Es kommt dort zu einer reproduzierbaren Null-Pointer-Exception.

Derzeit haben wir einen Workaround, der uns hilft dies zu erkennen.

Falls jemand eine Lösung bzw. Verbesserung im Calimero-Heartbeat hat, wäre ich ganz Ohr :)