LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP Write

Hi Adam,

 

I couldnt understand which number you are talking about  , I couldnt see the image that you mentioned , sorry about that. I am trying to communicated between two LabVIEW programs 

LabVIEW 8.5 and LabVIEW 8.51

Labview Vision Acquisition 8.5 

and LabVIEW IMAQ USB.

The network i worked with is  LAN and 3G (HSPA) , I tested in both of them. UDP Write works well with LAN but gets stuck with 3G . I tried replacing UDP with TCP and it works well. It happens everytime with the 3G however sometimes it happens after sending 50 sets of data (each around  8 KB) while other times more quickly. I wonder what UDP Write.vi is waiting for because UDP doesnt wait for acknowledgement unlike TCP.

 

Could you please post the image that you were talking about again . 

 

 

0 Kudos
Message 11 of 18
(1,191 Views)

Hi aman,

Thanks for the additional information.  I made that post at the end of a very long day and completely forgot to attach the image.  Sorry about that.  It is attached to this post.  You can get the task manager through the keyboard shortcut of Ctrl-Shift-Esc

.

Message Edited by Adam_H on 12-19-2008 10:12 AM
Adam H
National Instruments
Applications Engineer
0 Kudos
Message 12 of 18
(1,179 Views)

Hi Adam,

The CPU usage percentage is around 36% to 26% , there is no other program running except labview and the internet connection program. The value keeps on changing (those changes occured in half a minute) and it says labview is using 2 to 4 threads ( the third column) where as the system idle process shows 70 and system as 30). Is this informaiton any useful to find what the problem might be. I disconnected the internet connection but yet UDP Write is waiting for the data transmission to finish (doesnt return anything) . The problem doesnt happen when LAN is used but only with wireless. If I use TCP , then the problem occur but only with UDP Write. 

Aman

0 Kudos
Message 13 of 18
(1,155 Views)

Hi Aman,

We are getting closer to the useful data.  This number will always be changing.  Was the information you gave me for when the VI was "running" or not?  It would be best if I could know what this number is both when the VI is running and not running.  If I can compare these two numbers it will help me to see what is going on when the VI is locked up.

Message Edited by Adam_H on 12-26-2008 01:10 PM
Adam H
National Instruments
Applications Engineer
0 Kudos
Message 14 of 18
(1,114 Views)

Hi Adam,

 

The CPU Usage % that I had mentioned is while the VI is running. Once the program is stuck, the only way to get out is to kill from task manager so it is not possible to find out CPU usage after stopping the program. Before running the VI, the CPU Usage % is 0 to 1 %.

 

aman 

Message Edited by aman_bajra on 12-26-2008 10:21 PM
0 Kudos
Message 15 of 18
(1,102 Views)

Hi aman,

I have a few more questions for you.  Before the VI locks up do you receive the information on the other computer?  What are you using to connect to the 3G network?  I was a little unclear on whether it worked with TCP or not.  Did you try this and if so did work or did it fail as well? 

 

Also could try slowing the transfer speed down.  So instead of sending 5 frames per second send let say 1.  This way we can see if maybe you are exceeding the available bandwidth.  When you do this let me know if it takes longer to lock up or if it stops locking up completely.

 

Adam H
National Instruments
Applications Engineer
0 Kudos
Message 16 of 18
(1,048 Views)

Hi Adam, Aman,

 

I realize this thread is terribly old, but it describes the problem I'm running into exactly.  I am tracing a hang-up in one of my VIs to where a UDP write simply hangs and doesn't time out after the default 25 seconds.

 

I most normally see the problem with a compiled version of my VI and I don't see this problem when running under LabView (I'm using 8.5), although I don't run it under LabView very often.

 

When I get this block, the CPU usage of my VI process becomes essentially zero. 

 

In order to recover, I need to kill the VI process and restart it.  Other threads in the VI continue appear to continue running, however.

 

0 Kudos
Message 17 of 18
(767 Views)

It looks like this was identified in 65723/4CKGJ6Q7 and corrected in LabView 8.5.1.

 

0 Kudos
Message 18 of 18
(757 Views)