TCP Read block error 66 in LabView 2009

[Lana_A.]

I am using URL Get HTTP Document to send C++ code to microcontroller and URL Get Document to read the content of the file that microcontroller creates after the code execution.

This vi was working perfectly in LabView 8.6. Then when we reinstalled Windows XP and installed LabView 2009 the TCP Read block in URL Get HTTP Document displays error 66 and the output Content is empty in both Get Document blocks.

The microcontroller does receive the code and execute it - I see the file with the content through internet browser. It is the TCP read block somehow cannot pass this content back to vi.

Is there a special setting in LabView 2009 that has to be changed in order to allow the TCP Read block to work properly?

Please help me.

[Ever_Song]

Hi Lana A.,

Error 66 indicates a timeout error (either in Windows or LabVIEW; see this Knowledgebase). The first thing we should try is making sure we are allowing access. This can be done by under Tools>>Options>>VI Server in LabVIEW (here is a knowledgebase that talks about the settings found in here). Here you can add access for the microcontroller (it may be worth comparing these settings in LabVIEW 2009 and 8.6).

[Lana_A.]

Hi Ever Song,

Thank you for your response.

I reviewed this information in Knowledgebase. Also I set up one more computer with LabView8.6 and run my vi again – it is working without any errors and giving me the data.

I opened Options in both versions to compare. VI Server settings in the LabView8.6 are untouched; everything there is in the Default setting. And this default is the same as in the LabView 2009.

I checked in the box TCP/IP in VI Server of LabView 2009 and I added the IP address of the microcontroller in the Machine Access – nothing change: I still see the error from TCP Read block and my data file is empty. When I enter the location of the microcontroller file in internet browser (http://192.168.1.162/test.txt) I see my data.

I attached the pictures of VI Server settings and my block diagram with error on it.

Thank you,

            Lana

[Ever_Song]

You mentioned that you reinstalled Windows XP, it may be that Windows is blocking the microcontroller. Are you testing the application in LabVIEW 8.6 and 2009 on the same computer? If not, check to make sure that the Window’s firewall (or other security software’s) settings allow the microcontroller access.

Also, try increasing the timeout length on the TCP read block to determine if the connection is just timing out, or that connection is actually being closed. If we increase the timeout to something very long (or infinite) and it times out, then we know that something else is closing the connection.

[Lana_A.]

We are testing LABVIEW 8.6 and 2009 on different computers.

On the one with LABVIEW 8.6, Windows XP was not reinstalled more than a year.

I turned off Window’s firewall and antivirus on the new computer that has LABVIEW 2009 (my administrator said that there is no other security software on that computer).

In this case, the test does not show any errors but the data file is still empty.

Should I still increase the timeout on TCP Read block?

[Ever_Song]

Good to hear that we were able to eliminate the connection closed errors. It makes sense that the Windows XP firewall could have been blocking access as it is only capable of blocking inbound connections. Adding an exception to the firewall for the microcontroller should allow you to keep the firewall on but still allow access to the microcontroller.

Try increasing the timeout if the TCP read is timing-out. If it is not timing out, confirm that we are able to receive data from the microcontroller on the LabVIEW 2009 computer. Also, confirm that the port settings (or service name) are setup correctly.

[Lana_A.]

The picture above (pic1.jpg) is the picture of VI Server settings that I have right now.  I don’t know if this is correct. How to find if this is correct port number or what is the service name?

[Lana_A.]

I connected the constant -1 to timeout input of TCP Read block. Windows firewall and antivirus were turned off. After all these TCP Read block still shows the error 66 and content of the data file is empty.

[Ever_Song]

I think we need to narrow down the issue and determine if it is a LabVIEW issue or a Windows issue. I have composed a few steps below to try and narrow down the issue:

1. Confirm that you can access the microcontroller from the LabVIEW 2009 computer without using LabVIEW (open it up in your browser like before). This will help determine if it is something in the coding that is causing the issue or something on the Windows side.

2. Also, confirm that the microcontroller is receiving the C++ code sent by the LabVIEW 2009 computer by running just the GET HTTP Documents portion of the LabVIEW VI (disable the TCP Read portion) and checking through a browser to see if the data is being generated.

3. Try and see if we can use a shipping example to pull any data from the microcontroller while it is outputting data (if possible since we may need the GET’s). These can be found by in LabVIEW going to Help >> Find Examples. Browse to Networking >> TCP & UDP. A good one to start with is Simple Data Client.vi.

4. Is the error 66 being thrown immediately when the TCP read is being called or does it wait for a while and then throw the error?

Also, could you post a screenshot of a simplified portion of your code that reproduces the issue it would be greatly appreciated.

Thanks,

[Lana_A.]

Yes, I can access the microcontroller without Labview: I type in internet browser http://192.168.1.162/test.txt and I see the data that is changing every time I run test. Also the command to execute the C++ code comes to the microcontroller because I see that the microcontroller enable the measurement equipment.

What code do you like to see? The block diagram of my vi? I attached the block diagram picture. Let me know if you want to see the C++ code that is loaded to the microcontroller or something else. I will send you on Monday. I did not run the Simple Data Client.vi yet. I will do it on Monday.

Thank you very much for helping me,

             Lana