Befehlskette Version 3.2.1

Versionsdaten

Auslöser der Erweiterung

In Version 3.2 führte ein Alarm während der Befehlsausführung zu einer Ausnahme und damit zu einem abrupten Ende des normalen Programmlaufs. Für einen Roboter mit aktivem Sauger oder ungünstiger Armposition war das nicht ausreichend.

Änderungen und Erweiterungen

• Die fehlerhafte Queue wird sofort gestoppt und anschließend vollständig gelöscht.
• Die alte Befehlskette kann nach einem Alarm oder Halt bewusst nicht fortgesetzt werden.
• Aktive Alarmnummern werden aus den Alarmbytes ermittelt und dezimal sowie hexadezimal angezeigt.
• Das Programm versucht, gespeicherte Alarmzustände zu löschen, prüft aber anschließend erneut, ob die Ursache weiter besteht.
• Die aktuelle kartesische Position wird im Fehlerbetrieb ausgegeben.
• Der Saugerstatus wird sofort angezeigt.
• Eine vorgegebene sichere Ausgangsposition kann im Beispielprogramm festgelegt werden.
• Sofortfahrten werden überwacht: Zielprüfung, Alarmprüfung und Timeout.
• Für die Zielprüfung gelten 1 mm Positionstoleranz und 2° Rotationstoleranz.
• Der Timeout für eine Sofortfahrt beträgt standardmäßig 30 Sekunden.

Fehlerbetriebsmenü

1 = Zu frei gewählten Koordinaten fahren
2 = Zur vorgegebenen Ausgangsposition fahren
3 = Saugerstatus anzeigen
4 = Sauger sofort ausschalten
5 = Programmende, wenn der Sauger AUS ist
9 = Programmende trotz aktivem Sauger erzwingen
? = Menü erneut anzeigen

Das Menü verwendet weiterhin die Tastatureingabe-Queue. Alte Eingaben werden vor dem Fehlerbetrieb verworfen, damit ein früherer Steuerbefehl nicht versehentlich als Menüauswahl interpretiert wird.

Sicherheitsentscheidungen

• Ein Programmende über Menüpunkt 5 ist nur möglich, wenn der Sauger ausgeschaltet ist.
• Menüpunkt 9 erlaubt ein erzwungenes Ende und macht die verbleibende Verantwortung ausdrücklich sichtbar.
• Eine Sofortfahrt wird nicht einfach als beendet betrachtet; die aktuelle Pose muss innerhalb der festgelegten Toleranzen liegen.
• Tritt während einer Sofortfahrt erneut ein Alarm auf, wird auch diese Bewegung abgebrochen.
• Die fehlerhafte ursprüngliche Queue bleibt verworfen und kann nicht wieder gestartet werden.

Bekannte Probleme und Grenzen

• Der Fehlerbetrieb erhöhte den Umfang und die Komplexität des Moduls deutlich.
• Das Löschen eines Alarmzustands beseitigt nicht automatisch dessen mechanische oder geometrische Ursache.
• Eine eingegebene freie Zielposition kann außerhalb des sicheren Arbeitsbereichs liegen; der Bediener muss die Koordinaten beurteilen.
• Die Verbindung bleibt zwar bestehen, aber der Fehlerbetrieb ist weiterhin rein tastaturgeführt.
• Ein sicherer Zustand kann nicht in jeder mechanischen Lage automatisch hergestellt werden.
• Der Funktionsumfang war für Schüler schwerer zu überblicken als die ursprüngliche lineare Befehlskette.

Bedeutung für die weitere Entwicklung

Version 3.2.1 zeigte, dass neben der normalen Ablaufsteuerung auch ein bewusstes Fehlerkonzept benötigt wird. Gleichzeitig wurde deutlich, dass Sicherheitsfunktionen und didaktische Übersichtlichkeit gegeneinander abgewogen werden müssen.