Roboterprogrammierung mit SPS-Entwicklungsumgebung
Von der SPS auf den Roboter
Um einen Roboter in die Produktionslinie zu integrieren, sind Anlagenbauer gezwungen, fehlendes Roboterwissen hausintern aufzubauen oder extern einzukaufen. Dabei gilt es, wichtige Fragen zu klären, wie: Welcher Roboter ist der richtige? oder Wer kann den Roboter in Betrieb nehmen? Darüber hinaus lässt sich fehlendes Roboter-Know-how mithilfe der Programmierung über eine SPS ausgleichen und macht die mühsame Abstimmung zwischen Roboterspezialisten und SPS-Programmieren überflüssig.
Kunden verlangen mehr und mehr Flexibilität bei der Auswahl des Roboterherstellers. (Bild: Glaess Software & Automation GmbH)
Aus der Sicht der Programmierung gibt es zwei Teams: Roboterprogrammierer und SPS-Programmierer. Befindet sich das Roboter-Know-how nicht im Haus wird hierfür Fremdpersonal eingekauft. Beide Teams entwickeln für ihre Bereiche die eigentlichen Ablaufprogramme sowie die Mensch-Maschinen-Schnittstellen, also die Visualisierungen, mit denen letztendlich die Anlagenabschnitte bedient werden. Verbunden über den Feldbus werden Schnittstellen mit Handshakes vereinbart.
Probleme bei der Instandhaltung heute
Trotz hoher Verfügbarkeit der Anlagen kommt es hin und wieder zu Störungen und damit zu Anlagenstillständen. In der Regel besitzt der Endkunde ebenfalls kein Roboter-Know-how, oftmals aber ein Instandhaltungsteam mit SPS-Programmiererfahrung. Ist der Anlagenbediener nicht in der Lage, den Fehler alleine zu lokalisieren und damit die Störung zu beseitigen, wird die firmeninterne Instandhaltung zu Hilfe gerufen. Routiniert wird das Programmiergerät an die SPS angeschlossen und versucht, den Fehler zu debuggen. Führt das Debugging der SPS nicht zum Erfolg, muss ein Roboterspezialist geordert werden. Erst dann kann die Ursache in Verbindung mit dem Roboter gefunden werden, was unter Umständen einen längeren Anlagen- und damit Produktionsstillstand nach sich zieht. Oftmals wird die Suche nach der Fehlerursache durch gegenseitige Schuldzuweisungen behindert. Nicht nur während der Projektierungs-, der Programmier- und der Inbetriebnahmephase kommt es ggf. zu Reibungspunkten. Auch in der Zeit der Gewährleistung können getrennte Teams zu Mehraufwänden führen, die letztendlich den Gewinn schmälern – sowohl auf der Seite des Anlagenlieferanten, als auch beim Endkunden selbst wegen Produktionsausfällen. Hat der Anlagenlieferant einen passenden Partner mit Roboter-Know-how gefunden, der auch im Supportfall gut mit ihm zusammenarbeitet, führt eine weitere Kundenanforderung zu neuen Herausforderungen: Kunden verlangen mehr Flexibilität bei der Auswahl des Roboterherstellers. Der Anlagenlieferant hat beispielsweise die Partnerfirma beauftragt, für seine Lösung ein Roboterprogramm für einen Kuka-Roboter zu schreiben. Nun fordert der Kunde für eine nahezu identische Anlage z.B. einen Stäubli- oder einen Yaskawa-Roboter. Der Kuka-Roboter wird klassisch mit Kuka-KRL programmiert, während der Stäubli mit VAL 3 und der Yaskawa mit Inform III programmiert wird. Dabei unterscheiden sich schon die Entwicklungsumgebungen erheblich.
Die Verbindung zwischen Roboter und SPS erfolgt beispielsweise via Ethercat, Profinet oder Ethernet/IP: (Bild: Glaess Software & Automation GmbH)
Roboterintegration morgen
Nun ist der Anlagenlieferant also in der Lage, in seiner gewohnten SPS-Entwicklungsumgebung mithilfe der Roboter-Befehls-Bibliotheken den Roboter selbst zu programmieren. Bei der Planung (Auswahl des richtigen Roboters) sowie bei der Grundinbetriebnahme (Installation Robotersoftware, Einrichten der Arbeitsräume, Vermessen der Werkzeuge und der Bases) wird er noch Unterstützung benötigen. Dieser Aufwand ist jedoch sowohl zeitlich als auch von den Kosten her gesehen ein relativ geringer Teil im Vergleich zum Gesamtaufwand. Die gesamte Programmierung nimmt der Anlagenlieferant selbst vor. Unterschiedliche HMI-Programmierungen sowie das Programmieren der Schnittstellen zwischen Roboter und SPS entfallen. Mit SPS-Robotik ist nur noch ein Programmierteam nötig. Sowohl bei der Programmierung als auch bei der Inbetriebnahme vor Ort gibt es keine Abstimmungsprobleme zwischen Roboter- und SPS-Programmierer mehr. Nach der Inbetriebnahme ist der Anlagenlieferant selbst in der Lage, die gesamte Anlage, samt Roboter, selbst zu supporten. Da der SPS-Programmierer nun auf Handshakes mit dem Roboterprogramm verzichten kann, hat er die Möglichkeit, den Roboter auf völlig andere Weise in seinen Ablauf integrieren. Er behandelt nun selbst mehrere Roboter verschiedener Hersteller gleichzeitig in der SPS, wie den Rest der Anlage.
