Ethernet communication problem after upgrading to cfp-2220

[Armen]

My application, which communicate with external power supply with ethernet interface and based on TCP Communicator from NI Examples was running fine with cFP2120 and LabVIEW RT 8.51. After upgrade to cFP2220 it fails to talk with device. What could be wrong? Should I change some timing settings with faster processor?

[RavensFan]

Are you sure you are using the latest fieldpoint drivers?    cFP2220 is a newer controller and the drivers present for 8.5 may be older than the new controller.

[Armen]

Thank you for fast reply, I am using FieldPoint 6.01, but I also tested 6.02 with the same result

[DianaS]

Hi

the cFP-2120 is running Phar Lap and the cFP-2220 is running VXWorks.

See also here:

http://digital.ni.com/public.nsf/allkb/3BAFCDC5CC7908BB8625757F00727560?OpenDocument

http://zone.ni.com/devzone/cda/tut/p/id/6344

[Armen]

Hi All,

After one year I have to return to the same problem: I have a perfect communication when starting my application from "My Computer" part of project. When I shift it to the cFP-2200 target - it makes one (or two) cycles of communication and then full silence - timeout error 56. What is a difference between starting aTCP communication from Fieldpoint target and from Windows computer? I made a test with TCP example program: set Passive TCP communication  program in Windows PC and Active TCP communication program in the Fieldpoint - it works just fine, and it works fine when I trying to control the Power Supply with my VI from Windows PC, but when I trying to talk with Power Supply from FieldPoint cFP-2200 it behaves differently.

Pleas help me,

Thank You.

[GeneHancock]

I am having very similar results.  I have a very stable code base that works great in 2120 and recently when I upgraded to 2220 I have random results.  My code uses TCP and UDP to communicate to a Touch Panel PC.  The TCP is used only occasionally when a user changes a setpoint on the TPC.  After the upgrade I now have many random failures in the TCP Communications in the cFP.  Also I am having big issue with running Code from my PC on the cFP-2220. 

Sounds like there are issues from 2120 OS and 2220 OS.  Wouldn't the compiler tell me if I am using functions that are not supported in the 2220?

[GeneHancock]

I did some more research and testing and it seems that Timed Loops in the cFP 2220 (vxWorks) controller should be avoided.  I found a brief mention in the known issues that the open Ethernet connection code in a timed loop would cause an OS "crash" that would require reboot to recover from.  I did not have this exact condition but did have some other TCP code in a time loop.  I also had several other bits of code in separate loops that did logging, the Main control loop, UDP sending, and so on.  After removing all Timed loops I have not seen a TCP failure in several hours where I was seeing it within 15 min before.

Are there more issues similar to this? 

[gsussman]

There is an issue with the cFP-2220 controllers and the ability to talk to LXI type instruments using VISA. The issue relates to the VISA passports for the ethernet communication either not being enabled or being turned off completely on the VX-Works targets. I went through this issue about a year ago and one of the AEs was able to get me past the problem. I believe it required loading one or two .out files on the system and manually editing a couple of the config files. I am looking back into my notes but can't locate the service request number.

If the issue you have is related to the TCP thread working for awhile then going dead, you may want to use the distributed system manager to check the CPU utilization on your controller. If the controller hits 100% CPU usage it will start to suspend threads to try and lighten it's load. See the following idea exchange post

[GeneHancock]

I have looked at the CPU loading and it is in the 20 - 30% range.  To date I was under the impression that it was a CPU loading issue and spent a lot of time slowing everything down.  Most of my threads run every 100 to 200 mSec.  When I monitor the CPU load it will stop running at the same time I lose the ability to comunicate with the cFP. 

[gsussman]

When the distributed system manager looses it's connection to the RT system it is a pretty good indicator that the TCP thread has been suspended.

Just becase you don't see the graph spike up does not mean that the CPU did not quickly spike and just cut everything TCP related off.

I would go through my code a little at a time and try disabling particular parts to see if there is one function in particular that seems to be the culprit. The first place I would look is any driver the cFP uses to communicate to an external bus. Putting some logging operations in your RT code may also give you some idea as to what is going on, however you need to relize that logging to the disk will take a significant amount of CPU time.

Lastly....and I should have mentioned this first...is to turn on the console monitoring (DIP switch on the top of the controller). Connect a PC with Hyperterminal or other emulator running to the RS232 port on the top of the controller to monitor the console messages coming out. You can write messages to the console window in your code so you have an idea as to what is executing at what time. I believe that you may also be able to see the CPU usage from that window, although this may only be available on the PXI RT controllers.

I find the RT controllers particularly difficult to debug when you run into these problems because as soon as the issue occurs, the RTOS cuts the development system off and you have no more visibility.