LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Video transmission from one computer to another computer over TCP

Solved!
Go to solution

There is an interesting situation and if I use both server VI and client VI on the same computer everything works as expected but if I run Server VI and Client VI on different computers, communication is established but I cannot view the video on SERVER VI. No errors Client There is also data flow from server to server. It just doesn't show the video.
Does anyone know the solution to this problem?
In the application I want to create;
-Server VI should be opened first, then Client VI should be run.
-Client VI should read random double numbers from Server VI.
-Client VI will send videos from webcam to Server VI.

 

 

Download All
0 Kudos
Message 1 of 64
(653 Views)

Do you have a license for IMAQdx on the other computer?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 64
(621 Views)

yes. I think there is no problem here. Because I have tested for each computer. Both computers can display video without any problem.

It just doesn't display after it's transferred over TCP.

0 Kudos
Message 3 of 64
(613 Views)

@constructionworker wrote:

yes. I think there is no problem here. Because I have tested for each computer. Both computers can display video without any problem.

It just doesn't display after it's transferred over TCP.


You haven't posted anything about troubleshooting steps you took, so we'er just starting with the very basics.  Have you checked that it's not a firewall issue?

 

Anyone who wants to jump in, please do.  I don't claim to be an expert in video transmission by any means.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 64
(605 Views)

I don't quite understand what you mean by firewall. I can stream video with different methods, but I decided to try this method because they work a bit slow.
I run both VIs on one computer and there is no problem, but when I run either of them on a different computer, this problem occurs.

0 Kudos
Message 5 of 64
(598 Views)

@constructionworker wrote:

I don't quite understand what you mean by firewall. I can stream video with different methods, but I decided to try this method because they work a bit slow.
I run both VIs on one computer and there is no problem, but when I run either of them on a different computer, this problem occurs.


Oh, I just opened your client VI.  You create a connection to localhost.  I don't think that will work if it's on a different computer than the server VI.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 64
(580 Views)

Your code is quit strange. One thing that sticks out is that in your client code the server address is hardcoded to "localhost" which would definitely not allow you to communicate with the server on a different computer. the way that you manage the connections on the server is quite strange. Rather than blindly sending the as flattened data you should create a very basic message header which at a minimum would be the length of the following data. I don't know why you are using a timeout error to actually read the image data. That makes no sense at all. I would also assume that your image data is much larger than 3 bytes, which is all that you try to read for each image. You should not use the type cast to load the data into the image indicator. You should reverse what you did on the client side. So you should use "Unflatten From String" to return the data is an image. You status check probably won't work like you would like since you will only listen for connections for 100 ms when you are in the Status Check state. If you are in the send state and a client tries to connect there will be no listener to accept the connection. From a client/server perspective this is not a good implementation. You really need to define some type of basic protocol for your data.

 

With respect to the wall, on your server PC is port 6341 open? If the firewall blocks this port your client will never be able to connect.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 7 of 64
(575 Views)

@Mark_Yedinak wrote:

Your code is quit strange. One thing that sticks out is that in your client code the server address is hardcoded to "localhost" which would definitely not allow you to communicate with the server on a different computer. the way that you manage the connections on the server is quite strange. Rather than blindly sending the as flattened data you should create a very basic message header which at a minimum would be the length of the following data. I don't know why you are using a timeout error to actually read the image data. That makes no sense at all. I would also assume that your image data is much larger than 3 bytes, which is all that you try to read for each image. You should not use the type cast to load the data into the image indicator. You should reverse what you did on the client side. So you should use "Unflatten From String" to return the data is an image. You status check probably won't work like you would like since you will only listen for connections for 100 ms when you are in the Status Check state. If you are in the send state and a client tries to connect there will be no listener to accept the connection. From a client/server perspective this is not a good implementation. You really need to define some type of basic protocol for your data.

 

With respect to the wall, on your server PC is port 6341 open? If the firewall blocks this port your client will never be able to connect.


-I defined ''localhost'' to the IP address of the other computer, I only used localhost while sharing the code while testing a computer.

-I used the timeout so that the server is not stopped even if the client is closed.

 

Currently the data transfer seems to be working fine except sending ''12275500'' for the second video when I created a change as below.

 

Is there any way to speed this up?

constructionworker_0-1657306897429.png

 

client

constructionworker_1-1657306918468.png

server 

Untitled.png

 

0 Kudos
Message 8 of 64
(566 Views)

I would still recommend a rewrite of the code. The server logic is bizarre to say the least. A true server would have a task which simply listens and spawns next tasks as clients connect. This is not necessary if the server supports one, and only one client at a time. You should not use the timeout event as a trigger to actually read the data. this is a very strange construct. As mentioned earlier, a basic protocol would help quite a bit. For instance, every message you send would include a header which contains a message type and a length field. The length field would specify the amount of data which is contained in the message. So, the server could simply read with a timeout of -1 waiting for x number of bytes. X is the size of your header. If the message ID is a U16 and the length is a U32, your header is 6 bytes. After reading this you check the length field to see if there is more data. If so, read it. If not process the message and then go back to waiting for the read of a message header. There is no strange "look for a timeout which will then trigger me to actually read data" construct. If necessary, you can put a short timeout on the read of the header which simply allows the server to do some other processing between receiving messages. However, hear when you receive a timeout you clear the error, do some basic task/processing if necessary and then go back to waiting for a message header.

 

This is a much cleaner server implementation than what you have posted. It also has a basic protocol which allows you to have a variety of message types. Other messages could be an exit/stop message, clear buffers or any other type of processing that may be needed.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 9 of 64
(559 Views)

@Mark_Yedinak wrote:

I would still recommend a rewrite of the code. The server logic is bizarre to say the least. A true server would have a task which simply listens and spawns next tasks as clients connect. This is not necessary if the server supports one, and only one client at a time. You should not use the timeout event as a trigger to actually read the data. this is a very strange construct. As mentioned earlier, a basic protocol would help quite a bit. For instance, every message you send would include a header which contains a message type and a length field. The length field would specify the amount of data which is contained in the message. So, the server could simply read with a timeout of -1 waiting for x number of bytes. X is the size of your header. If the message ID is a U16 and the length is a U32, your header is 6 bytes. After reading this you check the length field to see if there is more data. If so, read it. If not process the message and then go back to waiting for the read of a message header. There is no strange "look for a timeout which will then trigger me to actually read data" construct. If necessary, you can put a short timeout on the read of the header which simply allows the server to do some other processing between receiving messages. However, hear when you receive a timeout you clear the error, do some basic task/processing if necessary and then go back to waiting for a message header.

 

This is a much cleaner server implementation than what you have posted. It also has a basic protocol which allows you to have a variety of message types. Other messages could be an exit/stop message, clear buffers or any other type of processing that may be needed.


To be honest, I changed the server and client logic a little bit for me.
Let me explain the type of application I want to have as follows;
Application on first computer:
-It is the application to run first. The application will start running and wait for the second computer to send the videos.
-If the application on the second computer starts running, it will display the number of connections to understand that the application on the second computer is connected.
If the videos start coming, it will start sending some numerical information.

Application on Second Computer:
-It is the second application that will work.
The application will run, send the connection information to the first computer and start reading and sending videos from the cameras.
-It will display the incoming numerical data on the screen as an extra.

 

I'm trying to understand your suggestion to rewrite the code, it sounds like a cleaner implementation.

But I suspect there is some difference between the method you suggested and the application I want to create.
Even if the application on the second computer has a problem and closes, I do not want the application on the first computer to close. I tried to explain the application I want to create above in detail. I added the generated code.
If you can make changes to the code, I can try so I can better understand what you mean.

-I removed the timeout case structure.
Thank you for all your suggestions.

Download All
0 Kudos
Message 10 of 64
(549 Views)