E 12.03.01.1 MAN Kap12 A01 ROB Allgemeinteil 171010 de PDF

Standarddokumentation für Anlagen im Karosseriebau
Kapitel 12.1 Robotertechnik-Allgemeinteil

Standard
Electrics
BP V2.0
Robotertechnik-Allgemeinteil
(A01_PLC)
Kuka-Roboter mit Steuerung KRC4
Erstellt: A. Ermer, S. Rüdiger

Erstellungsdatum: 28.01.2013
Letzte Änderung: 10.10.2017
Version: 1.14
Sprache: deutsch
Weitere Sprachen: englisch, spanisch
Gültigkeit besitzt immer die „deutsche“ Version!
MAN_Kap12_A01_ROB_Allgemeinteil_171010_de.docx
© Alle Rechte bei BMW AG, auch für den Fall von Schutzrechtsanmeldungen.
Jede Verfügungsbefugnis, wie Kopier- und Weitergaberecht, obliegt der BMW Group.
Seite 1 von 75
Standard
Electrics
BP V2.0
Inhaltsverzeichnis Kap 12.1

Inhaltsverzeichnis Kap 12.1 ..................................................................................................................... 2
Änderungsdokumentation: ....................................................................................................................... 4
12.1.1 Allgemeine Themen ......................................................................................................... 5
12.1.1.1 Zweck ................................................................................................................................ 5
12.1.1.2 Bewegungsbefehle ........................................................................................................... 6
12.1.1.3 Lastdatenermittlung .......................................................................................................... 6
12.1.1.4 Justage-Offset lernen ....................................................................................................... 7
12.1.1.5 Tool und Base-Daten ........................................................................................................ 7
12.1.1.6 Energiezuführung ............................................................................................................. 7
12.1.1.7 Sprache ............................................................................................................................. 7
12.1.1.8 Dokumentierung................................................................................................................ 8
12.1.1.9 Datensicherung ................................................................................................................. 8
12.1.1.10 Dateien für die BMW Standardanwendung ...................................................................... 8
12.1.1.11 Kopieren von Programmen und Dateien .......................................................................... 8
12.1.1.12 Passwörter ........................................................................................................................ 8
12.1.1.13 Abnahme........................................................................................................................... 8
12.1.1.14 Zuordnung der Tätigkeiten ................................................................................................ 9
12.1.2 Prozessdaten (E/A-Bereiche) ........................................................................................ 11
12.1.3 Sicherer Roboter, Safe Operation ................................................................................. 12
12.1.3.1 Allgemein ........................................................................................................................ 12
12.1.3.2 Funktionen ...................................................................................................................... 12
12.1.3.2.1 Zellenbereich ................................................................................................................ 13
12.1.3.2.2 Überwachungsräume ................................................................................................... 13
12.1.3.2.3 Sichere Werkzeuge ...................................................................................................... 13
12.1.3.2.4 Achs-, Raum- und kart. Geschw. und sicherer Betriebshalt ........................................ 16
12.1.3.2.5 Bremsentest ................................................................................................................. 16
12.1.3.2.6 Justagereferenzierung .................................................................................................. 16
12.1.3.2.7 Anhaltewege ................................................................................................................. 17
12.1.3.3 Grundeinstellungen ......................................................................................................... 18
12.1.3.4 Mit geltende Dokumente ................................................................................................. 22
12.1.4 Programme, allgemein ................................................................................................... 23
12.1.4.1 Programmstruktur ........................................................................................................... 23
12.1.4.2 Ablagestruktur ................................................................................................................. 24
12.1.4.3 Zuordnungstabelle Programm-Nummern ....................................................................... 25
12.1.4.4 Test des Programmablaufs ............................................................................................. 26
12.1.5 Programme, Detail ......................................................................................................... 27
12.1.5.1 Programm: CELL ........................................................................................................... 27
12.1.5.2 Anwenderprogramme ..................................................................................................... 28
12.1.5.3 Organisationsprogramme ............................................................................................... 29
12.1.5.4 Wartungsprogramm ........................................................................................................ 29
12.1.5.5 Applikationsspezifische Programme ............................................................................... 30
12.1.5.6 Serviceprogramme ......................................................................................................... 30
12.1.5.7 Abbruchprogramme ........................................................................................................ 30
12.1.5.8 Standardprogramme ....................................................................................................... 30
12.1.6 Variablen und Datenlisten ............................................................................................... 31
Seite 2 von 75
Standard
Electrics
BP V2.0
12.1.6.1 Kuka-System-Datenliste: $config.dat ............................................................................. 31

12.1.6.2 Standplatzspezifische Datenliste: A01_plc_User.dat .................................................... 31
12.1.6.3 Applikationsspezifische Datenliste: Axx_yyy_User.dat ................................................. 31
12.1.6.4 Applikationsspezifische Positionsdatenliste: Axx_yyy_global.dat ................................. 31
12.1.7 Home-Stellungen ........................................................................................................... 32
12.1.7.1 Home-Konfiguration ........................................................................................................ 32
12.1.8 Initialisierungskonzept ................................................................................................... 33
12.1.9 Job`s .............................................................................................................................. 35
12.1.9.1 Job: Konzeptbild ............................................................................................................. 35
12.1.9.2 Job: Programmbefehl ..................................................................................................... 36
12.1.9.3 Job: komplexe Beispiele ................................................................................................. 42
12.1.10 Area´s ............................................................................................................................. 44
12.1.10.1 Area: Konzeptbild ........................................................................................................... 44
12.1.10.2 Area: Programmbefehl .................................................................................................... 45
12.1.10.3 Area: komplexes Beispiel ............................................................................................... 50
12.1.11 Kollisionsschutz ............................................................................................................. 51
12.1.11.1 Kollisionsschutz: Konzeptbild ......................................................................................... 51
12.1.11.2 Kollisionsschutz: Programmbefehl.................................................................................. 52
12.1.12 Userkommunikation ....................................................................................................... 56
12.1.12.1 Userkommunikation: Konzeptbild ................................................................................... 56
12.1.12.2 Userkommunikation: Programmbefehl ........................................................................... 57
12.1.13 Typ-Nummer / User-Nummer ...................................................................................... 63
12.1.13.1 Typ- / User-Num senden ............................................................................................... 63
12.1.13.2 Typ- / User-Num senden, erstmalig nach JobRequest Anforderung............................. 63
12.1.13.3 Typ-Nummer / User-Nummer anfordern ........................................................................ 64
12.1.13.4 Undefinierter Nummernbereich....................................................................................... 65
12.1.13.5 Beispielprogramm ........................................................................................................... 65
12.1.14 Programmabbruch ......................................................................................................... 66
12.1.14.1 Programmabbruch: Konzeptbild ..................................................................................... 66
12.1.14.2 Programmabbruch: Roboter in Home-Stellung: ............................................................. 67
12.1.14.3 Programmabbruch: Roboter in keiner Home-Stellung:................................................... 67
12.1.14.4 Programmabbruch: Abortprogramme ............................................................................. 68
12.1.14.5 Programmabbruch: komplexes Beispiel ......................................................................... 69
12.1.15 „CheckHome“ und „Rehome“.......................................................................................... 71
12.1.15.1 Funktion „CheckHome“ ................................................................................................... 71
12.1.15.2 „CheckHome“ mit der Funktion „Rehome“ ...................................................................... 72
12.1.16 Sonstige Funktionen ....................................................................................................... 73
12.1.16.1 Stopp am Prozesspunkt .................................................................................................. 73
12.1.16.2 Controlled Stop ............................................................................................................... 73
12.1.16.2.1 Controlled Stop: Programmbefehl ........................................................................... 73
12.1.16.3 Verriegelung bei Mehrfachanfrage gleicher Area´s und Coll-Zonen .............................. 74
Seite 3 von 75
Standard
Electrics
BP V2.0
Änderungsdokumentation:
Datum Thema Bemerkung Name

10.10.2013 Kap. 12.1.15. Neues Kapitel eingefügt, Stopp am Pro- Ermer /
zesspunkt und Controlled Stopp ergänzt Ruediger
21.10.2013 Kap. 12.1.4 Übersichtsbild Ordnerstruktur angepasst Ermer /
Ruediger
28.10.2013 Kap. 12.1.2 EA-Anbindung an den Masterbereich er- Ermer /
gänzt Ruediger
28.10.2013 Kap. 12.1.4.3 Detaillierung „Job-Bezug“ eingefügt Ermer /
Ruediger
21.11.2013 Kap. 12.1.4 Übersichtsbild Ordnerstruktur nochmals ge- Ermer /
ändert Ruediger
21.11.2013 Kap. 12.1.5.4 Beschreibung Wartungsprogramme geän- Ermer /
dert Ruediger
21.02.2014 Kap. 12.1.13.2 Kap. Typ- / User-Num senden, erstmalig Ermer /
nach JobRequest Anforderung eingefügt. Ruediger
21.02.2014 Kap. 12.1.1.11 Zuordnung der Tätigkeiten detaillierter be- Ermer /
schrieben Ruediger
21.02.2014 Kap.12.1.15.3 Mehrfachanfrage Request-Befehle be- Ermer /
schrieben Ruediger
06.06.2014 Kap.12.1.4.1 Programmstruktur, Beschreibung ergänzt, Ermer /
Beispiel-Bild geändert Ruediger
02.12.2014 Kap. 12.1.3 Kapitel Sicherer Roboter komplett neu Ermer /
Ruediger
31.03.2015 Kap. 12.1.15.2.1 ILF Controlled Stopp hinzugefügt Ermer /
Ruediger
07.08.2015 Kap.12 Einarbeitung Themen Infoveranstaltung Ermer /
(Umlaute, Serviceprogramme, Controlle- Ruediger
dStop)
16.11.2015 Purpose, Weitere Informationen und Einzelheiten hin- Garrett
Datensicherung zugefügt
BMW Standard Application
files
Anwenderprogramme
04.12.2015 Kap. 12.1.9 JobRequest Funktion „AnyJob“ ergänzt Ermer
Kap 12.1.9 Job Beispiel Beispiele ergänzt
29.01.2016 CheckHome & Rehome Funktion „CheckHome & ReHome“ Garrett
06.04.2016 Kap. 12.1.3.2.3 Hinweis auf richtige Anwendung Safe-Tool Rüdiger
bei Sonderfällen (z.B. Mobifräser)
08.12.2016 Kap. 12.1.4.1/ 12.1.7 Homekonzept eindeutiger beschrieben Rüdiger
09/18/17 Kap. 12.1.1.2 CD added
09/28/17 Kap. 12.1.14.2/ 12.1.14.3 Satz Initialisierung gelöscht da falsch Rüdiger
10/10/17 Kap. 12.1.9.1 Job Konzeptbild aktualisiert Rüdiger
Seite 4 von 75
Standard
Electrics
BP V2.0
12.1.1 Allgemeine Themen
Die Richtlinien für Aufstellung, Handhabung und Programmierung der Roboterspezifikation

„SPEZ_Kap_04_Roboter_xxxxxx.pdf“ sind einzuhalten.
Der Anlagenlieferant ist verpflichtet qualifizierte Roboterprogrammierer einzusetzen.

Die Anforderungen der Technologie Karosserierohbau zur Qualifizierung sind der Elektrospezifika-
tion für Anlagen im Karosseriebau (MAN_Kap12_01_ROB_Allgemeinteil_160218_de.docx) zu ent-
nehmen
12.1.1.1 Zweck
Die in diesem Dokument beschriebenen Regeln, Richtlinien und Konzepte sind zu beachten
und anzuwenden, um sicherzustellen, dass alle Standards und Konzepte eingehalten wer-
den.
Das vorliegende Dokument enthält keine anwendungsspezifischen Anforderungen, da diese

im spezifischen „Dokument für Anwendungsstandards“ beschrieben werden.
Die Systemlieferanten und Roboterprogrammierer sind verpflichtet, alle im BMW Standard

angegebenen Anforderungen zu erfüllen und alle offenen Fragen an das verantwortliche
BMW Roboterprojekt „GEL“ weiterzuleiten.
Die Dokumentation des Standards soll Benutzern Anweisungen, Richtlinien, Beispiele, Erläu-
terungen und Lösungen zu allen Roboterproblemen in Bezug auf den BMW Standard bereit-
stellen.
Die Einhaltung des Standards ist eine maßgebliche Voraussetzung für die finale Abnahme.
Überblick Für wen ist dieses Dokument bestimmt?

Dieses Dokument für den Standard ist „dy- Alle Roboterprogrammierer und Code-Ent-
namisch“, d. h., es wird kontinuierlich aktua- wickler, die für oder im Namen von BMW
lisiert, angepasst und verbessert. Es wer- arbeiten, müssen sich an diesen Standard
den regelmäßig Updates auf den BMW Ser- halten.
ver freigegeben. Systemlieferanten sind an-
gehalten, immer mit der aktuellen Version
zu arbeiten und wichtige Informationen an
die entsprechenden Personen weiterzulei-
ten.
Seite 5 von 75
Standard
Electrics
BP V2.0
12.1.1.2 Bewegungsbefehle
Es sind ausschließlich die Bewegungsbefehle PTP, LIN, CIRC sowie die applikationsspezifischen Be-
wegungsbefehle freigegeben. Die neuen Befehle (NewMotion) sind im Projekt G1x/G3x nicht zugelas-
sen und dürfen nicht verwendet werden!
Die Funktion Collision Detection (CD) ist nicht freigegeben und darf nur nach Rücksprache und Bestä-
tigung der BMW Fachstelle verwendet werden!
12.1.1.3 Lastdatenermittlung
Vor der Programmierung muss für jedes Werkzeug und jedes Bauteil eine Lastdatenermittlung
(Masse, Schwerpunkt und Trägheitsmomente) am realen Roboter durchgeführt werden.
Ausgenommen sind kleine Bauteile, die im Bezug zur Robotertraglast keinen signifikanten Einfluss
haben auf das Bewegungsverhalten haben. (Kleinteile mit <= 2% der Nennlastlast)
Die benötigte Softwareoption ist im Lieferumfang enthalten. (Hauptmenü > Inbetriebnahme > Ver-
messen > Werkzeug > Werzeuglastdaten)
Der Roboter muss jederzeit (u.a. auch in den Home-Positionen) mit diesen, real ermittelten Daten
betrieben werden. Grundsätzlich muss der Anlagenlieferant sicherstellen dass der Roboter zu keinem
Zeitpunkt überlastet wird.
Wird bei der Lastdatenermittlung festgestellt, dass der Roboter überlastet ist, muss dies unverzüglich
an die zuständige Fachstelle bei BMW gemeldet werden.
Hinweis: Sollten zu Beginn der Programmierung am realen Roboter falsche Gewichtsdaten verwen-
det werden kann es wegen der Funktion „Absolutgenauigkeit“ zu Punktversatz kommen.
Seite 6 von 75
Standard
Electrics
BP V2.0
12.1.1.4 Justage-Offset lernen

Bei der Erstinbetriebnahme wird der Roboter von einem KUKA-Service-Mitarbeiter justiert, dabei darf
kein Werkzeug am Roboterflansch montiert sein.
Nach Anbau der Werkzeuge muss der Programmierer die Funktion „Justage-Offset lernen“ für jedes
Werkzeug (inkl. aller Werkzeuge die über Wechsler gedockt werden), durchführen.
Die Konstellation, Bauteil im Handling, braucht nicht separat berücksichtigt werden.
Hinweis: Es ist zu berücksichtigen, dass in der Justage-Position genügend Bewegungsfreiheit pro

Achse vorhanden ist, um eine Komplett-Justage (inkl. verschiedener Werkzeug) durchführen zu kön-
nen. In Einzelfällen ist es zulässig, wenn die Achsen 1+7 an einer anderen Stelle justiert werden. Die
Achsen 2 bis 6 müssen immer an der gleichen Position justiert werden!
12.1.1.5 Tool und Base-Daten

Grundsätzlich sind alle Programme im Fahrzeugkoordinatensystem zu erstellen. Alle Tool-Werte (z.B.
Roboterzange, Handling) sind als 6-D Daten aus dem Offline-Simulationssystem zu übernehmen. Alle
Base-Werte (z.B. Werkzeugplatte, externe Zangen) sind aus den Daten der Zellenvermessung zu
übernehmen. Die Vorgehensweise ist in der „Richtlinie_Geosim_OLZP“ beschrieben.
Es stehen 128 Tool-Datensätze und 128 Base-Datensätze zur Verfügung. Die detaillierte Zuordnung
befindet sich in der Datei „LIST_yymmdd_Roboterschnittstelle_BP_V2.0.xlsx unter Mappe
„Tool+Base Zuordnung“. Diese Zuordnung muss eingehalten werden.
12.1.1.6 Energiezuführung
Der Roboter wird mit einer standardmäßigen Einstellung der Energiezuführung ausgeliefert. Im Vor-
feld muss mit einem Simulationssystem eine optimale Einstellung ermittelt werden. Die Einstellung
der Energiezuführung hat vor Programmierbeginn mit den in der Simulation ermittelten Daten zu er-
folgen. Der Anlagenlieferant hat die Pflicht die Einstellung so zu optimieren das eine maximale Le-
bensdauer gewährleistet ist. Kollisionen und überschreiten des Biegeradius müssen ausgeschlossen
sein. Es dürfen nur die standardmäßigen Befestigungselemente (unverändert) verwendet werden. Die
Einstellung bzw. die Optimierung der Energiezuführung wird vom Roboterlieferanten abgenommen.
Eine erfolgreiche und dokumentierte Abnahme ist Teilvoraussetzung für die Erreichung der Anlagen-
Endabnahme.
12.1.1.7 Sprache
Alle Texteingaben (Beschreibungen/Kommentare usw.) müssen in der Muttersprache des betref-
fenden Werkes ausgeführt werden. (China in Englisch)
In jedem Anwenderprogramm muss ein Programmkopf mit folgenden Informationen beinhaltet und
bis zur Übergabe gepflegt werden.
 Programmbeschreibung
 Name der Firma
 Name Ersteller
 Datum der Erstellung
 Änderungsverlauf
Zum besseren Verständnis sind an wichtigen Programmstellen Kommentare einzufügen.

Achtung: Bei Verwendung externer Editoren muss das Format ANSI eingestellt sein!
Es dürfen keine Umlaute verwendet werden!
Seite 7 von 75
Standard
Electrics
BP V2.0
12.1.1.8 Dokumentierung
Die Dokumentierung sämtlicher Daten hat im RobotWorkbook (Roboterdokumentation) zu erfolgen.
12.1.1.9 Datensicherung
Die Verantwortung für die Datensicherheit obliegt, bis zur Übergabe, dem Roboterprogrammierer. Die
Datensicherung des Robotersystems erfolgt generell in Form eines Archives. Dadurch ist sicherge-
stellt, dass nach einem Datenverlust, das System wieder komplett hergestellt werden kann!
Die Daten müssen nach dem gültigen Datenarchivierungskonzept über das Netzwerk gesichert wer-
den. Für Inbetriebnahme bzw. Störfälle ist eine temporäre Sicherung oder Wiederherstellung des
Systems über USB bzw. WorkVisual möglich.
Die Ersteller von Befehlszeilen, SE-Partner und Programmierer müssen sicherstellen, dass Software-
code für die Inbetriebnahme, Kommentare, temporäre Deklarationen, nicht mehr verwendeter Code
usw. vor der Abnahme entfernt werden. Dazu gehören auch Programme, temporäre Kopien von Rou-
tinen, zusätzliche Backups des Roboterspeichers, die während der Programmierung oder Inbetrieb-
nahme generiert werden, sowie Daten, die als Teil der Offlineprogrammierung (OLP) bereitgestellt
wurden.
Achtung:
Ein Archiv beinhaltet neben den Anwenderdaten auch Standard.- bzw. Systemdaten. Der Roboter-
programmierer ist verantwortlich dass diese Daten nicht gelöscht bzw. geändert werden.
Insbesondere nach einem Standardupdate ist darauf zu achten, dass kein komplettes Archiv wieder-
hergestellt wird.
12.1.1.10 Dateien für die BMW Standardanwendung

Systemlieferanten, Programmierern und SE-Partnern ist es untersagt, Änderungen an den Quellcode-
dateien für die BMW Standardanwendung vorzunehmen.
Systemlieferanten, Programmierer und SE-Partner dürfen zudem keine Systemdateien hinzufügen oder
entfernen, es sei denn, dies ist von der Dokumentation des Standards vorgesehen oder wurde vom
entsprechenden BMW Roboterprojekt „GEL“ genehmigt.
12.1.1.11 Kopieren von Programmen und Dateien

Das Kopieren und Übertragen von Programmen, Routinen, Konfigurationen, Parametern usw. von ei-
nem Roboter zu einem anderen ist nicht zulässig. Dadurch soll verhindert werden, dass Fehler in den
Originaldaten zu anderen Robotern ohne Wissen des Benutzers übertragen werden. Dies kann sich
auf zukünftige Updates oder Änderungen an der Software negativ auswirken.
Das erste Roboter-Backup, das vom Roboterlieferanten als Teil der ersten Inbetriebnahme bereitgestellt
wird, enthält eindeutige Daten für diesen Roboter. Deshalb darf keinesfalls ein vollständiges Backup
von einem anderen Roboter wiederhergestellt werden.
12.1.1.12 Passwörter
Die aktuell gültigen Passwörter können bei Bedarf in der Fachstelle Robotertechnik nachgefragt werden.
Passwörter dürfen vom Anwender nicht verändert werden!
12.1.1.13 Abnahme
Die Einhaltung des Standards ist eine Teilvoraussetzung für die Abnahme. Die standardmäßig einge-
stellten Parameter bzw. Maschinendaten z.B. für Geschwindigkeit, Beschleunigung, usw. dürfen nicht
ohne Rücksprache verändert werden. Bei der Abnahme werden von BMW Überprüfungsroutinen ein-
gesetzt, die den Speicherabzug systematisch nach Auffälligkeiten durchforsten.
Sollten Auffälligkeiten auftreten, die den ordnungsgemäßen Betrieb des Roboters beeinflussen wird
die Abnahme zurückgewiesen und der Anlagenlieferant muss sämtliche Mängel beseitigen.
Seite 8 von 75
Standard
Electrics
BP V2.0
12.1.1.14 Zuordnung der Tätigkeiten
Zuordnung der Tätigkeiten Ausführender
Die Bereitstellung der Inbetriebnahme Daten sind Grundvoraus-set- Anlagenbauer

zung und müssen dem Roboterlieferanten vor der Inbetriebnahme zur
Verfügung gestellt.
Die Inbetriebnahme Dateien werden mit Hilfe des „XML-Generators“
erzeugt (project:xml). Die Grundlage dafür ist eine Ausleitung aus dem
E-Plan.
Die Inbetriebnahme Dateien enthalten folgende standplatz-spezifi-
schen Informationen:
 Benötigte Applikationen (IBN.xml)
 Profinetkonfiguration des Roboters
 EA-Verschaltung und Startadressen der einzelnen Teilnehmer
 Langtexte
 Aktuelle GSDML-Dateien
 IP-Adresse und Computername für Meldungsausgabe
Der Anlagenbauer muss die Daten auf Funktionalität und Plausibilität

prüfen.
Eine erneute Inbetriebnahme Aufgrund fehlerhafter Inbetriebnahme

Dateien geht zu Kosten des Anlagenbauers und müssen vom AL beim
Roboterlieferanten separat beauftragt werden.
Durchführung der Erstinbetriebnahme anhand einer Inbetriebnahme- Fa. KUKA

Checkliste (Optische Überprüfung Manipulator, Steuerschrank und
Schlauchpaket, Kontrolle der Steckverbindungen, Erstjustage, usw.)
Inbetriebnahme KUKA Lineareinheit falls vorhanden.
Installation/Update der KUKA Systemsoftware (KSS) auf dem mit dem Fa. KUKA
AG abgestimmten Stand.
Installation der BMW Standardapplikationssoftware mit den vom Anla- Fa. KUKA
genbauer bereitgestellten Inbetriebnahme Dateien.
Bei der Inbetriebnahme werden alle Profinet-Teilnehmer auf nicht

„immer verfügbar“ gesetzt.
Anbau der Werkzeuge nach Vorgabe inkl. Überprüfung (Handachsen Anlagenbauer

A4, A5, A6 in Null-Stellung)
Bei allen Teilnehmern, die nicht über Werkzeugwechsler betrieben Programmierer

werden muss die Einstellung auf „immer verfügbar“ gesetzt werden.
Die Gerätetaufe der einzelnen Profinet Teilnehmer ist durchzuführen.
Roboter ins Fahrzeugkoordinatennetz ein messen bzw. vorgegebene Programmierer

Daten eingeben und überprüfen.
Vorgegebene Werkzeugdaten eingeben und überprüfen Programmierer
Seite 9 von 75
Standard
Electrics
BP V2.0
Für jedes Werkzeug (Tool) müssen die korrekten Lastdaten, inkl. Zu- Programmierer
satzlastdaten, ermittelt werden. Siehe Kap. 12.1.1.3
Die Funktion Offset lernen für jedes Tool ausführen. Programmierer

Siehe Kap. 12.1.1.4
Erstellung, Einbringung und Optimierung des Anwenderprogrammes, Programmierer

inkl. Einhaltung des Programmierstandards.
Risikoanalyse durchführen und ggf. Maßnahmen festlegen Anlagenbauer
Programmierung und Testen der durch die Risikoanalyse geforderten Programmierer

Sicherheitsmaßnahmen. Siehe Kap. 12.1.3
Einstellen und optimieren des Medienpaketes. Das Medienpaket vom Programmierer

Roboterlieferanten abnehmen lassen. Siehe Kap. 12.1.1.6
Dokumentierung nach Vorgabe im RobotWorkbook. Programmierer

Siehe Kap. 12.1.1.8
Datensicherheit gewährleisten. Siehe Kap. 12.1.1.9 Programmierer
Seite 10 von 75
Standard
Electrics
BP V2.0
12.1.2 Prozessdaten (E/A-Bereiche)

Die E/A-Kommunikation zur SPS und den Applikationen erfolgt über ProfiNet. Es stehen keine wei-
teren Bussysteme zur Verfügung.
Die Anbindung an die SPS umfasst einen standardisierten Bereich von 255 Byte. Die Belegung der
einzelnen Applikationssignale ist nicht fest vergeben, sondern wird bei der Inbetriebnahme nach den
Daten des E-Plans generiert.
User- und Systemsignale (Byte: 0-63 / Bit 1 -512) > fest zugewiesen
Applikationssignale (Byte: 64-253 / Bit 513-2032) >Zuordnung erfolgt nach E-Plan
Systemintern belegt (Byte: 254-255 / Bit 2033-2048) > fest zugewiesen
Die Anbindung der Applikationen an den unterlagerten „Masterbereich“ umfasst einen standardisier-
ten Bereich von max. 718 Byte. Die Belegung der einzelnen Applikationssignale ist nicht fest verge-
ben, sondern wird bei der Inbetriebnahme nach den Daten des E-Plans generiert.
Applikationssignale (Byte: 256-974 / Bit 2049-7800) >Zuordnung erfolgt nach E-Plan

Systemintern belegt (Byte: 975-1023 / Bit 7801-8192) > fest zugewiesen
Für die Sicherheitssignale steht ein Bereich von 8 Byte (ProfiNet-Safety) zur Verfügung.
Für die Visualisierung der dynamisch zugeordneten Signale stehen unter dem Menü
„Anzeige“ -> „BMW“ applikationsspezifische Statusfenster zur Verfügung.
Konzept: Bei der Inbetriebnahme werden nach Grundlage des E-Plans mit dem Tool „XML-
Generator“ über „WorkVisual“ die benötigten Applikationspakete aufgespielt und die dynamische
E/A-Zuordnung realisiert.
Hinweis: Der E-Plan muss zum Zeitpunkt der Inbetriebnahme der realen Anlagenkonfiguration ent-
sprechen, ansonsten kann der Roboterinbetriebnehmer (KUKA) nicht die richtigen Applikationspa-
kete aufspielen.
Eine detaillierte Zuordnung ist der Datei „LIST_yymmdd_Roboterschnittstelle_BP_V2.0.xlsx“ zu ent-

nehmen!
Seite 11 von 75
Standard
Electrics
BP V2.0
12.1.3 Sicherer Roboter, Safe Operation
12.1.3.1 Allgemein
Im Projekt werden alle Roboter mit der Option „KUKA.SafeOperation“ ausgeliefert. Hierbei handelt
sich um eine sicherheitsbewertete Software zur Achs- und Raumbegrenzung mit Hardwarekompo-
nenten.
Grundsätzlich sind alle Roboter nach der gültigen SPEZ_xxxxxx_Sicherheitskonzept_Karosseriebau,

der EN ISO 10218 und den mit geltenden Normen und Dokumenten abzusichern.
Eine Risikobeurteilung muss für jeden Roboter durchgeführt werden.
Werden Aufgrund der Risikobeurteilung Schutzmaßnahmen notwendig, müssen die benötigten Si-
cherheitsparameter (z.B. Koordinaten der Schutzbereiche, Geometrie des Werkzeuges, zulässige
Geschwindigkeit, usw.) in die Robotersteuerung eingegeben werden.
Die Daten, z.B. für Schutzräume, können am realen Roboter erzeugt oder über ein Offline-System
erstellt werden. Die Bedienung bzw. Eingabe der Konfigurationsdaten für „KUKA.SafeOperation“ er-
folgt über die Software WorkVisual oder direkt am Robotersystem.
In der Technologie Karosseriebau muss der zyklische Bremsentest, für alle Achsen, bei allen Robo-
tern aktiviert sein.
Die Schutzmaßnahmen müssen in der realen Zelle überprüft und die Funktion sichergestellt werden.
Das Schutzziel gemäß Risikobeurteilung muss erreicht werden.
Die Dokumentierung aller Sicherheitsdaten hat in der Anlagensicherheitsdokumentation

(FORM_xxxxxxx_8_1_5_v80_Sicherheitseinrichtungen_60204) zu erfolgen. Im „RobotWorkbook“
sind ausschließlich Layouts abzulegen.
Hinweis:
Die Schutzmaßnahmen sind erneut zu überprüfen wenn Roboterablaufprogramme geändert werden
bei denen der Roboter in einen Schutzbereich einfährt (z.B. Werkerarbeitsplatz).
Als Programmänderung gilt hierbei unter anderem: entfernen von Bewegungspunkten, geänderte
Anfahrt zum Schutzbereich. Änderung der Geschwindigkeit etc.. Durch diese Programmänderungen
kann es zum Beispiel zu anderen Nachlaufwinkeln des Roboters kommen und somit ist es möglich,
dass das Schutzziel nicht mehr erreicht wird.
12.1.3.2 Funktionen
KUKA.SafeOperation stellt folgende Funktionen zur Verfügung:
 Benutzerdefinierter Zellenbereich
 16 benutzerdefinierte Überwachungsräume (kartesisch /achsspezifisch)
 16 sichere Werkzeuge mit sicherem TCP und bis zu 6 Kugeln
 Sichere Überwachung achs, -raum und kartesischer Geschwindigkeiten
 Sicherer Betriebshalt
 Sichere Ein- und Ausgänge für Überwachungen und Statusmeldungen
 Überprüfung der Bremsen
 Überprüfung/ Überwachung der Synchronisation
 Konfiguration über Robotersteuerung oder in WorkVisual
 Visualisierung der Räume/ Werkzeuge und E/A`s am Programmierhandgerät
 Anhaltewege ermitteln mit in BMW-Oberfläche integrierten KUKA Tool Nachlauf Logging
Seite 12 von 75
Standard
Electrics
BP V2.0
12.1.3.2.1 Zellenbereich
Wenn aus der Risikobeurteilung und/ oder der SPEZ_xxxxxx_Sicherheitskonzept_Karosseriebau
hervorgeht das der Roboter als sicher auszulegen ist muss der Zellenbereich definiert werden.
Der Zellenbereich ist ein permanenter, immer aktiver, kartesischer Arbeitsraum der der Absicherung
des Arbeitsbereiches des Roboters dient.
Hinweis:
Konfiguration, Programmierung und Funktionstests sind anhand der KUKA Dokumentation
KUKA.SafeOperation, der Risikobeurteilung und der SPEZ_xxxxxx_Sicherheitskonzept_Karosseriebau
durchzuführen.
12.1.3.2.2 Überwachungsräume
Die bis zu 16 Überwachungsräume können kartesisch- oder achsspezifisch definiert werden, die kar-
tesische Variante ist nach Möglichkeit immer anzuwenden.
Folgende Konfigurationsoptionen sind bei den Überwachungsräumen einstellbar:

 Arbeits- bzw. Schutzraum
 Raumspezifische kartesische Geschwindigkeit innerhalb oder außerhalb
 Aktivierung bzw. Deaktivierung über sichere Eingänge
 Verletzungsmeldung über sichere Ausgänge
 Stopp bei Verletzung Raumgrenze
 Referenzstopp bei fehlender Justagereferenzierung
Hinweis:
Konfiguration, Programmierung und Funktionstests sind anhand der KUKA Dokumentation
KUKA.SafeOperation, der Risikobeurteilung und der SPEZ_xxxxxx_Sicherheitskonzept_Karosseriebau
durchzuführen.
Anhaltewege sind zu berücksichtigen wenn dies aus der Riskobeurteilung und/ oder der
SPEZ_xxxxxx_Sicherheitskonzept_Karosseriebau/ MAN_xxxxxxx_8_2_Leitfaden_Standardsituationen her-
vorgeht.
Es sind sinnvolle Namen für die Räume zu definieren.
12.1.3.2.3 Sichere Werkzeuge

Die bis zu 16 sicheren Werkzeuge werden gegen die Grenzen der kartesischen Überwachungs-
räume überwacht.
Ein sicheres Werkzeug wird grundsätzlich über den Safe-TCP und bis zu 6 frei konfigurierbaren Ku-
geln modelliert. Dabei ist darauf zu achten das sich keine Bauteile/ Teile des Werkzeugs außerhalb
der Kugeln befinden (Werkzeug inkl. Bauteil muss von den Kugeln komplett umhüllt sein).
Die sicheren Werkzeuge werden über sichere Eingänge aktiviert. Die Ansteuerung bzw. Aktivierung
von Werkzeugen erfolgt ausschließlich über die Sicherheits-SPS.
Als Safe-TCP ist der „normale TCP“ zu verwenden (z.B. Zange feste Pinole, Hilfs-TCP beim Grei-
fer). Bei einer Werkzeugkombination (z.B. Zange/ Handling) ist als Safe-TCP der TCP zu verwenden
der am weitesten vom Flanschmittelpunkt entfernt ist. Bei Einsatz eines Werkzeugwechslers mit nur
einem sicheren Werkzeugmodell (keine Umschaltung des sicheren Tools) ist als Safe-TCP der „nor-
male TCP“ des Werkzeuges zu verwenden das am weitesten vom Flansch entfernt ist.
Seite 13 von 75
Standard
Electrics
BP V2.0
Bei Wechselwerkzeugen müssen unter Umständen mehrere sichere Werkzeuge definiert werden
die dann von der Sicherheits-SPS umgeschaltet werden (entsprechend der optionalen Sicherheits-
schalter an den Bahnhöfen).
Sofern möglich sollten so viel wie möglich Werkzeuge in einem sicheren Werkzeug zusammenge-
fasst werden. Das heißt bei annähernd gleicher Werkzeuggeometrie ist nur ein Tool zu verwenden.
Es muss das Werkzeug mit der größten Geometrie, inklusive Bauteilen, als sicheres Werkzeug kon-
figuriert werden.
Hinweis:
Die im Werkzeug befindlichen Bauteile können nicht hinzu- bzw. weggeschaltet werden, d.h. das
Safe-Tool ist immer mit Bauteilen!!
Nur bei unterschiedlichen Geometrien die aus Zugänglichkeitsgründen nicht zusammengefasst

werden können dürfen mehrere Werkzeuge definiert werden (siehe auch folgende Konzeptbilder)
Seite 14 von 75
Standard
Electrics
BP V2.0
Für den Werkzeugwechsler ohne gedocktes Werkzeug ist bei Bedarf das Safe-Tool 15 zu verwen-
den.
Falls es Probleme mit der Zugänglichkeit bei dem Safe-Tool „Greifer mit angedocktem Mobi-
Wechsler/Fräser“ gibt, ist es möglich mit der Montage eines zusätzlichen optionalen Sicherheits-
schalters, an der Ablage des Mobifräsers, ein zusätzliches Safe-Tool zu konfigurieren.
Achtung!
Im Falle dass die Geometrie des Safetools „Handling mit Mobifräser“ kleiner als die Geometrie des
Safetools „Handling mit Bauteil“ ist muss in der SPS eine zusätzliche Logik programmiert werden !
Ist kein Programm (z.B. 62 oder 63) mit der kleinen Geometrie „Handling mit Mobifräser“ aktiv/ ge-
startet, muss die sichere Toolumschaltung auf True geprüft werden.
Im Fehlerfall muss die SPS einen Sofort-Halt ausgeben.
An jedem sicheren Werkzeug wird ein sicherer TCP (Safe-TCP) definiert, an dem die konfigurierten
Geschwindigkeiten überwacht werden. Der Safe-TCP ist nicht automatisch identisch mit dem akti-
ven TCP des Grundsystems.
Seite 15 von 75
Standard
Electrics
BP V2.0
12.1.3.2.4 Achs-, Raum- und kart. Geschw. und sicherer Betriebshalt

Können bei Bedarf (wenn es aus der Riskobeurteilung hervorgeht) entsprechend der
KUKA.SafeOperation Dokumentation verwendet werden.
12.1.3.2.5 Bremsentest
Mit dem Bremsentest überprüft die Robotersteuerung die Haltebremsen auf Funktion und Ver-
schleiß.
Wenn sich Personen in der Nähe eines Roboters aufhalten können, der aufgrund seiner Masse bzw.
Werkzeuglast eine Gefährdung darstellt, ist ein zyklischer Bremsentest vorzusehen.
In der Technologie Karosseriebau muss für jeden Roboter der Bremsentest realisiert werden!
Hinweis:
Es dürfen nicht die KUKA-Standard BrakeTest Programme verwendet werden!
Das BMW-Programm für den Bremsentest „Prog251_braketest.src“ und das BMW-Programm für die
Parkposition „BMWBrakeTestPark.src“, ist zu erstellen (Positionen, Wege, Werkzeugwechsel etc.
teachen) bzw. das dazu äquivalente Offline erzeugte OLP-Programm ist anzupassen.
Der Bremsentest wird von der SPS alle 24 Stunden angestoßen. Der Aufruf im Automatikablauf er-
folgt mit „Prog251_BrakeTest“.
Hinweis:
Der Bremsentest wird von Home1 gestartet. Falls es möglich ist, soll die Home1 als Test-Position
verwendet werden. Die Parkposition ist idealerweise die Transportstellung bzw. muss so gewählt
werden das der Roboter gefahrlos zusammensacken kann.
12.1.3.2.6 Justagereferenzierung
Mit der Justagereferenzierung wird überprüft, ob die aktuelle Position des Roboters mit einer Refe-
renzposition übereinstimmt. Der Roboter kann nur mit SafeOperation sicher überwacht werden wenn
die Justagereferenzierung erfolgreich war.
Achtung:
Dieses Programm wird nur benötigt falls bei der Risikobeurteilung die Notwendigkeit von SafeOpe-
ration Funktionen festgelegt wurde.
Der im Lieferumfang von KUKA enthaltene Referenztaster muss verwendet werden.

Der Referenztaster muss nicht mit der KUKA- Bedämpferplatte (Stimmgabel) bedämpft werden, son-
dern soll nach Möglichkeit mit dem Greifer oder der Zange bedämpft werden!
Es dürfen aber keine beweglichen Teile wie Stifte, Spanner usw. verwendet werden, auch Rundungen
wie E-Schäfte sind nicht zulässig!
Die alternative Variante, Sicherheitsschalter über die SPS rangieren, ist nicht zulässig!
Hinweise:
Es dürfen nicht die KUKA-Standard Referenzierprogramme verwendet werden!
Seite 16 von 75
Standard
Electrics
BP V2.0
Das BMW-Programm für die Justagereferenzierung „Prog250_MasterReference“ ist zu erstellen (Po-

sitionen, Wege, Werkzeugwechsel etc. teachen) bzw. das dazu äquivalente Offline erzeugte OLP-
Programm ist anzupassen.
Das Programm startet und endet in Home 1. Die Stellung des Roboters muss so gewählt werden,
dass alle Achsen des Roboters (ggf. inkl. Linearachse) erfasst werden.
Der Aufruf im Automatikablauf erfolgt mit „Prog250_MasterReference“.
Bei Verwendung von Werkzeugwechslern ist die Referenzierung nur für ein Werkzeug zu realisie-
ren. Vorrangig sollte das Werkzeug verwendet werden, das in Stellung „Home1“ zum Einsatz
kommt.
12.1.3.2.7 Anhaltewege
Wenn der Roboter durch eine Überwachung von SafeOperation gestoppt wird, benötigt er einen
Anhalteweg bis zum Stillstand (Anhalteweg = Reaktionsweg + Bremsweg).
Aus der Risikobeurteilung geht hervor ob die Anhaltewege mit berücksichtigt werden müssen. Zur
Ermittlung der Anhaltewege in der Planungsphase sind die Diagramme aus der Spezifikation des
Roboterherstellers zu verwenden.
Bei der fertig programmierten Zelle kann für die dann aktuelle Situation auch das Tool Nachlauf
Logging der Firma KUKA verwendet werden. Dieses Tool zeichnet z.B. beim Verletzen eines Schutz-
raums die Achs-Winkel bei Verletzung und die Achswinkel nach Stillstand auf. Daraus wird der Nach-
lauf errechnet und ausgegeben.
Seite 17 von 75
Standard
Electrics
BP V2.0
12.1.3.3 Grundeinstellungen
Folgende Bilderdoku soll bei der Definition der richtigen Grundeinstellungen helfen.
Bei der Inbetriebnahme wurde der zyklische Bremsentest automatisch aktiv geschaltet. Die Einstellun-
gen bleiben bei den Default-Werten. Die SPS startet den Bremsentest zyklisch an (alle 24 Stunden).
Seite 18 von 75
Standard
Electrics
BP V2.0
Unter Hardwareoptionen sind die Einstellungen gemäß dem Bild unten durchzuführen.
Seite 19 von 75
Standard
Electrics
BP V2.0
Die Geschwindigkeiten sind bei den globalen Parametern Default mäßig vorbelegt.
Die rotatorische Achsüberwachung wird bei der maximalen Geschwindigkeit T1 auf 100 °/s gestellt
(KUKA-Default 30 °/s)
Seite 20 von 75
Standard
Electrics
BP V2.0
Bei der Justagereferenzierung ist der von KUKA mitgelieferte Referenztaster zu verwenden. Der Refe-
renztaster muss nicht mit der KUKA- Bedämpferplatte (Stimmgabel) bedämpft werden, sondern soll
nach Möglichkeit mit dem Greifer oder der Zange bedämpft werden!
Es dürfen aber keine beweglichen Teile wie Stifte, Spanner usw. verwendet werden, auch Rundungen
wie E-Schäfte sind nicht zulässig!
Es muss für die Überwachungsräume und sicheren Werkzeuge ein sinnvoller Name verwendet werden
(z.B. Stations- oder Werkzeugnummer).
Für den Werkzeugwechsler ohne Werkzeug ist Safe-Tool 15 zu verwenden!
Als Safe-TCP ist der „normale TCP“ zu verwenden (z.B. Zange feste Pinole, Hilfs-TCP beim Greifer).
Bei einer Werkzeugkombination (z.B. Zange/ Handling) ist als Safe-TCP der TCP zu verwenden der am
weitesten vom Flanschmittelpunkt entfernt ist. Bei Einsatz eines Werkzeugwechslers mit nur einem si-
cheren Werkzeugmodell (keine Umschaltung des sicheren Tools) ist als Safe-TCP der „normale TCP“
des Werkzeuges zu verwenden das am weitesten vom Flansch entfernt ist.
Die weitere Konfiguration ist je nach Anwendungsfall vorzunehmen.
Seite 21 von 75
Standard
Electrics
BP V2.0
12.1.3.4 Mit geltende Dokumente

Sicherheitskonzept: SPEZ_xxxxxx_Sicherheitskonzept_Karosseriebau
MAN_xxxxxx_8_2_Leitfaden_Standardsituationen_D_E
FORM_xxxxxxx_8_1_5_v80_Sicherheitseinrichtungen_60204
Methodenbeschreibung OLP: PR_xxxxxx_RobKalDat_SafeMove
Unterlagen von KUKA: Spezifikation_QUANTEC/ FORTEC_xxxxx

KST_SafeOperation_xx_de
Doku_Nachlaufwegeermittlung
Unter anderen geltende Normen: DIN_EN_ISO_10218-1

DIN_EN_ISO_10218-2
Sowie die im Sicherheitskonzept aufgeführten
Seite 22 von 75
Standard
Electrics
BP V2.0
12.1.4 Programme, allgemein
12.1.4.1 Programmstruktur
Grundsätzlich ist ein einfacher Programmablauf zu bevorzugen. Der Roboter muss in jedem Zyklus
aus dem Programm CELL.SRC, mit einer Programmnummer gestartet werden und am Ende wieder
ins Programm CELL zurückspringen.
Die verschiedenen Programmnummern sind primär für das erneute an starten des Roboters bei
„Start nach Störung“ zu verwenden. Das Organisationsprogramm z.B. „Prog001_xxxxx“ enthält ei-
nen kompletten Roboterablauf. Weitere Programmnummern stellen jeweils einen reduzierten Um-
fang des Organisationsprogramms dar, wie in nach folgender Grafik dargestellt.
In Ausnahmefällen und nach Rücksprache/Genehmigung der jeweiligen BMW-Fachabteilung ist es

möglich ein Programm in einer Endlosschleife laufen zu lassen. In diesem Fall muss das Programm
trotzdem über CELL gestartet werden.
Aufgrund der Möglichkeit, Programm-Abbrüche inkl. Rückfahrbewegung zu einer Home-Stellung

realisieren zu können, soll folgende Programmstruktur mit maximal 2 Home-Stellungen (Home1 –
ohne Bauteil / Home2 – mit Bauteil) umgesetzt werden.
Nach Rücksprache/Genehmigung der jeweiligen BMW-Fachabteilung ist es, in begründeten Aus-
nahmefällen auch möglich mehr Home-Stellungen zu verwenden. In diesem Fall ist die Option
Rehome zwingend erforderlich!
Das Roboterprogramm startet aus Home 1 und fährt alle Abläufe unmittelbar nacheinander durch
und endet wieder in Home 1. Home 2 und in Ausnahmefällen weitere Home-Stellungen werden
ausschließlich im Fehlerfall, nach einem Abbruch angefahren.
Grundsätzlich soll sich in Home 1 kein Bauteil im Greifer befinden.
Hinweis: Alle Wartungs-Programme werden Grundsätzlich aus Home 1 gestartet.

Siehe Kap. : 12.1.5.4 Wartungsprogramme
Seite 23 von 75
Standard
Electrics
BP V2.0
12.1.4.2 Ablagestruktur
Im Arbeitsordner (R1-Verzeichnis) des Roboters ist wie folgt aufgebaut:
Seite 24 von 75
Standard
Electrics
BP V2.0
12.1.4.3 Zuordnungstabelle Programm-Nummern
Job-Bezug:
Es stehen 64 Jobs zur Verfügung die Grundsätzlich in Bezug zu den Programm-Nummern benutzt
werden sollen. Werden bei einem Roboter mehrere Werkzeuge verwendet, wird zusätzlich zur Job-
Nummer eine User-Nummer von der SPS übergeben bzw. kann eine User-Nummer angefragt werden!
Beispiel: Pick(Job 1) – Place(Job 2) – Spot(Job 3)
Prog001_xxx: Job 1 – 2 – 3
Prog002_xxx: Job 2 – 3
Prog003_xxx: Job 3
Prog062_TipDress: Job 62 (bei mehreren Zangen, Aufruf inkl. UserNum)
Prog063_TipChange: Job 63 (bei mehreren Zangen, Aufruf inkl. UserNum)
Prog064_Maintenance: Job 64 (bei mehreren Werkzeugen, Aufruf inkl. UserNum)
Progamm- Programm Name:

Nr.
1 Prog001_xxxxxxxxxxxxxxx Anwenderprogramme mit Job-Bezug (1-49)
2 Prog002_xxxxxxxxxxxxxxx
.
.
50 Applikationsspezifische Programme Programme mit Job-Bezug (50-64)
.
.
.
62 Prog062_TipDress
63 Prog063_TipChange
64 Prog064_Maintenance (Wartungsprogramm)
. frei
. frei
. frei
250 Prog250_MasterReference
251 Prog251_BrakeTest
252 reserviert
253 reserviert
254 reserviert
255 reserviert
Seite 25 von 75
Standard
Electrics
BP V2.0
12.1.4.4 Test des Programmablaufs
Der Programmierer muss sicherstellen, dass alle Programme auf Funktion und Kollisionsfreiheit getes-
tet wurden. Bei Verwendung von „bedingten“ Programmabläufen (z.B. bei IF oder SWITCH /CASE Be-
fehlen) muss jede Möglichkeit getestet und Fehlkombinationen ausgeschlossen werden. (z.B. durch
ein Default - CASE)
Ein Default-Errorprogramm steht dem Anwender zur Verfügung! „Plc_DefaultError()“
Weitere Information im Kap. 0
Beispiel:
Seite 26 von 75
Standard
Electrics
BP V2.0
12.1.5 Programme, Detail

Bei allen neuen bzw. geänderten Programmen ist darauf zu achten das diese komplett, bzw. die ge-
änderten Teile, in Handbetrieb abgefahren werden. Dasselbe gilt für Offline erstellt Programme.
12.1.5.1 Programm: CELL

Der Automatikbetrieb kann nur erfolgen wenn der Roboter über das Programm CELL.SRC gestartet
wurde. Im Display des Programmierhandgerätes erscheinen Meldungen bzw. Dialogabfragen um
den Bediener an die Programmstelle zu führen, an der auf Betriebsart „Automatik Extern“ geschal-
ten werden kann.
Die Betriebsart „Automatik“ ist im Anlagenverbund nicht zulässig, die SPS wird keinen Start ausge-
ben!
Für jede Programm-Nummer ist im CELL.SRC ein „CASE“ vorgesehen bzw. zu erstellen. Im jeweili-
gen CASE ist ausschließlich der Aufruf des Organisationsprogrammes einzutragen.
Cell.SRC
......
......
SWITCH
CASE 1
Prog001_xxxxx() Prog001_xxxxx.SRC
CASE 2
Prog002_xxxxx () ; kompletter Ablauf
CASE 3 Bauteil_holen
Prog003_xxxxx () Schweissen
..... Bauteil_ablegen
ENDSWITCH Prog002_xxxxx.SRC
END
; reduzierter Ablauf
Schweissen
Bauteil_ablegen
END Prog003_xxxxx.SRC
; reduzierter Ablauf
Bauteil_ablegen
END
Seite 27 von 75
Standard
Electrics
BP V2.0
12.1.5.2 Anwenderprogramme
Alle für die BMW AG zu erstellenden Anwenderprogramme, sind nach dieser Vorschrift zu benennen.
Abweichungen sind nur nach Rücksprache und Zustimmung durch die Fachabteilungen zulässig.
Grundsätzliche Erwartung ist eine einfache Programmierung sowie die Möglichkeit, dass nach Stö-
rungen ein schneller Einstieg in den Automatikablauf erfolgen kann.
Die Programmnamen müssen die Teilaufgabe, den Werkzeugbereich und den Fahrzeugtyp enthal-
ten. Es sind max. 23 Zeichen möglich.
Die folgende Struktur und die Trennung mit „_“ ist einzuhalten:
{Aufgabe}_{Werkzeugbereich}_{Typ}
z.B. Spot_ST20FX1_G11
1. Aufgabe – Liste mit Abkürzungen für Anwendungen

Aufgabe – Abkürzung Beschreibung
Spot Punktschweißen
Stud Bolzenschweißen
Glue Kleben (gluing)
Pick Greifen von Teilen
Drop Platzieren von Teilen
Arc Lichtbogenschweißen
Clinch Falzen
Flow Fließlochschrauben
Rivet Nieten
Nut Mutternschweißen
Fasten Befestigen/Schrauben
Hem Säumen
Laser Laserschweißen
Search Suchen
Stack Ablegen von Teilen
Spray Besprühen von Teilen
Fit Optimal anpassen
Inline Inlinemessen
Check Prüfen, z. B. nach dem Kleben
Stamp Stamping
Scan Abtasten
Vrtfx Virtuelle Vorrichtung
Dock Werkzeug zum Andocken
Undock Werkzeug zum Abdocken
Beschreibung: Teilaufgabe
Die Teilaufgabe beschreibt die Haupttätigkeit im jeweiligen Programm. Dies kann z.B. Ablegen,
Schweißen, Bearbeiten, Kleben usw. sein.
Beschreibung: Werkzeugbereich
Durch das BMW-Anlagenkennzeichnungssystem (AKZ-Masterstring) sind alle Komponentenbe-
zeichnung vorgeschrieben. (z.B. ST = Station, FX = Werkzeug/Vorrichtung, usw.) für die meisten
Komponenten sind 3-stellige Nummernblöcke reserviert. Die Vollständige Bezeichnung für ein Werk-
zeug nach AKZ-Masterstring ist somit wie folgt definiert: ++ST010+FX001
Um nicht unnötige Zeichen zu verschwenden ist es zulässig wenn die Stationsbezeichnung bzw. der
Werkzeugbereich abgekürzt wird.
Die Eindeutigkeit der Bezeichnung muss aber sicher gestellt sein. z.B. ST10FX1
Seite 28 von 75
Standard
Electrics
BP V2.0
Beschreibung: Typ
Für die Typbeschreibung sind 3 Zeichen reserviert. (z.B. G11 oder G30). Sollte ein Programm für
mehrere Typen gleichzeitig verwendet werden (z.B. für G11 und G12) ist auch die Angabe G1x zuläs-
sig. Der Typ kann entfallen wenn nur ein Typ im Roboter programmiert ist und kein weiterer Typ spä-
ter integriert wird.
12.1.5.3 Organisationsprogramme
Das Organisationsprogramm Prog001_xxxxx.SRC enthält den kompletten Roboterlauf. Die weiteren
Programme (z.B. Prog002_xxxxx.SRC, Prog003_xxxxx.SRC, usw.) stellen jeweils einen reduzierten
Umfang des Grundprogramms dar.
Wenn bei verschiedenen Typen dieselben Abläufe abzuarbeiten bzw. wenn typbezogen andere Ab-
läufe notwendig sind, können diese in dem Befehl Job Request / TypReq realisiert werden.
In den Organisationprogrammen dürfen keine Bewegungsabläufe programmiert werden!
Nach Rücksprache/Genehmigung der jeweiligen BMW-Fachabteilung ist es auch möglich eine an-
dere Programmstruktur zu wählen.
12.1.5.4 Wartungsprogramm
Unter dem Begriff „Wartungsprogramm“ werden Programme verstanden, die über eine Programm-
Nr. von der SPS gestartet werden.
Der Standard sieht ein Wartungsprogramm(Prog064_Maintenance) vor, dass ausschließlich von
Home1 gestartet und in Home1 enden muss.
Bei Verwendung von mehreren Werkzeugen wird zum Programmaufruf zusätzlich eine User-Nummer
mit übergeben, mit der über eine „Switch/Case-Auswahl“ die einzelnen Wartungsprogramme aufgerufen
werden.
Hinweis: Das Programm 64 ist ein reines Organisationsprogramm, die einzelnen Wartungsprogramme
sind im Verzeichnis „BMW_Utilities“ abzulegen.
Grundsätzlich muss für jedes Werkzeug ein Wartungsprogramm inkl. der Wartungsposition realisiert
werden.
Bei Verwendung eines Werkzeugwechslers ist auch eine Wartungsposition ohne gedockte Werkzeuge
vorzusehen.
Für den SPS-Handshake stehen standardisierte E/A`s zur Verfügung.
Reinigungsstellung:
Für jeden Roboter muss ein Reinigungsprogramm erstellt werden. Der Aufruf erfolgt über das War-
tungsprogramm und der Übergabe der „User-Nr. 100“.
Die Reinigungs-Position ist so zu wählen dass für das Reinigungspersonal ein freier und gefahrloser
Anlagenzutritt gewährleistet ist. In der Regel wird dies eine Position oberhalb von Home1 sein.
Die Auswahl der Positionen hat nach ergonomischen Gesichtspunkten zu erfolgen und ist mit der
jeweiligen BMW-Fachstelle festzulegen.
Ein kollisionsfreier Ablauf muss gewährleistet sein, bei Bedarf ist das Kollisionsschutzkonzept zu be-
rücksichtigen.
Seite 29 von 75
Standard
Electrics
BP V2.0
12.1.5.5 Applikationsspezifische Programme

Unter dem Begriff „Applikationsspezifische Programme“ werden Programme verstanden, die für
eine Roboterapplikation benötigt werden und in der Betriebsart „Automatik“ abgefahren werden
können. Programm-Templates liegen im R1 Verzeichnis unter BMW_Utilities.
Für die Applikationsspezifischen Programme, mit Jobbezug, sind die Programmnummern 50-64 vor-
gesehen, die Programmnummern 62 und 63 sind für das Punktschweißen fest vergeben und 64 für
das Wartungsprogramm (Maintenance).
Für alle anderen Programme müssen die Programmnummern zwischen SPS- und Roboterprogram-
mierer individuell abgestimmt werden und entsprechend vom Roboterprogrammierer im Cell-/ Orga-
nisationsprogramm programmiert werden.
Damit der schnelle Zutritt in die Anlage gewährleistet ist, muss in der Serviceposition ein Controlled
Stop ausgegeben werden. Dies kann über das ILF PlcCom mit setze Ausgang, warte Eingang oder
über das ILF Controlled Stop realisiert werden (siehe auch Kap. 12.1.15.2 Beschreibung Befehle/
ILF´s).
12.1.5.6 Serviceprogramme
Unter dem Begriff „Serviceprogramme“ werden Programme verstanden, die nicht von der SPS ge-
startet werden können. Serviceprogramme werden lediglich in der Betriebsart „Hand“ angewählt
bzw. gestartet, Automatikbetrieb ist nicht zulässig.
Der benötigte Umfang und die Auswahl der Servicestellung hat nach ergonomischen Gesichtspunk-
ten zu erfolgen und ist mit der jeweiligen BMW-Fachstelle festzulegen.
Beispiel: Schweißzangen-Wechselposition (ohne automatischen Werkzeugwechsler)
12.1.5.7 Abbruchprogramme
Die Abbruchfunktion birgt bei Falschanwendung ein erhebliches Kollisionsrisiko.
Ob bzw. in welchem Umfang das Abbruchkonzept umgesetzt werden soll, ist mit der zuständigen
BMW-Fachstelle abzuklären!
Abbrüche können über die Befehle „Job Request“ und „Area Request“ programmiert werden.
Hinweis: Abbruchprogramme müssen immer in einer Home-Stellung enden und mit einer entspre-
chend sicheren Geschwindigkeit erstellt werden.
Ein kollisionsfreier Ablauf muss gewährleistet sein, bei Bedarf ist das Kollisionsschutzkonzept zu be-
rücksichtigen. Bei Verwendung und bei Änderungen muss sichergestellt werden dass alle möglichen
Programmabläufe getestet wurden.
Weitere Informationen zum Abbruchkonzept im Kap. 12.1.14
12.1.5.8 Standardprogramme
Für die einzelnen Applikationen stehen Standard-Programmpakete zur Verfügung, diese werden je
nach Bedarf auf dem Roboter installiert. Für jede Applikation gibt es eine Programmiervorschrift die
eingehalten werden muss.
Standardprogramme dürfen nicht verändert werden!
Hinweis: Bei späteren Softwareupdates werden die Standardprogramme geändert bzw. komplett
ausgetauscht.
Werden Änderungen benötigt, muss Rücksprache mit dem Auftraggeber erfolgen.
Seite 30 von 75
Standard
Electrics
BP V2.0
12.1.6 Variablen und Datenlisten

Werden User-spezifische Variablen benötigt sind folgende Anforderungen zu erfüllen:
 Prüfen ob evtl. eine bestehende Variable schon vorhanden ist und verwendet werden kann.
 Der Name muss so gewählt werden, dass eine Doppeldeklaration auszuschließen ist.
(z.B. Applikationsspez. Variablen beginnen mit einem Applikationskürzel „scr_xxxxxx“)
 Der Variablenname muss so den Variablenzweck erkennen lassen.
 Eine möglichst geringe Zeichenanzahl enthalten.
 Bevorzugte Sprache für Variablennamen ist Englisch
 Der Name muss sich einen Indikator für den Variablentyp beinhalten
 Durch Trennung mit „_“ und einer sinnvoller Groß/Kleinschreibweise kann die Lesbarkeit
deutlich erhöht werden!
12.1.6.1 Kuka-System-Datenliste: $config.dat

Die $config.dat wird ausschließlich für die Daten/Variablen verwendet, die vom Kuka-System vorgege-
ben werden. (d.h. Home-Positionen, Tooldaten, Lastdaten, Base-Daten usw.) Alle anderen standplatz-
spezifischen Daten dürfen nicht in der $config.dat abgelegt werden.
Achtung: Bei Updates werden alle sonstigen, in der $config.dat deklarierten Variablen, nicht berück-
sichtigt!
12.1.6.2 Standplatzspezifische Datenliste: A01_plc_User.dat

Alle sonstigen standplatzspezifischen Daten/Variable die der User deklariert, müssen in der
„A01_plc_User.Dat“ abgelegt werden.
12.1.6.3 Applikationsspezifische Datenliste: Axx_yyy_User.dat

Für jede Applikation steht eine standplatzspezifische Datenliste zur Verfügung. Die Variablen sind in
der Regel vordeklariert und müssen vom User standplatzspezifisch angepasst werden.
12.1.6.4 Applikationsspezifische Positionsdatenliste: Axx_yyy_global.dat

Für jede Applikation steht eine Datenliste für globale Positionsdaten zur Verfügung. Alle globalen ap-
plikationsspezifischen Positionen (z.B. Schweißpunkte) müssen in dieser Datenliste abgelegt werden.
Seite 31 von 75
Standard
Electrics
BP V2.0
12.1.7 Home-Stellungen
Das BMW-Standardkonzept sieht die Verwendung von maximal 2 Home-Stellungen (Home1 – ohne
Bauteil / Home2 – mit Bauteil) vor. Die Home-Positionen sind global angelegt und deshalb in allen
Programmen gültig.
Es besteht in Ausnahmefällen nach Rücksprache/ Genehmigung der jeweiligen BMW-

Fachabteilung die Möglichkeit, bis zu 5 verschiedene Robotergrundstellungen (Home 1 bis 5) zu
verwenden. In diesem Fall ist die Option Rehome zwingend erforderlich!
Achtung: Wenn eine Home-Position verändert wird, kann es zu Kollisionen in anderen Programmen
führen! Nach jeder Änderung müssen alle betroffenen Programme überprüft werden.
Grundsätzlich gilt:
 „Home1“ ist für die Grundstellung ohne Bauteil zu verwenden.
 Die Home-Stellung 2 und eventuell genehmigte weitere werden nur verwendet, falls sie tat-
sächlich im Programm benötigt werden.
 Eine entsprechende Bezeichnung ist für jede verwendete Home-Position zu konfigurieren
 Im Programm sind grundsätzlich in jeder Home-Position, die richtigen Lastdaten zu verwen-
den.
Eine Verknüpfung der Grundstellung mit Bauteilkontrollen oder ähnliches wird nicht im Roboterpro-
gramm, sondern über die SPS realisiert.
Home 1 und Home 2 (bzw. weitere) sollten untereinander kollisionsfrei anfahrbar sein. Wenn dies
nicht möglich ist, ist die Rehome Funktion mit den entsprechenden Home to Home Programmen zu
verwenden.
12.1.7.1 Home-Konfiguration
Die benötigte Anzahl, die Bezeichnung und die Übernahme der Positionsdaten müssen über ein
Konfigurationsmenü eingestellt werden. Nach erfolgreicher Konfiguration wird vom Robotersystem
automatisch der entsprechende „Home-Ausgang“ gesetzt, wenn der Roboter die Position erreicht
hat.
Mit der Funktion „ Wiederherstellen“ kann ggf. die jeweilig zuletzt gültige Home-Stellung zurückge-
holt werden.
Hinweis: Der „Home-Ausgang“ wird vom System nur dann gesetzt, wenn die Konfigurierung über
dieses Menü erfolgt ist.
Seite 32 von 75
Standard
Electrics
BP V2.0
12.1.8 Initialisierungskonzept
Standardmäßig werden alle Ausgänge bzw. Variablen beim „Starten von CELL“ eines Roboters defi-
niert zurückgesetzt. Dies umfasst die Systemfunktionen, die applikationsspezifischen Einstellungen
sowie die userspezifischen Umfänge.
Grundsätzlich gilt, dass alle vom Programmierer verwendete Funktionen (z.B. Area´s, User-Aus-
gänge, Variablen, usw.) im Anwenderprogramm wieder definiert zurückgesetzt werden sollen.
Es muss aber davon ausgegangen werden das ein Bediener den Programmablauf nach einer Störung
irgendwann Abbricht und den Roboter erneut über „CELL“ startet. Diese Situation muss abgefangen
werden!
Für die Initialisierung (Start nach Störung) stehen die für dem User folgende Programme im Verzeich-
nis „BMW_Init“ zur Verfügung.
Init_BeforeHome: (InitBeforeHome.src)
Initialisierung Anwenderumfänge, bevor der Roboter sich bewegt
Init_InHome: (InitInHome.src)
Initialisierung Anwenderumfänge, nachdem der Roboter die Homestellung erreicht hat
Init_Produktion: (InitProduction.src)
Initialisierung Anwenderumfänge, jedes Mal bevor eine neue SPS-Programm-Nr. angefordert wird!
Hinweis:
Im Programm „InitProduction.src“ wird das Systemprogramm „A01_plc_init.src“ aufgerufen und
darin werden alle Systemausgänge zur SPS initialisiert. Der Aufruf darf nicht entfernt werden.
Sollten einzelne Funktionen (z.B. Areas, Jobs, CollZone, Userausgänge) im Programmablauf trotz-
dem benötigt werden, muss der User die Funktionen nach dem Aufruf von „A01_plc_init.src“ explizit
wieder setzen!
Achtung:
Nach Beendigung eines Programmablaufes wird „InitProduction.src“ sofort durchlaufen. Wenn eine
Funktion (z.B. Job Done) erst spät am Ende des Programmablaufes gesetzt wird, kann es vorkom-
men das die SPS dies nicht mitbekommt (Zykluszeit), weil „InitProduction.src“ das zurücksetzen so-
fort ausführt. Einzige Abhilfe: Funktion früher im Programmablauf setzen oder ggf. eine kleine War-
tezeit programmieren!
Seite 33 von 75
Standard
Electrics
BP V2.0
Übersichtsbild:
Seite 34 von 75
Standard
Electrics
BP V2.0
12.1.9 Job`s
In der Regel haben Roboter in einem Programm mehrere verschiedenen Aufgaben d.h. verschie-
dene Jobs zu erledigen. Mit dem Jobkonzept werden diese Teilaufgaben mit der SPS über standar-
disierte Ein- und Ausgänge synchronisiert. Die SPS wertet diese Signale für Visualisierung, Aufbe-
reitung für Start nach Störung und zur Zeitüberwachung aus.
12.1.9.1 Job: Konzeptbild
Folgendes Konzeptbild veranschaulicht die Benutzung von Job Started, Job Done und
JobClaerAll.
Seite 35 von 75
Standard
Electrics
BP V2.0
12.1.9.2 Job: Programmbefehl
Das Inlineformular für den Job-Befehl ist so aufgebaut, dass es sich je nach Einstellung dynamisch
verändert. Auf den folgenden Seiten werden einzelnen Eingabemöglichkeiten beschrieben.
Für die Programmierung steht der Standardbefehl „Job“ (mit und ohne Bewegung) für 64 Job´s zur
Verfügung.
Bitte beachten sie die Hinweise zum Initialisierungskonzept Kap.12.1.8
Eingabefeld 1: Auswahl der Funktion
JobStarted:
Über diese Funktion wird der SPS mitgeteilt dass ein Job gestartet wurde. Das „JobStarted“ wird
nicht automatisch nach Freigabe des „JobRequest“ ausgeführt sondern an der Stelle im Anwender-
programm programmiert, an der die Teilaufgabe tatsächlich beginnt.
Beispiel: Der Job „Schweißen“ wird vorzeitig freigegeben und der Roboter fährt bis zum
Drehtisch. Erst wenn der Drehtisch „bereit“ meldet darf der Roboter in den Bereich (Area)
einfahren. Der Job „Schweißen“ beginnt erst nach der Freigabe.
JobDone:
Über diese Funktion wird der SPS mitgeteilt dass ein Job erledigt wurde. Das „JobDone“ wird in der
Regel nach der Ausführung des letzten Prozesspunktes gesetzt. Der Status von „JobStarted“ bleibt
unverändert.
Beispiel: Nachdem der letzte Schweißpunkt auf das Bauteil gesetzt wurde wird über
„JobDone“ der SPS mitgeteilt dass dieses Bauteil komplett fertig bearbeitet ist. Sollte danach
ein Handeingriff erfolgen und der Roboter manuell in Grundstellung gefahren werden, kann
die SPS die weitere Programmaufbereitung durchführen.
Seite 36 von 75
Standard
Electrics
BP V2.0
JobRequest:
In der SPS wird angefragt ob die Freigabe für einem bestimmten Job vorhanden ist. Für Ausnahme-
fälle gibt es zusätzlich die Möglichkeit dass die SPS eine Job-Nr. vorgeben kann. Hierbei handelt es
sich um die Funktion „AnyJob“, die jedoch nur nach Absprache mit der zuständigen Steuerungs-
technik verwendet werden darf.
In der Regel wird die Funktion JobRequest nur im Organisationsprogramm verwendet.
Zusätzlich besteht die Möglichkeit zu der entsprechenden Jobanfrage eine Type-Nummer und/oder
eine User-Nummer anzufordern. Bei Verwendung von „AnyJob“ ist zu bedenken dass u.U. nicht für
alle möglichen Jobs in der SPS eine User.- oder Type-Nummer zur Verfügung steht.
Informationen und Einschränkungen sind der SPS-Dokumentation zu entnehmen!
JobRequest-Befehle können über die SPS abgebrochen werden.
Seite 37 von 75
Standard
Electrics
BP V2.0
JobClearAll:
Über diese Funktion wird der SPS mitgeteilt dass alle Jobs erledigt wurden. Die „Job-Schnittstelle“
wird komplett zurückgesetzt. Einzelne Jobs können nicht zurückgesetzt werden. Es bleiben alle „Job-
Started“ und „JobDone“ –Signale im Status solange erhalten, bis mit „JobClearAll“ alles abgelöscht
wird.
Diese Funktion ist vorrangig für die Verwendung in den Initialisierungsprogrammen und für den letz-
ten Programmschritt entwickelt worden.
Eingabefeld 2: Auswahl Bewegungsart

Bei den Funktionen „Job_Started“, „Job_Done“ und Job_ClearAll können Bewegungspositionen
programmiert werden. Job_Request ist nur ohne Bewegung möglich.
Nach Auswahl von „PTP oder LIN“ erscheinen alle notwendigen Felder, die für Bewegungseinstel-
lung notwendig sind.
Je nach Auswahl, wird die Position dementsprechend angefahren. Der „Started-Ausgang“ wird im-
mer im Vorlauf gesetzt, der „Done-Ausgang“ und „ClearAll“ wird getriggert an der programmierten
Position ausgeführt.
Seite 38 von 75
Standard
Electrics
BP V2.0
Eingabefeld 3: Job Nummer
Es stehen maximal 64 Jobs zur Verfügung. Analog zu den Job-Nummern sind auf der E/A-Schnitt-
stelle Aus- bzw. Eingänge aufgelegt.
Eingabefeld 4: Continue
Wird der Schalter „CONT“ programmiert, „überschleift“ der Roboter, ansonsten wird ein Vorlauf-
stopp ausgeführt und der Roboter bleibt an der programmierten Position stehen.
Die Funktionen „Done“ und „ClearAll“ werden unabhängig von dieser Einstellung immer positions-
genau ausgeführt.
Seite 39 von 75
Standard
Electrics
BP V2.0
Eingabefeld 5: Description
xx….
In diesem Feld besteht die Möglichkeit einen bis zu 40 Zeichen langen Text eingeben.
Grundsätzlich muss jeder verwendete Befehl beschrieben werden.
Beispiel: „Schweissen beendet“ oder „Kleben Teil xx beendet“
Die Eingabe soll verständlich sein und zusätzliche Informationen für den Anwender bieten.
Ein Eintrag „Job 1 erledigt“ würde keine zusätzliche Information bringen!!!
Eingabefeld 6: Typ-Nummer und/oder User-Nummer
Zusätzlich zu einer Job-Nummer-Anforderung (Job_Request) kann eine Typ-Nummer und/oder eine

User_Nummer von der SPS angefordert werden. Es muss lediglich das „Häkchen“ im entsprechen-
den Feld gesetzt werden. Der Programmablauf wird solange gestoppt bis von der SPS die gültigen
Nummern gesendet werden. Die Funktion wird im Vorlauf bearbeitet.
Für beide Nummern sind Bereiche von 1-255 festgelegt. Eine „0“ ist keine gütige Auswahlmöglich-
keit.
Die übergebene Typ-Nummer bzw. User-Nummer wird im System in Variablen zwischengespeichert
und können anschließend im Programmablauf einmalig mit den Funktionen „GetTypNum“ bzw. „Ge-
tUserNum“ abgegriffen werden.
Hinweis: Die Funktionen „GetTypNum“ und „GetUserNum“ liefern aus Sicherheitsgründen nur ein-
malig nach einer Anfrage den gültigen Wert zurück! Bei einer erneuten Anfrage wird eine „0“ ausgege-
ben!
Weitere Informationen zu Typ- und User-Nummer: Kap. 12.1.13
Seite 40 von 75
Standard
Electrics
BP V2.0
Eingabefeld 7: Abbruch
Es ist nicht gefordert dass bei jedem Job eine Abbruchfunktion realisiert wird. Diese Funktion birgt
bei Falschanwendung ein erhebliches Kollisionsrisiko. Es ist jeweils mit dem Auftraggeber abzustim-
men wie und in welchen Umfang das Abbruchkonzept realisiert werden soll.
Weitere Informationen zum Abbruch: Kap. 12.1.14
Abort= „NoAbort“
Die Programm-Abbruchfunktion ist nicht aktiviert.
Abort= „Home1 … Home5“

Die Programm-Abbruchfunktion ist aktiviert und ein „Abort“ könnte über die SPS ausgelöst werden.
Sollte von der SPS kein Abbruch angestoßen werden, hat die Einstellung keine Auswirkung, der Pro-
grammablauf wird wie programmiert weiter abgearbeitet!
Im Falle des Abbruchs wird das laufende Programm verlassen und der Roboter fährt mit reduzierter
Geschwindigkeit direkt zu der gewählten Homeposition! Anschließend wird eine neue Programm-Nr.
von der SPS angefordert.
Achtung: Es muss durch die Programmierung sichergestellt werden dass der Roboter die Home-
Position kollisionsfrei anfahren kann.
Abort= „AbortProgXX“
Im Falle des Abbruchs wird das laufende Programm verlassen und das ausgewählte „Abortpro-
gramm“ wird gestartet. Anschließend wird eine neue Programm-Nr. von der SPS angefordert.
Achtung: Es muss durch die Programmierung sichergestellt werden dass der Roboter das Abbruch-
programm kollisionsfrei abfahren kann!
Hinweis: Ein Abbruchprogramm wird systemtechnisch generell mit reduzierter Geschwindigkeit

ausgeführt.
Seite 41 von 75
Standard
Electrics
BP V2.0
12.1.9.3 Job: komplexe Beispiele

Jobanfrage mit Type.- und UserNummer (Regelfall)
Beispiel: BT-Entnahme aus 3 Behältertürmen, Bearbeitungsstation und Ablagestation
Schematischer Programmablauf:
Seite 42 von 75
Standard
Electrics
BP V2.0
Jobanfrage über „AnyJob“ (Sonderfall)

Beispiel: BT-Entnahme aus 3 Behältertürmen, Bearbeitungsstation und Ablagestation
Schematischer Programmablauf
Seite 43 von 75
Standard
Electrics
BP V2.0
12.1.10 Area´s
In der Regel arbeiten Roboter in verschiedenen Bereichen (Area´s). Mit dem Areakonzept ist die Ver-
waltung dieser Bereiche realisiert. Die Bereiche sind nicht wie beim Kollisionsschutzkonzept anlagen-
übergreifend zu sehen, sondern gelten lediglich zwischen den jeweiligen Roboter. Grundsätzlich ist
die SPS der Verwalter der Bereiche und der Roboter kann lediglich „anfragen“ ob ein Bereich frei ist
oder „melden“ sobald ein Bereich betreten bzw. verlassen ist.
12.1.10.1 Area: Konzeptbild
Seite 44 von 75
Standard
Electrics
BP V2.0
12.1.10.2 Area: Programmbefehl

Das Inlineformular für den Area-Befehl ist so aufgebaut, dass es sich je nach Einstellung dynamisch
verändert. Auf den folgenden Seiten werden einzelnen Eingabemöglichkeiten beschrieben.
Für die Programmierung steht der Standardbefehl „Area“ (mit und ohne Bewegung) für 32 Area´s
zur Verfügung.
Eingabefeld: Auswahl der Funktion
AreaRequest:
Über diese Funktion wird bei der SPS angefragt ob für den Roboter ein Bereich (Area) frei zum ein-
fahren ist. Die Anfrage erfolgt immer im Vorlauf, das bedeutet dass u.U. mehrere Bewegungsschritte
vor dem Erreichen der Area-Grenze die Anfrage bei der SPS bearbeitet wird. Ist die Area gesperrt
bleibt der Roboter an der programmierten Position stehen und wartet bis die Freigabe erteilt wird.
Sollte die Freigabe bereits vor Erreichen der programmierten Position erfolgt sein, bleibt der Roboter
nicht stehen sondern „überschleift“ die Bewegung.
AreaRelease:
Über diese Funktion wird der SPS mitgeteilt dass der Roboter ein Bereich (Area) verlassen hat. Die
Abarbeitung erfolgt nicht im Vorlauf sondern wird exakt auf die programmierte Position getriggert.
Eingabefeld: Auswahl Bewegungsart

Der Area-Befehl kann ohne und mit Bewegungspositionen programmiert werden.
Seite 45 von 75
Standard
Electrics
BP V2.0
Bei Auswahl „PTP oder LIN“ erscheinen alle notwendigen Felder die für Bewegungseinstellung not-
wendig sind. Je nach Auswahl, wird die Position dementsprechend angefahren.
Der „Request“ wird immer im Vorlauf ausgeführt, das Release wird immer getriggert an der pro-
grammierten Position abgearbeitet.
Eingabefeld: Area Nummer
Es stehen maximal 32 Areas zur Verfügung. Analog zu den Area-Nummern sind auf der E/A-Schnitt-
stelle Aus- bzw. Eingänge aufgelegt.
Seite 46 von 75
Standard
Electrics
BP V2.0
Eingabefeld: Continue
Wird der Schalter „CONT“ programmiert, überschleift der Roboter, ansonsten wird ein Vorlaufstopp
ausgeführt und der Roboter bleibt an der programmierten Position stehen. Die Funktion „Rlease“ wird
immer, unabhängig von dieser Einstellung, positionsgenau ausgeführt.
Eingabefeld: Description
Shuttle frei ?
In diesem Feld besteht die Möglichkeit einen bis zu 40 Zeichen langen Text einzugeben.
Beispiel: „ Einfahren in Drehtisch“ oder „Shuttle verlassen“
Ein Eintrag „Anfrage Area 1“ würde keine zusätzlich Information bringen!!!
Seite 47 von 75
Standard
Electrics
BP V2.0
Eingabefeld: Abbruch
Es ist nicht gefordert dass bei jedem Bereich (Area) eine Abbruchfunktion realisiert wird. Diese Funk-
tion birgt bei Falschanwendung ein erhebliches Kollisionsrisiko. Es ist jeweils mit dem Auftraggeber
abzustimmen wie und in welchen Umfang ein Abbruchkonzept realisiert werden soll.
Weitere Informationen zum Abbruch: Kap. 12.1.14
Abort= „NoAbort“
Die Programm-Abbruchfunktion ist nicht aktiviert.
Abort= „Home1 … Home5“

Im Falle des Abbruchs wird das laufende Programm verlassen und der Roboter fährt mit reduzierter
Geschwindigkeit direkt zu der gewählten Homeposition! Anschließend wird eine neue Programm-Nr.
von der SPS angefordert.
Achtung: Es muss durch die Programmierung sichergestellt werden dass der Roboter die Home-
Position kollisionsfrei anfahren kann.
Abort= „AbortProgXX“
Im Falle des Abbruchs wird das laufende Programm verlassen und das ausgewählte „Abortpro-
gramm“ wird gestartet. Anschließend wird eine neue Programm-Nr. von der SPS angefordert.
Achtung: Es muss durch die Programmierung sichergestellt werden dass der Roboter das Abbruch-
programm kollisionsfrei abfahren kann!
Hinweis: Ein Abbruchprogramm wird systemtechnisch generell mit reduzierter Geschwindigkeit

ausgeführt.
Seite 48 von 75
Standard
Electrics
BP V2.0
Eingabefeld: ClearAll
Die Funktion ClearAll löscht alle Anfragen (Request´s) und alle Bereiche werden gleichzeitig freige-
geben. Diese Funktion ist vorrangig für die Verwendung in den Initialisierungsprogrammen entwickelt
worden. Grundsätzlich sollen die Bereichsfreigaben einzeln an den Stellen programmiert werden, an
denen der Roboter den Bereich verlässt.
Seite 49 von 75
Standard
Electrics
BP V2.0
12.1.10.3 Area: komplexes Beispiel
Seite 50 von 75
Standard
Electrics
BP V2.0
12.1.11 Kollisionsschutz
In vielen Anlagen arbeiten mehrere Roboter gleichzeitig, teilweise auch am gleichen Bauteil. Die Be-
wegungsabläufe der Roboter überschneiden sich zeitweise räumlich und können zu Kollisionen füh-
ren. Mit dem Kollisionsschutzkonzept wird geregelt welcher Roboter zu welcher Zeit einen Bewe-
gungsraum (Kollisionszone) betreten darf. In der SPS werden die unterschiedlichen Kollisionszonen
verwaltet und für einzelne Robotern freigegeben bzw. gesperrt. Es stehen standardisierte Roboter-
befehle für 1-254 Zonen zur Verfügung.
Grundsätzlich gilt:
 Kollisionszonen sind anlagenbezogen, d.h. eine Zonen-Nr. darf nur einmal pro Anlage vergeben
werden!
 Es kann sich nur ein Roboter in einer „Kollisionszone“ aufhalten!
 Der erste Roboter der eine Zone anfrägt, bekommt die Freigabe, alle anderen müssen warten!
 Die Freigabe einer Kollisionszone kann nur der Roboter durchführen, der die Zone belegt hat!
Hinweis: Auch wenn sich im normalen Programmablauf die Roboter nicht berühren, weil sie zeitlich
versetzt arbeiten, ist der Bewegungsablauf durch den Kollisionsschutz abzusichern. Es könnte z.B.
im Testfall ein Roboter mit reduzierter Geschwindigkeit betrieben werden!
12.1.11.1 Kollisionsschutz: Konzeptbild
Seite 51 von 75
Standard
Electrics
BP V2.0
12.1.11.2 Kollisionsschutz: Programmbefehl
Das Inlineformular für den Kollisionsschutz-Befehl ist so aufgebaut, dass es sich je nach Einstellung
dynamisch verändert. Auf den folgenden Seiten werden einzelnen Eingabemöglichkeiten beschrie-
ben.
Für die Programmierung steht der Standardbefehl „CollZone“ (mit und ohne Bewegung) für 1-254
Kollisionszonen zur Verfügung
Eingabefeld: Auswahl der Funktion:
CollZone Request:
Mit dieser Funktion wird bei der SPS angefragt ob der Roboter in einem Anlagenbereich (Kollisions-
zone) einfahren darf. Die Anfrage erfolgt immer im Vorlauf. Das bedeutet dass u.U. mehrere Bewe-
gungsschritte vor dem Erreichen der Kollisions-Grenze, die Anfrage bei der SPS gestellt wird. Ist die
Zone gesperrt, bleibt der Roboter an der programmierten Position stehen und wartet bis die Freigabe
erteilt wird. Sollte die Freigabe bereits vor Erreichen der programmierten Position erfolgt sein, bleibt
der Roboter nicht stehen sondern „überschleift“ die Bewegung.
CollZone Release:
Mit dieser Funktion wird der SPS mitgeteilt dass der Roboter den Anlagenbereich (Kollisionszone)
verlassen hat. Die Abarbeitung erfolgt nicht im Vorlauf sondern wird exakt auf die programmierte Po-
sition getriggert.
Hinweis: nur der Roboter, der eine Zone belegt hat, kann diese auch freigeben. Freigaben für nicht
belegte Zonen haben keine Auswirkung!
Eingabefeld: Auswahl Bewegungsart

Der CollZone-Befehl kann ohne und mit Bewegungspositionen programmiert werden.
Seite 52 von 75
Standard
Electrics
BP V2.0
Bei Auswahl „PTP oder LIN“ erscheinen alle notwendigen Felder die für Bewegungseinstellung not-
wendig sind.
Je nach Auswahl, wird die Position dementsprechend angefahren.

Der „Request“ wird immer im Vorlauf ausgeführt, das Release wird immer getriggert an der pro-
grammierten Position abgearbeitet.
Eingabefeld: Auswahl ExtPlc
In der Regel soll der Befehl im eigenen SPS-Bereich wirken. Optional kann der SPS mitgeteilt wer-
den dass die Kommunikation für den SPS-Nachbarbereich vorgesehen ist.
PLC= „ “ (leer)
Der Befehl wirkt im eigenen SPS-Bereich. (Standardeinstellung)
PLC= „ExtPlc“
In seltenen Fällen kann es vorkommen dass ein Roboter über die Anlagenebene in 2 verschiedenen
SPS-Steuerungen Aufgaben erledigen muss. (z.B. im Bereich der zugehörigen SPS wird ein Bauteil
aufgenommen und im Bereich einer anderen SPS muss es abgelegt werden) In diesem Fall kann mit
der Auswahl „ExtPlc“ der SPS mitgeteilt werden das dieser Befehl im anderen SPS-Bereich wirken
soll.
Seite 53 von 75
Standard
Electrics
BP V2.0
Eingabefeld: Kollisions-Zonen Nummer
Es stehen maximal 1-254 Zonen zur Verfügung. Auf der E/A-Schnittstelle stehen für den Anwender
keine einzelnen Ein- und Ausgänge zur Verfügung. Die Kommunikation ist über eine 8 Bit-Nummer
sowie Steuerbits realisiert. Die Eingaben „0“ und „255“ sind keine gültigen Zonen-Nummern und
können nicht ausgewählt werden.
Wird der Schalter „CONT“ programmiert, überschleift der Roboter, ansonsten wird ein Vorlaufstopp
ausgeführt und der Roboter bleibt an der programmierten Position stehen. Die Funktionen „Release“
wird immer, unabhängig von dieser Einstellung, positionsgenau ausgeführt.
Seite 54 von 75
Standard
Electrics
BP V2.0
Eingabefeld: ClearAll:
Die Funktion ClearAll gibt alle von diesem Roboter belegten Kollisionsbereiche frei. Diese Funktion
ist vorrangig für die Verwendung in den Initialisierungsprogrammen entwickelt worden. Grundsätzlich
sollen die Kollisionsfreigaben einzeln an den Stellen programmiert werden, an denen der Roboter den
Bereich verlässt.
Beispiel: „K-Zone zu 01R02“
Ein Eintrag „anfrage Koll-Zone 1 “ würde keine zusätzliche Information bringen!!!
Seite 55 von 75
Standard
Electrics
BP V2.0
12.1.12 Userkommunikation
In vielen Fällen ist es notwendig Programmabläufe zwischen dem Roboter und der SPS zu synchro-
nisieren bzw. Informationen auszutauschen. Der PLC_COM-Befehl wurde entwickelt um die meisten
Situationen eines Handshakes zwischen SPS und Roboter abzubilden. Der Befehl ist in 3 Ebenen
aufgebaut. Das bedeutet es können 3 Kommandos programmiert werden.
Hinweis: Es müssen nicht alle Ebenen genutzt werden.
Der Befehl unterstützt die 512 PLC-E/A´s, eine User-Nummer (8 Bit) und eine Typ-Nummer (8 Bit).
In Ebene 1 kann einer der SPS-Ausgänge gesetzt bzw. zurückgesetzt werden.

In Ebene 2 kann auf einen der SPS-Eingänge gewartet oder eine Aktion angestoßen werden.
In Ebene 3 kann einer der SPS-Ausgänge zurückgesetzt bzw. gesetzt werden.
Beispiel 1:
Der Roboter hat die Wartungsposition erreicht und meldet dies zur SPS.
1. Kommando: Set PLC_do_ServicePos / Wartungsstellung erreicht

2. Kommando: Wait PLC_di_10 / Rückmeldung Wartung erledigt, der Roboter darf weiterfahren
3. Kommando: Reset PLC_do_ServicePos / Wartungsposition verlassen
Beispiel 2:
Der Roboter soll aus einem Magazin verschiedene Teile entnehmen. Die SPS kennt den Inhalt des
Magazins und gibt die Reihenfolger der Entnahme vor.
1. Kommando: Set PLC_do_20 / Anforderung einer Fach-Nummer

2. Kommando: UserNum_Request / Anforderung der Fach-Nummer
3. Kommando: Reset PLC_do_20 / Rücksetzen der Anforderung
12.1.12.1 Userkommunikation: Konzeptbild
Seite 56 von 75
Standard
Electrics
BP V2.0
12.1.12.2 Userkommunikation: Programmbefehl
Das Inlineformular für den Userkommunikations-Befehl ist so aufgebaut, dass es sich je nach Einstel-
lung dynamisch verändert. Auf den folgenden Seiten werden einzelnen Eingabemöglichkeiten be-
schrieben.
Für die Programmierung steht der Standardbefehl „Plc_Com“ (mit und ohne Bewegung) zur Verfü-
gung.
Eingabefeld: Auswahl Bewegungsart:
Der Kommunikationsbefehl kann ohne und mit Bewegungspositionen programmiert werden. Bei
Auswahl „PTP oder LIN“ erscheinen alle notwendigen Felder die für Bewegungseinstellung notwen-
dig sind. Je nach Auswahl, wird die Position dementsprechend angefahren.
Eingabefeld: Auswahl der Funktion für das 1. Kommando
Es ist möglich die Aktionen „setze User-Ausgang“ und „rücksetze User-Ausgang“ auszuwählen.
Keine Auswahl (“_“) bedeutet, es wird keine Funktion ausgeführt.
Seite 57 von 75
Standard
Electrics
BP V2.0
Eingabefeld: Auswahl eines User-Ausgangs zum 1. Kommando
Es können nur die 512 PLC-Ausgänge der Standardschnittstelle ausgewählt werden. Andere Aus-
gänge werden von diesem Befehl nicht unterstützt.
Seite 58 von 75
Standard
Electrics
BP V2.0
Eingabefeld: Auswahl der Funktion für das 2. Kommando
Für das 2. Kommando können 7 verschiedene „Aktionen“ eingestellt werden.
Wait_Input=1
Der Programmzeiger wartet bis der angegebene Eingang den Zustand „high“ erreicht.
Wait_Input=0
Der Programmzeiger wartet bis der angegebene Eingang den Zustand „low“ erreicht.
Request_UserNum
Über die standardisierte Schnittstelle wird die von der SPS eine User-Nummer angefordert. Der Pro-
grammzeiger bleibt bei dieser Auswahl stehen, bis die SPS eine gültige User-Num (1-255) sendet.
Die Verwendung der Nummer „0“ ist nicht zulässig. Im weiteren Programmablauf kann dann diese
User-Nr. für verwendet werden. (siehe Kap. 12.1.13.3)
Send_UserNum
Über die standardisierte Schnittstelle kann der SPS eine User-Nummer gesendet. Der Nummernbe-
reich von 0-255 ist zulässig. (siehe Kap. 12.1.13.1)
Request_TypNum
Über die standardisierte Schnittstelle wird die von der SPS eine Type-Nummer angefordert. Der Pro-
grammzeiger bleibt bei dieser Auswahl stehen, bis die SPS eine gültige Type-Num (1-255) sendet.
Die Verwendung der Nummer „0“ ist nicht zulässig. Im weiteren Programmablauf kann dann diese
Type-Nr. für verwendet werden. (siehe Kap. 12.1.13.3)
Send_TypNum
Über die standardisierte Schnittstelle kann der SPS eine Typ-Nummer gesendet. Der Nummernbe-
reich von 0-255 ist zulässig. (siehe Kap. 12.1.13.1)
Keine Auswahl (“_“) bedeutet, es wird keine Funktion ausgeführt.
Seite 59 von 75
Standard
Electrics
BP V2.0
Eingabefeld: Zuordnung eines User-Eingangs zum 2. Kommando
Es können nur die 512 PLC-Eingänge der Standardschnittstelle ausgewählt werden. Andere Ein-
Eingabefeld: Senden einer User-Nummer
Bei der Auswahl „Send_UserNum“ und „Typ_UserNum“ kann im Eingabefeld die Zahl 0-255 einge-
geben werden.
Seite 60 von 75
Standard
Electrics
BP V2.0
Eingabefeld: Auswahl der Funktion des 3. Kommandos
Es ist möglich die Aktionen „Reset_Output“ und „Set_Output“ auszuwählen. Keine Auswahl (“_“)
bedeutet, es wird keine Funktion ausgeführt.
Eingabefeld: Zuordnung eines User-Ausgangs zum 3. Kommando
Es können nur die 512 PLC-Ausgänge der Standardschnittstelle ausgewählt werden. Andere Aus-
Seite 61 von 75
Standard
Electrics
BP V2.0
Wird der Schalter „CONT“ programmiert, überschleift der Roboter die Bewegung. Die eingestellten
Aktionen werden im Vorlauf ausgeführt. Wird „CONT“ nicht eingestellt bleibt der Roboter an der pro-
grammierten Position stehen. Die eingestellten Aktionen werden erst danach ausgeführt.
Beispiel: „Kamera 1, Bild starten!“
Ein Eintrag „ Setze Output 1 und Warte Input1 “ würde keine zusätzliche Information bringen!!!
Seite 62 von 75
Standard
Electrics
BP V2.0
12.1.13 Typ-Nummer / User-Nummer

Über die Befehle „JobRequest“ und „PlcCom“ kann mit der SPS eine 8 Bit lange Typ-Nummer bzw. eine
User-Nummer ausgetauscht werden.
Typ-Nummern werden vorrangig für Auswahl/Rückmeldung unterschiedlicher Fahrzeugtypen (z.B.
G11, G12, usw.) verwendet. Die User-Nummer bietet eine weitere Möglichkeit Detailunterscheidun-
gen (z.B. Ablagefach-Nr. benennen) in den Programmablauf zu ermöglichen.
Achtung: Für die Übermittlung von Typ-UserNummer dürfen ausschließlich die vorgesehenen Be-
fehle bzw. Funktionen verwendet werden. Die Auswertung der direkten E/A-Signale ist nicht zulässig,
da der Status nur kurzfristig während, der Kommunikation, ansteht!
12.1.13.1 Typ- / User-Num senden

Das Senden einer Typ- oder User-Nummer muss über den Roboterbefehl „PlcCom“ programmiert
werden.
Weitere Informationen: PlcCom: Kap. 12.1.12.2
12.1.13.2 Typ- / User-Num senden, erstmalig nach JobRequest Anforderung
Die Funktion wurde entwickelt um der SPS die Möglichkeit der Kontrolle zu geben, ob das Roboter-
programm tatsächlich in den vorgesehenen Ablauf gesprungen ist! Dies kann u.U. der Fall sein
wenn die Logik in den Organisationsprogrammen fehlerhaft ausgeführt ist oder wenn z.B. Ablauf-
programme fehlerhaft kopiert wurden.
Beispiel: Programmablauf mit 2 Typen
Wird im Programmablauf eine Typ.- oder >User-Nummer über den JobRequest-Befehl angefor-
dert, erwartet die SPS beim ersten zurücksenden immer das die gleiche Nummer „zurückge-
spiegelt“ wird! Wird eine andere Nummer zurückgesendet wird der Programmanlauf gestoppt und
es werden entsprechende Meldungen am Roboterbediengerät und am Anlagen-PC ausgegeben.
Die Rückspiegelung erfolgt über den „Plc-Com-Befehl“ im Ablaufprogramm!
Seite 63 von 75
Standard
Electrics
BP V2.0
Beispiele: Fehlermeldung am Roboterbediengerät
Die Überprüfungsfunktion in der SPS wirkt nur beim erstmaligen zurücksenden der Nummer nach-
dem ein „JobRequest-Befehl inkl. TypNum/UserNum-Anforderung“ programmiert wurde!
Die Funktion wird bei folgenden Situationen aufgehoben:

 Nach „Starte von Cell“
 Nach „Anforderung Programm-Nr.“
 Nach einem „JobDone-Befehl“ im Anwenderprogramm
 Nach einer erfolgreichen Nummern-Rückspiegelung
 Nach einem JobRequest-Befehl ohne „TypNum/UserNum-Anforderung“
12.1.13.3 Typ-Nummer / User-Nummer anfordern
Das Anfordern einer Typ- oder User-Nummer muss über die Roboterbefehle „JobRequest“ oder
„PlcCom“ programmiert werden. Sollte zum Zeitpunkt der Anforderung keine gültige Nummer in der SPS
anstehen bleibt der Bewegenzeiger im Roboterbefehl stehen und gibt nach Ablauf der „MaxTime“ eine
Meldung aus. Diese Meldung kann nicht quittiert werden, das Roboterprogramm wartet bis eine gültige
Nummer ausgetauscht und verifiziert ist.
Nach erfolgreicher Anforderung wird die Nummer in einer internen System-Variable zwischengespei-
chert. Im Anwenderprogramm kann sie über die Funktion „GetTypNum“ bzw. „GetUserNum“ weiterver-
arbeitet werden. Falls die Nummer nur einmalig benötigt wird, kann sie direkt über die Funktion verwen-
det werden, ansonsten kann sie in eine Anwendervariable kopiert werden.
Achtung: Die Funktionen liefern aus Sicherheitsgründen nur einmalig nach einer Anfrage den gültigen
Wert zurück! Bei einer erneuten Anfrage wird eine „0“ ausgegeben!
Weitere Informationen:
JobRequest: Kap. 12.1.9.2
PlcCom: Kap.12.1.12.2
Seite 64 von 75
Standard
Electrics
BP V2.0
12.1.13.4 Undefinierter Nummernbereich

Um die Situation „Übertragung einer unbekannten Nummer“ abzusichern muss im Anwenderprogramm
ein „Default-Case“ programmiert werden. Das Programm „plc_defaulterror()“ ist für diesen „Fehlerfall“
zu verwenden. Im Falle des Fehlers bleibt der Cursor im Programm „plc_defaulterror()“ gefangen. Es
wird folgende Meldung ausgegeben.
Wird die Nummer wie im Beispielprogramm: 12.1.13.5 mit übergeben, wird sie zur Anzeige gebracht.
Der Handeingriff „Starte von CELL“ sowie die Überprüfung ggf. eine Änderung des Anwenderpro-
gramms wäre anschließend notwendig!
12.1.13.5 Beispielprogramm
Seite 65 von 75
Standard
Electrics
BP V2.0
12.1.14 Programmabbruch
Im Karosseriebau ist es üblich das verschiedene Programm-Nummern für das Starten eines Roboters
nach einer Störung verwendet werden. (Siehe Kap. Programmstruktur12.1.4.1).
Das Abbruchkonzept wurde entwickelt um gezielte Aussprünge aus dem „normalen“ Programmab-
lauf zu realisieren. Grundsätzlich muss ein „Abbruch“ immer in einer Home-Stellung enden! Der er-
neute Einsprung in den Programmablauf erfolgt immer über die Anforderung einer neuen Programm-
Nummer.
Ein Abbruch kann nur über die Befehle „Job“ oder „Area“ programmiert werden. Über diese Befehle
wird der SPS lediglich mitgeteilt, dass sich der Roboter aktuell auf einer möglichen Abbruch-Position
befindet. Der Abbruch wird ausschließlich von der SPS ausgelöst!
Generell muss der Abbruch an geeigneten Positionen im Programm (z.B. vor Beginn eines Jobs) re-
alisiert werden. Der Abbruch eines begonnenen Jobs ist nicht zulässig!
Hinweis: Die Abbruchfunktion birgt bei Falschanwendung ein erhebliches Kollisionsrisiko. Bei Ver-
wendung muss sichergestellt werden dass alle möglichen Programmabläufe getestet wurden. Es ist
jeweils mit dem Auftraggeber abzustimmen wie und in welchen Umfang das Abbruchkonzept reali-
siert werden soll!
12.1.14.1 Programmabbruch: Konzeptbild
Es wird in 2 verschiedene Abbrucharten unterschieden:

Seite 66 von 75
Standard
Electrics
BP V2.0
12.1.14.2 Programmabbruch: Roboter in Home-Stellung:

Diese Funktion wurde vorrangig für Abbrüche in Organisationsprogrammen entwickelt. Die Realisie-
rung erfolgte über den Befehl: Job Request / Abort = Home1(2,3,4,5)
Falls die SPS einen Abbruch auslöst, wird überprüft ob sich der Roboter auf einer Home-Stellung
befindet. Wenn ja, wird das Roboterprogramm an dieser Stelle abgebrochen und der Programmzeiger
ins Programm „CELL“ auf die Zeile „neue Programm-Nummer anfordern“ gestellt.
Achtung: In diesem Anwendungsfall muss sichergestellt sein dass sich der Roboter auf der angege-
benen Home-Stellung befindet, ansonsten würde der Roboter die gewählte Home-Position auf dem
direkten Weg anfahren.
Job-Befehl unter Kap. 12.1.9.2, Eingabefeld Abbruch
12.1.14.3 Programmabbruch: Roboter in keiner Home-Stellung:

Diese Funktion wurde vorrangig für Abbrüche an definierten Positionen in Anwenderprogrammen
entwickelt. Die Realisierung erfolgte über die Befehle:
Area Request / Abort „AbortProgXX“ oder „Home1 … Home5“
Job Request / Abort „ AbortProgXX“ oder „Home1 … Home5“ (falls der Roboter noch nicht auf der
gewählten Home-Position steht)
Falls die SPS einen Abbruch auslöst, wird das ausgewählte „AbortProgramm“ gestartet bzw. die an-
gegebene „Home-Stellung“ direkt angefahren. Die Geschwindigkeit wird hierbei reduziert. Im Ab-
bruchprogramm muss sichergestellt werden dass es in einer Home-Stellung endet, ansonsten wird
der Abbruch mit einer Fehlermeldung abgewiesen. Der Handeingriff „Starte von CELL“ sowie die
Überprüfung ggf. eine Änderung des Anwenderprogramms wäre anschließend notwendig!
Nach einem geglückten Abbruch wird der Programmzeiger ins Programm „CELL“ auf die Zeile „neue
Programm-Nummer anfordern“ gestellt.
Job-Befehl unter Kap. 12.1.9.2, Eingabefeld Abbruch
Area-Befehl unter Kap.12.1.10.2, Eingabefeld Abbruch
Seite 67 von 75
Standard
Electrics
BP V2.0
12.1.14.4 Programmabbruch: Abortprogramme
Grundsätzlich müssen alle Abort-Programme so ausgeführt und getestet sein, dass Kollisionen in
allen Fällen ausgeschlossen sind.
Abort-Programme können in den Befehlen „Job“ und „Area“ erst benutzt werden, wenn sie über das
Menü „ModAbortPrograms“ erstellt worden sind. Die Namenskonvention ist hierbei zwingend einzu-
halten! Da Abbruchprogramme nicht im Regelablauf eingebunden sind und nur in Ausnahmefällen
benutzt werden, sind diese mit einer geeigneten Geschwindigkeit zu programmieren.
Beim Abbruch ist zu bedenken dass evtl. auch das Kollisionsschutz- und Areakonzept aktualisiert
werden muss. Die letzte Position muss eine Home-Stellung sein, ansonsten kann ein weiterer Pro-
grammablauf in Automatik nicht gestartet werden.
Das erforderliche Menü befindet sich unter:
Die Ablage der Programme erfolgt im Verzeichnis: R1 /Program / Abort
Seite 68 von 75
Standard
Electrics
BP V2.0
12.1.14.5 Programmabbruch: komplexes Beispiel
Seite 69 von 75
Standard
Electrics
BP V2.0
Seite 70 von 75
Standard
Electrics
BP V2.0
12.1.15 „CheckHome“ und „Rehome“

Die Instruktion „CheckHome“ ist für die Verwendung in 2 Szenarien gedacht. Zweck der Instruktion ist
es zu überprüfen, dass sich der Roboter in der angegebenen „Home“-Position befindet, bevor eine
Routine ausgeführt wird. Wenn die Roboterposition nicht mit der angegebenen „Home“-Position über-
einstimmt, wird eine Fehlermeldung in der SPS angezeigt. Wenn der optionale Parameter „Rehome“
ausgewählt ist, wird zusätzlich zu der oben genannten Instruktion überprüft, ob eine Routine vorhan-
den ist, die den Roboter zwischen den „Home“-Positionen automatisch bewegt.
Hinweis:
Diese Funktionalität ist erst ab der A01-Version V1.0.4 mit V8.0 SPS Bausteine verfügbar.
12.1.15.1 Funktion „CheckHome“

Diese Instruktion ist an keine Position gebunden, sondern dynamisch. Sie zeigt ausschließlich die pro-
grammierten „Home“-Positionen an.
Diese Instruktion sollte beim Start von Prozessprogrammen sowie dann eingegeben werden, wenn
eine Bestätigung der „Home“-Position erforderlich ist.
Seite 71 von 75
Standard
Electrics
BP V2.0
12.1.15.2 „CheckHome“ mit der Funktion „Rehome“
Die Benutzerschnittstelle „ModHomePrograms“ wird zum Erstellen der Programme „Home to Home“
verwendet, die vom Konzept her dem „Abbrechen von Programmen“ ähnelt. Die Programme
„HomeX_to_HomeX“ sind im Ordner „Home Programs“ gespeichert und MÜSSEN für einen sicheren
Roboterpfad zwischen den „Home“-Positionen programmiert werden.
Der Line Builder ist dafür verantwortlich, dass vor der Übergabe alle Programme vollständig getestet
wurden.
Seite 72 von 75
Standard
Electrics
BP V2.0
12.1.16 Sonstige Funktionen
12.1.16.1 Stopp am Prozesspunkt

Der Anwender soll einen Prozess, gezielt bei einem bestimmten Prozesspunkt, anhalten können.
Hierzu ist in der Visualisierung am Anlagen-PC ein Bedienbild vorgesehen.
Dieses ist über die Menü Zeile / Allgemein / Prozessdaten / Roboterdaten zu erreichen.
Abbildung der Eingabemaske am AnlagenPC
Der Bediener muss die Prozess ID und die dazugehörige Applikation Nummer eingeben. Außerdem
ist eine maximale Überprüfungszeit ein zu stellen, wie lange es maximal dauern darf, bis der Pro-
zesspunkt gefunden ist. Hat innerhalb dieser Zeit kein Roboter diese ID erkannt wird die Überprü-
fung automatisch beendet. Gestartet wird die Überprüfung mit dem Start Button.
Hinweis: Ist eine Überprüfung aktiv, ist während dessen mit einer schlechteren Taktzeit zu rechnen.
Grund hierfür ist, jeder Roboter frägt vor jedem Prozesspunkt, das SPS Signal ProcessRel ab. Die-
ses Signal, wird bei aktivierter Prozesspunktüberwachung, immer erst auf eins gesetzt, wenn die
SPS kontrolliert hat, dass die vom Roboter ausgegebene nächste Prozess Nummer nicht die zu
überprüfende ist.
12.1.16.2 Controlled Stop

An jeder Schutztür befindet sich ein Taster für Anforderung zum Betreten (Blaue Taste).
Nach Betätigung wird von der SPS das Eingangssignal PLC_di_ControlledStop gesetzt.
Der Roboter beendet seinen aktuellen Prozess an geeigneter Stelle und meldet mit dem Ausgangs
Signal PLC_do_ControlledStop der SPS das der Roboter kontrolliert gestoppt ist. Weiterhin wird,
nach einer Zeit, eine Meldung im Roboter ausgegeben, dass er kontrolliert gestoppt wurde.
Wenn alle Roboter einer Anlage einen kontrollierten Stopp ausgeben wird die Freigabe der Schutz-
tür von der SPS erteilt.
12.1.16.2.1 Controlled Stop: Programmbefehl
Das Inlineformular für den ControlledStop-Befehl ist nur für Sonderfälle vorgesehen, wo ein Con-
trolled Stop benötigt wird und dies nicht über die Standardbefehle abgedeckt ist.
Hinweis: Das ILF muss in einer Repeat Until Schleife mit Wartezeit programmiert werden.
Ein Anwendungsfall für das ILF ist zum Beispiel an einer Sichtposition zur Klebeauftragskontrolle.
Beispiel zur Umsetzung:
Seite 73 von 75
Standard
Electrics
BP V2.0
12.1.16.3 Verriegelung bei Mehrfachanfrage gleicher Area´s und Coll-Zonen

Die „Area“ und „CollZone“ Befehle können positionsgetriggert und überschliffen im Vorlauf pro-
grammiert werden. Werden die gleichen Bereiche mehrfach hintereinander angefragt und freigege-
ben besteht die Gefahr dass sich die Signale zeitlich überschneiden und in der SPS einen undefi-
nierten Zustand erzeugen würden.
Beispiel:
Um dies zu verhindern, wurde im „Area“ und „CollZone“ Befehl eine Verriegelung eingebaut.
Der Release-Befehl meldet bereits im Vorlauf die Nummer des Bereiches, der freigegeben
werden soll. Der Request-Befehl überprüft, ist der Bereich, der angefragt wird, zur Freigabe
vorgemerkt. Ist dies der Fall, wartet der Request-Befehl bis die Freigabe vom Hauptlauf erfolgt ist.
Eine Mehrfachanfrage und zwischenzeitliche Freigabe macht keinen Sinn und das Anwenderpro-
gramm muss berichtigt werden.
Im Automatikablauf wird folgende Meldung ausgegeben:
Seite 74 von 75
Standard
Electrics
BP V2.0
Im T1 oder T2-Betrieb kann es vorkommen das durch versetzen des Cursors oder durch Abbruch
eines Programmes ein Bereich wiederholt angefragt wird. In diesem Fall liegt kein Programmfehler
vor, trotzdem spricht die Verrieglung an. Es wird zum Hinweis folgende Dialogmeldung ausgege-
ben.
Wird der Dialog mit „Ja“ beantwortet, wird die „vorherige Request-Anfrage“ abgebrochen und eine
„neue Request-Anfrage“ an die SPS gesendet!
Wird mit „Nein“ quittiert bleibt die Programmfolge unverändert, die Steuerung wartet unverändert
auf die Freigabe von der SPS.
Seite 75 von 75

E 12.03.01.1 MAN Kap12 A01 ROB Allgemeinteil 171010 de PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

E 12.03.01.1 MAN Kap12 A01 ROB Allgemeinteil 171010 de PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Standarddokumentation für Anlagen im Karosseriebau

Kapitel 12.1 Robotertechnik-Allgemeinteil

Kuka-Roboter mit Steuerung KRC4

Erstellt: A. Ermer, S. Rüdiger

Gültigkeit besitzt immer die „deutsche“ Version!

Inhaltsverzeichnis Kap 12.1

12.1.6.1 Kuka-System-Datenliste: $config.dat ............................................................................. 31

Datum Thema Bemerkung Name

12.1.1 Allgemeine Themen

Die Richtlinien für Aufstellung, Handhabung und Programmierung der Roboterspezifikation

Der Anlagenlieferant ist verpflichtet qualifizierte Roboterprogrammierer einzusetzen.

Das vorliegende Dokument enthält keine anwendungsspezifischen Anforderungen, da diese

Die Systemlieferanten und Roboterprogrammierer sind verpflichtet, alle im BMW Standard

Überblick Für wen ist dieses Dokument bestimmt?

12.1.1.4 Justage-Offset lernen

Hinweis: Es ist zu berücksichtigen, dass in der Justage-Position genügend Bewegungsfreiheit pro

12.1.1.5 Tool und Base-Daten

Zum besseren Verständnis sind an wichtigen Programmstellen Kommentare einzufügen.

12.1.1.10 Dateien für die BMW Standardanwendung

12.1.1.11 Kopieren von Programmen und Dateien

12.1.1.14 Zuordnung der Tätigkeiten

Zuordnung der Tätigkeiten Ausführender

Die Bereitstellung der Inbetriebnahme Daten sind Grundvoraus-set- Anlagenbauer

Der Anlagenbauer muss die Daten auf Funktionalität und Plausibilität

Eine erneute Inbetriebnahme Aufgrund fehlerhafter Inbetriebnahme

Durchführung der Erstinbetriebnahme anhand einer Inbetriebnahme- Fa. KUKA

Bei der Inbetriebnahme werden alle Profinet-Teilnehmer auf nicht

Anbau der Werkzeuge nach Vorgabe inkl. Überprüfung (Handachsen Anlagenbauer

Bei allen Teilnehmern, die nicht über Werkzeugwechsler betrieben Programmierer

Roboter ins Fahrzeugkoordinatennetz ein messen bzw. vorgegebene Programmierer

Vorgegebene Werkzeugdaten eingeben und überprüfen Programmierer

Die Funktion Offset lernen für jedes Tool ausführen. Programmierer

Erstellung, Einbringung und Optimierung des Anwenderprogrammes, Programmierer

Risikoanalyse durchführen und ggf. Maßnahmen festlegen Anlagenbauer

Programmierung und Testen der durch die Risikoanalyse geforderten Programmierer

Einstellen und optimieren des Medienpaketes. Das Medienpaket vom Programmierer

Dokumentierung nach Vorgabe im RobotWorkbook. Programmierer

12.1.2 Prozessdaten (E/A-Bereiche)

Applikationssignale (Byte: 256-974 / Bit 2049-7800) >Zuordnung erfolgt nach E-Plan

Eine detaillierte Zuordnung ist der Datei „LIST_yymmdd_Roboterschnittstelle_BP_V2.0.xlsx“ zu ent-

12.1.3 Sicherer Roboter, Safe Operation

Grundsätzlich sind alle Roboter nach der gültigen SPEZ_xxxxxx_Sicherheitskonzept_Karosseriebau,

Die Dokumentierung aller Sicherheitsdaten hat in der Anlagensicherheitsdokumentation

Folgende Konfigurationsoptionen sind bei den Überwachungsräumen einstellbar:

12.1.3.2.3 Sichere Werkzeuge

Nur bei unterschiedlichen Geometrien die aus Zugänglichkeitsgründen nicht zusammengefasst

12.1.3.2.4 Achs-, Raum- und kart. Geschw. und sicherer Betriebshalt

Der im Lieferumfang von KUKA enthaltene Referenztaster muss verwendet werden.

Das BMW-Programm für die Justagereferenzierung „Prog250_MasterReference“ ist zu erstellen (Po-

Für den Werkzeugwechsler ohne Werkzeug ist Safe-Tool 15 zu verwenden!

Die weitere Konfiguration ist je nach Anwendungsfall vorzunehmen.

12.1.3.4 Mit geltende Dokumente

Methodenbeschreibung OLP: PR_xxxxxx_RobKalDat_SafeMove

Unterlagen von KUKA: Spezifikation_QUANTEC/ FORTEC_xxxxx

Unter anderen geltende Normen: DIN_EN_ISO_10218-1

12.1.4 Programme, allgemein

In Ausnahmefällen und nach Rücksprache/Genehmigung der jeweiligen BMW-Fachabteilung ist es

Aufgrund der Möglichkeit, Programm-Abbrüche inkl. Rückfahrbewegung zu einer Home-Stellung

Hinweis: Alle Wartungs-Programme werden Grundsätzlich aus Home 1 gestartet.

Im Arbeitsordner (R1-Verzeichnis) des Roboters ist wie folgt aufgebaut:

12.1.4.3 Zuordnungstabelle Programm-Nummern

Beispiel: Pick(Job 1) – Place(Job 2) – Spot(Job 3)

Progamm- Programm Name: