Crio Ethernet Port 'Crashes', Error 42

[Maurice_01]

The problem relates to this post and might even be the same:

http://forums.ni.com/ni/board/message?board.id=170&thread.id=345733

It took me a while to figure out what was going on. Even had a network analyzer to monitor the network traffic. I now am able to reproduce this problem in a very simple way. I have a 'TCP open connection.vi' immediately followed by a 'TCP close connection.vi'. There are some additional shared variables to monitor the status of the TCP open and close vi's. I run this program in an 100 ms timed loop.

I run the program on the controller. I unplug the network cable, wait 5 seconds, replug the cable and voila. It is not possible to ping the controller or to connect to it through the project explorer. However the shared variables are still alive and through an application that is running on my pc I can see that the 'TCP open connection.vi' generates an error 42. In fact any TCP vi generates this error.

The Compact rio is not able to recover from this problem. The only way I know is to reboot the crio in the project explorer or MAX or do it manually. Since we have 15 Crio's that are supposed to run 24/7 and who's only way of data-streaming is through TCP this is a big problem. 

Is there any other way to recover from this problem? Is it possible the check the 'readynes' of the ethernet hardware to prevent something like this?

Controller: 9014

Network: use DHCP

halt system if TCP/IP fails = false.

[Christian Mergl]

Hey,

This is a known behaviour and will be handeld under CAR #141011.

You can contact your local NI Office to ask for updates on the CAR's status.

As a workarround for this you can ping the server before trying to open the connection using the Ping.vi from the RT Utilities palette where you will also find a VI to programmatically reboot the cRIO in case you are unable to ping it.

Christian

[Maurice_01]

Thanks for your reply. I only have one more question:

I am not familiar with the term CAR. What is CAR #141011?

[Mathan]

CAR means Corrective Action Request.

You can see the list of bug fixes in the NI website.

[Christian Mergl]

Thanks Mathan!

Exactly, CAR means for you that R&D is working on this and there should be a fix in one of the future versions of the software.

Christian

[Maurice_01]

Meanwhile I am trying to figure this thing out using the realtime ping vi. I am using LV861. If I use that ping vi in my controller application it crashes at the second iteration. (Software) reboot is not an option, because of external reasons. Maybe I am doing something wrong.

What I am trying to do: 

The Compact Rio initiates the TCP/IP connection to a windows ftp server. So in addition I would like to either ping the Crio itself from the controller application and see if it is 'alive' or I would like to ping the windows server to see if I can setup a connection. The ping vi only relates to the controllers.

I attached a small vi so you can see how I trie to use the ping vi. (I disabled the rest, because I don't need it in this particular case). Maybe this is the wrong approach, but since the Crio is the one initiating the connection I don't know how to do it any other way... 

[Christian Mergl]

Hey Maurice,

I'm not 100% sure if this is now the same issue then descriped in the CAR.

I would suggest to contact your local NI Office for support on that so that we can add your investigations to the CAR and maybe find another suitable workarround for your application. 

Thanks,

Christian

[Maurice_01]

Ok I got a bit further , although the problem is not solved. I run the test5 vi (see attachment) and unplug the cable wait 10 secs or so and reconnect the cable. This is how I get it in error-mode. If I try to ping it from DOS, I get a positive reply, so that works. If I try to reconnect from the project window, I get an error. If I watch the shared variables I first see an error 56, wich after 10 seconds or so changes in the error 42. The shared variables are still approachable.

If however, and now it gets intersting, I unplug it in the designated 5000 ms time-frame (see attachment) and then later reconnect the cable, I can reconnect with the vi through the project explorer. This may take a few tries, but eventually I can reconnect. Something seems to go wrong when you unplug the cable while it busy with a tcp/ip function.

This is kinda interesting. Still have to figure out how to use this information to design an application that ALWAYS works.

[Maurice_01 · Accepted solution]

The solution:

Do not place any TCP/IP functions inside a timed while loop. Instead use a normal while loop and use a wait ms.vi to do the timing. This seems to do the trick.

Thanks, Maurice

[Christian Mergl]

Can you set your last post as solution then, other users might stumble over the same issue.

Thanks,

Christian