LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Read data sent via ethernet with TCP

Hello, I have a camera that send information through an ethernet cable using the TCP protocol. I can read the data with the camera's software, but I want to do it with Labview. I found the IP adress of the camera and the port used with Wireshark, and I'm using this VI ton catch the data I need : 

Vi usedVi used

 

But unfortunately this does not work, I read no data. I tried to ping the camera using the IP adress in the Window's command prompt, and I have a timeout error, so I'm wondering if all of this is caused by the firewall that blocks the access to it. 

 

Do you think there is something I'm missing with the VI or is it related to the firewall ? 

0 Kudos
Message 1 of 12
(2,350 Views)

Generally, firewalls block ingoing TCP connections. It should not be an issue here. Are you sure all it's needed is to open the TCP connection? No commands?

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 2 of 12
(2,331 Views)

I have no knowledge in ethernet communication so I may miss some steps, but I thought that if you specify the correct IP and port you can "spy" the data if the firewall doesn't block it, with no specific command coming from the data flow itself, but I may be wrong. 

Speaking of the firewall I changed my network from the company network to the local network and I was able to ping the camera, which means that the company security was blocking it. Even in the local network I'm still not able to grab the data but this is a small step at least. 

0 Kudos
Message 3 of 12
(2,293 Views)

You need to consult the documentation describing this camera feature. Alternatively, I guess that using Wireshark you can spy the communications between the camera program and the device (I'm no expert in this, though) and see if the program sends any data packet to the camera before receiving the stream.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 4 of 12
(2,289 Views)

I actually managed to see the data with Wireshark and the communication between the PC and the camera works fine, my issue here is more to find a way to extract the data to a third party software (LabView in my case). The documentation is not explaining clearly how to do it, it provides some solutions using different industrial protocols with other third-party softwares, but I wanted to do it with LabView. 

0 Kudos
Message 5 of 12
(2,282 Views)

Well if you don't receive any data it's obvious that opening the connection is not enough, probably you need to send some request.

The question is: can you figure out from Wireshark what is missing (since you don't have a good documentation)?

 

 

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 6 of 12
(2,270 Views)

Hi!

 

First of all, you can not establish a second connection to the device to monitor the data on a first connection.

Each connection is on its own and does not see the communication on the other.

Further more, many devices allow only one connection at a time. But a ping is usually always possible.

 

The IP of your device is in the 169.254 subnet. This means the device tried to obtain an IP adress from a DHCP server, but did not get one. It has then choosen a free IP of this special subnet on its own. If the device is reconnected to the network, it might end up with an other IP adress. To communicate with the device, your computer also needs an IP in the same subnet. This could explain why you can't even ping the device. Is the working software running on the same PC? (The software for sure has a way to find out what IP the device has)

 

Sure, a firewall can cause problems, but I guess it's something different.

 

Also, your code has two problems:

 

It tries to establish a connection for 10 seconds, and if it fails, it will enter the WHILE loop with an error. The TCP Read will just pass the error from its input to its output without doing anything, also not waiting the 25s timeout. Since the error is fed into the TCP Read again in the next iteration, the loop will run as fast as possible, causing high CPU load. 10s is more than enough to establish a connection, but you will never notice if you have no connection or are simply receiving no data, if you don't listen to your CPU fan.

 

If the connection can be established (no error), the TCP Read will try to read 200 bytes for 25s. If it does not receive 200 bytes, it will throw an timeout error 56, which it feeds to itself in the next iteration. Like above, the loop will run as fast as possible and will never again try to read data.

 

Message 7 of 12
(2,247 Views)

@HFotia wrote:

I actually managed to see the data with Wireshark and the communication between the PC and the camera works fine, my issue here is more to find a way to extract the data to a third party software (LabView in my case). The documentation is not explaining clearly how to do it, it provides some solutions using different industrial protocols with other third-party softwares, but I wanted to do it with LabView. 


Which industrial protocols?  I've used both MODBUS and Ethernet/IP with LabVIEW before.  You have to download some VIs or DLLs to use them, but you can do it.  Can you tell us what brand and model the camera is?  Some have their own toolkits you can use.  FLIR, for instance, has a "Spinnaker SDK" for its line of cameras, which while it doesn't officially list as supporting LabVIEW I have gotten it to work as well.

 

As for the initial questions... sometimes "Ping" doesn't work either because of a firewall, but also could be because the device itself is programmed not to respond to a ping. I've used maybe a couple dozen Ethernet devices with LabVIEW and there were 2 that just wouldn't return pings for some reason but would still communicate otherwise.

 

For the other question though, some devices will send out information as soon as a connection is made but others won't send out anything until they receive some form of instructions to start sending.  If your camera is in that second category, then that's why you don't get data.  If you check with Wireshark again, there's a fair chance that it doesn't just open the port, it opens it and sends a packet with an instruction in it which then starts the camera streaming.

0 Kudos
Message 8 of 12
(2,241 Views)

@Sebastian.Weber  a écrit :

First of all, you can not establish a second connection to the device to monitor the data on a first connection.

Each connection is on its own and does not see the communication on the other.

Further more, many devices allow only one connection at a time. But a ping is usually always possible.

Ok I didn't knew that, so it means that I have to wait that the data is sent to the camera software and find a way to send the data from it. 

Concerning the ping thing, I swapped between company network and local network. The ping worked, so it was a company IT security issue I guess.

 


@Sebastian.Weber  a écrit :

The IP of your device is in the 169.254 subnet. This means the device tried to obtain an IP adress from a DHCP server, but did not get one. It has then choosen a free IP of this special subnet on its own. If the device is reconnected to the network, it might end up with an other IP adress. To communicate with the device, your computer also needs an IP in the same subnet. This could explain why you can't even ping the device. Is the working software running on the same PC? (The software for sure has a way to find out what IP the device has)


You're right about the DHCP, I did not think about it but as I switched to the local network I have no longer a link to the DHCP server. But from what I see in Wireshark the PC does have an IP in the same 169.254 subnet. 

 


@Sebastian.Weber  a écrit :

Also, your code has two problems:

 

It tries to establish a connection for 10 seconds, and if it fails, it will enter the WHILE loop with an error. The TCP Read will just pass the error from its input to its output without doing anything, also not waiting the 25s timeout. Since the error is fed into the TCP Read again in the next iteration, the loop will run as fast as possible, causing high CPU load. 10s is more than enough to establish a connection, but you will never notice if you have no connection or are simply receiving no data, if you don't listen to your CPU fan.

 

If the connection can be established (no error), the TCP Read will try to read 200 bytes for 25s. If it does not receive 200 bytes, it will throw an timeout error 56, which it feeds to itself in the next iteration. Like above, the loop will run as fast as possible and will never again try to read data.


Ok so if I understand well it is better to link directly the "TCP Open" and "TCP Close" error teminals without going through the loop, and do not use the "TCP Read" error terminal, or at least avoid the shift register so it not feeds itself with the error. 

 

Thank you for these informations Sebastian !

0 Kudos
Message 9 of 12
(2,217 Views)

@Kyle97330  a écrit :

Which industrial protocols?  I've used both MODBUS and Ethernet/IP with LabVIEW before. 

 The options available are EtherNet/IP, PROFINET, SLMP, CC-Link IE Field basic and Mobus TCP.

 


@Kyle97330  a écrit :
Can you tell us what brand and model the camera is?

Sure, I am using a Cognex DM475 camera. 

 


@Kyle97330  a écrit :

For the other question though, some devices will send out information as soon as a connection is made but others won't send out anything until they receive some form of instructions to start sending.  If your camera is in that second category, then that's why you don't get data.  If you check with Wireshark again, there's a fair chance that it doesn't just open the port, it opens it and sends a packet with an instruction in it which then starts the camera streaming.


I'll check it out, I will see if I am able to decrypt the first messages sent between the PC and the camera. 

0 Kudos
Message 10 of 12
(2,214 Views)