From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP Write and Read take too long

Hello, I´m using an ESP8266 WIFI module as a client (controlled by a PIC18F2550), and a Timed Loop, where first a TCP Write sends "x" bytes to the module and then  a TCP Read receives "y" bytes from the module. It works. The problem is that for the application, I need 10ms for each iteration of the Timed loop.

The PIC  sends the bytes (through the module) 1ms later than it receives from LabVIEW. And the operation (Write - Read) takes less than 2ms. But despite the timed loop is set to 10ms, each iteration takes 30ms.

Do you know why?. Is there a way to make the TCP Write and TCP Read VI's work faster?

Here is the code. Before the timed loop, a TCP listen, wait for the connection, once the module and LabVIEW are connected, it goes to the loop.

Thanks.

0 Kudos
Message 1 of 5
(2,681 Views)
0 Kudos
Message 2 of 5
(2,658 Views)

Hi Hector,

 

Do you know why?

Because of all those bended wires? The data will flow faster through straight wires! (Just joking…)

The Rube-Goldberg constructs in your code also doesn't help to speed up the loop.
 

despite the timed loop is set to 10ms, each iteration takes 30ms.

It doesn't make sense to put a non-deterministic operation like TCP communication into a deterministic loop like the TWL!

Use a standard while loop and work with the timeouts of the TCP operation to read and write data as fast as possible…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 3 of 5
(2,634 Views)

Hi, I tried disabling the Nagle algorithm but nothing happen. Without the TCP Read, the loop goes ok, each 10ms. It seems like the problem is in the TCP Read.

0 Kudos
Message 4 of 5
(2,592 Views)

Nagle would only affect the write; not the read (unless your PIC uses the same algorithm).  Like GerdW said, TCP is non-deterministic.  Don't expect it fit your timing constraints.

0 Kudos
Message 5 of 5
(2,562 Views)