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. 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.
- Ensure that the variable HTTP_PROXY is set up in the machine variables.
- 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 you get this error when using the TCP Read.vi to read a response sent by your network device after sending a command from the cRIO, verify that the command has the correct syntax. Incorrect commands may not generate an answer from the device, causing a timeout error. Pay special attention to the termination characters as their representation may vary between Operating Systems. For more information, refer to LabVIEW Termination Characters.
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.