Viele Rückmeldungen

[str]

Hallo zusammen !

In einem rel. großen Projekt habe ich so meine Sorgen mit Rückmeldungen (Statusobjekte von Schalt- bzw. Jalousieaktoren). Ein Zentralbefehl von der Visu fährt z.B. den Sonnenschutz auf/ab. Von ca. 200 Jalousieaktoren sollten eigentlich Rückmeldungen eintrudeln - es kommen aber nur ca. 20. Real ist der Sonnenschutz aber gefahren. Alle Behänge haben gleiche Laufzeiten - das könnte Problem sein. Die Linienkoppler werden mehr als 15 Telegramme nicht puffern können, somit kommen nur ein paar RM auf dem Backbone an.
Hat von Euch jemand Erfahrung mit solchen Großprojekten ?
Mein Projekt besteht aus 7 Bereichen, 24 Linien und ca. 800 Busteilnehmern.

[Michel]

Wie schreibt schon unser Forenmitglied Hannes in seinem Buch:
Und auch ein weiterer Nachteil (von Rückmeldeobjekten) soll nicht unerwähnt bleiben: Würde man in grösseren Anlagen generell mit Rückmeldeobjekten arbeiten, hätte der Bus bei einem zentralen Ausschaltbefehl ein Problem - unter Umständen möchten dann hunderte von Aktorobjekten gleichzeitig ihre Meldung loswerden. Aus diesem Grund sollten Rückmeldekanäle nur dann eingerichtet werden, wenn es wirklich sinnvoll erscheint, auch Visualisierungen lassen sich dadurch ganz gut unterstützen. In allen anderen Fällen, ... , sollte in grösseren Projekten auf eine Rückmeldung verzichtet werden.
Ich würde, wie oben schon zitiert, auf die Rückmeldeobjekte verzichten und z.B. mit dem Homeserver eine Sequenz einrichten, die jeweils nacheinander an einzelne Gruppen deiner Jalousieaktoren eine entsprechende Leseanfrage sendet. So erhältst du deine korrekten Stati in der Visu. ;)
Zwar etwas zeitverzögert, aber immerhin kommen sie an! :D

[str]

Herr Leidenroth hat wahrscheinlich verdammt recht.
@michel: Einen Homeserver hab ich leider nicht im Projekt - dafür aber den Facility Pilot von Jung. Habe zwar noch nicht rausgefunden, wie der FAP definiert zum Lesen überredet werden kann, ich hoffe aber mal ...
Freundliche Grüße

[Meudenbach]

800 TLN ist doch noch kein Grossprojekt :rolleyes: ...

Du wirst es kaum schaffen, alle Statusobjekte "sauber" durch den Linienkoppler zu "würgen". Im ungünstigsten Fall, d.h. alle Aktoren wollen exakt gleichzeitig einen Status senden, werden schon je Linie nur max. 4 Statis übertragen werden können.
Bei einem solchen Vorhaben, muss dies schon in der Planung berücksichtigt werden und dabei schaut man sich dann ganz genau das Verhalten der entsprechenden Aktoren an.

Über den Linienkoppler hinaus wird das Problem dann erheblich größer, denn nun "fütterst" Du den LK mit nahezu "Volllast". Der Koppler wiederum sowie jeder weitere Koppler in der Hauptlinie wollen diese Telegramme natürlich weiterleiten... dies natürlich auch wieder unter nahezu "Vollast". Da sind Kollisionen unvermeidbar. Merke: Ein Telegramm wird nach 4 erfolglosen Versuchen, es abzusetzen, verworfen. Mit jedem neuen Versuch wird die Priorität zwar angehoben, aber es sind da ja noch mehrere Koppler, die senden wollen... und nicht unberücksicht darf die "Grundlast" bleiben, also der Traffic, der eben innerhalb des "normalen" Betrieb so anfällt.

Auf dem Backbone wird dann nicht mehr viel übrig bleiben...

Ein weiteres Problem ist jedoch, dass beim "Überlauf" des Kopplers bzw. bei Auslastung des Kopplers "busy's" produziert werden. Dies kann zu Störungen des Betriebes führen. Sicherlich spielt sich das alles innerhalb weniger Sekunden ab, aber es kommt dann oft, wie es kommen muss und wichtige Schaltfolgen (Uhren, Störmeldungen, Zentralbefehle o.ä.) werden nicht ausgeführt, da in diesem Zustand der Koppler keine Telegramme mehr verarbeiten bzw. weiterleiten kann.

Theoretisch mag das zwar alles funktionieren und wird von sog. "Experten" mit gefährlichem "Halbwissen" schön geredet, aber die Erfahrungen zeigen doch recht deutlich andere Ergebnisse...

Wie löst man nun solch ein Problem:

ich gehe mal fest davon aus, dass Du Filtertabellen gesetzt hast !!!

Kopplertausch:
Linienkoppler der neusten Genaration einsetzten. Hierbei wurde, meines Wissens, der Pufferspeicher auf bis zu 100 Telegramme erhöht. Dies hilft aber nur eingeschränkt.

... besser

Fast Backbone Topologie:
Heißt im Klartext Bandbreitenerhöhung durch Einsatz eines Backbone's auf Basis Ethernet. Hilft auch nur wirklich, wenn sämtliche Koppler durch sog. LAN Koppler ersetzt werden.

... am besten

Spezielle LAN Koppler
wie zB der eibNode der Fa. BabTec. Dieser verfügt über ein Speicher des Prozessabbildes. D.h. er kennt die Zustände aller Adressen innerhalb der Linie. Die eigentlichen STATUS Telegramme werden durch den eibNode gesperrt, also auch nicht weiter übertragen.
"Oben auf" sitzt der NetX OPC - Server. Dieser liest dann lediglich den Adressspeicher der jeweiligen eibNodes aus und das über 10MBIT...

Man könnte nun versuchen vorerst nur die BK's zu tauschen und dann auch die LK's. Ich denke letzteres wird jedoch notwendig sein. Bitte beachten, dass die Problematik innerhalb einer Linie auch hierdurch nicht behoben wird.

Ansonsten bleibt nur die vom Michel vorgeschlagene Vorgehensweise, die ich im Übrigen auch favorisiere. Aber auch hier gilt es einiges zu beachten !!! Eine SW wie zB die B-CON bietet hierfür genau die notwendigen Mechanismen um solch "geziehlte" Abfragen innerhalb eines definierten Zeitraumes auszulösen...
Es macht schließlich nur Sinn die Werte abzufragen, die ich grad betrachte...

LG

[str]

@meudenbach: "800 TLN ist doch noch kein Grossprojekt" - sicherlich wurde hier das Präfix "relativ" überlesen. Hauptsächlich finde ich im Forum Postings von "Häuslebauern", die mit ein paar EIB-Geräten arbeiten ... deswegen RELATIV :) .

Danke für die Vorschläge.
Als Koppler sind ABB LK/S4.2 im Einsatz. Trotzdem ist die Telegrammlast u.U. zu hoch bei Zentralbefehlen. Ethernet-Anbindung ist im Projekt nicht möglich. Gezielte Leseanfragen halte ich für zu aufwändig. Der Verzicht auf "echte" Rückmeldungen ist wahrscheinlich die bessere Wahl.

[Norbe]

naja wenn du visualisierst , solltest du die Zustände schon haben .
Ich hab das gleiche Problem genau wie Michel´s Vorschlag gelöst , es werden gezielt regelmässig die Stati abgefragt.
Soooo aufwändig ist das auch wieder nicht , war ne halbe Stunde Arbeit mitm HS

[Meudenbach]

Hallo Norbe,

wie hast denn das realisiert, wenn ich fragen darf ??

LG

[Norbe]

nur mitm Telegrammgenerator zyklich und einmal nach Neustart eine Sequenz gestartet , die nacheinander die KO´s der Stati abfragt , feddisch

[Meudenbach]

na ob das praktikabel ist....:rolleyes:

LG

[Michel]

Zyklisch abfragen macht IMHO keinen Sinn, es sei denn ich brauche den richtigen Status auch auf Tastsensoren.
Also ich würde das so machen:
Sequenz starten, wenn:

Visu-Seite mit den entsprechenden Stati aufgerufen wird, oder
für den Fall das mehrere Visu´s zeitgleich laufen, Sequenz nach Empfang der Zentraladresse startenToggeln ist dann natürlich kein guter Befehl; weder auf der Visu-Seite noch auf den Tastsensoren ;) .

[EIB-Bertl]

Hallo

Um dieses Problem zu vermeiden, teile ich den Zentralbefehl (z.B. alle Jalousien auf) auf mehrere Befehle auf, die eine Zeitverzögerung von einigen Sekunden haben. Dadurch wird nur eine begrenzte Anzahl von Rückmeldungen generiert, die vom EIB und den LK locker verarbeitet werden kann.
Da du den FAP vom Jung verwendest, kannst du mit einer Sequenz einfach die Befehle der Reihe nach ablaufen lassen.

mfg
EIB-Bertl