Error code 63 with a CompactRIO

[N Nayfeh]

I have a CompactRIO system running with an independent RT target. I connect to the cRIO using a crossover cable, and I have a small monitoring/diagnostics program I can use to check the independent RT target. Anyways, the system had been running for approximately 3 weeks, when suddenly it stopped working. When I try to use my monitoring/diagnostics program, I get "Error code 63" . I can't tell if its "serial port receive buffer overflow" or the "The network connection was refused by the server" version of the error.

The serial port on the cRIO is not being used. The system is powered on and off when not in use.

What's even more puzzling, is that NI-MAX has no problem connecting and verifying that the cRIO and modules are working, Labview FPGA has no problem connecting and running.

Any thoughts on what's causing the error and why the independent VI on the cRIO suddenly stopped working?

Edit: Oooh, I forgot to mention, Labview version 7.1 with the latest crio and visa drivers for 7.1 (didn't get the stuff for 8).

Message Edited by N Nayfeh on 03-06-2006 09:30 AM

[Bassett_Hound]

N Nayfeh,

It sounds like your monitoring/diagnostic program is having problems communicating on a port via TCP/IP.  Error 63 at TCP Open Connection means that the server refused the connection or that the server hasn't been started.  Its possible that the TCP/IP settings disabled on the RT Target.  To enable these in LabVIEW goto Tools>> RT Target : xxx.xxx.xxx.xxx Options....
 
In the Select 'VI Server Configuration' from the combo box and make sure the TCP/IP checkbox is checked.  Next goto the 'TCP/IP Access List' and make sure either the IP address of the host or a '*' is specified.  I believe this will solve your problem.

If you have to change your TCP/IP settings you may need to take your original VIs and rebuild your executable.

Hope this helps.

Bassett

[N Nayfeh]

Thanks for the reply Bassett H,

I checked that setting and it seemed ok. I have run the monitoring program before with no problems.

I still get that error after checking it. The more I play with the system, the more it seems like the independent vi got corrupted or wiped off the RT engine on the cRIO. Is this possible due to some software glitch or memory leak?

[Bassett_Hound]

Its always possible that the vi was corrupted or that there is a small memory leak depending on your Application architecture.  If the controller  is opening VI's dynamically, which then open references to the hardware of the cRIO FPGA, and also download code and open VI's dynamically on the FPGA. It is possible that many VI's doing this simultaneously is not thread safe enough, so that TCP communication becomes thread starved and therefore your connection gets refused.

Another scenario is that garbage is not being collected, and a small amount of memory is still allocated even though your processes close bad and then disappear from the list. After time, this might add up to enough RAM to crash the TCP thread.

One way to eliminate FPGA references as a possibility is to replace the Controller VI's with ones that don't do anything on the FPGA. Then you could see if the effect was RT starving RT, or if the FPGA is starving RT.   I have attached a two Host-RT TCP/IP VIs taken from the LabVIEW examples you could use to try this.

Regards,

Bassett