Totmann-Schaltung

Ich hatte bereits beschrieben, dass man bei kritischen Komponenten die Funktion Einschaltdauer nutzen kann, damit die Technik bei Funkstörungen in einen definierten (sicheren) Zustand zurückfällt. An anderer Stelle hatte ich das Programm für meinen Rasenmäh-Roboter so erstellt, dass die Befehle von der CCU so lange gesendet werden, bis der gewünschte Zustand erreicht ist. Hier ist nun die Zusammenfassung beider Ideen.

Die Aufgabe weiterhin: Der Rasenmäher soll bei Regen nicht losfahren.

Mit dem bisherigen Programm war das nicht sichergestellt: Wenn der Abschaltbefehl trotz hektischer Versuche der CCU nicht ankommt, dann bleibt der Aktor eingeschaltet und der Mäher fährt los. Das gilt es um jeden Preis zu verhindern – und das ist keine leichte Aufgabe, denn der HM-LC-Sw2-FM zählt zu meinen eher unzuverlässigen Kandidaten.

Totmann-Schaltung

Als Totmann-Schaltung bezeichnet man ein Sicherheitssystem, das eine Maschine oder ähnliches automatisch abschaltet, wenn nicht regelmäßig durch einen Bediener eine Aktion durchgeführt wird.

Beispiele sind etwa Spielzeug-Drohnen, die bei Abriss des Funkkontakts selbstständig ihre Position halten oder sanft landen. In etwas größerem Maßstab gibt es das auch bei der Bahn: Drückt der Triebfahrzeugführer nicht regelmäßig einen Knopf, ertönt ein Alarmsignal und der Zug wird gestoppt.

Das Programm auf dieser Seite ist also eigentlich keine Totmann-Schaltung, sondern eher eine Tot-CCU-Schaltung: Wenn die CCU stirbt (oder zumindest nicht erreichbar ist), bleibt der Mähroboter stehen.

Voraussetzungen

Für das Programm brauche ich natürlich eine Regenerkennung. Die Regenerkennung hatte ich bereits im Zusammenhang mit dem Langzeit-Timer beschrieben. Diese ist unverändert: Wenn der Kombisensor „Regen“ erkennt, wird ein Zähler hochgesetzt, der dann stündlich reduziert wird.

Für mein Programm bedeutet das, dass die Ladestation ausgeschaltet werden soll, wenn die Systemvariable Rasenmaeher Regen größer als 0 ist.

Die zweite Voraussetzung – wie immer – ist eine Systemvariable.

Auch diese hatte ich schon beim vorherigen Programm angelegt.

Der Rasenmäher mäht bei mir von 16:00 bis 17:00 – wenn er denn darf. Diese Zeit ist am Gerät selbst einprogrammiert.

Systemvariable schalten

Die Systemvariable wird zeitgesteuert durch zwei WebUI-Programme geschaltet.

Das erste Programm prüft, ob es um 15:45 regnet oder ob ich abwesend bin.

Bei Regen oder Abwesenheit wird Rasenmaeher Laden auf aus gesetzt – die weiteren Programme sorgen dann dafür, dass rechtzeitig vor 16:00 der Strom zur Ladestation gekappt wird.

Kein Strom – Rasenmäher fährt nicht.

Das Programm startet ausschließlich zum Zeitpunkt, der im Zeitmodul eingestellt ist. Die restlichen Bedingungen stehen auf nur prüfen: Wenn es anfängt zu regnen oder ich das Haus verlasse, soll der Ladestrom nicht abgeschaltet werden, damit der Rasenmäher nicht irgendwo auf dem freien Feld stehenbleibt.

Das zweite Programm schaltet jeden Tag um 17:15 den Strom über die Systemvariable wieder ein.

Um diese Zeit ist das Programm des Rasenmähers auf jeden Fall beendet, so dass er in seine Station zurückkehrt und bis zur nächsten Startzeit geladen werden kann.

Ladestation schalten

Das Programm für die Ladestation besteht aus zwei Teilen.

Die erste Wenn … -Bedingung reagiert darauf, dass Rasenmaeher Laden auf ein steht.

Zunächst wird die Einschaltdauer auf 11 Minuten gesetzt und dann die Ladestation eingeschaltet.

Mit 307 Sekunden Verzögerung (also 5 Minuten + 7 Sekunden) wird Rasenmaeher Laden erneut auf ein gestellt. Weil bei der Bedingung bei Aktualisierung auslösen ausgewählt ist, startet sich das Programm alle fünf Minuten immer wieder selbst.

Geht ein Schaltbefehl wegen einer Funkstörung verloren – kein Problem. Geht ein zweiter verloren, schaltet sich kurz darauf die Ladestation sicherheitshalber aus.

Die 307 Sekunden dienen dazu, die Schaltbefehle zu entzerren – und um Kollisionen zu vermeiden, wenn die Systemvariable über das Zeitmodul exakt zum Minutenwechsel gesetzt wird.

Wichtig ist auch der Haken bei Vor dem Ausführen alle laufenden Verzögerungen … beenden. Wird er nicht gesetzt, dann schaltet das Programm die Systemvariable immer wieder auf ein, auch wenn zwischenzeitlich ein anderes Programm sie auf aus gesetzt hatte. Das wollen wir definitiv nicht.

Der zweite Sonst wenn … -Teil reagiert entsprechend darauf, dass Rasenmaeher Laden auf aus steht.

Wird die Systemvariable gesetzt, wird sofort die Verzögerung für den ersten Teil unterbrochen (wegen des Hakens) und der zweite Teil ausgeführt.

Im zweiten Teil wird der Aktor sofort ausgeschaltet und wieder gut fünf Minuten später die Systemvariable gesetzt, so dass das Programm sich selbst aufruft. Eine Einschaltdauer braucht es hier nicht: aus ist aus.

Auch hier wieder der Haken bei Vor dem Ausführen alle laufenden Verzögerungen … beenden.

Protokoll

Ich habe mal die Protokollierung für meine Systemvariable und den Aktor eingeschaltet.

Zu erkennen ist, wie bis 15:45 die Systemvariable immer wieder auf ein gesetzt wird, so dass das Programm sich selbst auslöst und wiederum den Aktor schaltet, der seinen Schaltzustand: ein zurückmeldet.

Um 15:45 wird die Systemvariable auf aus gesetzt – das Programm schaltet sofort den Aktor aus und beginnt von jetzt an, sich für den Zustand aus wieder selbst zu starten.

Im Protokoll ist auch noch zu erkennen, dass ich bei meinem ersten Versuch einen Kardinalfehler begangen habe: Die Verzögerung, mit der das Programm sich selbst aufruft, war auf exakt 5 Minuten eingestellt. Damit besteht die Gefahr, dass der Zeitpunkt für die Ausführung genau mit dem Zeitpunkt eines der Zeitmodule übereinfällt, mit denen die anderen Programme die Systemvariable setzen.

Um das zu verhindern, habe ich die Zeit dann auf 307 Sekunden geändert.