Has anybody captured an error frame occurence with CAN driver version 2.2

[RyanJ]

I was very excited about the appearance of the Comm Error Frame Type in version 2.0 of the driver. I have a Series 2 card and was working with the CAN driver version 2.2 to attempt capture error frames with an in house written tool.

Currently we have a tool from Vector that we must use to monitor our CAN system for Error Frames that occur due to a discrepancy in the ATMEL CAN core that we are using. We would like to get rid of the Vector tool and though we could because this capability appeared to be available in the NI driver.

I executed ncConfig with NC_ATTR_LOG_COMM_ERRS = NC_TRUE and the called the ncRead command to get data from the Read Queue. The tools built upon the NI CAN driver and the Vector tool seen exactly the same data, except that when the a communication attempt was turned into an error, the Vector tool indicated and Error Frame had occurred and nothing was available from the NI tool.

Has anybody captured an NC_FRMTYPE_COMM_ERR Frame with the ncRead command, and if so would you be willing to help.

Thanks.

[biker2000]

Hi Ryan

Unfortunately, NI-CAN 2.2 is not capable of directly logging the 'error frame'.
When you set NC_ATTR_LOG_COMM_ERRS = NC_TRUE, only the following communication problems can be logged directly as frames in the read queue:

8000000B hex:Comm. error: General
4000000B hex:Comm. warning: General
8001000B hex:Comm. error: Stuff
4001000B hex:Comm. warning: Stuff
8002000B hex:Comm. error: Format
4002000B hex:Comm. warning: Format
8003000B hex:Comm. error: No Ack
4003000B hex:Comm. warning: No Ack
8004000B hex:Comm. error: Tx 1 Rx 0
4004000B hex:Comm. warning: Tx 1 Rx 0
8005000B hex:Comm. error: Tx 0 Rx 1
4005000B hex:Comm. warning: Tx 0 Rx 1
8006000B hex:Comm. error: Bad CRC
4006000B hex:Comm. warning: Bad CRC
0000000B hex:Comm. errors/warnings cleared
8000000C hex:Transceiver fault warning
0000000C hex:Transceiver fault cleared
(if frame type is NC_FRMTYPE_COMM_ERR)

The only thing you can currently do, is poll the NC_ATTR_SERIES2_ERR_ARB_CAPTURE attribute (with ncGetAttribute; only available on Series 2 CAN cards!) to see, if an error occurred. However, given that this method only allows you to detect, whether a new error frame occurred since the last time you checked the register, this method cannot be used for accurately counting error frames (as error frames can occur faster on the bus than you can check this register).

-B2k

[RyanJ]

Is this going to be fixed in 2.3

[LoganS]

That's something that you'll probably want to submit product feedback on. According to b2k's response, by design "NI-CAN 2.2 is not capable of directly logging the 'error frame'", so it is not classified as a bug. If you want that to be a feature of NI-CAN, this discussion forum is one place to request, but the better place to request such a feature is by going to the following webpage and submitting specific product feedback.

Product Suggestion Center

Logan S.

[RyanJ]

What type of errors get capture by in the read queue, it still doesn't make any sense that this listing does not cover when an error occurs.

8000000B hex:Comm. error: General
4000000B hex:Comm. warning: General
8001000B hex:Comm. error: Stuff
4001000B hex:Comm. warning: Stuff
8002000B hex:Comm. error: Format
4002000B hex:Comm. warning: Format
8003000B hex:Comm. error: No Ack
4003000B hex:Comm. warning: No Ack
8004000B hex:Comm. error: Tx 1 Rx 0
4004000B hex:Comm. warning: Tx 1 Rx 0
8005000B hex:Comm. error: Tx 0 Rx 1
4005000B hex:Comm. warning: Tx 0 Rx 1
8006000B hex:Comm. error: Bad CRC
4006000B hex:Comm. warning: Bad CRC
0000000B hex:Comm. errors/warnings cleared
8000000C hex:Transceiver fault warning
0000000C hex:Transceiver fault cleared

For example: 2 CAN devices are communicating with the NI card monitoring, 1 device is transmitting, the other device sees the communication as invalid and transmits an error frame during say the data field. This would result in the message being an error in the NI card becaue the error frame is in violation of Bit Stuffing. Why in this case does ID 0x8001000B not get transmitted to indicated that the NI card found an error: Stuff and under what circumstance would an error: Stuff be indicated?

[biker2000]

Hi Ryan

I see what you’re trying to do. Unfortunately, the NI-CAN Hardware and Software Manual lags one very important piece of information:
When logging of Communication Errors is enabled (NC_ATTR_LOG_COMM_ERRS = NC_TRUE) the listed warnings are reported in the read queue ONLY when the CAN controller enters or is in the 'Error Passive' state (i.e. the transmit error counter or the receive error counter increments above 127).
The code that is returned reflects the last failure that causes the counter to reach the 'Error Passive' state. So, if CRC failures incremented the counter to 120 and then a stuffing failure occurs, the read queue will list the stuffing failure.

Thus, sporadic bus failures will not be captured.

-B2k

[RyanJ]

biker2000 and LoganS

Thanks for all of the support on this issue, I am better understanding how the NI CAN card works.

However, the described functionality provides little to no value in how I am using the National Instruments CAN card and I have submitted a Product Suggestion through the link provided earlier in this thread. Your example describes exactly why the implemented Error reporting is not useful. Many errors have to occur before the transition to Error Passive, but you only get the last one, which may or may not reflect what the overall problem is in the system.

Also, this leads me to another problem that I am having. The transition to Error Passive and Bus Off were added in a recent version of the CAN driver. Was there ever any though to making this configurable. It is problematic for me every time I restart the system that the NI card is connected to because the NI card ends up in Bus Off. I know this is following the CAN Protocol (our physical layer has Dominant = Zero = 0 V, when the system is powered down the NI Card would see may consecutive Dominant bits) because of Rule 6, section 8 (Fault Confinement) in the Bosch CAN specification. However, the NI card in my application is being used to monitor and interact with the system, it is not part of the functioning system. When it goes to Bus Off, my test application is dead. I would rather the occurrence of errors get reported, so I can see what the problem is, and fix what is wrong with the system, but still continue to function as best possible. I use the NI card in a lab environment for testing.

Again, thanks for everything
Nathan

[JLS]

Hello,

I believe you are in touch with NI directly now; repost if you are still looking to this post.

Thanks,

JLS

[KaBooOoom]

Hi !

I want to do exactly the same thing as Ryan.. did you find a solution to log all CAN errors (like CANanalyser) ?? And did you find how to restart an application after a busoff (without closing and reopen the CAN network ) ??

I know it now makes a while the post has been written, but anyway, if someone could help me ... thanks !

[RyanJ]

Unfortunately I have not had time since the post to complete further work.  There was some revisions in version 2.3 of the driver to address this, but it still does not appear to function as desired.  We continue to use an old version of CANanalyser to monitor the occurance of bus errors, but am frustrated that we cannot always be looking for these errors all the time.