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.
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.
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)
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 |
make |
cd evision-0.3.9\simpletest\Debug .\simpletest.exe |
cd evision-0.3.9/simpletest ./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_drobProb | die Wegwerfwahrscheinlichkeit |
p_maxdroblength | die maximale Länge der Paketserie, die weggeworfen werden soll |
p_logfilename | der 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.
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 |
Doppelklick auf evision-0.3.9\mfctest\Debug\mfctest.exe
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.
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 eth X 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!
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.
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.
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.
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. Interface | 169.254.0.9 |
2. Interface | 169.254.0.10 |
Kamera | 169.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:
Zeile | Netzwerkziel | Netzwerkmaske | Gateway | Schnittstelle | Anzahl |
---|---|---|---|---|---|
1 | 127.0.0.0 | 255.0.0.0 | 127.0.0.1 | 127.0.0.1 | 1 |
2 | 169.254.0.0 | 255.255.0.0 | 169.254.0.9 | 169.254.0.9 | 30 |
3 | 169.254.0.0 | 255.255.0.0 | 169.254.0.10 | 169.254.0.10 | 30 |
4 | 169.254.0.9 | 255.255.255.255 | 127.0.0.1 | 127.0.0.1 | 30 |
5 | 169.254.0.10 | 255.255.255.255 | 127.0.0.1 | 127.0.0.1 | 30 |
6 | 169.254.255.255 | 255.255.255.255 | 169.254.0.9 | 169.254.0.9 | 30 |
7 | 169.254.255.255 | 255.255.255.255 | 169.254.0.10 | 169.254.0.10 | 30 |
8 | 224.0.0.0 | 240.0.0.0 | 169.254.0.9 | 169.254.0.9 | 30 |
9 | 224.0.0.0 | 240.0.0.0 | 169.254.0.10 | 169.254.0.10 | 30 |
10 | 255.255.255.255 | 255.255.255.255 | 169.254.0.9 | 169.254.0.9 | 1 |
11 | 255.255.255.255 | 255.255.255.255 | 169.254.0.10 | 169.254.0.10 | 1 |
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 = | 10101001 | 11111110 | 00000000 | 00000001 |
& | ||||
255.255.0.0 = | 11111111 | 11111111 | 00000000 | 00000000 |
= | ||||
169.254.0.0 = | 10101001 | 11111110 | 00000000 | 00000000 |
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.
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
.
Eine mit Hilfe von Doxygen generierte Programmdokumentation mit grapischer Darstellung der Klassenbeziehungen ist hier (protected) verfügbar.
Am 06.09.2006 wurde ein Vortrag (protected) gehalten. Download (protected) (60 K)