Solution
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. Review the general and the specific scenarios sections and execute the steps accordingly:
General Troubleshooting
- 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 this timeout value is not set correctly or is set too low, try raising the timeout value to see if you're able to see your communication successfully while remaining within your project's specifications.
- 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 "http://74.125.224.72/" instead of "http://www.google.com"
- If you receive message "500 InternalServerError" at this step and are hosting on a CompactRIO continue troubleshooting through that link.
- Using telnet command to check whether the TCP port is opened or not, refer to this KB for how to use telnet command.
- If the telnet command shows that connection to TCP port is failed, reach out IT department for advice or allow access of that TCP port is recommended. Sometimes IT department will block some TCP port for security purpose.
- 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.
- If turning off the firewall doesn't work, try changing inbound rules in the Firewall Advanced Settings.
- In Firewall Advanced Settings, LabVIEW has two inbound rules by default. One blocks the TCP communication for public networks, and the other one the UDP communication for public networks as well.
- In addition to the previous step, one should create a custom inbound rule to force the firewall to accept the desired protocol communication.
- Make sure that both devices are on the same subnet, and have the same subnet mask. See "Inconsistent IP Settings" When Connecting to Real-Time Target in NI MAX for more information on configuring NI network devices.
- 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 you are using a cRIO target
- If the cRIO is set as Client and the VI is setup as Startup VI, make sure the timeout on TCP Listen.vi in the Server is large enough. Some targets can take up to 90 seconds to startup, run the Client VI and connect to the Server VI.
- Try using the cRIO as the Server of the communication by placing the TCP Listen.vi in the RT VI. In some cases firewalls can be blocking TCP ports on the host.
If Using the RT 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 Open Suse 11.1:
If Using SFTP VIs in LabVIEW versions 2021, 2022, and 2023 in RT Controller:
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.