cfp-2200 ethernet communications hang

[Alisha_P]

Hi Christoph,

95% is a pretty high CPU usage. Do you see the same problem when you run a program that is less demanding on the processor? (you could try adding some wait time to your current program to test this)? In general, high CPU usage is what most commonly causes the processor to get so busy that communication drops (i know that Mark seems to be having a different issue). 

[Alisha_P · Accepted solution]

Mark,

I know that the constant 50% CPU probably rules out any problem with high CPU usage causing the processor to hang. Have you monitored your program at all? Do we know if it always hangs at a certain point in the program? 

Have you tried reformatting, upgrading software etc?

If this still happens after reformatting, software changes, with no program running on it, then my guess would be that there is some hardware problem with the controller. If you can reproducibly recreate a noticable processor hang independent of the program running on it, then you could consider sending the controller in for repair.

[clenk]

hi alisha,

i gave thought to the high cpu usage, too. however this is not the first system we use with this cpu usage. we changed some processes to lower the communication load and cpu usage.

so. this is what happens:

- communication hang between cfp (2210 and 2220) and pc. the application seems to still run (watchdog, serial communication, actuator control)

- it's possible to "ping" it and it's findable in the MAX to perform a software restart

- after performing "find devices" in the MAX, the I/O-modules aren't show values (no datatransfer from the cFP)

- the variables created in the DSM can't communicate with I/O channels or cFP variables

we are using LABView 2011 SP1 and Fieldpoint 6.0.10. The first time the issue occurs we used LABView 2009 SP1 and Fieldpoint 6.0.6. The issues did not occur when using LABView 2009 SP1 and Fieldpoint 6.0.5. At that time we downgraded the software back to 6.0.5. and it worked fine. (without changing the source code). But now we don't want to downgrade again from 6.0.10 back to 6.0.5.

so .. what changed in the fieldpoint driver between 6.0.5 and 6.0.6?

are there functions in LABView which influence the communication in this way

how it is possible to find the detailed problem?

thanks a lot

regards,

christoph

[Alisha_P]

Hi Christoph,

The main change between FieldPoint 6.0.5 and 6.0.6 was to add support for LAbVIEW 2009 SP1 (so it would not have been expected to work with 6.0.5 and 2009 SP1) and a few bug fixes unrelated to your problem. The overall driver has gone through very little change over the last few years as we are no longer developing new FieldPoint hardware. I think if there were general problems with communication hangs on all 2210 and 2220 controllers post 6.0.5, it would have been generally reported and fixed.

Probably, this is an issue specific to your program (or less likely, your controllers). 

Each upgrade of the drivers does require greater memory space and processor time. Perhaps your program is taking up enough of these resources that the added space from the drivers (and the newer LabVIEW versions) put it over the edge. You said that you changed some processes to lower the CPU usage and communication load. We recommend having a CPU usage under 75%. Are you down to 75%? If you can reproduce this issue with a program consistently taking less than 75% of the CPU usage, then we can investigate other options.

[MarkFreeman]

Hi Alisha,

Thanks for your note.  This is a remote customer site so monitoring is going slow.

Planning on re-deploying to the cFP and then determining if hardware or programming as you suggest.

Would still be interested in feedback on my question:  if ethernet comm is interrupted due to wireless bridge problems, can that contribute to this type of problem?  Can the comm recover after the link comes back up or is user intervention required?

best regards,

Mark

[Alisha_P]

Hi Mark,

No problem! Make sure you're monitoring memory use as well (I know that you did at some point, but not sure to what extent).

Loss of network access should not cause the processor to hang. The program should run independent of network connection (unless you're programmed it to require information from the network for certain areas of code). Comm should recover without user intervention as long as nothing has changed about the network setup. For example, if the cRIO is set to acquire its IP address from DHCP, but the DHCP server isn't available when the cRIO starts up then it will acquire a link local address and won't be reachable over the network until you restart it again and it is able to acquire a DHCP address. If the IP address is held constant, then you should always be able to reach it as long as the network is available and unblocked.