LabVIEW
Problem with 'Port Number' for TCP/IP device
(assuming wondows)
Try to run the old software and connect to the camera. Now open a command prompt and type "netstat -n". You should see a list of active connections, search the one with the camera IP and note the remote port number.
Most likely, this won't help you much unless you know how to talk to the camera via TCP. What is the make and model. Have you checked their web site for an application note?
Altenbach had mostly said what is to say about this. The port number of a device is a vital information that belongs to the protocol specification of that device. Since you do not have the port number it seems very likely that you do not have the protocol specification yet. Finding out the port number is not difficult but reverse engineering a binary protocol is almost like trying to put together the original document after it went through the shredder. Basically it is a no-go or there needs to be much economical value behind it to justify the expense.
@MarkfromSAGE wrote:
I'm currently talking to a camera device using a serial connection from LV7.1. (The device is used for reading 2D bar codes or datamatrices, scribed into a glass plate with a laser). This works well except I suspect I am getting buffer overruns from the amount of data the camera is sending back. The manufacturer of the camera suggests I use the ethernet connection as this should prevent this problem. I ran their software and the communication is fine - I can get all the information I want via the network.
However, when I try to put together a labview vi to establish a connection to the networked device, I am forced to enter a remote port number into the TCP open connection vi. I don't know what this should be. Can anyone help me determine what it is?
Notes: I successfully 'pinged' the device, so I know the IP address. The manufacturer's setup software makes no mention of remote port number. I am connected to the device via a hub, which is also connected to my LAN.
Your options are to get the protocol specification from the camera manufacturer and if he is not cooperating (which is quite common as most companies in image processing consider every piece of information as highly important proprietary information) you should look for possibilities to either embed their software (ActiveX for instance) into your application or find such an interface from someone else who might have gotten the specs after signing a deadly Non Disclosure Agreement.
And of course remember this next time you need to buy image processing hard- or software and take the availiiability of low level specs into consideration. A cheap camera or software can get expensive if you can't use the provided software for whatever reason and need to get (or in worst case reverse engineer) a protocol or other solution to connect the piece to your own prefered software environment.
Maybe in a long time from now even people in image processing will understand that free flowing information is almost always better for everyone involved.
Rolf Kalbermatter
