← Hauptseite für Robotik
← Hauptseite des Praktikums Produktionstechnik

Einführung

Das hier behandelte Projekt beschäftigte sich mit der Ansteuerung eines Delta Omron Adept Roboters der Firma Kuchenmeister. Dieser wurde im Rahmen einer Bachelorarbeit zu einem 3D-Drucker umfunktioniert. Ziel ist es die hohe Geschwindigkeit des Roboters zu nutzen, um 3D-Drucke schneller zu realsieren. Das Projekt wurde auf zwei Gruppen aufgeteilt. Gruppe 11 beschäftigte sich mit der für den 3D-Druck notwendigen Hard- und Software (Druckbettheizung, Extruder und Hot-End ansteuerung). Als Gruppe 12 war es unsere Aufgabe die bereits vorhandenen Software- und Hardwarekomponenten der vergangenen Bachelorarbeit zu ergänzen. Zielsetzung war die Ansteuerung des Roboters mit möglichst gleichmäßiger Geschwindigkeit. Näheres ist im Abschnitt Funktionsablauf zu finden.

Delta Omron als 3D-Drucker

Ausgangssituation

Bei der Übernahme war der 3D-Drucker vollständig konzipiert und aufgebaut. Lediglich eine variable Druckbetteinstellung fehlte bei diesem Aufbau. Die Verschaltung war ebenfalls vollständig. Die Software war nicht funktionstüchtig und das Druckbett war weder beschichtet noch einstellbar. Die Aufgabe war daher die Optimierung der Software, sowie die Konstruktion einer geeigneten Druckbettnivellierung.

Herausforderungen des Projektes

Die bereits vorhandene GUI und das dazugehörige MAtlab Skript wurde über den MAtlab App Designer realisiert. Um dieses nachvollziehen zu können war eine Einarbeitung in die Logik vom Matlab App Designer von Nöten. Die eigentliche Ansteuerung des Roboters erfolgte über das OMRON-eigene Programm ACE, welches sich der Programmiersprache eV+ bedient. Für das Verständnis bestehender Codes und deren Ergänzungen war auch hier intensive Einarbeitung notwendig. Für die Verbindung zwischen Matlab und ACE mussten wir uns zudem intensiv mit dem tcpip-Netzwerkprotokoll auseinandersetzen um nachvollziehen zu können, was eigentlich an ACE übergeben wird. Für die Druckbettnivellierung musste ein entsprechendes Konzept entwickelt werden.

Umsetzung

Im Folgenden werden detailliert die Schritte zur Umsetzung und Problemstellungen welche währendessen auftraten beschrieben.

Programmierung der Ansteuerung

Zur Ansteuerung des Roboters sind zwei Teilsysteme essenziell. Zum einen ist ein Programm-Code notwendig, der die Koordinaten für die X-, Y- und Z-Position aus dem G-Code extrahiert. Zum anderen braucht man noch eine Kommunikationsschnittstelle zwischen PC und Roboter bzw. Smart-Controller, damit die extrahierten Daten versendet werden können. Für die Extraktion der X-, Y- und Z-Koordinaten aus dem G-Code wurde bereits eine Grafische Benutzeroberfläche (GUI) mit dem MATLAB App-Designer entwickelt. Diese GUI ist in der Lage den G-Code in Strings zu splitten und die Positionskoordinaten an die Software des Smart-Controllers zu versenden. Dabei wird der vorher erstellte G-Code eingelesen, Zeile für Zeile abgearbeitet und die X-, Y-, Z-Koordinaten und G-Befehle extrahiert und in einen neuen String gespeichert. Dieser String wird dann über eine TCP-Schnittstelle an den Controller des Roboters gesendet.

TCP-Schnittstelle

Damit der Roboter angesteuert werden kann, muss er zuerst mit einem Smart-Controller verbunden sein. Dafür wurde der Adept Smart-Controller CX verwendet. Dieser ist über eine RJ-45 Ethernet Schnittstelle (LAN-Kabel) mit der Netzwerkkarte des PCs verbunden. Mit Hilfe einer TCP-IP(v4) Verbindung können dann die Daten vom Client zum Server und vom Server zum Client gesendet werden. Dabei wird der PC als Client und der Roboter als Server definiert. Als Verbindungs-IP wird die IPv4-Adresse des Controllers verwendet. Diese kann am Controller abgelesen werden und muss vor der Inbetriebnahme des Roboters in den Windows Netzwerkeinstellungen eingestellt werden.

Da der Hersteller des Roboters OMRON ist, wird auch deren Software Entwicklungsumgebung zur Ansteuerung des Roboters genutzt. Die Software, die hier verwendet wurde ist die Automation Control Environment oder auch kurz ACE genannt. Mit dieser Software ist man in der Lage den Roboter per Jog-Control (Hand) oder auch über einen Programm-Code zu steuern. In ACE wurde bereits ein Programm erstellt, welches die Daten dann über eine TCP-IP Verbindung von MATLAB empfängt und aus den Positionskoordinaten Verfahr-Befehle generiert.

TCP-Rückkanal

Leider wurde dies nur einseitig programmiert, sprich die Daten wurden nur in eine Richtung gesendet und der Roboter gab keine Rückmeldung, ob und wann er seine Position erreicht hatte. Das führte dann dazu, dass der Roboter zu schnell Daten empfangen hat und gar nicht erst losgefahren ist oder beim Verfahren der Positionen abgekürzt hat. Um das zu optimieren mussten wir einen Rückkanal in der Kommunikation zwischen PC und Roboter implementieren. Um das zu realisieren wurde in ACE eine neue Variable "move_status" angelegt und in die Bewegungs-Funktionen eingefügt. Diese Variable hat ein Boole'sches Verhalten wird beim Aufruf der Funktion bzw. beim Start der Roboterbewegung auf "1" gesetzt. Über den Befehl "BREAK" in ACE wird die Funktion so lange durchlaufen, bis die Endposition des aktuellen Verfahr-Befehls erreicht wurde. Sofort nach dem BREAK wird die Variable auf "0" gesetzt und über den Befehl "WRITE" an die TCP-Schnittstelle gesendet. Über die "waitfor()"-Funktion in MATLAB kann man dann den aktuellen Status der TCP-Verbindung abfragen und erneut Daten senden, sobald eine null empfangen wurde.

Probleme bei der Ansteuerung

Leider trat nach der erfolgreichen Implementierung der Bewegungsabfrage das nächste Problem auf. Bei zu hohen Geschwindigkeiten und zu kurzen Abständen zwischen den Positionskoordinaten fing der Roboter an zu stottern. Dies machte sich vor allem bei radialen Bewegungen bemerkbar, wie z.B. fahren eines Kreises. Denn bei jeder Position muss der Roboter durch die Bewegungsabfrage kurzzeitig anhalten und danach wieder beschleunigen. Über Tests wollten wir dann herausfinden, welche optimalen Parameter zur "ruckelfreien Fahrt" führen könnten. Dies führte dann leider dazu, dass der Roboter anfing zu streiken und die Fehler M2 bzw. M4 am Display ausgab. Höchstwahrscheinlich war das schnelle fahren und anhalten der Grund für diesen Fehler. Jedoch kann man behaupten, dass solche Industrieroboter in der Regel nicht anfällig für solche "Bewegungen" sein sollten. Nach stundenlanger Problemsuche, kamen wir dann zu dem Entschluss den Hersteller des Roboters, OMRON zu kontaktieren. Nach erfolgreicher Kontaktaufnahme gelang es uns dann den Fehler des Roboters durch hoch- und runterklappen der Achsen per Break-Release-Knopf zu beheben. Vorher mussten natürlich die Karbonarme demontiert werden, da man die Achsen ansonsten nicht bis an den Anschlag drehen kann. Danach war der Roboter wieder einsatzfähig und konnte wieder problemlos bedient werden.

Fahrtests

Durch die Kontaktaufnahme mit OMRON haben wir außerdem auch gelernt, dass man über den ACE-Befehl "ACCEL" die Beschleunigung und Entschleunigung des Roboters steuern kann. Der Wert der Beschleunigung gibt an, wie lange es dauert bis der Roboter seine Endgeschwindigkeit erreicht. Die Entschleunigung ist dasselbe wie eine negative Beschleunigung, also eine Bremsung, je höher der Wert, desto schneller und stärker bremst der Roboter ab.

Mit Hilfe eines selbst erstellten Skripts in MATLAB, haben wir dann den Roboter jedes Mal eine Kreisbewegung fahren lassen. Dabei haben sich folgende Tests ergeben:

Test Nr.	Positive Beschleunigung	Negative Beschleunigung	Ergebnis
1	50	0	Roboter fährt sehr langsam, bremst nach jeder Koordinate ab
2	50	25	Starkes Stottern erkennbar
3	50	50	Stottern erkennbar
4	50	75	Stottern erkennbar
5	50	100	Stottern erkennbar
6	50	200	Stottern erkennbar
7	100	10	Zittern erkennbar
8	100	25	Starkes Zittern erkennbar
9	100	50	Sehr starkes Zittern erkennbar
10	100	75	Sehr starkes Zittern erkennbar
11	100	100	Ursprungsproblematik

Durch die Tests ergab sich dann, dass Test Nummer 7 den besten Fahrverlauf hatte. Jedoch war das noch keine optimale Lösung, denn die Problematik des "Zitterns" bestand weiterhin. Deswegen bedarf es hier weiterhin Optimierungspotenzial.

Druckbettnivellierung

Eine Druckbettnivellierung ist notwendig, wenn das Druckbett durch mechanische oder thermische Belastung nicht mehr Eben ist. Dies hat beim Druck die Folge, dass die Schichten ungleichmäßig aufgetragen werden und das Aussehen wie auch die mechanische Eigenschaften des Werkstücks beeinträchtigt werden können. Im worst-case lösen sich die ersten Schichten durch mangelnde Haftung wodurch der Druck fehlschlägt. Die Bearbeitung der zu realisierenden Druckbettnivellierung lässt sich in 2 Abschnitt gliedern. Einerseits musste ein Konzept zu mechanischen Druckbetteinstellung erstelt werden. Anderseits sollte die Matlab GUI um eine Nivellierungssteuerung ergänzt werden.

Konzept

Der Großteil der handelsüblichen 3D-Drucker nutzt zur Druckbettnivellierung federgelagerte Druckbettverschraubungen. Über eine Rändelmutter lässt sich die Schraube lösen oder anziehen, wodurch sich das Druckbett senkt oder hebt. Eine Feder zwischen dem Schraubenkopf und dem Druckbett dient dabei als Lager für das Druckbett. Dieses Konzept haben wir an unseren Anwendungsfall angepasst.

Das bisher an Aluprofilen fixierte Druckbett soll ach rechts verschoben werden. Die vorhandenen Bohrungen können dadurch weitergenutzt werden und das verschobene Zentrum des Roboters wird dadurch ebenfalls leicht ausgeglichen. Zudem sollen so alle 9 Positionen der Schrauben gut erreichbar sein. An der Seite des Profils sollen 40x40mm Winkel angebracht werden, auf welchen das Druckbett lagern soll. Für die Auswahl der Federn wurde das Gewicht der Alu-Grundplatte, der Glasplatte sowie 2kG Zuschlag für das Druckerzeugnis einberechnet.

GUI

Um den Druckkopf auf eine der 9 Schrauben anzufahren, um dann das Druckbett in der Höhe anzupassen, wird eine Bedieneroberfläche benötigt. Somit wurde die bereits vorhandene Matlab GUI ergänzt. Der Bediener sieht 9 sog. Radio-Buttons, welche der geometrischen Anordnung der Schrauben entsprechen. Eine Nummerierung dieser Buttons soll den Bediener durch die Sternförmige Nivellierung führen. Hinter jedem Radio-Button verbirgt sich ein Gcode der entsprechende Positionen auf der Grundplatte darstellt. Über den Knopf "Anfahren" wird der Gcode an ACE versendet und der Druckkopf auf die Position gefahren.

Bisher sind nur die Endpositionen in Matlab hinterlegt. Für eine sicherere Nivellierung sollte noch folgender Pseudocode umzusetzten:

while ("Abbruch"-Button ==false) 
{
 wenn ("Anfahren"-Button==true) 
 {
  Hinterlegten XYZ Koordinaten auslesen und in Variable schreiben.
  Z schnell auf Höhe 100mm verfahren
  Ausgelesene XY Koordinaten anfahren
  Z langsam auf Höhe 1mm verfahren (hier Möglichkeit abzubrechen, falls Düse droht auf das Druckbett zu stoßen.)
 }
}

Tutorial zur Nutzung von Omron ACE

Hier zu finden sind Schritt für Schritt Anleitungen zur Nutzung des Jog-Controls von Ace und der Erstellung eines Beispielprogrammes mithilfe von ACE.

Abnahmetest

Einleitung

Dieser Artikel beschreibt den Inbetriebnahmeprozess des Delta Adept als 3D Drucker. Der hier aufgezeigt Abnahmetest erfolgte als Simulation über ACE 3.7. Zur prüfung vor Ort wurden Schritte eingefügt, welche für den realen Test notwendig sind.

Verwendete Daten

SVN-Projektarchiv: https://svn.hshl.de/svn/MTR_GPE_Praktikum/trunk/Fachthemen/Delta_Roboter_Adept_als_3DDrucker in Version 4322 Benötigte Software: ACE 3.7 ; Matlab R2022b

Der Testfall im Detail

Die Tabelle zu den Testfällen lässt sich über den Knopf "Ausklappen" anzeigen.

Bezeichnung: Abnahmetest
Erstellt von: Stanislawski , Kaczmarek
Erstellt am: 03.01.2023
Testinstanz: PC / ACE 3.7 (hier Emulator) / Matlab R2022b

Schritt Nr.	Beschreibung	Ausgangszustand	Aktion(en)	Erwartetes Ergebnis	Ergebnis	Bewertung	Bemerkung
Precondition 1	PC und Daten vorbereiten	PC ist aus, Kabel nicht eingesteckt, lokale Daten veraltet	Start des PCs, Update SVN Arbeitskopie (Pfad: https://svn.hshl.de/svn/MTR_GPE_Praktikum/trunk/Fachthemen/Delta_Roboter_Adept_als_3DDrucker) Revision 4322	Der PC ist hochgefahren, die Anlage betriebsbereit und alle benötigten Dateien aus dem SVN Repository sind lokal gespeichert	PC ist an, SVN-Ordner (siehe vorherige) ausgecheckt	i.O.
Precondition 2	Anlage hochfahren	Anlage ist aus	Hauptschalter am Schaltkasten umlegen	Anlage ist betriebsbereit, SmartController wird bestromt.	<in Simualtion nicht prüfbar>	-
Precondition 3	PC und SmartController über Ethernet verbinden	Ethernet Kabel nicht an PC angeschlossen	Ethernet Kabel (gelb) rückseitig am PC anschließen	Ethernet Kabel ist in PC eingesteckt	<in Simualtion nicht prüfbar>	-
Precondition 4	Matlab GUI und ACE 3D Druck Skript öffnen (nicht im Emulationsmodus) starten	Kein Programm geöffnet	Matlab GUI "START_GUI.mlapp" und ACE Skript "3D-Druck.BA.awp" öffnen. (siehe Bemerkung)	Matlab GUI ist geöffnet und das ACE Skript wird im normalen (nicht Emulationsmodus [Checkbox beim öffnen der Datei im Dialogfenster]) ausgeführt.	Matlab GUI ist geöffnet und das ACE Skript wird im normalen (nicht Emulationsmodus [Checkbox beim öffnen der Datei im Dialogfenster]) ausgeführt.	i.O	Matlab GUI: "Delta_Roboter_Adept_als_3DDrucker\03_Vorgehen nach V-Modell\05_Entwicklung\Programmierung\3D_Drucker\GUI\START_GUI.mlapp" ACE: "Delta_Roboter_Adept_als_3DDrucker\03_Vorgehen nach V-Modell\05_Entwicklung\Programmierung\ACEVplusProgamm\3D-Druck.BA.awp"
Precondition 5	Verbindung zwischen Matlab und ACE (SmartController) herstellen	Matlab und Ace geöffnet aber nicht verbunden	ACE: links im Worksapce Explorer "matlab.verb" aufklappen und auf "matlab.verb()" rechtsklick ->"Auf Task ausführen"-> "Task 0" Matlab: Schalter in der GUI auf "ACE" stellen und Schaltfläche "Verbinden" betätigen.	GUI gibt Rückmeldung "ReadyACE"	GUI gibt Rückmeldung "ReadyACE"	i.O
Precondition 6 (optional)	Druckbett nivellieren	Anlage ist einsatzbereit und Verbindung zu ACE ist hergestellt.	In der GUI die unteren Radio-Buttons in der mit den Zahlen vorgegeben Reihenfolge auswählen und jeweils "Anfahren" betätigen.Das Druckbett mit den Stellschrauben so einstellen dass ein Blatt Papier leicht kratzend zwischen Druckbett und Düse bewegt werden kann.	Roboter fährt Stellpositionen einzeln an und Druckbett kann an den jeweiligen stellen justiert werden.	Roboter führt keine Bewegung aus.	ni.O	Kommunikation zwischen MAtlab und ACE schlägt hier fehl. Druckbettnivellierung ist noch nicht vollständig ausgebaut.
Testschritt 1	Zu druckende Datei importieren	Anlage ist betriebsbereit und Verbindung zu Matlab hergestellt.	Gcode als Textdatei eintragen und auf "Import" drücken. Hier testweise eintragen_ "texthallo_kurz.txt"	GUI gibt Rückmeldung "Importende"	GUI gibt Rückmeldung "Importende"	i.O.
Testschritt 2	Druck starten	Datei ist importiert und Anlage betriebsbereit	Schaltfläche "Drucken" betätigen.	GUI gibt Rückmeldung "Drucken". Roboter bewegt sich.	GUI gibt Rückmeldung "Drucken". Roboter bewegt sich.	i.O
Postcondition 1	Anlage herunterfahren	Anlage läuft	Verbindung in der GUI trennen, Hauptschalter umlegen	SmartController aus.	<in Simualtion nicht prüfbar>	-
Postcondition 2	PC herunterfahren	PC läuft	Software Matlab und ACE schließen, PC abmelden	PC abgemeldet	PC abgemeldet	i.O.

Ansteuerung des Roboters für das Fahren mit möglichst gleichmäßiger Geschwindigkeit Fehlerfall mit Roboter beschreiben, dafür sinnvollen Ort heraussuchen und mit Prof. Göbel absprechen!

Bau eines 3D-FFF-Druckers mit Hilfe des Delta-Roboters Omron/Adept Quattro: Ansteuerung des Roboters

Inhaltsverzeichnis