cRIO intermittent comm failure

[Randy_Lloyd]

I have a cRIO-9073 that is about 5 years old. Within 6 months (maybe sooner) of setting it up, we started having intermittent comm failures that caused the running application to hang wherever it happened to be at the time. We were still working on software development, and thought it might be a flaw in the software. We have two identical cRIO set-ups, running identical cRIO and PC applications to control custom mechanical test machines. Each system has its own control PC, but they are all connected on a common private network. I no longer have a service support agreement with NI, so I cannot get any help directly from them anymore.

The two systems were essentially not being used the last three years. We have a summer intern here that is trying to work with them, and he did some more troubleshooting. He tried running the faulty cRIO system with the PC and software from the other "good" system, and still had the same problem. The "good" system has been running without problem since day one. This suggests that there is something wrong with that particular cRIO-9073's controller module.

Has anyone out there had a similar experience, and if so, what was required to correct it? 

Thanks in advance for any help anyone can provide.

Randy Lloyd

Idaho National Laboratory

[nanocyte]

No, I've never quite had an issue like that but any time I hear comm failure (I assume you mean ethernet) I immediately think CPU use. Do you use any priority, scan engine, or timed loops in your app. High priority stuff can crowd out the network so you might want to set everything to normal priority, normal while loops, and FPGA mode just to see if that's the issue.

The other thing you might want to do is check your error logs from max and see if there's any useful crash info there. You can also connect an RS232 cable to your chassis and turn on debug logging to see if there's any weird messages there.

[Randy_Lloyd]

Tnx for the info. We are using scanning (vs. FPGA) to handle data in and data out. There are no real high speed loops running. There is one at 500 Hz that is just monitoring for error conditions on a couple inputs and sends out a trigger signal to other loops. It is not very CPU intensive.

We have two identical systems (cRIO-9073) with two PCs and two identical software packages. Both PC/software combos will operate with the "good" cRIO with no problems or errors. Both PC/software combos get the same intermittent comm failure when operating the "bad" cRIO.

This suggests to me a problem of some type with the "bad" cRIO chassis. I will see about checking a few of the things you mentioned.

[crossrulz]

The other time I have seen issues is when the hard drive gets full.  I saw a cRIO completely freeze just due to a setting that the customer set which caused the logger to log a ton of data, filling up the drive.

[Great-Britton]

Hey,

I would try using the RAD utility to make an image of the "good" cRIO, then format the "bad" cRIO and use the RAD utility to deploy the "good" cRIO's image to it.  Even if it doesn't fix the issue, it would rule out a lot of possible problems.