RT Apllication loses communication

[didje]

I'm develloping an apllication with a Crio 9012 in LabVIEW 8.2.
My application contains two loops running on the Crio Controller. One of them is communicatiing with the FPGA, the other one controls the TCP/IP communication.
The TCP/IP communication is quite busy it sendsand receives up to 20 000bytes. However due to interupts running on the FPGA. I don't need to run the TCP /IP loop faster than 5Hz.

I found that the controller would loose communication after a few minutes when the communication loop runs every 250ms. If I try to probe the errors generated by the TCP/IP functions, the system TCP/IP connection does not fail and beomes highly reliable.
After building this application as a RT apllication, the communication is lost after a few minutes. My TCP/IP loop retrieves the comunication but the two seconds during which the communication have been lost cannot be tolerated due to data transfer taking place between the Host computer and the FPGA.

I have changed the timer in the TCP/IP loop for a 500ms wait. This cure the problem when running in the Labview environment system. However the communication still fail while running the same  code as a RT apllication.
I have been monitoring the controller with the system manger, It uses only 5% of the CPU for the TCP/IP loop and 15% for the FPGA host. The memory usage is slightly above 50% and it doesn't increase with time.

I wouldn't be surprised if the opposite happened: being able to run reliably a RT apllication but not being able to run it in the labview environment and monitoring it at the same time.

Can anyone think about a difference between the TCP/IP communication in both configuration that would justify such a behaviour.

Sorry for the lenght of the mesage and thank you in advance for your help

Etienne

[tedpixie]

Strange, I had to do the oposite in simulated crio the labview enviroment. (In production mode, when the code is actually run by the crio there is no problem.) I had a tcp/ip loop executing every 500ms, the I saw this post and wondered if I could do the oposite. I timed it to 250ms and what do you know, the connection is stable as a rock. I don't know why, I like to blame the windows xp's tcpip stack ;).

Even

[didje]

    Strange behaviour that you have.
On my system I can say It's not Windows XP as the CRIo that closes the port.
Ni have been workiing on this I'm waiting for an answer soon.

Thank you for your interest

I'll post a workaround as soon as I've got one

Etienne

[rex1030]

We are having the same problem. Whats strange with us is that the program worked fine for a while. We didnt change anything and the program started having this problem. It seems to be the code, though, because we ran it on multiple devices and different computers and the code still same problem (9102 and 9104). Random disconnects during running. When you use the lightbulb, it works fine. Consider yourself lucky yours only loses connection for a little while and then regains. Ours never regains the connection.

Still waiting for a solution and trying to work it out on our end.


Message Edited by rex1030 on 04-04-2008 02:58 PM

[Joseph_Loo]

Are you running the RT in the intranet where the company is controlling the network or are you running it within a private network with no other network?

The reason I ask this, in the older fieldpoint devices, it would work in a private network with no problems. The minute we placed on the intranet, we would loose communciation with the device. It seems that the intranet was bombarding the fieldpoint with other "packets" and this would hang the device up.

[didje]

Hi Joseph,

I was running the system with a crossover cable. so no network overload from other devices.

NI helped me to cure this problem.

Which version of LabVIEW, RT and RIO are you using?

Mine worked better with 8.5 and RIO 2.3.1 and using a bug fix from NI.

My problem was actually a problem of timeout (I reduced the timeout to 1000ms to find out when the connection failed as fast as possible) When the timeout was increased to 2000ms the system became rock solid.

You should try to contact NI, they will be able to help you on this matter.

Regards

[Joseph_Loo]

Whe we found out that it was a problem, we had the units for awhile. It turns out there were no fixes.

[rex1030]

I fixed my problem too. My problem was in my program. There were some instances where I would have the program enter a loop and poll a variable waiting for it to change. I didn't have any 'wait' sub VI in the loop. The RT system would enter that loop and consider my instructions more important than other system processes... like internet communication. It would then drop the connection and since I had it set up in MAX to halt system with a loss of internet activity, the program would crash as well. It was quickly resolved by adding a wait of even 10 or 20 ms. It was a simple oversite, but some of you may be doing the same thing and not realizing it. So check for that as well.

[rex1030]

By the way, a timeout of 2000 ms (2 seconds) is nuts. Thats an eternity for a computer. I would look at what is eating up your processor time. Maybe use the trace utitlity to get a real picture of what is actually happening.