bff62002 internal error occurred in the ni-can driver

[John_Gourlay]

Can somebody tell me what status code bff62002 means?  I'm using the frame api for C, and this error is returned by ncWrite.  This happens using a USB board, serial number 130913f, and exactly the same application works without error using a port of a PCI board.  An nicanErr.txt file was written, and here is the beginning of it.  The lines I omitted are just repetitions of the [INDEX_n] sections included below:

[OSINFO_SECTION]
OS=Microsoft Windows XP Workstation                                                                                                                          
Service_Pack=Service Pack 2 (Build 2600)

[DRIVER_VERSION_SECTION]
NICAN.DLL_VERSION=2.5.0f0
NICANFRM.DLL_VERSION=2.5.0f0
DRIVERS\NICANPK.DLL_VERSION=2.5.0f0
NICANPU.DLL_VERSION=2.5.0f0
NICANTSK.DLL_VERSION=2.5.0f0
NICANCFQ.DLL_VERSION=2.5.0f0
NCVI.DLL_VERSION=2.5.0.12288
NICAN_S1.NFW_VERSION=2050000
NICAN_S2.NFW_VERSION=2050000

[CURRENT_SECTION]
Section_Index=79

[INDEX_0]
Local_Time= 02/04/2008 13:25:20.359
Err_Status= Status:0xa0000002-Location:0x20000000-Internal:0x00000000
Function= ncWrite-CAN2
[INDEX_1]
Local_Time= 02/04/2008 13:25:20.468
Err_Status= Status:0xa0000002-Location:0x20000000-Internal:0x00000000
Function= ncWrite-CAN2

John Gourlay

[DirkW]

Hi John,

This internal error happens whenever the onboard firmware detects a not handled error condition. That means it is not your programming fault, its just not handled.

Try to update your driver to 2.5.2., to see whether it happens again. Then attache your error log file again.

You can download the NI-CAN 2.5.2 driver here.

DirkW

[John_Gourlay]

Dirk,

I upgraded the NI-CAN driver, and now I get no error return codes, but I get no communication either.  Recall that if I use NI MAX to change the interface names, I can run my program successfully using a port of a PCI board.  Also, the USB board self-tests correctly and works properly with the bus monitor feature of MAX.  The USB board is an NI USB 8473.  The PCI board is an NI PCI-CAN Series 2.

Is there some difference in the way the two types of CAN board should be configured?  What I'm doing, I believe, is very simple.  I first call ncConfig, then ncOpenObject, and then ncCreateNotification for NC_ST_READ_AVAIL.  Then, I expect to be able to send frames using ncWrite and to receive frames using ncRead within the NC_ST_READ_AVAIL callback function.  With the USB board, when I call ncWrite nothing happens, and my callback function is never called.

I call ncConfig with values for the following attributes:
NC_ATTR_BAUD_RATE,    
NC_ATTR_READ_Q_LEN,   
NC_ATTR_WRITE_Q_LEN,  
NC_ATTR_CAN_COMP_STD, 
NC_ATTR_CAN_MASK_STD, 
NC_ATTR_CAN_COMP_XTD, 
NC_ATTR_CAN_MASK_XTD, 
NC_ATTR_LOG_COMM_ERRS 

John

[DirkW]

John,

The USB CAN device does not support all API functions. See this Link  for more information.

The NI-CAN driver installs the NI-Spy, which logs all the api commands, when your program executes. Could you run the Spy together with your program and post the log file?

Thus i could hopefully see whats wrong.

DirkW

[John_Gourlay]

Dirk,

Attached is an NI Spy capture showing the problem.  CAN0 is the USB board, and CAN1 is port 2 of a PCI board.  They're connected to each other, and there is nothing else on the bus.  The test configures and opens both ports identically and tries to send a frame from CAN1 to CAN0.  The NI CAN library never calls the NC_ST_READ_AVAIL callback function for CAN0.  In spite of the successful return codes, the USB board apparently never really goes on line, because CAN1 goes into error-passive state for lack of an acknowledgement.  You can see the call to the callback for CAN1 to deliver the no-acknowledgement communciation error.

It's impractical for me to send you the whole program I'm running.  It's a big, programmable system for running end-of-line production tests of automotive components such as engines and transmissions.  I am including the one C file that contains all of calls to the NI CAN library.  The functions you'll be interested in are pc2_ds_open_port and receive_frames.

John

[DirkW]

Hi John,

Make sure you have thye latest NI-CAN driver installed. I used NI-CAN 2.5.2 and it worked fine.

Besides that have you ever tried running the USB Application only to receive something?

When you call the notification configuration the first time in your process, its recommended to call it in disable state ones, before you call it with your actual configuration to make sure everything is reseted. (see below)

"ncCreateNotification (19464256, 0, 0, NULL, NULL)

 ncCreateNotification (19464256, 1, 4294967295, 0x00411054, 0x00408E98)"

Hope that helps.

DirkW

[John_Gourlay]

Dirk,

I added the "resetting" call to ncCreateNotification, but the behavior of the program did not change.

Yes, I am using NI-CAN 2.5.2, and yes, the USB board works correctly to receive frames using the bus monitor feature of MAX.

Thanks for your ideas, but I still need more.

John

[John_Gourlay]

The situation is not quite what I said in my previous message.  What's happening now is that I'm getting an internal error (0xBFF62002) from ncGetHardwareInfo very early in the initialization of my program.  I've attached the NicanErr.txt file and NI Spy output.

[DirkW]

What i can see in you spy log file is that you call the get hardware info VI from different process IDs. What exactly is your setup to do so.  Could youy ecxplain your hardware setup when you run the spy log and perhaps you could add your code so i can try to reproduce this error?

DirkW

[John_Gourlay]

There are two identical processes, one controlling CAN0 and one controlling CAN1.  During initialization each one calls the function verify_board, which you already have, to verify that the configuration in the NI MAX is the same as the configuration in the Bauer PCS test system.