Machine Vision im Steuerungstakt
Immer öfter bremst die historisch gewachsene Trennung von Automatisierung und Vision genau dort, wo Präzision und Geschwindigkeit gefragt sind. Mit EtherCAT als normiertem Kommunikations-Backbone wird die Bildverarbeitung hingegen zum gleichberechtigten Netzwerkteilnehmer und Baustein der Steuerungsarchitektur. Für Maschinenbauer, Applikationsingenieure und Vision-Integratoren bedeutet das: hochgenaue Synchronisation mit allen Maschinenprozessen, reduzierte Engineering- und Hardwarekosten sowie eine vereinfachte Inbetriebnahme und Diagnose.
Wer heute in der Konstruktion eine Inspektionsaufgabe integriert, kämpft selten mit dem Algorithmus. Er kämpft mit den Schnittstellen. Separate Vision-Controller hängen an einem eigenen Netzwerk, tauschen über ein Gateway Statuswörter mit der SPS aus und arbeiten auf nichtgekoppelter Zeitbasis. Ein Blitz-Controller triggert die Beleuchtung über eine dritte Signalkette, ein weiteres Engineering-Tool verwaltet die Kameraparameter. Jede dieser Grenzen kostet Bauraum im Schaltschrank, Klemmpunkte, Inbetriebnahmezeit – und vor allem Determinismus. Bislang war die Kommunikation zwischen Bildverarbeitung und Steuerung komplex und schwer beherrschbar, weil Latenzen aus Netzwerkstacks und Betriebssystemeinflüssen nicht sicher kalkulierbar sind. Ein doppeltes Problem: Die Anlage wird langsamer als nötig, und sie erfordert Spezialwissen in zwei Disziplinen gleichzeitig.
„Die Trennung von Bildverarbeitung und Steuerung war nie eine technische Notwendigkeit, sondern das Ergebnis zweier getrennt gewachsener Ingenieurkulturen“, betont Bernd Stöber, Senior Produktmanager Vision bei Beckhoff. „Wer heute noch zwei Welten pflegt, bezahlt das mit Komplexität – dem im Maschinenbau teuersten Werkstoff überhaupt.“
Grund 1: einheitliche Zeitbasis
Die technische Grundlage der Integration von SPS und Vision ist der Distributed-Clocks-Mechanismus (DC) von EtherCAT. Im Gegensatz zu rein synchroner Kommunikation arbeiten verteilte Uhren mit hoher Jitter-Toleranz. Der Abgleich erfolgt vollständig hardwarebasiert: Die Zeit des ersten DC-fähigen Slaves wird zyklisch an alle weiteren Teilnehmer verteilt, die Laufzeitverzögerung im Netzwerk wird beim Hochlauf – auf Wunsch auch kontinuierlich im Betrieb – gemessen und kompensiert. Der resultierende Jitter liegt deutlich unter 1 µs, typischerweise im zweistelligen Nanosekundenbereich. Die absolute Systemzeit wird mit 64 Bit-Auflösung geführt, die Zeitmessung erfolgt mit 1 ns Auflösung.
Für die Bildverarbeitung ist das der entscheidende Hebel: Kameras und Beleuchtungen werden zeitlich exakt definiert zu allen anderen Maschinenprozessen betrieben – relativ zu den Geräten im Netzwerk ebenso wie absolut zu einer übergeordneten Referenzzeit. Die Bildaufnahme lässt sich damit deterministisch auf eine Förderbandposition oder eine Achsposition triggern, statt sie über eine Lichtschranke und einen unbestimmten Software-Handshake anzustoßen. Track-and-Trace-Anwendungen und die exakte Produktverfolgung in EtherCAT-synchronisierten Applikationen werden so zur Standardaufgabe.
Grund 2: Trigger und Licht aus der Echtzeit
Konsequenterweise entsteht auch das Licht aus derselben Zeitbasis. Die LED-Ansteuerungsklemme EL2596 enthält ein flexibles Netzteil, das die Beleuchtung mit dem gewünschten Strom und der gewünschten Spannung versorgt – von Dauerlicht bis zu kurzen Lichtpulsen im kHz-Bereich. Jeder Einzelblitz wird per Distributed Clocks beziehungsweise Timestamp von der Steuerung kontrolliert ausgelöst. Die Klemme verfügt über einen Triggerausgang zum Auslösen der Kamera sowie eine schnelle Strom- und Spannungsregelung, sodass beispielsweise auch Zeilenkameras eine konstante Beleuchtung erhalten. Die umfangreiche Echtzeitdiagnose der Ein- und Ausgangsströme und -spannungen erlaubt eine detaillierte Kontrolle der Lichtstärke. Beim Verlassen eines vorgegebenen Lastkorridors schaltet die Klemme zum Schutz der LED rückstellbar ab. Für ein mikrosekundengenaues Hardware-Triggersignal an die Kamera steht zusätzlich die zeitstempelbasierte Ausgangsklemme EL2262 zur Verfügung.
Die Multi-Color-LED-Beleuchtungen von Beckhoff in den Bauformen Flächen-, Ring- und Balkenlicht erzeugen konstante Lichtverhältnisse und schaffen im spektral anpassbaren Pulsbetrieb den bestmöglichen Kontrastunterschied zwischen Prüfmerkmal und Umgebung. Weil die Synchronisierungsfähigkeit über Distributed Clocks keinen externen Triggerloop erfordert, ist der Pulsbetrieb ohne zusätzliche Hard- und Software-Schnittstellen umsetzbar. Im Effekt frieren sehr hohe Lichtintensitäten die Bewegung ein, ohne die Beleuchtung thermisch zu überlasten. Bauteile müssen für die Prüfung nicht mehr abgebremst und wieder beschleunigt werden, was Platz in der Anlage spart. Gleichzeitig sinken Netzteilleistung, Kühlaufwand und Energieverbrauch, die LED-Lebensdauer steigt und die Empfindlichkeit gegenüber Umgebungslicht sinkt.
Grund 3: kürzere Reaktionszeiten
Dass Vision-Ergebnisse ohne Verzug in eine Bewegung münden, ist zuerst eine Eigenschaft des Busses. EtherCAT umgeht die Nachteile von Standard-Ethernet durch sein Funktionsprinzip: In der Regel genügt ein einziger Frame, um in allen Teilnehmern die Ausgangsinformationen zu aktualisieren und mit demselben Frame die Eingangsinformationen einzulesen. Jeder Teilnehmer liest die an ihn adressierten Daten on the fly und legt seine Eingangsdaten in den weitergeleiteten Frame; das Telegramm wird lediglich um die Hardware-Durchlaufzeit verzögert. Es gibt keine Store-and-Forward-Latenz durch Switches, keine Protokollstacks in der Zwischenebene und keine unvorhersehbaren Verzögerungen, weil ausschließlich der Master aktiv senden darf.
Die Bildverarbeitung läuft also nicht neben der Steuerung, sondern in ihr. Ohne Zeitverluste durch Schnittstellen kann direkt auf die Ergebnisse reagiert werden – buchstäblich in der nächsten Zeile SPS-Code und mit verzögerungsfreier Kommunikation zu den Motion-Komponenten.
Grund 4: Aufwand und Kosten reduziert
In der Stückliste schlägt sich die Integration wirtschaftlich positiv nieder. Es entfallen der separate Vision-Controller, der Blitz-Controller und die zugehörigen Schnittstellen. Alle Vision-Hardwarekomponenten werden in einer Engineering-Umgebung über EtherCAT parametriert. Ebenso wichtig ist die Freiheit im Anlagenlayout: EtherCAT erlaubt die freie Topologiewahl und kombiniert Linien-, Stern- und Baumstrukturen, sodass Kameras und Beleuchtungen dort platziert werden, wo der Prozess sie braucht, und nicht dort, wo eine Switch-Infrastruktur es zulässt.
EtherCAT P führt diesen Gedanken bis an die Kamera: Kommunikation und Power laufen über ein vieradriges Standard-Ethernet-Kabel. Dabei bleiben alle EtherCAT-Eigenschaften – z. B. freie Topologie, Verarbeitung der Telegramme im Durchlauf, hochgenaue Synchronisation, umfangreiche Diagnose – erhalten. Anders als bei klassischem Power over Ethernet lassen sich Teilnehmer wie Kameras und die zugehörigen Beleuchtungen kaskadiert an einem Einspeisegerät betreiben. Das Ergebnis sind reduzierte Engineering- und Hardwarekosten, eine vereinfachte Inbetriebnahme und ein spürbar geringerer Anlagen-Footprint. Besonders deutlich wird das bei den Vision Units von Beckhoff, die Kamera, Multicolor-LED-Beleuchtung und fokussierbare Optik mit Liquid-Lens-Technologie in einem gekapselten IP65/67-Gehäuse vereinen. Die SPS steuert über EtherCAT sämtliche Einstellungen der Funktionskomponenten zur Laufzeit – Fokuslage, Lichtfarbe, Intensität und Pulslänge sowie die Kameraparameter.
Grund 5: durchgängige Diagnose
Vision profitiert unmittelbar von den systeminhärenten Diagnoseeigenschaften des Busses. In jedem Teilnehmer prüft der EtherCAT Slave Controller das durchlaufende Telegramm über eine Prüfsumme; nur fehlerfrei empfangene Telegramme werden der Applikation zur Verfügung gestellt, fehlerhafte inkrementieren einen Zähler und werden für die nachfolgenden Teilnehmer gekennzeichnet. Durch Auslesen dieser Fehlerzähler lokalisiert der Master die Fehlerstelle exakt – ein wesentlicher Vorteil gegenüber klassischen Feldbussen, bei denen sich Störungen auf der gemeinsam genutzten Leitung ausbreiten und die Quelle unbestimmt bleibt. Selten auftretende Störeinflüsse werden erkannt und verortet, bevor sie die Maschinenfunktion beeinträchtigen.
Selbst ein loser Stecker ist über den Link-Lost-Counter schnell auffindbar. Hinzu kommen das Einscannen und der Vergleich der Netzwerktopologie beim Hochlauf sowie Diagnosemechanismen auf allen im Feldbusstandard spezifizierten ISO/OSI-Ebenen. Weil Maschinenwerte und Bilddaten auf derselben Zeitachse liegen und Bilder mit zuverlässig nachvollziehbaren Zeitstempeln gespeichert werden, lässt sich die Ursachenanalyse anschließend über Achsprofile, I/O-Signale und Aufnahmen hinweg führen. Im Gegensatz zu einer klassischen GigE-Vision-Kamera, bei der feste Usersettings einprogrammiert sind, bleibt die EtherCAT-gesteuerte Hardware stets offen für die zur Laufzeit von der SPS vorgegebenen Parameter. Das erleichtert nicht nur den Austausch im Servicefall, sondern auch die Suche nach fehlerhaften Parametern in den eingebundenen Geräten entfällt.
Fazit: vom Add-on zum integralen Maschinenbestandteil
Die Basis für eine effiziente Vision-Integration bildet nicht die Automatisierungstechnik, sondern die Kommunikationstechnologie dahinter. EtherCAT ist als offener Standard normiert – einschließlich Applikationsschicht und Geräteprofilen – und wird von der EtherCAT Technology Group als offiziellem Normungspartner der IEC weiterentwickelt. Genau diese Normierung macht aus einer Kamera einen gleichberechtigten Teilnehmer der Automatisierung: Sie bekommt dieselbe 64-Bit-Systemzeit wie Servoachse und Digitalklemme, sie liegt im selben zyklischen Prozessabbild, sie wird über dieselben Diagnosemechanismen überwacht. Wo bislang ein Gateway zwischen Vision-Controller und SPS stand, steht heute ein Frame, das im Durchlauf verarbeitet wird. EtherCAT benötigt typischerweise nur ein einziges Telegramm für das gesamte Netzwerk und ist damit schlanker und schneller als andere Feldbus- oder Industrial-Ethernet-Technologien. Vision wird so vom Add-on zum integralen Maschinenbestandteil, ohne dass der Konstrukteur dafür eine zweite Systemwelt pflegen muss.