Siemens Logo Input Variablen werden nach Netzwerk-Reset falsch ausgelesen

Hallo zusammen. Hattet ihr dieses Problem schon mal?

An einer Siemens Logo (V8.3) liegt am Eingang I1 eine Dauer-„1“ (high). Im Falle eines Alarms wird diese 1 zu einer null. Soweit so gut. Nun hab ich Beschwerden bekommen, dass schon zweimal der Alarm ausgelöst wurde, aber ohne dass der Eingang auf „0“ ging. Im Debug hab ich nachgelesen und siehe da:

Die Logo wird schön brav alle 2000ms ausgelesen. Jedes mal, wenn Fehlarm ausgelöst wurde, kann man im log erkennen: Error, Update Timer (10s nach der letzten erfolgreichen Meldung, also 8s überfällig). Aber dann kommt das Problem: Der Eingang I1 wird als „0“ ausgelesen und der Eingang I2 als „1“, was aber beides nicht sein kann. Damit wird natürlich der Fehlalarm ausgelöst :astonished:

Danach kommt noch was mit „der angegebene Host ist unbekannt“, „kann Daten nicht zur Instanz weiterleiten“. Dann dauerts noch kurz und plötzlich werden alle Werte wieder korrekt eingelesen. Das selbe passierte auch schon mal nach der Meldung „Discovery Server - Netzwerkschnittstellen haben sich geändert. Verlasse Multicastgruppe für Schnittstelle (x.y.z)“.

Ich hab den Logo-Konfigurator verwendet. Vor ein paar Jahren, wo es den noch nicht gab, hab ich brav Speicherzellen der Logo ausgelesen, und damals ist das selbe passiert. Immer wenn das Netzwerk sich mal kurz aufrappelt oder sonst was die Verbindung ausbremst, werden anschließend falsche Logo-Eingangswerte angezeigt. Je nachdem, wieviel Polizei und Feuerwehr dadurch anrückt, kann das blöd sein… :roll_eyes:

Hat jemand ein Würgaround?
Danke für eure Ideen :blush:

Da zwischen der LOGO! und Symcon keine feste Hardwareverbindung besteht, ist zu Vermeidung von Fehlalarmen - bei einer Netzwerkverbindung - ein aktives Ausgangssignal an der LOGO! auf 1 zu setzen. Dafür kannst du dann das Profil ~Alert in Symcon benutzen. Die Verbindung zur LOGO! solltest du dann intern mit einem zweiten Ausgang (NQ) überwachen und einen internen Alarm (Watchdog) auslösen.

Hallo Senior,
danke für deine schnelle Antwort.
OK, ich könnte die logische 1 invertieren, so dass im Alarmfall eine 1 anliegt, und ansonsten eine Null. Dann frage ich statt dem Eingang einen Merker ab. Aber denkst du, dass man dem Merker trauen kann? Wie ich eingangs beschrieben habe, wird ja auch der Eingang I2, der logisch 0 ist, beim Auslesen durch Symcon im „Fehlerfall“ als eine „1“ gelesen. Also eigentlich kann man weder den einsen noch den Nullen trauen. Oder was meinst du?

Ich hab auch schon überlegt, einen Merker sekundenweise zu toggeln. Symcon würde dann merken, wenn der Merker zu lange gleich stehen bleibt. Aber bei der unregelmäßigen, langatmigen (alle 2000ms) Abfrage durch Symcon, könnte ich mir vorstellen, dass das scheitert… Höchstens mit einem erheblichen Aufwand (Symcon toggelt einen Merker - Logo toggelt daraufhin auch einen Merker - Symcon überprüft, ob die Logo getoggelt hat…). Ganz schöner Act…

Gibt es vielleicht einen Symcon-Flag, der anzeigt „Verbindung zur Logo via Ethernet OK“?

Oder eine andere Lösung?

Danke!
Gruß Fritz

Wenn der Clientsocket oder die SplitterInstanz ebenfalls die Verbindung verliert, kannst du über das Eventcontrol ein Script starten und z.b. selber so eine Variable setzen.

Alternativ kannst du auch per Intervall z.b. einen Wert per Script setzen oder auch lesen und den Rückgabewert des Befehls auswerten um zu erkennen daß die Funktion erfolgreich ausgeführt wurde, also die Logo verbunden ist.
Michael

ich habe das wie folgt gelöst:
Lebenszeichen LOGO



„Aber viele Wege führen nach Rom“