Mehrere Kameras verwenden

Ab v2.0.0 kann eine Installation mehrere Kameras betreiben. Jede Kamera ist ein Modul mit eigener Konfigurationsdatei und eigener Adresse auf dem Data Layer, und jede angeschlossene Kamera benötigt eine eigene Lizenz. Siehe Neue Kamera-Einstellungsdateien anlegen.

Gegenüber einer Installation mit einer Kamera kommt eine gemeinsam genutzte Ressource hinzu: Alle Kameras senden ihre Bilder über eine Netzwerkverbindung an einen Port des Geräts, auf dem der Cam Driver läuft. Diese Verbindung ist die Grenze. Diese Seite beschreibt, wie Sie das Netzwerk aufbauen und wie Sie sicherstellen, dass niemals zwei Kameras gleichzeitig ein Bild übertragen.

Warum mehrere Kameras geplant werden müssen

Eine GigE-Vision-Kamera verteilt ein Bild nicht über die Zeit bis zum nächsten Bild. Sie sendet das gesamte Bild als Burst von UDP-Paketen mit der vollen Übertragungsrate der Verbindung und ist danach still. Eine 1-Gbit/s-Verbindung trägt einen solchen Burst zur Zeit.

Beginnt eine zweite Kamera ihren Burst, während der erste noch läuft, erhalten der Switch und der Netzwerk-Port des Hosts mehr Daten, als sie weiterleiten können. Die überzähligen Pakete werden verworfen. GigE Vision hat keine Wiederholung, die einen ganzen Burst retten kann, das Bild kommt also unvollständig an und der Cam Driver verwirft es:

  • control/status/code ist -10004 (couldNotCaptureImage), und über den Handshake bleibt capture/ready false, bis ein reset erfolgreich ist.

  • Das Protokoll enthält eine Zeile wie Error: Image is incomplete with filled size 1076592 / 1259712 = 85 %.

Eine einzelne Kamera hat die Verbindung für sich allein und zeigt das selten. Deshalb kann eine Installation, die mit einer Kamera funktioniert, ausfallen, sobald eine zweite hinzukommt - ohne dass sich an Kameras, Verkabelung oder Beleuchtung etwas geändert hat.

Zwei Maßnahmen verhindern das, und beide werden benötigt:

  1. Die Verbindung trägt ausschließlich Kameradaten - siehe Hardwareaufbau.

  2. Die Kameras übertragen nicht gleichzeitig - siehe Triggerquelle. Wie Sie das erreichen, hängt von der Triggerquelle ab.

Hardwareaufbau

Switch und Kabel

Jumbo Frames

Der Switch, jeder Kabelweg und der Netzwerk-Port des Hosts müssen Jumbo Frames unterstützen, und die MTU-Größe muss auf jedem Gerät im Pfad auf 8000 oder 9000 gesetzt sein. Ein großes Paket trägt etwa sechsmal so viele Bilddaten wie die Voreinstellung von 1500 Byte, was den Overhead pro Paket und die Zahl der Pakete verringert, die verloren gehen können. Setzen Sie packetSize des Cam Drivers auf die MTU-Größe, die der Pfad tatsächlich unterstützt; ein Paket, das größer ist als die kleinste MTU im Pfad, wird verworfen. Siehe Änderung der MTU-Größe.

Übertragungsrate

Verwenden Sie an jedem Port 1 Gbit/s oder mehr. Der Port des Hosts ist der Engpass, denn alle Kameras teilen ihn sich.

Kabel

Verwenden Sie "Foil Shielded Twisted Pair"-Kabel. Im Schaltschrank zeigt sich schlechte Schirmung als gelegentlich unvollständige Bilder, die genau wie ein Bandbreitenproblem aussehen.

Keine SPS-Daten im Kameranetz

Verwenden Sie einen Switch, der ausschließlich Kameradaten trägt: die Kameras und den einen Port des Hosts, auf dem der Cam Driver die Bilder empfängt. Schließen Sie die SPS, den Feldbus und das übrige Anlagennetz an einen anderen Port des Hosts an.

Das ist in beide Richtungen wichtig:

  • Ein Bild-Burst füllt die Verbindung für die wenigen Millisekunden, die er dauert, vollständig aus. Alles andere auf dieser Verbindung wird so lange verzögert, was für ein echtzeitfähiges oder zyklisches Protokoll schädlich ist.

  • Umgekehrt ist jedes Telegramm, das das Anlagennetz auf die Kameraverbindung legt, Bandbreite, die dem Burst fehlt - unvollständige Bilder werden dadurch wahrscheinlicher.

Triggerquelle

Die Kameras dürfen nicht gleichzeitig übertragen. Wie Sie das erreichen, hängt davon ab, was sie auslöst.

Triggerquelle Vorgehen

Software-Trigger (capture)

Nehmen Sie eine Kamera nach der anderen auf und starten Sie die nächste Kamera erst, wenn das vorherige Bild angekommen ist. Siehe Software-Trigger: eine Kamera nach der anderen.

Hardware-Trigger

Alle Kameras belichten prinzipbedingt im selben Moment, deshalb müssen die Kameras selbst ihre Pakete verschränken. Berechnen und setzen Sie GevSCPD und GevSCFTD. Siehe Hardware-Trigger: Bandbreite zwischen den Kameras aufteilen.

Software-Trigger: eine Kamera nach der anderen

Der Cam Driver hat keinen synchronisierten Trigger für mehrere Kameras. Jedes Modul löst seine eigene Kamera aus, sobald sein eigener Request eintrifft. Der Client bestimmt also, wann welche Kamera überträgt - und der Client muss die Aufnahmen nacheinander ausführen.

Führen Sie die Capture-Handshakes zweier Kameras niemals so aus, dass beide Kameras gleichzeitig übertragen. Eine Aufnahme muss abgeschlossen sein, bevor der nächsten Kamera das Capture aufgetragen wird.

Eine Aufnahme startet, wenn capture/request wieder auf false fällt, und sie ist abgeschlossen, wenn capture/ready wieder auf true steht. Zwei Kameras können daher gemeinsam vorbereitet und nacheinander freigegeben werden:

  1. Setzen Sie camera1 capture/request auf true.

  2. Warten Sie, bis camera1 capture/ready false ist.

  3. Setzen Sie camera2 capture/request auf true.

  4. Warten Sie, bis camera2 capture/ready false ist.

  5. Setzen Sie camera1 capture/request auf false. Kamera 1 belichtet und überträgt jetzt.

  6. Warten Sie, bis camera1 capture/ready wieder true ist. Das Bild von Kamera 1 ist angekommen und die Verbindung ist frei.

  7. Setzen Sie camera2 capture/request auf false. Kamera 2 belichtet und überträgt jetzt.

  8. Warten Sie, bis camera2 capture/ready wieder true ist.

Zwei Kameras nacheinander aufnehmen
%% Zwei Kameras werden nacheinander mit dem Software-Trigger aufgenommen. Mermaid rendert es im Browser; bearbeiten und Vorschau unter https://mermaid.live
sequenceDiagram
  autonumber
  participant C as Client (SPS oder Programm)
  participant M1 as Modul camera1
  participant M2 as Modul camera2
  M1-->>C: capture/ready = true
  M2-->>C: capture/ready = true
  C->>M1: camera1 capture/request = true
  M1-->>C: camera1 capture/ready = false
  C->>M2: camera2 capture/request = true
  M2-->>C: camera2 capture/ready = false
  C->>M1: camera1 capture/request = false
  Note over M1: Kamera 1 belichtet und überträgt<br/>die Verbindung trägt nur dieses Bild
  M1-->>C: camera1 capture/ready = true
  C->>M2: camera2 capture/request = false
  Note over M2: Kamera 2 belichtet und überträgt<br/>die Verbindung trägt nur dieses Bild
  M2-->>C: camera2 capture/ready = true

Bei mehr als zwei Kameras erweitern Sie dasselbe Muster: alle vorbereiten, dann eine nach der anderen freigeben und abwarten.

Diese Abfolge setzt die Standardeinstellung von handshakeEdge voraus, FALLING_EDGE. Mit RISING_EDGE startet eine Aufnahme, sobald capture/request true ist, sodass schon das Vorbereiten einer Kamera sie übertragen lässt. Führen Sie dann je Kamera einen vollständigen Capture-Handshake aus: Warten Sie, bis ihr capture/ready wieder true ist, bevor Sie capture/request der nächsten Kamera setzen. Siehe Wann eine Funktionalität läuft.

Wenn Sie statt des Handshakes die execute-Methode verwenden, gilt dieselbe Regel, und sie ist einfacher einzuhalten: <Kameraname>/control/capture/execute kehrt erst zurück, wenn die Aufnahme abgeschlossen ist. Rufen Sie die Methode also für eine Kamera auf, warten Sie auf ihre Rückkehr und rufen Sie sie erst dann für die nächste Kamera auf. Rufen Sie capture/execute nicht für mehrere Kameras parallel auf. Siehe Eine Methode ausführen.

Aufnahmen nacheinander kosten mehr Zeit als Aufnahmen, die sich überlappen. Reicht die Zykluszeit nicht aus, verwenden Sie einen Hardware-Trigger mit den folgenden Bandbreiteneinstellungen: Die Kameras belichten dann im selben Moment und nur die Übertragung wird auseinandergezogen.

Hardware-Trigger: Bandbreite zwischen den Kameras aufteilen

Beim Hardware-Trigger belichten alle Kameras im selben Moment - meist ist das der Grund, ihn zu verwenden -, die Aufnahmen lassen sich also nicht nacheinander ausführen. Stattdessen werden die Übertragungen verschränkt: Jede Kamera lässt zwischen ihren eigenen Paketen eine Lücke, die für die Pakete der anderen Kameras ausreicht, und jede Kamera beginnt zu einem anderen Zeitpunkt. So wechseln sich die Pakete der Kameras auf der Verbindung ab, statt zu kollidieren.

Zwei GigE-Vision-Features leisten das. Beide sind Kamera-Features, keine Einstellungen des Cam Drivers:

Feature Bedeutung

GevSCPD

Paketverzögerung. Die Lücke, die die Kamera zwischen zwei Paketen desselben Bildes lässt.

GevSCFTD

Bildübertragungsverzögerung. Wie lange die Kamera wartet, nachdem sie übertragungsbereit ist, bevor sie das erste Paket sendet. Damit werden die Kameras gegeneinander versetzt.

Schritt 1: Zeit für ein Paket

Ermitteln Sie zuerst, wie lange ein Paket die Verbindung belegt.

Byte pro Sekunde     = Übertragungsrate / 8
Zeit pro Byte        = 1 s / Byte pro Sekunde
Paket auf der Leitung = packetSize + Ethernet-Overhead
Paketzeit            = Paket auf der Leitung x Zeit pro Byte
P                    = Paketzeit + Puffer     (Puffer: 10 % bis 30 % der Paketzeit)

Der Puffer fängt den restlichen Rahmen-Overhead und die Latenz des Switches auf. Kleinere Werte lassen keine Reserve, deutlich größere verschenken Bandbreite.

Für eine 1-Gbit/s-Verbindung und packetSize 9000:

Größe Wert

Übertragungsrate

1 Gbit/s = 125.000.000 Byte/s

Zeit pro Byte

8 ns

Paket auf der Leitung

etwa 9014 Byte

Paketzeit

9014 x 8 ns = 72.112 ns

Puffer (etwa 11 %)

7.888 ns

P

80.000 ns

Schritt 2: Werte je Kamera

Mit N Kameras und n als Nummer der Kamera (1, 2, 3 …​):

GevSCPD  (jede Kamera) = P x (N - 1)
GevSCFTD (Kamera n)    = P x (n - 1)

Jede Kamera erhält dasselbe GevSCPD: Während ein Paket dieser Kamera auf der Verbindung ist, muss für je ein Paket der übrigen N - 1 Kameras Platz sein. GevSCFTD gibt jeder Kamera einen anderen Vorlauf, damit nicht alle ihr erstes Paket im selben Moment auf die Verbindung legen.

Tabelle 1. Zwei Kameras, P = 80.000 ns
Kamera GevSCPD GevSCFTD

Kamera 1

80.000 ns

0 ns

Kamera 2

80.000 ns

80.000 ns
Tabelle 2. Vier Kameras, P = 80.000 ns
Kamera GevSCPD GevSCFTD

Kamera 1

240.000 ns

0 ns

Kamera 2

240.000 ns

80.000 ns

Kamera 3

240.000 ns

160.000 ns

Kamera 4

240.000 ns

240.000 ns

Schritt 3: Verbleibende Bildrate prüfen

Die Verzögerungen bremsen jede Kamera. Prüfen Sie, ob das Ergebnis noch zu Ihrer Zykluszeit passt und ob der Trigger nicht schneller gesendet wird, als eine Kamera liefern kann.

Für ein Bild von 960 x 1280 Pixeln in Mono8 (1.228.800 Byte), packetSize 9000 und zwei Kameras:

Größe Wert

Bildgröße

960 x 1280 x 1 Byte = 1.228.800 Byte

Bilddaten pro Paket

etwa 8.992 Byte

Pakete pro Bild

1.228.800 / 8.992 = 137 Pakete

Abstand zwischen zwei Paketen

72.112 ns + 80.000 ns = 152.112 ns

Übertragung eines Bildes

137 x 152.112 ns = etwa 20,8 ms

Höchste Bildrate je Kamera

etwa 48 Bilder pro Sekunde

Beide Kameras erreichen das gleichzeitig, es kommen also etwa alle 20,8 ms zwei Bilder an. Dieselbe Kamera allein und ohne Verzögerungen würde ein Bild in etwa 9,9 ms übertragen und etwa 101 Bilder pro Sekunde erreichen: Zwei Kameras zusammen kosten ungefähr so viel Gesamtzeit wie zwei Bilder nacheinander, aber ohne Kollisionen.

Wo die Werte gesetzt werden

Der Cam Driver setzt GevSCPSPacketSize und GevSCPD aus der Kamerakonfiguration:

Einstellung in der Kamerakonfigurationsdatei Knoten auf dem Data Layer Kamera-Feature

packetSize

<Kameraname>/transport-layer/packet-size

GevSCPSPacketSize

packetDelay_us

<Kameraname>/transport-layer/inter-packet-delay-us

GevSCPD

Beide Knoten sind schreibgeschützt, solange die Kamera verbunden ist. Setzen Sie sie daher in der Kamerakonfigurationsdatei oder auf dem Data Layer, bevor Sie die Kamera verbinden.

Für GevSCFTD gibt es keine eigene Einstellung. Setzen Sie es je Kamera über die Feature-Knoten der Kamera unter hdvisionsystems/lumiscan-cam-driver/<Kameraname>/features oder in einer Feature-Datei, die in cameras[].featureFiles des Moduls eingetragen ist und bei jedem Verbinden der Kamera angewendet wird. Siehe GenICam-Features.

Der Wert von packetDelay_us wird trotz des Namens unverändert an GevSCPD der Kamera übergeben. GevSCPD und GevSCFTD werden in der jeweiligen Einheit der Kamera gezählt, die sich zwischen Herstellern unterscheidet: Manche Kameras zählen in Nanosekunden, viele in Ticks des Zeitstempelzählers. Lesen Sie GevTimestampTickFrequency aus den Feature-Knoten der Kamera und rechnen Sie um: Ticks = Nanosekunden x GevTimestampTickFrequency / 1.000.000.000. Bei den verbreiteten 125.000.000 Hz (8 ns pro Tick) ergeben die obigen 80.000 ns den Wert 10.000. Ziehen Sie die Dokumentation des Kameraherstellers heran und prüfen Sie den geschriebenen Wert, indem Sie das Feature zurücklesen.

Weitere Hinweise

  • Verwenden Sie eine Flanke als Trigger (TriggerActivation auf RisingEdge, FallingEdge oder AnyEdge). Ein Pegel (LevelHigh, LevelLow) erzeugt die hier beschriebene Verschränkung nicht.

  • Halten Sie die Triggerfrequenz unter der in Schritt 3 berechneten Bildrate. Die Verzögerungen senken sie, und eine Kamera, die schneller getriggert wird, als sie übertragen kann, verwirft Bilder.

  • Die Rechnung setzt voraus, dass alle Kameras dieselbe Bildgröße, dasselbe Pixelformat und dieselbe packetSize verwenden. Unterscheiden sie sich, berechnen Sie P aus dem größten Paket und prüfen Sie das Ergebnis mit der langsamsten Kamera.

  • Sind Bilder weiterhin unvollständig, erhöhen Sie den Puffer aus Schritt 1 in Richtung 30 % oder verkleinern Sie das Bild über die ROI der Kamera.

Das Verfahren folgt der Application Note Bandwidth sharing in multi-camera systems von LUCID Vision Labs, die es für deren Kameras beschreibt.