Servotechnik, PC-basierte Steuerungen und Datenbusse sind das Rückgrat moderner Verpackungsmaschinen. Doch ein schnelles Anpassen an unterschiedliche Packstoffe, Pack-güter und Formate ist nur auf standardisiertem Weg möglich.
Von unserem Redaktionsmitglied Werner Möller – ia-redaktion@t-online.de
Durch moderne Antriebs- und Steuerungstechnik sowie Informatik entstehen für die Verpackungsindustrie immer leistungsstärkere mechatronische Einheiten. Die komplexer werdenden Maschinen haben allerdings durch Änderungen und Anpassungen – gleich durch wen verursacht – hohe Zeitaufwendungen und Mehrkosten zur Folge. Darin sind die Funktionsrisiken noch nicht berücksichtigt. In künftigen Projekten gewinnen wiederverwendbare Funktionsbausteine an Bedeutung. Wer effizienter antreiben, steuern und bedienen will, benötigt Standards für Feldbusse, Schnittstellen und Automatisierungssoftware.
Bei der Steuerungs- und Antriebsschnittstelle muss generell zwischen Hardware und Software unterschieden werden. Hardwareseitig ist konkret der Antriebsbus und dessen Anschaltung zu berücksichtigen, bei der Software das Application Programmers Interface (API), also die Programmierschnittstelle, die festlegt, wie ein Programmierer mit den Achsen einer Verpackungsmaschine umgehen kann. Dazu hat die US-amerikanische Omac-Vereinigung (Open Modular Architecture und Controls) 1999 eine Zielsetzung vereinbart, die drei Standardplattformen als Basis für Verpackungsmaschinensteuerungen vorsieht.
Das leistungsfähigste System besteht aus einer PC-basierten Hardware. Nicht fehlen dürfen hier Standardnetzwerke mit dem TCP/IP-Protokoll. Kommuniziert wird über Ethernet oder drahtlos einmal mit der Leitebene oder über das Firmennetz. Den Kontakt an die Feldebene realisieren Protokolle wie Ethernet/IP oder Profinet. Herkömmliche Feldbusse binden hier langsameren E/A an die SPS-Logik. Die Motoren sind über den Antriebsbus mit den Regelgeräten verbunden.
Bei dem zweiten, etwas einfacheren System ersetzt ein Embedded-Controler den PC, während bei dem hardwaretechnisch günstigsten System diese Aufgabe den Antriebsreglern zufällt. Insbesondere beim Aufteilen der Steuerungsaufgabe auf mehrere Controller fällt bei dieser Plattform auf, dass der Antriebsbus nicht nur zur Kommunikation der Antriebsdaten zwischen dem Master und den Slaves verwendet wird. Er dient auch als Kommunikationsmedium für die verteilte Logik-Applikation. Auch das Hinunterladen der Applikation sowie das Parametrieren oder Diagnostizieren erfolgt über den Antriebsbus.
Aus der Anwendung heraus besteht kein Unterschied zwischen den Varianten. Der Nutzer kann kurzfristig entscheiden, in welche der vorhandenen Konstellationen er seine Applikation hinunterladen möchte. In der Praxis ist dieses Prinzip vergleichbar mit Microsofts .Net-Technologie, wo Programme über das Netzwerk verteilt und erst unmittelbar vor der Ausführung auf der betreffenden Maschine in den jeweiligen betriebssystemspezifischen Kontext übersetzt werden.
Was noch fehlt, ist eine durchgängige Kommunikationstechnik. Derzeit zeichnet sich ab, dass herkömmliche Feldbusse durch die echtzeitfähigen Protokolle Ethernet/IP oder Profinet auf TCP/IP-Ethernet-Standard abgelöst werden. Für einen zukünftigen Antriebsbus würde das bedeuten, dass diese Technik nur ohne firmenspezifische Anpassungen und Eingriffe Sinn macht. Erst damit können Anwender die Vorteile des niedrigen Anschaltpreises, hohen Bekanntheitsgrades und der weitverbreiteten Werkzeuge für Diagnose und Inbetriebnahme nutzen.
Antriebsbusse: Was sie leisten müssen
Ein zukünftiger Antriebsbus muss eine herstellerübergreifende Austauschbarkeit von Komponenten auf dem Antriebsbus ebenso bieten wie das Zu- oder Abschalten eines Teilnehmers. Die konkreten Anforderungen sind:
– Hohe Bandbreite ( >100 MBit/s)
– Mindestens 60 Teilnehmer an ein Bussegment
– Einfache Verdrahtung ohne Hubs oder Switches
– Maximale Kabellänge von 50 bis100 m
– Automatische Konfiguration ohne Einstellung
– Neben Regelgeräten sollen auch schnelle E/A oder Sensoren anschaltbar sein
Über einen synchronen Datenkanal mit einer Zykluszeit von 125µs werden die Daten übertragen, während der asynchrone Datenkanal mit TCP/IP als Trägerprotokoll dient. Folgende Dienste über Standard-Protokolle sind dann möglich:
– Up- oder Download von Software
– Backup oder Restore aller Daten
– Web-Diagnose und Standardkonfiguration
– Parametrierbares Versenden einer E-Mail als Warnung oder Fehlermeldung
– Neben der Zeitsynchronisation im µs-Bereich auch Datums- und Uhrzeitsynchronisation
Teilen:
