Befehlskette Version 3.2

Versionsdaten

Ziel der Version

Version 3.2 erweiterte die Befehlskette von reinen Bewegungsabläufen zu einfachen Pick-and-Place-Abläufen. Neben den PTP-Bewegungen konnten jetzt auch der Sauger geschaltet und sein Pumpenschaltzustand ausgegeben werden.

Neue Befehle

("sauger_ein", "Sauger einschalten", 1000)
("sauger_aus", "Sauger ausschalten", 500)
("sauger_status", "Saugerstatus anzeigen", 0)

• sauger_ein schaltet Pumpe und Ventil über SetEndEffectorSuctionCup(..., isQueued=1) ein.
• sauger_aus schaltet den Sauger als Queue-Befehl aus.
• sauger_status liest den aktuellen Pumpenschaltzustand mit GetEndEffectorSuctionCup().

Änderungen an der Befehlsverarbeitung

• Bewegungs- und Saugerbefehle werden getrennt eingelesen, geprüft und anschließend einheitlich in interne Befehlsdaten umgewandelt.
• Bewegungsbefehle dürfen weiterhin sechs oder sieben Einträge besitzen.
• Saugerbefehle dürfen in einer kurzen, mittleren oder vollständigen Form angegeben werden: nur Name, Name plus Text oder Name plus Text und Pause.
• Unbekannte Befehlsnamen und falsche Parameterzahlen führen zu verständlichen Fehlermeldungen.
• Die Queue-Anzeige stellt Bewegungs- und Saugerbefehle in derselben nummerierten Folge dar.
• Die Tastatursteuerung aus Version 3.1 bleibt vollständig erhalten.

Besonderheit des Befehls sauger_status

GetEndEffectorSuctionCup() ist kein Queue-Befehl. Die Abfrage kann deshalb nicht direkt an einer bestimmten Stelle in die Dobot-Queue eingefügt werden.

Als zeitliche Markierung wird ein kurzer WAIT-Befehl von 500 ms eingetragen. Sobald dessen Queue-Index erreicht ist, liest Python den Saugerstatus und gibt ihn einmalig aus.

Beispielhafter Ablauf

befehle = [
    ("fahre_zu", 180, 160, 50, 0, "Fahre zu Punkt 1"),
    ("sauger_ein", "Sauger einschalten", 1000),
    ("sauger_status", "Status nach dem Einschalten anzeigen", 0),
    ("fahre_zu", 240, 140, 70, 0, "Fahre zu Punkt 2", 2500),
    ("sauger_aus", "Sauger ausschalten", 500),
    ("sauger_status", "Status nach dem Ausschalten anzeigen", 0),
]

Bekannte Probleme und Grenzen

• Die Statusabfrage ist nur über einen Queue-Marker zeitlich angenähert, weil die eigentliche Abfrage nicht queuefähig ist.
• Der Saugerstatus ist kein Vakuum- oder Werkstücksensor.
• Ein Alarm oder Timeout beendet den normalen Ablauf weiterhin über einen Fehler. Eine sichere Nachbehandlung innerhalb desselben Programms fehlt noch.
• Nach einem Halt oder Alarm bleibt die Verantwortung für das Ausschalten des Saugers und die sichere Roboterposition beim Bediener beziehungsweise beim äußeren Programm.
• Die externe Steuerung über ESP32 oder Netzwerk ist noch nicht enthalten.

Bedeutung für die weitere Entwicklung

Mit Version 3.2 war die Befehlskette erstmals für einen vollständigen einfachen Transportablauf geeignet: anfahren, ansaugen, verfahren, ablegen und Saugerstatus kontrollieren.