LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to increase UDP write VI transmit size

Solved!
Go to solution

I get the following error while trying to transmit a message using the UDP transfer VI:

 

Error 113 occurred at UDP Write in dataServer.vi

Possible reason(s):

LabVIEW:  A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram was smaller than the datagram itself.

 

Does anyone know how to increase the internal buffer size to allow larger datagrams?

0 Kudos
Message 1 of 10
(6,104 Views)
Thanks for the help. The example is for a UDP read; I am getting the error on a UDP write.
0 Kudos
Message 3 of 10
(6,095 Views)

It is the same you need increase size of buffer ,

But in udp it is better you send litte datagramme ,  <= 8ko

0 Kudos
Message 4 of 10
(6,083 Views)

Hello,

 

What is the size of your data? UDP's architecture does not support more than 64MB of data in a single transfer. Have yu tried using TCP transfer or using Producer/Consumer design patterns?

 

Andy Chang
National Instruments
LabVIEW Control Design and Simulation
0 Kudos
Message 5 of 10
(6,060 Views)
Thanks for all of the help; What value do you need to change in the UDP_set_receive_buffer VI in order to incrase the size of the TX buffer instead of the size of the RX buffer?
0 Kudos
Message 6 of 10
(6,036 Views)
Solution
Accepted by topic author davida2000

Hello Davida2000,

 

You should be able to use 8192 bytes which is 0x2000 in hex. The problem that you are experiencing would be resulted from Winows buffering, so the best solution may be to make a loop and queue and pull the data from there.

Andy Chang
National Instruments
LabVIEW Control Design and Simulation
Message 7 of 10
(6,014 Views)

Hello

 

Ok let's look at this . i want to send my data from my pxi to my PC using ethernet. I have tried using the given example of sent and recive data using UDP and TCp/IP. But the problem is while i am sending data  using udp I can not send data more than 2MB. i have attemped what is told to do on TX and RX side as i have put that dll science before write data .But what is this 8192 .Does it means more than 2Mb ie 8192x2Mb or what? Aslo i have experienced changing the buffer size write(udp) for wsock.dll in TX vi  to any value less than 8192 it reads the same 65000x32bits of data while it should be 8192x32 which is less than 65000x32 since i have fixed the size to 8192 .And then if i give more than 8192 like 4MB or any other the Udp write donot go beyond 65000 data input as output of size_of _read buffer in TX vi shows 0 . What seems to me is that this wsock.dll is not working on TX side. The bufer size remains the same as 65000*32bits even if i make wsock.dll input buffer size 4Mb or any other. similar might would be the case on RX side..... 

 

someone claimed over here is 64Mbps who. if he or anyone can explain? 

 

I am having a simple TX vi in which data is string of length 65000(32bit) or more.

 

regards

0 Kudos
Message 8 of 10
(5,780 Views)

I am seeing same issue. The solution listed here (http://digital.ni.com/public.nsf/allkb/D5AC7E8AE545322D8625730100604F2D?OpenDocument) has the UDP receive end pipe expansion. 

 

UDP_set_receive_buffer.vi - This VI takes in a connection ID for a UDP transfer, and sets the receive buffer size.

 

While the UDP Transmit side is same 65K limit. 

 

So it seems like there is no way to increase the limit from both Tx and Rx UDP. So the UDP pipe is only being expaneded in the Rx side not the Tx side.. Issue remains same.. 

 

unless i am not understanding something right... Please someone explain it.. if i am wrong. 

0 Kudos
Message 9 of 10
(4,339 Views)

Hello Maxout,

 

It appears that this is an old forum post.  I recommend creating a new thread or post on a newer forum.  You will likely get a stronger response from the NI community.  In response to adjusting the Tx buffer size, it is logical that there is a way to do so that would be similar to the .vi you referenced.  I will look deeper into this, but I believe the NI community will be able to get a solution to you quickly on a newer post.

 

John R.
National Instruments
0 Kudos
Message 10 of 10
(4,308 Views)