CanWarnComm

[Brian C]

Hello Justin,

> I don't believe that this means the bus off state occurs if any of the CanErrComm* values are returned. A bus off error ONLY occurs when the transmit error counter exceeds the value of 255. CanErrComm* values can be returned even if this state has not been reached.

Then what's difference between the CanWarnComm* error codes and the CanErrComm* error codes?

> From the manual, it looks like you will have to log the bus errors (using the ncSetAttribute function) first, then during an ncRead function you'll be able to determine of the bus is off. When bus errors are being logged, the ncRead function can return a value of 6 in the IsRemote field

It doesn't work.  ncRead returns CanErrCommNoAck and the NCTYPE_CAN_STRUCT is empty (all zeros).

Brian

[Eric_K]

Brian,

The "CanWarnComm" status warning indicates that CAN bus problems have been detected, but communication is proceeding. This warning corresponds to the CAN controller chip on the NI-CAN card entering what is known as "CAN Error Passive state".This happens on every NI-CAN board, if the error counter of the can chip reaches 127. If the bus problem continuous and the error counter reaches the 255, the can Chip stops any communication and the error message occurs. It is important to note that a can controller can not reach the 255 by only receiving frames. The receive error counter stops incrementing after 127. A bus off  state is always caused by a transmit process reaching the 255 error limit.

Eric K

Applications Engineering

National Instruments

[Brian C]

Eric,

> The "CanWarnComm" status warning indicates that CAN bus problems have been detected, but communication is proceeding.  This warning corresponds to the CAN controller chip on the NI-CAN card entering what is known as "CAN Error Passive state".

OK. 

What about the other CanWarn* error codes?  Do they also indicate that a problem occurred but communications is proceeding?  Or do they indicate a bus off?

> If the bus problem continuous and the error counter reaches the 255, the can Chip stops any communication and the error message occurs.

What error message?  Do you mean the CanErrCommNoAck value is returned?

> A bus off  state is always caused by a transmit process reaching the 255 error limit.

And how can I tell when that happens using your company's API?

Brian

[Justin_E]

Brian,

I think the big thing with these error codes that needs to be clarified is when each of the error codes occur. The CanWarnComm (and likewise the CanCommWarning/CanCommError) errors are returned from the NI-CAN functions themselves, and indicate that one of these three errors has occured. More detailed information about these errors can only be obtained if the ncSetAttribute function is called and Log Comm Warnings is set to true. Once this occurs, you will be able to obtain the CanErrCommNoAck, etc. errors from the arbitration ID of the Communication Warning or Error Frame. A warning is returned, like Eric said, when the counter reaches 127, and an error is returned when the counter reaches 255. If you look at the user's manual, you will see that there is both an error and a warning for various things (stuffing, format, no ack, etc), so the difference between when a "no ack" warning occurs and when a "no ack" error occurs is based on the size of the error counter. 

You should be able to see that a bus off state has occured when CanCommError is returned from the NI-CAN function. 

[Brian C]

Justin,

> More detailed information about these errors can only be obtained if the ncSetAttribute function is called and Log Comm Warnings is set to true.

As I CLEARLY stated early, IT DOES NOT WORK.

The result from the attached program is...

The error code BFF62005 was returned from a call to ncSetAttribute.

Brian

[Brian C]

Justin,

> You should be able to see that a bus off state has occured when CanCommError is returned from the NI-CAN function. 

Thank you.

Brian

[GPIB_Guru]

I am pretty certain the Log Comm Errors is not supported by the USB-CAN, but the Log Bus Errors is...

This will return a bus error frame that provides you with 4 useful bytes of data:

0 - Comm State

1 - TX Error Counter

2 - RX Error Counter

3 - ECC Register from the SJA100

The Comm state is:

0 - Error Active

1 - Error Passive

2 - Bus Off

If this property is false, the comm state should be returned in the error cluster of subsequent API calls - (the first write will likely return successful since it just queues up frames and the controller is likely in the error active state). If you are in error active, I would expect a successful status (0), if you are in error passive, I would expect the status of CanCommWarning (0x3FF6200B), if you are in bus off, I would expect the status of CanCommError (0xBFF6200B). It is probable that you may get a status of 3FF6206B, which means that no ack was detected.

[Justin_E]

Ah, good catch GPIB Guru!

[Brian C]

Guru,

Thanks!  That certainly helped.

If...

•   NC_ATTR_LOG_BUS_ERROR is true
•   a bus error occurs
•   and a NC_ST_READ_AVAIL notification is active

...shouldn't a NC_ST_READ_AVAIL notification occur?

Thanks,

Brian

[Justin_E]

I don't believe so. The description of the NC_ST_READ_AVAIL state is as follows :

At least one frame is available, which you can obtain using an
appropriate read function.
The state is set whenever a frame arrives for the object. The state is
cleared when the read queue is empty.

So, since a bus error occurs, a frame shouldn't have arrived for the object, and thus this state won't be set.