LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Keep getting Error Code: 66 TCP Read --Help!!!

I have an application running on a PXI 8145 RT processor that runs fine except that after about 8 or 9 days the TCP read loop will report "Error Code: 66 TCP Read" and my application then crashes because I am only ignoring timeouts (Error 56.) To me it sounds like a memory allocation problem with the TCP VIs. I reboot the system and all is fine and good again for another 8 or 9 days. Any ideas why this would occur after 8 or 9 days consistently?
0 Kudos
Message 1 of 7
(6,066 Views)
Tommy,
It may not necessarily be memory usage in the TCP VIs themselves. Review your application for things that will use memory, such as build arrays. For more information on memory management in LabVIEW see the third section VI Memory Usage of the following Tutorial from LabVIEW>Development System>Optimizing Applications>Memory Management.
http://zone.ni.com/devzone/conceptd.nsf/webmain/732CEC772AA4FBE586256A37005541D3?opendocument&node=DZ52065_US

For more specific RT information see the LabVIEW>Real-Time Module>Timing Loops and Optimizing Performance category.
http://zone.ni.com/devzone/devzone.nsf/webcategories/B8D8F00D8FB6FE8B86256B5D00798F76?opendocument&node=174823_US
0 Kudos
Message 2 of 7
(6,066 Views)
Thanks for your answer however I have eliminated all build string and build array functions from the program. I have also made sure that all arrays are initialized. What other functions use the the memory manager that could be causing the TCP Read not to lose its connection?
0 Kudos
Message 3 of 7
(6,066 Views)
Hi Tommy,

The no EOC VI should be trapping error 66 and the VI should continue to run. However, on RT sometimes you will get error 64 instead of 66. The following link contains an updated no EOC VI that may help.

http://pong.ni.com/public.nsf/websearch/94B5958AC81EA6FC86256AB200686A8B?OpenDocument

I hope this solves your problem. Why do you think it's a memory problem? Have you been monitoring the memory usage on the RT controller?

Dafna
0 Kudos
Message 4 of 7
(6,066 Views)
dafna:
Thanks but that still doesn't help. I do get error 66. Not 64. Why would I want to trap and ignore an error 66?
I believe that there is some type of memory problem because the system runs fine for about 8 or 9 days then I get an error 66 which causes my application to stop running. This happens although the connection has not been disconnected or terminated. If I reboot every week then the problem never arises. Therefore, to me it seems like some type of memory leak in RT. Maybe something with Pharlap and TCP? This problem is still occurring as I write. Still looking for help, -Tom
0 Kudos
Message 5 of 7
(6,066 Views)
Hi Tommy,

The problem you are seeing could be due to a memory leak, but then it seems to me that you wouldn't be able to re-establish a connection if you'd run out of memory. You can check your memory usage by adding this line to your ni-rt.ini file: TargetMemInfo = TRUE
then look until Tools>>Network Options.

I suggest you contact NI's RT support and have them look at the code. There are several other possible reasons this could be happening (for example it could be network related.)

Thanks,
Dafna
0 Kudos
Message 6 of 7
(6,066 Views)
Dafna:
The only way that I re-estalish a connection is by performing a cold reboot to the system. Just restarting the application will not work because they crash immediately. Therefore I still believe that something is using up memory and since the memory is completely cleared and reset on a reboot the problem is temporarily fixed. Also, I used the Targetmemeinfor=True line in the NI-RT.ini file however with LV 6.1 it does not return the information that was returned about the Heap memory when I was running LV 6.0.3.
0 Kudos
Message 7 of 7
(6,066 Views)