Ethernet-Kommunikation mit SICK Ranger Kamera funktioniert nicht

(04.01.2012 11:33 )ahebauer schrieb:  Hallo,

in einem Messaufbau nutze ich eine 3D-Zeilenkamera der Firma SICK,
die über eine G-Bit Ethernet-Schnittstelle mit einem PC kommuniziert.

Die Kamera wird in LabVIEW ähnlich der NI-IMAQ VIs über ein LabVIEW
Toolkit der Firma SICK angesprochen (mit VIs wie 'Init', 'Setup', 'Start',
'Get Images', 'Stop', 'Exit'). Dieses Toolkit wurde für LabVIEW 8.5 entwickelt,
aber auch unter LV 2010 lief es immer einwandfrei.

Ich würde jetzt gerne LV 2011 nutzen, jedoch werden beim Aufruf der VI 'Get Images'
keine Daten in LabVIEW mehr empfangen (VI läuft gegen TO). Der Verbindungsaufbeu und
die Parametrierung der Kamera funktioniert komischerweise fehlerfrei (Probleme beim
Verbindungsaufbau würden im Fehler-Cluster direkt ausgegeben). Ich habe den Fehler
bereits zurückverfolgt: der TO tritt auf, da wirklich keine Daten empfangen werden. Die
Kamera zeichnet aber Daten auf und sendet diese auch (sichtbar anhand der Status-LEDs).

Meine Frage: Was wurde in Bezug auf die Etehernet-Schnittstelle von LV 2010 zu 2011
geändert, was dieses Phänomen erklären könnte?

Der Hersteller der Kamera hat leider keine Möglichkeit, eine Anpassung des Toolkits
vorzunehmen (Änderung der hinterlegten DLLs). Auch der LabVIEW-Support konnte mir
nicht weiterhelfen.

Ich hoffe, jemand hat eine Idee, wo der Fehler liegen könnte (und bitte nicht mit dem
Vorschlag kommen, doch weiterhin LV 2010 zu nutzen - die Option kenne ich selber )

Vielen Dank

Das ist viel zu breit. Was macht das SICK Toolkit? Ist es auf VIs basiert die die TCP/IP Nodes benützen? Oder ist es auf einer externen DLL basiert? Deine Meldung am Ende scheint das zweite nahezulegen, und dann ist die Chance das etwas am Handling der Ethernetschnittstelle in LabVIEW 2011 die Ursache ist ungefähr nur noch 0%.

Das sieht mehr nach einer Racecondition aus im LabVIEW Treiber, der die DLL aufruft, eventuel noch im Zusammenhang mit einem Bug/Fehler in der DLL. LabVIEW recompileiert VIs und kann Dinge auch in anderer Reihenfolge schedulen, wenn keine direkte Datenabhängigkeit besteht. Das kann bis LabVIEW 2010 eventuel gut funktionieren aber irgendeine Optimalisierung in LabVIEW 2011 kann so eine Racecondition zu Tage fördern. Wenn der DLL Aufruf das Timeout verursacht muss auch von dort gedebugt werden und das kann halt nur der DLL Entwickler mit Zugang zum Source Code.