transmit ERROR COUNTER and LISTEN ONLY on 8461

[Nekomajin]

Hello all.

I'm using pxi 8461 Series 2.with 2 ports.
I have a few questions about the ERROR COUNTER.
--------------------------------------------------------------------------------------------
Background:
I attached CAN0 and CAN1 with a CAN cable, then I opened the bus monitor in MAX on CAN1 in LISTEN ONLY mode, Baud Rate=500K

(all other sets are by default).
I used 'write net.vi' to send a frame on the bus, since  CAN1 is on listen only mode, the program is re-transmiting the same

frame all the time, about 4000 frames per second.

--------------------------------------------------------------------------------------------
My questions:
1. CAN1 is on listen only mode, there's no acknowlege bit on the bus. Why can I see messages on the bus monitor?

2. CAN1 is on listen only mode, so there's no acknowlege bit on the bus. If so, will the 'transmit error counter' of CAN0

increment?

3. Following qustion2, I used 'get attr.vi' to get the 'transmit error counter' of CAN0, and discover it increments from 0 to

128 MAX, the value never reached 255, and the CAN0 NEVER goes into bus off state.
I was confused, I've read the CAN manual but find no answer.

4. I used 'set attr.vi' to set CAN0 to 'single shot transmit', then I send FIRST frame to CAN1, there is no message appearing

on CAN1 bus monitor, the transmit error counter of CAN0 increments to 8. Then second frame, no message on bus monitor,

transmit error counter to 16.
Then third frame, no message on bus monitor, transmit error counter to 24....
When the 'transmit error counter ' reaches 128, I send a frame, there IS a frame on the CAN1 bus monitor, and after frames

all appear on the bus monitor.
I was confused why this happens.

Above all, CAN1 is always on LISTEN ONLY mode.

-------------------------------------------------------------------------------------------------
Thanks,
Neko

[Nekomajin]

 I notice there's a paragraph in CAN manual saying:

"If no CAN devices are connected to the network interface port, and you attempt to transmit
a frame, the CanWarnComm status occurs. This warning occurs because the missing
acknowledgment bit increments the transmit error counter until the network interface reaches
the error passive state, but bus off state is never reached."

does this explain my question 3?

[GPIB_Guru · Accepted solution]

---

@Nekomajin wrote:

--------------------------------------------------------------------------------------------

My questions:
1. CAN1 is on listen only mode, there's no acknowlege bit on the bus. Why can I see messages on the bus monitor?

2. CAN1 is on listen only mode, so there's no acknowlege bit on the bus. If so, will the 'transmit error counter' of CAN0

increment?

3. Following qustion2, I used 'get attr.vi' to get the 'transmit error counter' of CAN0, and discover it increments from 0 to

128 MAX, the value never reached 255, and the CAN0 NEVER goes into bus off state.
I was confused, I've read the CAN manual but find no answer.

4. I used 'set attr.vi' to set CAN0 to 'single shot transmit', then I send FIRST frame to CAN1, there is no message appearing

on CAN1 bus monitor, the transmit error counter of CAN0 increments to 8. Then second frame, no message on bus monitor,

transmit error counter to 16.
Then third frame, no message on bus monitor, transmit error counter to 24....
When the 'transmit error counter ' reaches 128, I send a frame, there IS a frame on the CAN1 bus monitor, and after frames

all appear on the bus monitor.
I was confused why this happens.

---

1. You can see the message since no error flag was associated to it, so it saw essentially a valid end of frame. (see answer to #4 for more details)

2. Transmit counter will increment on the transmitter, yes.

3. Per the CAN Specification (Part A, chapter 7, step 3, exception 1), no ACK error can cause the TX counter to increment to 128, but no farther. Only other transmission errors can cause the TX counter to increment past 128.

4. The transmitter on the first frame detects an invalid ACK, so it pushes an error frame onto the bus for the next 6 bits (ACK Delimiter and some of the end of frame). This causes the receiver to discard the message since it did not get a valid end of frame. Once the transmitter goes into error passive, the error frame changes from 6 dominant bits to 6 recessive bits. This prevents the end of frame from being corrupted, so the receiver does actually receive the frame. The fact that there was no ACK doesn't actually prevent reception (it is actually the error frame from the transmitter that does that)

[Nekomajin]

Hi Guru,

Thank for your reply.

I still have some questions:

1. Except 'single shot transmit' and device close, is there any method that I can prevent the transmitter from the never-stop transmiting?

2. How can I get the node into 'bus off' state?

[GPIB_Guru]

---

@Nekomajin wrote:

Hi Guru,

Thank for your reply.

I still have some questions:

1. Except 'single shot transmit' and device close, is there any method that I can prevent the transmitter from the never-stop transmiting?

2. How can I get the node into 'bus off' state?

---

1. Not really. The CAN bus is clear that the device shall continue to attempt to retransmit the frame until it is successful or the device goes bus off. The Single Shot Transmit was added for some of the time-triggered protocols on top to provide more determinism at the expense of possibly losing data.

2. You need to generate a real bus fault to get a node to bus off. Just having a NAK is not enough (as you have found). A couple ways that I have gotten hardware to bus off including transmitting at the wrong baud rate (TX at 80k, RX at 40k, for example as powers of two work pretty well). This can cause stuff errors or other errors (not always deterministic). The best bet is to send a frame with lots of 1s or 0s to make it happen more often. Other options would be to physically short the bus (CANH to CANL works well for High-Speed CAN to go bus off.