Nicht mehr wegzudenken: Bedeutung von GigE-Vision für die Industrielle Bildverarbeitung

Kabellängen von bis zu 100m pro Segment ermöglichen Multi-Kameraanwendungen auch mit weiträumig verteilten Kameras. Die Anbindung der Kameras kann über sehr preiswerte Switches vorgenommen werden. Die günstigsten 5-Port-Switches zum Anbinden von vier Kameras an einen Port, die das wichtige Feature Jumbo-Pakete unterstützen, kosten derzeit unter 20E, also weniger als 5E pro Kamera. Aufgrund der stetig steigenden Leistungsfähigkeit heutiger Industrierechner – Moores Gesetz lässt grüßen – können demnach mittlerweile mehrere unabhängige Bildverarbeitungsanwendungen auf einem Rechner laufen. Diese Skalierung ermöglicht immer kostengünstigere Bildverarbeitungslösungen. GigE-Vision hat auch das reibungslose An- und Abschalten von Kameras im Standard vorgesehen, wenn beispielsweise die Stromversorgung einer Maschine plus angeschlossener Kamera ab- oder zugeschaltet wird, um die übrigen Kameras nicht zu beeinflussen. Beim Multiplexen von mehreren Kameras in einen Datenstrom dürfen die benötigten Bandbreiten nicht außer Acht gelassen werden. Es ist mit einer Faustformel sehr einfach, die benötigte Bandbreite, die eine Kamera erzeugt zu berechnen: Bildbreite * Bildhöhe * BytesProPixel * Bilder Pro Sekunde (BytesProPixel: bei Schwarz/Weiß und 8Bit pro Pixel = 1, bei Farbe und RGB = 3) Dies ergibt die Netto-Datenrate für diese Kamera und Betriebsart. Um den Protokoll-Overhead von GigE-Vision zu berücksichtigen, müssen 5% hinzuaddiert werden. Eine VGA-Kamera in Schwarz/Weiß und 8Bit per Pixel und 30 Bildern pro Sekunde erzeugt also ca. 10MByte/s. Das ist die Bruttodatenrate pro Kamera. Die Bilddaten werden in einzelne Pakete (der Größe 1.500Byte bis ca. 9KByte bei Jumbo-Paketen) verpackt auf die Reise geschickt. Maximal kann eine Gigabit- Ethernet-Schnittstelle 125MByte/s akzeptieren. Ins Verhältnis gesetzt zur Bruttodatenrate können entsprechend viele Kameras an einem Netzwerk-Port bandbreitentechnisch unabhängig voneinander betrieben werden. In unserem Beispiel könnten demzufolge ein Dutzend Kameras über vier Switches kaskadiert angeschlossen werden. Wichtig ist jetzt: Wenn die benutzte Kamera eine höhere Bildfrequenz unterstützt, so wird sie die geringere Bilddatenrate durch Pausen zwischen den Bildern realisieren. Dementsprechend müssen die Kameras bereits während der Übertragung eines Bildes abgebremst werden, damit sie sich gegenseitig Zeit für die Übertragung der Pakete lassen. GigE-Vision hat hier einen Mechanismus vorgesehen, der wenig intuitiv ist, nämlich in \’timetick delay between pakets\‘. mvBlueCOUGAR-X Kameras erlauben die direkte Eingabe der Bandbreite in kByte/s. Kameraintern wird daraus die Berechnung des Delays zwischen den Paketen vorgenommen. Bild 2 illustriert dieses Verhalten: Oben ist die Umschaltung auf die Methode GevSCBWControl zu sehen – mit dem voreingestellten maximalen Wert 122.000kByte/s, was 125MByte/s entspricht. Unten dargestellt ist die Reduzierung auf 10MByte/s und in der Folge die Reduzierung der Bildfrequenz. Die mvBlueCougar-X Kameras bieten einen großen First in First out-Speicher (FiFo) von 64MByte für die Zwischenspeicherung von Bildern an. Eine VGA-Kamera kann dort mit voller Auflösung ca. 80 Bilder zwischenspeichern. Normalerweise bleibt dieser Speicher aus Latenzgründen unbenutzt, weil immer soviel Bilddaten abfließen sollten, wie sensorseitig entstehen. Der Speicher kann aber beispielsweise vorteilhaft benutzt werden, um eine begrenzte Anzahl von Bildern in einem schnelleren Burst-Modus aufzunehmen und sie langsamer auszugeben. Bild 3 illustriert dieses Verhalten: In einem anderen Beispiel kann ein konfigurierbar großer Teil des Speichers dazu verwendet werden, um die Pretrigger Historie, ähnlich wie bei einem Oszilloskop, aufzunehmen. Anzumerken ist, dass diese Option nicht Bestandteil des Standards ist, aber durch die Kamera Beschreibungs-Datei (gemäß dem GenICam Standard) einfach benutzbar gemacht wird. Folgender Anwendungsfall: Der Anwender nimmt eine Maschine auf, die zu einem bestimmten Moment ein bestimmtes Verhalten zeigt, auf welches sich triggern lässt. Mit Pretrigger kann der Anwender die Anzahl Bilder vor diesem Ereignis einstellen, die ihn auch interessieren. Die Kamera nimmt im Live-Mode zyklisch diese Pretrigger-Bilder in einem Ringpuffer auf. Wenn das Triggerereignis auftritt, werden zuerst die Pretrigger-Bilder, gefolgt von den Post-Trigger Bildern ausgegeben. Die Kamera gibt die Bilddaten anfangs beschleunigt aus bis zu dem Moment, wo sich Bildeinzug und Auslesen wieder synchronisieren (Bild 4). Counter und Timer GenICam stellt Counter- und Timer-Funktionalitäten bereit. Diese eignet sich hervorragend, um Kameras mit konfigurierbaren Eigenschaften zu \’bauen\‘. Ein Beispiel zeigt, wie eine Kamera für den Betrieb mit zwei wechselnden Integrationszeiten konfiguriert werden kann: In diesem Beispiel werden die beiden Integrationszeiten mit zwei Timern, die beiden unterschiedlich langen Wartezeiten mit zwei Countern belegt. Die Verschaltung erfolgt dadurch, dass sich Counter an einem Timer-Ende starten lassen und Timer an einem Zähler-Ende. Die Signale werden über Und- und Oder-Glieder verknüpft, worüber sich die Kamera triggert (Bild 5). Power-over-Ethernet (PoE) Zur diesjährigen Vision wird Matrix Vision die Option PoE für die mvBlueCougar-X vorstellen. Power-over-Ethernet (PoE) gibt die Möglichkeit, Kameras über das Netzwerkkabel mit Strom zu versorgen. Damit sind dann Einkabellösungen bei vielen Applikationen möglich. Allerdings sind PoE-fähige Switches oder Netzwerkkarten derzeit noch deutlich teurer. Zudem kann nach heutigem Standard die Kamera über das eine Kabel nur per Software-Trigger getriggert werden, eine präzisere Triggerung per Hardware oder die Nutzung der Ausgänge erfordert weiterhin eine separate Verkabelung. IEEE1588 Eine reizvolle Idee ist die im GEV 2.0 zur Standardisierung vorgeschlagene netzwerkweite synchrone Uhr gemäß IEEE1588 in einer GigE Vision 2.0-kompatiblen Kamera. Dies ermöglicht untereinander synchronisierten Kamerabetrieb ohne weitere Hardware-Unterstützung unter dem Motto: Alle Kameras laufen mit 30fps und beginnen damit um 12.00Uhr. Das geht bislang nicht, weil die Kameras nicht wissen, wie spät es ist, der Timestamp in den Kameras nicht gegen Drift geschützt ist und somit die Kameras über die Zeit auseinander laufen. Die Implementierung von IEEE1588 erfordert gleichwohl einigen Aufwand auf Hardware-wie auf Firmware- oder Software-Seite. Dieses Feature wird also wahrscheinlich High End-Kameras vorbehalten sein oder für spezielle Anwendungen im Broadcast-Bereich genutzt werden, wo Kameras immer synchronisiert arbeiten sollten. Vision 2011: Halle 4b, Stand 31