TCP/IP zu einer Kamera

drfunfrock

Level-1
Beiträge
934
Reaktionspunkte
72
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir haben hier so ein Vision System von Cognex, um Kabelfarben zu überprüfen. Das ist eine kleine Kamera inkl. Prozessor für die Bildverarbeitung im Gehäuse mit den Massen 12cmx 5cm x 4 cm. Ich wollte mich per LabView per TCP/IP an die Kamera koppeln, was mit einem einfachen Telnet-Programm auch klappte, nur nicht mit LabView. Zuerst öffnete ich die Verbindung, dann schrieb ich ein Kommando und nichts passierte.

Nach einem Tag mit vielem Ausprobieren, fand ich dann heraus, dass ich nach dem Öffnen der Verbindung erstmal lesend zugreifen musste, um ein Kommando schreiben zu können. Ich verstehe leider nicht warum?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das ist eine SmartImageSensor SC für die Spektralanalyse noch von DVTSensors bevor die von Cognex übernommen wurden. Im Prinzip muss ich per TCP/IP nur den String #Yi<CRLF> zur Kamera schicken und die wird getriggert. Als Ergebnis kommt eine Zeile wie

PASS FAIL FAIL PASS<CRLF>

heraus.

Ich habe das so angefangen:

1) Öffnen der Verbindung
2) Ein Dummyread mit Timeout 100 ms/ Warum der sein muss weiss ich nicht, habe ich experimentell ermittelt
3) Senden des Kommandostrings
4) Warten auf Resultat und lesen

Bei 4) gibt es manchmal Probleme, dass heisst es wird nichts gelesen und es kommt zu einem Timeout, aber eben nur manchmal. Anscheinend ist mir etwas über TCP/IP nicht so klar, aber die herkömmlichen TCP/IP-Bücher fahren immer auf das Unix-Interface ab und solche Problem sind denen unbekannt.

Ich hatte lange hier nicht geschrieben, weil ein Projekt mir einfach keine Zeit liess, aber für eine Antwort wäre ich echt dankbar
 
Ja wir haben 4 Scripts in der Kamera, die jeweil eine Pass oder Fail ausgeben. Ich habe dann einen Datalink (Siehe DVT Intellect Programm) in der Kamera eingerichtet, der nichts weiter macht, als die Ergebnisse der 4 Scripte in der Form

<Result> <Result> <Result> <Result><CRLF>

zur Verfügung zu stellen. Das heisst:

1) Kamera triggern
2) Ergebnis kommt als ASCII-Format per TCP/IP z.B.

Das geht auch per Telnet und selbst mit dem Telnet auf WindowsXP funktioniert das. Nur wenn ich das per TCP/IP und Labview machen möchte, bekomme ich ab und zu Probleme, weil es zu einem Timeout beim Lesen desTCP-Streams kommt. Ich mache also etwas beim Protokoll falsch. Meine Strategie ist die dass ich ein Kommando sende und dann eine Pause einlege, um dann den Lesevorgang zu starten. Die Frage ist nun, ob dieses Vorgehen dem TCP-Protokoll angemessen ist.
 
Hast Du schon mal Ethereal gestartet um zu sehen worin der Unterschied zwischen Telnet und Labview besteht?

Produktauswahl machen wir auch über Ethernet/IP, explizites Messaging, da "sehen" wir in unserer SPS virtuelle Ein-/Ausgangsworte.
 
Jah ich habe ja Wireshark gestartet und festgestellt, dass sich der TCPIPBuilder mehrfach connected. Daraufhin habe ich meine Strategie geändert:

1) Connect mit Timeout 3s und Wiederholung wenns nicht klappt
2) Lesezugriff: 0 Bytes, Timeout 10ms (Frage mich nicht warum das so sein muss)
3) Senden des Kommandos. Bei einem Fehler wird der Vorgang wiederholt.
4) Lesen der Antwort, Timeout=10ms. Bei Timeout wird der Vorgang max. 2s lang wiederholt
5) Disconnect

Das scheint so zu klappen. Bei TCP/IP wird anscheinend nichts im System-Buffer gespeichert, so dass bei einem zu späten Lesezugriff der Kram weg ist. Ich habe auch noch eine Doku erhalten, die mir sämliche Kommandos dokumentiert, wie sie das Windowsprogramm zum Programmieren verwendet, somit kann ich jetzt auch verschiedene Konfigurationen verwenden.

Jedenfalls hoffe ich, dass diese Struktur auch die nächsten Tests überstehen wird. Ich will in Zukunft auch andere Geräte so steuern, weil es einfach jede Menge Arbeit spart. Dieselbe Struktur kann ich auch mit TwinCat (Beckhoff) realisieren und möchte eine Kommunikation mit LabView (Dient der Steuerung eines Funktionstestes.) aufbauen, um den Funktionstest damit zu steuern.
 
Zurück
Oben