Error 56: Timeout When Communicating Between Network Devices Using LabVIEW

Updated Oct 22, 2018

Reported In


  • LabVIEW

Issue Details

  • I am trying to communicate between network devices using any of the TCP/IP based networking API's in LabVIEW, but the VIs timeout with Error 56 – LabVIEW: The network operation exceeded the user-specified or system time limit. What can I do to resolve this issue?
  • I am trying to talk to an end network device using my computer, but receive error 56.  I can run the same code successfully on another computer however.  What is happening?


This timeout error can be caused by configuring the TCP/IP functions incorrectly, and can often be cleared without detriment, as long as the data is being received. If the data is not being received, there are several troubleshooting steps below to mitigate this error.
  • Ensure that the VI generating the error has a correctly set timeout value. Example: When using the HTTP Client GET VI to receive a large string from a slow server, the default 10 second timeout may not be sufficient.
  • If you are using Reentrant VIs that are using TCP/IP, try turning off reentrancy. It is possible that a race condition is occurring that is causing the network to become busy and time out when writing or reading
  • The timeout error may be expected behavior for your application. When receiving data from TCP Read Standard, the TCP function will wait for the specified number of bytes for the duration of the timeout. If the function does not receive the full number, it will return the data it received with an error 56. See Clearing A Specific Error From the Error Cluster for information on clearing errors.
  • Ensure that the network cable is properly connected to each system or that the wireless network connection is properly established.
  • Use the IP address instead of the domain name when you open the connection to check for issues relating to your domain name server (DNS). Example: Use instead of
  • You can also try navigating to Tools»Options»VI Server and adding * to the Machine Access List by choosing Add at the bottom, entering * in the Machine name/access field, and ensuring that Allow access is selected. However, this will grant all machines access to the target machine.
  • Try to reach the network devices in question with a ping command in order to verify that the devices are still connected and communicating.
  • Turn off all firewalls and antivirus software packages installed on the computer to ensure no ports are blocked.
  • Make sure that both devices are on the same subnet, and have the same subnet mask.
  • Check if excessive local network traffic has slowed your network communication and caused transfers to take longer than expected.
  • If you are using the FTP VIs, check that the password being used does not contain any non-printable characters or spaces.
  • Make sure that the VI that is sending the information is running.
  • If the communication portion is placed in a subVI, try to take it out of the subVI and see if it works outside of the subVI.
  • Try using the "Simple TCP.lvproj" from the Examples in the LabVIEW Example Finder.
  • If you read and/or write repeatedly with a loop, try inserting a wait function in the loop (of around 200 ms). 
If using the RT Reboot Controller VIs:
  • Ensure that the MAC address you are wiring into the VI is accurate, and formatted correctly. Make sure that your string control or constant ID displaying its data in hexadecimal format. Example: 0080 2F0A 14FF. If your string control is not in hex format, right-click on it and select Hex Display.
If using the FTP Put File or TCP Wait On Listener VIs with LabVIEW for Linux on OpenSuse 11.1:
  • Configure the FTP Put File VI to use passive mode for FTP transfers.
Troubleshooting Using Packet Sniffing
If the above steps do not help, use a packet sniffing program to see if the data is being sent across the network. A third party tool called Wireshark can help you see if the data is arriving. If no data is arriving and you see this error, there is a problem either on the device sending data, or with your network. If data is arriving at Wireshark, and you still see this error, most likely you have a firewall issue or malformed TCP functions. Wireshark is available at Wireshark.  You can use Capture Filters with Wireshark to help isolate packets only going to/from a certain IP address.

Additionally, if the packets do successfully get sent out to the network, but the end device does not respond, there is a chance that the network adapter of the end device is defective.

Additional Information

Error 56 is caused by the LabVIEW code not receiving a network response within a user defined time limit. This error is a generic timeout error and can be the result of a lot of different factors. Error 56 is often a result of  Error 66 - LabVIEW: The network connection was closed by the peer​ which will cause the VI to wait for a response that is not coming until the server reaches a timeout limit, and closes the connection. 


Not Helpful