CAN comms become unreliable when upgrading to P4 PC

[paul s]

I have moved from a 800 MHz Pentium 3 computer to a 2.8 GHz Pentium 4 system with a custom written instrument control application which uses a PCI CAN card.  On the original PC everything worked fine, but on the new PC, the communication is dropped after a period of time, which may vary from a few minutes to hours.  Diagnostics indicate that everything in the application is still operating as it should be.  The problem has occurred in 2 seperate hardware systems, with both the Series 1 and Series 2 cards, and with versions 1.6 and 2.2 of the NiCAN drivers, and with both Windows 2000 and XP.  I would be grateful if anyone could shed some light on this.  

[biker2000]

Hi Paul,

When you upgraded your PC, the timing of your application has changed. Most of the code runs faster now (and in case of a hyper-threaded system possibly in independent threads) however, the timing of the CAN bus as well as the execution speed of most of the NI-CAN functions has not changed (as it depends on the PCI-CAN card).
One very typical example is this code snippet:
ncConfig()
ncOpen()
ncWrite()
ncClose()
One a somewhat slow system, this sends out a single CAN frame to the CAN bus. However, on a faster system, nothing happens. Why? The ncWrite() function completes when the data is transferred to the CAN card, NOT when the CAN card is finished with sending the data. On a fast system, the application sends the ncClose() command to the card, before it even started to process the data from the ncWrite() call. An ncWaitForState(WriteSucess) after the ncWrite() call will fix this problem.

Aside from this particular problem, there might be other sections in your code that are sensitive to the execution speed.
If a review of the code does not unveil those problems, you could run your application on the slower system and log all NI-CAN calls using NI Spy. Then repeat the same on the faster system. The differences between the two generated log files show which NI-CAN calls executed in a different order (parallel tasks) or too fast back to back.

I hope this helps,
-B2k

[paul s]

Hi.  Thanks for the reply.  Our code is implemented as follows:

Created once off when the thread is created (app start):
nican_ncOpenObject

Used continuosly in the thread for sending a can frame
nican_ncWrite
nican_ncWaitForState

Used continuosly in the thread for receving a can frame
nican_ncWaitForState
nican_ncRead

When the tread is closed (when the app is closed)
nican_ncCloseObject

the timeout on the wait function is 1 sec
nican_ncWaitForState(m_pPortHandle, DesiredState, NC_DURATION_1SEC, &ActualState );

It therefore seems that the problem lies elsewhere.

Paul

[biker2000]

Hi Paul,

OK, so already use the ncWaitForState function to avoid those problems. I guess, that leaves the second part of my suggestion: Comparing the NI Spy log files from running the application on the two different systems.

Before you run your application, launch NI Spy (Start » Programs » National Instruments), make sure that the NI-CAN API is monitored (Spy » Options… » View Selections) and start the capture. Now run your application. NI Spy is now logging all calls to the NI-CAN driver including the status of those calls. Take a look at the NI Spy log, NI Spy highlights those function calls that returned an error. Are there any errors returned on the new system that did not occur on the old one?

Could you post the two log files (from both systems)? If they contain confidential information you can export the spy log into a text file first and then post only those lines where an error is logged or where the execution seems to be out of order compared to the other log file.

-B2k