Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Warum ? das Ereigniss ist doch über den Bus gesendet worden und damit auch vom StandBy HS empfangen worden.
Das Ereignis ist gesendet worden, das Nicht-Ereignis aber nicht. Wenn der redundante (R) den Zufallsevent schon ausgeführt hätte, der aktive (A) aber noch nicht hat, muss das aus Sicht von R (nochmal!) nachgeholt werden. Alle Rollläden (nochmal aus eigener Sicht) rauffahren, zum Beispiel.
Klar das der über Logiken dies nun der Zeitschaltuhr beibringen muss, aber dann macht man halt nicht soviel mit der USZU sondern mit Logik.
Das sag' ich doch gerade mit 'es wird komplexer' .
Ein bißchen komplexer wird das schon. Wenn z.B. Abläufe mit Zufallsgenerator programmiert sind (SA/SU +/- Zufall, als Beispiel), ist ohne weitere Maßnahmen nicht eindeutig bestimmbar, ob zum Übernahmezeitpunkt das entsprechende Ereignis schon stattgefunden hat oder nicht.
Warum ? das Ereigniss ist doch über den Bus gesendet worden und damit auch vom StandBy HS empfangen worden. Klar das der über Logiken dies nun der Zeitschaltuhr beibringen muss, aber dann macht man halt nicht soviel mit der USZU sondern mit Logik.
Also bei Hot-Standby muß der Standby HS eben alles so machen als wäre er Active, nur eben nicht senden. Somit wären hier alle Zustände immer gleich wie im anderen ...
Ein bißchen komplexer wird das schon. Wenn z.B. Abläufe mit Zufallsgenerator programmiert sind (SA/SU +/- Zufall, als Beispiel), ist ohne weitere Maßnahmen nicht eindeutig bestimmbar, ob zum Übernahmezeitpunkt das entsprechende Ereignis schon stattgefunden hat oder nicht.
Beide HS müsten eine einzige virtuelle IP haben. Dann könnte der Stand-By HS auch diese IP Telegramme erhalten und wäre somit auch hier konsistent.
Wenn diese IP-Telegramme nur an den Aktive HS gehen würden, wäre ja der Kontext (also die Zustände) nicht bei beiden gleich. Dann müste man beim Umschalten doch wieder den Kontext rüber bringen.
Also bei Hot-Standby muß der Standby HS eben alles so machen als wäre er Active, nur eben nicht senden. Somit wären hier alle Zustände immer gleich wie im anderen und er könnte sofort übernehmen.
Sonst müssen alle Zustände übertragen werden und das geht sicher mit dem Remanentspeicher über FTP am besten.
Probleme mit Mund halten gibt es nur, wenn die IP der HS eindeutig sein muss (IP-Telegramme von Fremdsystemen). Dann muss man die wechelsseitig abschalten.
@Michel, @spookyt.:
Danke für den geduldigen Hinweis auf schon lange im Forum vorhandene Informationen... ich hatte gedacht alles zu dem Thema gefunden zu haben... sorry.
Die Lösung über gemeinsamen Remanentspeicher auf einem FTP scheint mir die robusteste zu sein. Aber vor allem ist diese in der Praxis bewährt. Ein externes Gerät sehe ich somit nicht als zwingend nötig.
@NilsS, @tbr, @Michel:
Die Softwarelösung hat mehr Charm, ist aber anfälliger denke ich.
Was ist an USZUs besonderes, dass diese Probleme mit Sendesperre bereiten?
Der HS/FS speichert automatisch alle 15 Minuten (nur bei Änderung) diese Daten ab. Vor einer Anpassung der Konfiguration des HS/FS durch den Experten werden die Daten gespeichert.
Einen Befehl dazu gibt es nicht, ausser dieser Einstellung, die du am von dir genannten Ort findest:
Speicherzyklus: Ca. alle 15 Minuten (turnusmäßig) wird der Remanentspeicher auf den/die FTP-Server abgelegt
Benutzerdefiniert (2..96): Bei jedem hier eingetragenen Speicherturnus wird eine Remanentdatei auf den/die FTP-Server gespeichert
Ansonsten ist das mit der Sendesperre nicht ganz trivial. Man denke da z.B. auch an die USZUs
Doch eigentlich schon man darf halt NIX direkt machen, sondern immer über iKO und Logik. (... oder man baut halt einfach mal eben die put Funktion der Queue aus ....)
Interessant sind doch eigentlich nur die Schnittstellen.
IP / KNX
so hat man ja zwangsläufig beim Start des Ersatzgerätes einen alten Stand... aktualisieren kann man ja nicht, da sie nicht gleichzeitig laufen dürfen.
Der zweite holt sich beim Start die Remanentdaten vom FTP-Server, wohin sie der ersten regelmäßig, in 15 Minuten Intervallen, hinschreibt.
Insofern ist "zwangsläufig alter Stand" nicht richtig. Voraussetzung ist naturgemäß, daß beide über dasselbe Projekt verfügen.
Ansonsten ist das mit der Sendesperre nicht ganz trivial. Man denke da z.B. auch an die USZUs
das geht schon. Beide HS/FS erhalten über IP-Routing ja alle GAs. des KNX.
Wenn der HS/FS im Stand-by nur die Zustände mitgeht und erst aktiv übernimmt, wenn der andere nicht mehr erreichbar ist.
Dann könnte er den Ersten sogar über den 230V reseten und wenn der wieder da wäre sogar wieder zurückgeben.
Wie Nils schon gesagt hat, muß man alle Logik entsprechend anpassen:
a.) Nur hörend Mode
b.) Aktiver Mode
So ist das halt, eben Arbeit
Gruß Tbi
PS: Das wäre ein Hot Stand-by. Wenn der zweite HS aus ist, ist es eine Cold Stand-By. Hier ist eben die Umschaltzeit viel länger, da erst der zweite starten muß.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
.
Einen Kommentar schreiben: