cfp-2000 loses communication

[jspaarg]

We have a CFP-2000 with the factory program (essentially a simple I/O module) that recently has started losing communication with the network.

Sometimes it will work for a few days prior to failing, sometimes for only a few hours.

Performing a hardware reset gets it running again for a few hours or days.

Does anyone have any idea as to what is wrong, or some test that we can perform?

Any help is appreciated.

[Matthew_Williams]

Do you know what versions of software are on the unit?  We have seen communications problems
with LVRT < 7.0 where the node will not resume communications promptly following a network
outage.

Are you able to ping the unit during the time that it is unresponsive?  Does the controller's web
page come up ok?  Can you ftp to the unit?  The different services rely on different portions of the
TCP stack.  In our case ping would always work, FTP and HTTP wouldn't work and MAX would
sometimes work.  We found that if we waited long enough ( minutes to 2-3 days) the controllers
would eventually resume proper communication on their own.  A reboot always restored comm
immediately.

Moving to LVRT 7.0 made a significant improvement.

Matt

[jspaarg]

Thanks for the quick reply Matthew W

Software loaded is:

LVRT = 7.1

Field Point Drivers = 5.0.2

Field Point VI Manager = 3.0.0

Data Socket for LVRT = 4.2

The unit is essentially a brain with the Factory I/O software and four directly-wired analog input modules

Further info from people actually working with the unit is that it seems to just stop updating data to the PC on the network that monitors the cfp.

It seems that the cfp transmits some zero packets and then ceases outputting data.

We can ping it and the web page comes up.

Have not tried to FTP although MAX does lose communication.

We cannot wait 2-3 days for a self-restore, although a reboot always works.

Our present band-aid is to reboot the system prior to each 20 minute data acquisition cycle.  This is completely unacceptable.

You said that LVRT 7.0 made an improvement, did it actually fix it?

Do you know of any testing that we can do to determine where the fault actually lies.

I am unaware of what Troubleshooting 101 is on this particular system.

Thanks again.

[Matthew_Williams]

We built a test rig with a PC, 3 ethernet hubs and the cFP.  The middle hub was
power cycled 20S on, 10S off to simulate network problems.  With this setup
our node communication (VI server) would hang or the node would reboot within
5 to 10 minutes with LVRT 6.1.3, ~ 24 hours or more with 7.0.  We have heard
that there were significant changes to the LVRT 8.x code and it should be better
but we can't go higher than 7.0 right now.

Current versions:
LVRT 7.0.0
FP Control Environ 4.1.7
FP VI Mgr 2.0.1
NI-IrDA RT 1.0.0
NI-Serial 2.5.3
NI-Visa 3.0.1
NI-Watchdog 2.1.5

If network issues are causing your problem, you might be able to induce the
problem by unplugging and plugging the network cable repeatedly.  That would
at least give a direction for further investigation.

Another thought would be to set the cFP ethernet settings to fixed values rather than
the default auto-negotiate, if it does seem to be network related.

Hope something in here is useful.

Matt