WatchDog aber wie?

[AUDSUPERUSER]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo

Mal angenommen, ihr müsst mit der vorhergehenden oder der nachfolgenden Anlage kommunizieren.
Da ist es kein Fehler, wenn man Überwacht, ob die Kommunikation noch steht.
Ich habe bei sowas schon viele Vorgehensweisen gesehen.
Wie macht ihr denn das so?

 

[rostiger Nagel]

mit einen Zähler die Komunikation Synchronisieren, ich sende einen
Auftrag und die Gegenstelle muß mir den Wert zurück senden, erst
dann wird der nächste Auftrag angestoßen, nach derm selben Schema.
Zusätzlich kommt eine Time Out überwachung rein, kommt nach einer
gewissen Zeit nicht die Antwort, wird dieses auch ausgewertet.

 

[MSB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also bei mir ist das im Regelfall keine "Auftragssteuerung",
sondern Anforderungen von Pumpen/Lüftern/Rüttlern/Reinigungen ...

Da legen wir eigentlich einfach beiderseitig ein Taktbit im Sende-DB auf,
dieses wird dann mit einem SV-Timer ausgewertet.
Sobald der Timer LOW ist, ist auf jeden Fall mal die Kommunikation ausgefallen.

Mfg
Manuel

 

[Andy79]

Wir machen das i.d.R. auch mit einem Taktmerker der auf die Schnittstelle gelegt wird. Sofern der Merker zu lange "0" oder "1" führt, ist die Kommunikation ausgefallen.

 

[Beren]

*gelöscht*

 

[SBC-User]

Zuviel Werbung?
-> Hier kostenlos registrieren

eine einfache variante ist z.B. eine Blinker mit xHz als telegramm abzusetzen, wenn innerhalb der zeit für einen definierten timeout am slave keine wertänderung erfolgt wird die kommunikation als fehlerhaft identifiziert, im gegenzug wird vom slave der inverse zustand des letzten timeout-telegramms gelesen, somit bekommen beide controller mit wann die kommunikation unterbrochen wurde und können über z.B. eine Interrupt-Routine entsprechende Betriebssichere zustände herstellen, es gibt bei diversen controllern auch die möglichkeit den rtc-counter auszuwerten, bei sonst snychronisierten rtc kann darüber auch eine einfache kommunikationsüberwachung erledigt werden

 

[Bender25]

Nur mal so in die Runde geschmissen. Wenn ich z.b. Daten via Ethernet sende mit AG_Send hab ich doch auch mein Error bzw mein Status. Reicht das nicht? Derzeit versende ich auch immer Zahlenwerte die ich auf änderung usw. abfrage. Nur das nervt mich.

 

[MSB]

Also ich kann jetzt nur mal so in die Runde schmeißen:
Die div. Status-Ausgaben der div. Kommunikationsbausteine halten bei weitem nicht was die Hilfe verspricht.

Insofern würde ich auf eine ebenso einfache wie wirkungsvolle direkte Auswertung nicht verzichten wollen.
Bzgl. der Art und Weise wurde hier ja schon einiges genannt.

Mfg
Manuel

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das durch den "Wachhund" überwachte "Hand-geschüttel", ermöglicht es
auch den Komunikations Partner zu Signalisieren ob der Datenaustausch
funktioniert.

 

[SBC-User]

ich schließe mich msb an, die kom-bausteine sind niemals ein ersatz für die prüfung der befelsrelevanz, der error der bausteine kann auch aus firmware-ebene heraus ausgelößt werden (internal interrupt) der die echte kommunikation garnicht beeinflussen muß, die bausteine sagen in der regel nichts über die echte kommunikation aus, sondern viel mehr ob die schnittstelle binnen ihrer parameter niemals kolabiert, gerade bei tcp/ip erfolgt ein kollabieren in einem netzwerk mit hoher broadcast-aktivität sehr häufig, das verlangsamt zwar die bus-kommunikation, macht sie aber nicht schlechter oder fehlerhaft

meiner meinung nach kann nur durch prüfen auf befehlsrelevanz eine sichere kommunikation detektiert werden