GigE Vision -0.3.9

implementiert von Jörg Anders <ja@informatik.tu-chemnitz.de>


Abstract

J. Anders <ja@informatik.tu-chemnitz.de> implemented a GigE Vision program library which works on Linux and MS Windows. Furthermore he wrote a WireShark plugin which allows you to sniffer GigE Vision Stream- and Control Protocol.


Zweck

GigE Vision ist ein Protokoll zum Steuerung von Kameras per UDP/IP/Gigabit-Ethernet. Diese Seite enthält die neueste Version einer zu entwickelnden GigE Vision -Programmbibliothek, die möglichst systemunabhängig sein soll.

Bisher implementiert

Quelltext

Der Quelltext ist (passwortgeschützt) in der Datei evision-0.3.9.zip (protected) (711 K).

Der Quelltext enthält außerdem eine Beispielanwendung (simpletest.cpp). Eine graphische (MFC-) Anwendung (mfctest) steht per CVS bereit. Nähere Informationen dazu findet man im (verschlüsselten) Archiv cvsinfo.zip (protected)

Übersetzung

Unter Microsoft-Windows

Mit VisualStudio-XX die Solution evision-0.3.9\evisionlib.sln durch:

      File --> Open Solution ...

öffnen, dann:

      Project --> Build Solution

Falls das mit Link-Fehlern endet, einfach nochmal:

      Project --> Build Solution

Unter Linux

      make

simpletest Starten

Unter Microsoft-Windows

       cd evision-0.3.9\simpletest\Debug
       .\simpletest.exe

Unter Linux

       cd evision-0.3.9/simpletest
      ./simpletest

Benutzung von simpletest

Die Version 0.3.9 verfügt über einen (ziemlich) robusten Resend-Algorithmus, der mit der alten Hardware bei bis zu 45% Paketverlust fehlerfrei zusammenarbeitet, das heisst, trotz dieser hohen Ausfallrate kommen aufgrund geschickt platzierter PACKETRESEND_CMDs alle Frames fehlerfrei an.

Zu Testzwecken enthält die Version 0.3.9 einen "Paketwegwerfer", der nur dann zur Verfügung steht, wenn in config.h "#define TESTING" programmiert ist. Er lässt sich über die Funktion:

      void EvLib::setTestingParameters (int p_drobProb, int p_maxdroblength, char *p_logfilename);

konfigurieren.

Dabei bedeuten:

p_drobProbdie Wegwerfwahrscheinlichkeit
p_maxdroblengthdie maximale Länge der Paketserie, die weggeworfen werden soll
p_logfilenameder Name des Logfiles, in welchem das Verhalten der Kamera dokumentiert werden soll

Der simpletest erfragt diese 3 Parameter. Werden diese "leer weggedrückt", so gelten die Standardwerte:
p_drobProb=45
p_maxdroblength=3
p_logfilename=""

Drückt man p_logfilename "leer weg", so wird nie weggeworfen und auch kein Logfile angelegt.

Nach dieser Auswahl wird man aufgefordert, die Interfaces anzugeben, auf welchen nach Kameras gesucht wird. Wenn man das nicht genau weiß, so kann man im Zweifelsfall auf die Auswahl verzichten.

Die Anwendung stellt eine Verbindung zur ersten gefundenen Kamera her und listet deren Parameter auf.

Es findet ein Test des High-Level EvisionImageHandlers statt. Auf der Konsole werden die gerade benutzten Blöcke ausgegeben.

Die Eingabe "s <ENTER>" stoppt den Stream-Channel.

mfctest übersetzen (nur Microsoft-Windows)

Wichtig! Das Verzeichnis mfctest muss im gleichen Verzeichnis wie evisionlib platziert werden!

Man lädt das Projekt:

      Open ... --> Projekt --> mfctest.vcproj

Dann:

      Build --> Build mfctest

mfctest Starten (nur Microsoft-Windows)

Doppelklick auf evision-0.3.9\mfctest\Debug\mfctest.exe

Benutzung von mfctest (nur unter Microsoft-Windows)

Vorbemerkung: Wenn simpletest nicht funktioniert, so wird auch mfctest nicht funktionieren. Deshalb sollte man zunächst simpletest ausprobieren.

Zunächst:

    Kamera --> Suchen

In dem Dialog eventuell auf Interfaces klicken und die Interfaces aussuchen, auf denen Kameras erwartet werden.

Dann die Schaltfläche neue Suche betätigen.

Im Auswahlfeld oben werden die gefundenen Kameras angezeigt. Man kann eine Kamera wählen.

Eventuell kann man jetzt die MTU, den StreamChannel- Timout und den ControlChannel - Timeout verändern. Außerdem lässt sich der Port ändern, auf dem die Kamera erreicht wird.

Im Zweifelsfall sollte man alle diese Werte beibehalten.

Dann:

	    Capture --> Start Capture

Dadurch wird ein Stream-Channel eröffnet und das empfangene Bild wird dargestellt. Das Capturen wird durch:

	    Capture --> Stop Capture

wieder beendet. Es wird die Framerate, die Datenrate und die Zahl der verlorengegangenen Pakete angezeigt. Eine genaue Buchführung der verlorengegangenen Pakete findet man anschließend in der Datei logg.txt.

Theoretisch kann man im Menü Sockets auswählen, welche Socket-Art verwendet wird. Da in der Version 0.3.9 jedoch nur die Berkeley-Sockets implementiert sind, führt die Verwendung der Turbo-Sockets zu Fehlern.

Das Programm wird durch:

	    Datei --> Beenden

beendet.

Was tun bei Timout ?

Wenn keine Bilder emfangen werden aber ansonsten alles andere funktioniert, so liegt es am Windows-Firewall. Man sollte diesen versuchsweise abschalten:

  Start --> Systemsteuerung --> Sicherheitscenter -->
  Windows-Firewall --> Inaktiv

Anderenfalls sollte man zunächst testen, ob die Netzwerkkarte für den Empfang so genannter "Jumbo-Frames" geeignet ist.

Unter Microsoft-Windows:

       start --> Systemsteuerung --> Netzwerk --> Netzwerkverbindungen -->
	   (Karte mit rechter (!) Maustaste auswählen) --> Eigenschaften --> Konfigurierern -->
	   Rest ist kartenabhängig, nach "Jumbo-Frame" suchen

Unter Linux:

        /sbin/ifconfig ethX mtu 6000

Werden weiterhin viele oder nur Timeouts angezeigt, so rührt das meist daher, dass sich die vorangegangene Anwendung die Exklusiv- oder Kontrollrechte gesichert und nicht wieder freigegeben hat. In diesem Fall hilft leider nur das Aus- und wieder Einschalten der Kamera.

Achtung! Nach dem Einschalten muss man ca. 40 Sekunden warten, bevor die Kamera wieder betriebsbereit ist!

GigE Vision -Plugin für Wireshark

Das Archiv evisionplugin-0.0.5.zip (protected) enthält ein Wireshark- (Ethereal-) Plugin für GigE Vision . Man benötigt eine (relativ) neue Variante des Programms. Tests mit Wireshark-0.99.x verliefen erfolgreich.

Installation

Unter Windows löscht man, falls vorhanden:

      del C:\Programme\Wireshark\plugins\<version>\evstrplugin.dll
      del C:\Programme\Wireshark\plugins\<version>\evctrlplugin.dll

Unter Linux löscht man, falls vorhanden:

      rm $HOME/.wireshark/plugins/evstrplugin.so
      rm $HOME/.wireshark/plugins/evctrlplugin.so

Nach dem Ent-zip-pen gibt man die folgenden Kommandos:

      cd evisionplugin-0.0.5
      copy *.dll C:\Programme\Wireshark\plugins\<version>\

Unter Linux:

      cd evisionplugin-0.0.5
      cp *.so $HOME/.wireshark/plugins/

Erste Kontrolle: Wenn die Plugins erfolgereich installiert sind, so muss es im Menü Help --> Supportet Protocols 2 neue Einträge: Evision Ctrl und Evision Stream geben.

Anmerkung 1: Das Evision-Control-Plugin erkennt das Protokoll anhand des benutzten Ports (57600). Sollte dieser jemals geändert werden (im Standard ist Port 3956 vorgesehen), so muss das Plugin geändert und neu übersetzt werden. Als Alternative kann man über das Menü Analyse --> Decode As .. die Dekodierung als GigE Vision Control Protocol erzwingen.

Anmerkung 2: Das Evision-Stream-Plugin erkennt das Protokoll automatisch durch so genanntes Port-Tracking.

Übersetzung aus der Quelle

Unter Linux holt man sich die Wirkeshark- Quelle von http://www.wireshark.org entpackt und konfiguriert diese. Dann passt man im GNUmakefile die Variable WIRESHARK_PATH so an, dass sie auf das Wireshark-Quellverzeichnis verweist, dann:

    cd evisionplugin-0.0.5
    make

Unter Microsoft-Windows ist die Übersetzung eine so grauenvolle Angelegenheit, dass dieses auf auf einer eigenen Seite beschrieben werden muss.

UDPTEST

In der Datei udptest.zip (protected) (7 K) befindet sich ein Testprogramm, welches verdeutlichen soll was passiert, wenn man 2 Interfaces im gleichen Subnetz hat und in das Subnetz sendet.

Die Übersetzung kann mit VisualC++ geschehen. Allerdings befindet sich im Verzeichnis udptest\Debug das bereits übersetzte Programm udptest.exe.

Angenommen die Konfiguration ist so:

1. Interface169.254.0.9
2. Interface169.254.0.10
Kamera169.254.0.1

Startet man udptest so:

	.\udptest.exe 169.254.0.1

so schickt das Programm 10000 UDP-Pakete à 1500 Byte an den Port 69 (TFTP-Port) der Kamera. Die Kamera wird darauf nicht reagieren, weil sie auf diesem Port nicht "hört".

Man wird nun feststellen, dass die Sendung immer nur über ein Interface geht. Das kann man mit Ethereal tun. Eindrucksvoller ist es, wenn man einen Switch mit Traffic-Anzeige-LED hat. Dann leuchtet nur eine der beiden grell auf, während die andere dunkel bleibt.

Falls nur ARP - Pakete kommen sollten, so setzt man ARP statisch durch die Kommandos:


	arp -s 169.254.0.1 00-01-02-03-04-05 169.254.0.9
	arp -s 169.254.0.1 00-01-02-03-04-05 169.254.0.10

(Den letzten Parameter muss man an die tatsächlichen IP-Adressen der beiden Interfaces anpassen.)

Der Grund ist die Routingtabelle. Diese kann man sich unter Windows durch das Kommando:

	route print

ausgeben lassen. Sie sieht (z.B.) so aus:

ZeileNetzwerkzielNetzwerkmaskeGatewaySchnittstelleAnzahl
1127.0.0.0255.0.0.0127.0.0.1127.0.0.11
2169.254.0.0255.255.0.0169.254.0.9169.254.0.930
3169.254.0.0255.255.0.0169.254.0.10169.254.0.1030
4169.254.0.9255.255.255.255127.0.0.1127.0.0.130
5169.254.0.10255.255.255.255127.0.0.1127.0.0.130
6169.254.255.255255.255.255.255169.254.0.9169.254.0.930
7169.254.255.255255.255.255.255169.254.0.10169.254.0.1030
8224.0.0.0240.0.0.0169.254.0.9169.254.0.930
9224.0.0.0240.0.0.0169.254.0.10169.254.0.1030
10255.255.255.255255.255.255.255169.254.0.9169.254.0.91
11255.255.255.255255.255.255.255169.254.0.10169.254.0.101

Entscheidend sind die Zeilen 2 und 3. Sie weisen beide einen Weg ins Netz 169.254.0.0. Soll jetzt ein Paket zum Ziel 169.254.0.1 geschickt werden, so wandelt das Betriebssystem die IP-Adresse und die Netzmaske in Binärzahlen um und vollzieht ein bitweises UND:

169.254.0.1 = 10101001111111100000000000000001
&
255.255.0.0 = 11111111111111110000000000000000
=
169.254.0.0 = 10101001111111100000000000000000

Und nun geht das Betriebssystem in der Routingtabelle die Spalte "Netzwerkziel" von oben nach unter durch. In der Zeile 2 gibt es die erste Übereinstimmung. Folglich gehen Pakete zum Ziel 169.254.0.1 (bei dieser Routingtabelle) stets über das Interface 169.254.0.9 und niemals über das Interface 169.254.0.10, denn nach dem Finden des Ziels wird kein weiterer Versuch durchgeführt.

API

Die API ist Bestandteil der Programmdokumentation und hier (protected) zu finden.

Die beiden StreamHandler sind gleichfalls in der Programmdokumentation enthalten und werden hier (protected) beschrieben.

Praktische Beispiele zu ihrer Nutzung findet man in simpletest.cpp und MyStreamHandler.cpp/h sowie im mfctest.

Programmdokumentation

Eine mit Hilfe von Doxygen generierte Programmdokumentation mit grapischer Darstellung der Klassenbeziehungen ist hier (protected) verfügbar.

Vortrag

Am 06.09.2006 wurde ein Vortrag (protected) gehalten. Download (protected) (60 K)