Ethernet-Kommunikation mit SICK Ranger Kamera funktioniert nicht

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

(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.

Hi
Ich stimme Rolfs Anmerkungen zu.

Als Alternative könntest Du versuchen, die Kamera direkt in das IMAQdx zu integrieren, falls Dir das Kommunikationsprotokoll bekannt ist. Dazu kannst Du den Camera File Generator von NI benutzen. Damit wäre die Kamera auch in den MAX integriert und auch das Memory Management wäre einfacher.

Gruß Holger

Danke für eure Antworten.

Zitat:Als Alternative könntest Du versuchen, die Kamera direkt in das IMAQdx zu integrieren, falls Dir das Kommunikationsprotokoll bekannt ist. Dazu kannst Du den Camera File Generator von NI benutzen. Damit wäre die Kamera auch in den MAX integriert und auch das Memory Management wäre einfacher.

... ist leider nicht möglich, da auch spez. Parameter- und Calibration-Files auf die Kamera geladen werden müssen
und ein spez. Framegrabber zum Einsatz kommt.

Zitat: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.

... ich denke mal, da wird mein Problem liegen. Leider habe ich keinen Zugang zum Quellcode der DLLs.

Also belasse ich es erst einmal doch bei LV2010.

(06.01.2012 15:48 )ahebauer schrieb:  ... ist leider nicht möglich, da auch spez. Parameter- und Calibration-Files auf die Kamera geladen werden müssen
und ein spez. Framegrabber zum Einsatz kommt.

Für diesen Zweck könntest Du Dir basierend auf IMAQdx eine lvlib schreiben, die das erledigt. Dafür gibt es die Low-Level Read/Write-Serial-VIs. Das hab ich für eine andere Kamera schon einmal gemacht.

Das mit dem spez. Framegrabber verstehe ich nicht. Der ist Dach in der Kamera drin und im wesentlichen unsichtbar, oder nicht? Für GigE-Kameras gibt es doch ein Standard-Protokoll. Wird das nicht eingehalten?

Gruß Holger