Getting notification of error active bus state

[John_Gourlay]

I'm using the frame api for C, and I'd like to get a notification callback when the CAN controller goes from the error passive bus state to the error active bus state.  Is there any way to do this?

[O_Proulx]

Hello John,

The only functions that return the “state” of the error are reads and writes.  You could make a function that would:

1.    Call a read (or get property)
2.    Inspect the error code
3.    Send notification (change a bit to 1 for example) if “state” has changed

You would have to run this function periodically to simulate a "notification".

Another option is to use the get property function to read the error counter.  The state goes from Error Active to Error Passive when the count equals 128.   The state also goes to "Bus Off Error" when the count is 255.

Have a great day.

[John_Gourlay]

Olivier,

Thanks for the ideas, but I really would like to avoid polling the interface for the bus state. 

I might have answered my own question, but I still need a little help.  I've found that if I set the
NC_ATTR_LOG_COMM_ERRS attribute to true, then I get read-available notifications and
NC_FRMTYPE_COMM_ERR frames from ncRead.  When the CAN controller goes into
error-passive state, the frame's arbitration id field contains 4003000B, "Comm. warning: No Ack".
When the CAN controller returns to error-active state, the frame's arbitration id field contains
0000000B, "Comm. errors/warnings cleared".

This is exactly what I want as far as it goes, but my remaining question is what if the CAN
controller goes into bus-off state?  I can't test this case easily.  What arbitration id value will
I get in this case?  Reading between the lines, I'm hoping that it is 8003000B, "Comm. error:
No Ack".  Is this right?

John

[O_Proulx]

Hello again John,

The error code depends on what causes the device to go into bus-off state.  As mentioned above, the device goes into bus-off state when the error counter reaches 255.  The arbitration ID of the NC_FRMTYPE_COMM_ERR frame will represent what caused the counter to go from 254 to 255.  If it is because the device received no acknowledgement for the previous frame, then you are right, the arbitration ID will be 8003000B, "Comm. error:No Ack".

You probably looked at this already, but just as reference, you can find the other error codes in this manual at page 11-73.  

Have a great day.

[John_Gourlay]

Olivier,

I can live with this answer, but I'd like to note that a CAN controller will never go into bus-off state for lack of an acknowledgement.  This means that if there is a bus-off notification it will have to appear as a different arbitration id, not 8003000B.  Do you have documentation that goes into more detail than page 11-73 about what circumstances can cause each of the arbitration id values?

John

[DirkW]

See the same manual Appendix B "CAN Error Detection and Confinement" for detailed CAN  ERROR information.

Keep in mind:

If the CAN controller goes into BUS off because the receive error counter reached  256, then you would need to restart your communication in order to clear the state.

If you enable the NC_ATTR_LOG_COMM_ERRS attribute all the warning and errors are logged to the read queue and you will not see any error/warning state anymore.

DirkW