| 30 ratings: |
|
2.43 out of 5 |
Why Am I Getting Timeout Error 56 When Communicating Between Network Devices?
Primary Software: LabVIEW Development Systems>>LabVIEW Full Development System
Primary Software Version: 7.1
Primary Software Fixed Version: N/A
Secondary Software: LabVIEW Modules>>LabVIEW Real-Time Module
Problem: 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?
Solution: 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.
Troubleshooting steps to try:
- Ensure that the VI generating the error has the timeout set high enough. E.g. If you use the HTTP Client GET VI to receive a large string from a slow server, the default 10 second timeout may not be sufficient; you may require 15 seconds to complete the transfer.
- The timeout error may be expected behavior for your application. If so, you will need to handle and clear the error message. See NI Community: Clearing A Specific Error From the Error Cluster to learn how to do this.
- 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). E.g. Use http://74.125.224.72/ instead of http://www.google.com.
- 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. Consult External Link: Using the Ping Command if you are unfamiliar with doing this.
- 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 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. E.g. 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.
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
External Link: Wireshark.
Related Links: External Link: Wireshark NI Community: Clearing A Specific Error From the Error Cluster KnowledgeBase 3B6BTU4B: Return IP Addres Instead of Machine Name in TCP Listen.vi and/or TCP Wait on Listener.vi External Link: Using the Ping Command LabVIEW Help: Using LabVIEW with TCP/IP and UDPNI Community: Basic TCP/IP Communication in LabVIEW KnowledgeBase 2CND08Z8: Error 64 When the Client Closes My TCP/IP Connection to an RT Engine KnowledgeBase 2M59E6T4: TCP Server Running on RT Target Returns Error 61 When Connection is Closed by TCP Client on Host KnowledgeBase 2X8GD12P: Error 54 in TCP Connection.vi while using FTP VI’s
Attachments:
Report Date: 03/01/2004
Last Updated: 11/23/2015
Document ID: 370GCFBS
