Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 0xBFF62133 with NI-CAN over NI-XNET

Solved!
Go to solution

My C app was written with the NI-CAN Channel API and works fine on the older PCI-CAN cards. Now it's running on a PCI-8512 with NI-XNET 1.3.0 and NI-CAN 2.7.2 Compatibility Library, and it gives this error spuriously: "NI-CAN:  (Hex 0xBFF62133) You set an attribute that is not supported when Virtual Bus Timing is disabled. Refer to the Frame To Channel Conversion section of the NI-CAN manual for a listing of attributes that return an error when Virtual Bus Timing is false. Solutions: 1) Set Virtual Bus Timing true (or leave as default). 2) Do not set the unsupported attribute."

 

My app does not use Frame To Channel Conversion nor the Virtual Bus directly, it is set to talk directly over the CAN0 hardware bus via the Channel API. Does the Compatibility Library use the Virtual Bus?

 

How can I avoid this error?

 

Thanks.

 

0 Kudos
Message 1 of 8
(8,111 Views)
The NI-XNET Compatibility Library doesn't use the Virtual Bus feature from NI-CAN, nor does it ever return that error code. Any calls to virtual ports should be correctly redirected to NI-CAN (and thus work as usual). Have you tried reproducing the issue with the latest versions of NI-XNET and NI-CAN? The latest version of NI-XNET is 1.4. What function is returning the error? You can get a call log by using NI IO Trace (AKA NI-Spy). Make sure that you enable NI-CAN under Tools -> Options -> View Selection.
0 Kudos
Message 2 of 8
(8,108 Views)

Thanks for the reply. Below is the Spy capture. Ignore the read warnings - there was no transmitter on the CAN bus. Notice that two of the three InitStart calls happen at the same time. My app is multi-threaded and each CAN task is handled by its own thread. All three threads try to init at the same time but one fails with that (bogus?) error. This was running on a quad-core CPU. I repeated the test after forcing the app to run on a single core and the error did not appear.

 

Is NI-CAN not thread-safe?

 

11740.  nctInitStart ("T1,T2,T3,T4", 0, 1, 0, 44)
Process ID: 0x00000FA8         Thread ID: 0x00000B04
Start Time: 13:59:47.828       Call Duration 00:00:00.015
Status: 0 (VI_SUCCESS)

11741.  nctRead (24, 1, NULL, NULL, {0}, 1)
Process ID: 0x00000FA8         Thread ID: 0x00000124
Start Time: 13:59:47.828       Call Duration 00:00:00.015
Status: 0x3FF62009

> 11742.  nctInitStart ("V1,V2,V3,V4", 0, 1, 0, 0)
> Process ID: 0x00000FA8         Thread ID: 0x00000C70
> Start Time: 13:59:47.828       Call Duration 00:00:00.015
> Status: 0xBFF63133

11743.  nctInitStart ("Speed,Torque,Dy...gEcho,DynoEStop", 0, 1, 0, 45)
Process ID: 0x00000FA8         Thread ID: 0x00000AA8
Start Time: 13:59:47.843       Call Duration 00:00:00.016
Status: 0 (VI_SUCCESS)

11744.  nctRead (24, 1, NULL, NULL, {0}, 1)
Process ID: 0x00000FA8         Thread ID: 0x00000124
Start Time: 13:59:47.843       Call Duration 00:00:00.000
Status: 0x3FF62009

> 11745.  nctClear (0)
> Process ID: 0x00000FA8         Thread ID: 0x00000C70
> Start Time: 13:59:47.843       Call Duration 00:00:00.000
> Status: 0xBFF621B0

11746.  nctWrite (44, 1, {0})
Process ID: 0x00000FA8         Thread ID: 0x00000EE0
Start Time: 13:59:47.843       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

11747.  nctRead (24, 1, NULL, NULL, {0}, 1)
Process ID: 0x00000FA8         Thread ID: 0x00000124
Start Time: 13:59:47.859       Call Duration 00:00:00.000
Status: 0x3FF62009

11748.  nctRead (24, 1, NULL, NULL, {0}, 1)
Process ID: 0x00000FA8         Thread ID: 0x00000124
Start Time: 13:59:47.859       Call Duration 00:00:00.000
Status: 0x3FF62009

11749.  nctWrite (45, 1, {0})
Process ID: 0x00000FA8         Thread ID: 0x00000ED4
Start Time: 13:59:47.859       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

0 Kudos
Message 3 of 8
(8,104 Views)
Solution
Accepted by topic author ClausB
So the actual error you see is 0xBFF63133, not 0xBFF62133 (error codes starting with 0xBFF63--- are NI-XNET errors). That's due to a bug in how the database is being imported (multiple threads are all attempting to create a cluster with the same name, hence the "duplicate cluster name" error). While the bug will be fixed in the future, in the meantime you will need to make calls to nctInitStart sequential. I'd recommend a small function that grabs a global mutex and then calls nctInitStart. Sorry for the inconvenience.
Message 4 of 8
(8,100 Views)

Good catch! Sorry I missed the different error code and so did my old app - it only reports the low 10 bits.

 

I will add the mutex. I had to do exactly that to solve a similar problem with DAQmx a while ago.

 

Thanks for your quick replies.

 

0 Kudos
Message 5 of 8
(8,097 Views)

The mutex worked. Thanks!

0 Kudos
Message 6 of 8
(8,088 Views)

@Chris Boyce wrote:
...a bug in how the database is being imported (multiple threads are all attempting to create a cluster with the same name, hence the "duplicate cluster name" error). While the bug will be fixed in the future....


Is the bug in NI-XNET or in NI-CAN?

 

Has it been fixed yet?

 

0 Kudos
Message 7 of 8
(7,580 Views)
It was a bug in the NI-XNET Compatibility Layer, a component of NI-XNET. It was fixed as of NI-XNET 1.5 (NI-XNET 1.6 is the latest).
0 Kudos
Message 8 of 8
(7,576 Views)