---
title: "Mehrere Kameras verwenden"
description: "Mehrere Kameras an einem LumiScan Cam Driver - Switch- und Port-Aufbau, und wie Software- oder Hardware-Trigger gleichzeitiges Senden verhindern."
product: "LumiScan Cam Driver"
component: "lumiscan-cam-driver-de"
version: "2.2.1"
display_version: "2.2.1.12"
latest_version: true
language: "de"
url: "https://docs.hdvisionsystems.com/de/lumiscan-cam-driver-de/lumiscan-camdriver/using-multiple-cameras.html"
---

# Mehrere Kameras verwenden – LumiScan Cam Driver

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](https://docs.hdvisionsystems.com/de/lumiscan-cam-driver-de/lumiscan-camdriver/creating-new-camera-settings-files.html).

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 {#why-planning-is-needed}

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](https://docs.hdvisionsystems.com/de/lumiscan-cam-driver-de/lumiscan-camdriver/using-multiple-cameras.html#hardware-setup).
2. Die Kameras übertragen nicht gleichzeitig - siehe [Triggerquelle](https://docs.hdvisionsystems.com/de/lumiscan-cam-driver-de/lumiscan-camdriver/using-multiple-cameras.html#trigger-source). Wie Sie das erreichen, hängt von der Triggerquelle ab.

## Hardwareaufbau {#hardware-setup}

### Switch und Kabel {#switch-and-cables}

- **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](https://docs.hdvisionsystems.com/de/lumiscan-cam-driver-de/lumiscan-camdriver/initializing-the-camera.html#mtu-size-change).
- **Ü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 {#separate-plc-traffic}

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 {#trigger-source}

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](https://docs.hdvisionsystems.com/de/lumiscan-cam-driver-de/lumiscan-camdriver/using-multiple-cameras.html#software-trigger). |
| 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](https://docs.hdvisionsystems.com/de/lumiscan-cam-driver-de/lumiscan-camdriver/using-multiple-cameras.html#hardware-trigger). |

### Software-Trigger: eine Kamera nach der anderen {#software-trigger}

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.

> [!IMPORTANT]
> 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**

```mermaid
%% 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.

> [!NOTE]
> 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](https://docs.hdvisionsystems.com/de/lumiscan-cam-driver-de/lumiscan-camdriver/general-concept-of-handshake.html#when-a-functionality-runs).

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](https://docs.hdvisionsystems.com/de/lumiscan-cam-driver-de/lumiscan-camdriver/execute-a-method.html).

> [!NOTE]
> 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 {#hardware-trigger}

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 {#calculate-the-packet-time}

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 {#calculate-the-delays}

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 {#calculate-the-frame-rate}

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 {#set-the-delays}

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](https://docs.hdvisionsystems.com/de/lumiscan-cam-driver-de/lumiscan-camdriver/initializing-the-camera.html#genicam-features).

> [!IMPORTANT]
> 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 {#hardware-trigger-notes}

- 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](https://support.thinklucid.com/app-note-bandwidth-sharing-in-multi-camera-systems/) von LUCID Vision Labs, die es für deren Kameras beschreibt.