Multiple frame retransmission by Hot Plugin of CAN cable

[fsolodovnik]

Hello Peak-System team.

I observe the multiple frame retransmission by Hot plug-In of the CAN cable between two Peak Devices
It relies to CAN interconnect cable, the both CAN devices remain plugged in in PC.
I have running PCANView (NOT IN LISTEN_ONLY MODE, NO FILTER APPLIED) with PCAN USBFD PCAN_USB Driver 4.3.0.16563 and latest FW on one side and
my own applibation using PCAN Chip USB and PCANBasic.dll.
The application sends CAN frames using CAN_Write and PCAN Chip USB once per second and does CAN_Uninitialize-CAN_Initialize sequence when it recognizes the CAN bus problem.
As expected I see on the disconnected from PCANView bus from the application the CAN frames repeated with maximal possible rate (3 frames per ms at 250 Kb speed)
But when I connect the CAN cable between devices I see sometimes several hunderts of repeated messages with the same rate 3-4 messages per millisecond
I expect that PCANView acknowleges the incoming CAN messages and the retransmission shall stop after first succesfull transmission i.e. when sender recognizes that ACK bit was driven by receiver
But It looks for me that PCAN Chip USB continues to send those messages
I observe these hunderts of CAN messages in the PCANView after cable connection, after several hunderts of nilliseconds everything recovers

I have a question : Is it possible to get the state of ACK bit of received message using PCANView or PCAN Explorer in trace mode?
Another question is : howto limit the amount of transmitted but not acknowleged CAN messages from PCAN Chip USB?
It is required to know the transmission status of the message, but it is not desired to transmit it 128 times before error recognition.

Thank You
Best regards, Fedor Solodovnik

[M.Maidhof]

Hi,

CAN uses an acknowlege bit to be sure the transmission was successfull. If you send out a message without a second active CAN node, the CAN-Controller will resend the message as fast as possible on the CAN bus infinite. If you send messages to the PCAN hardware while no transmission is possible, the frames will be stored in the TX queue of the driver and hardware, until the CAN bus is working again correctly with at least a second node. Than those stored messages will be send to the CAN as fast as possible. To reset the TX queue in the hardware and driver you can use a hardware reset by calling Uninitialize()/Initialize() again, or when you only want to empty the queue of the application you can use CAN_Reset(). See help for PCANBasic API for more details.

Answers to your questions:
- If you use the trace option with PCAN-View or PCAN-Explorer and enable the errorframes, you could see that those error frames are set as "acknowledge errors".
- see above, reset or init again.
- you will get a busheavy error directly after the CAN-Controller resends the same unack message more than 16 times. You will get this info through a status message with CAN_Read().

regards

Michael

[fsolodovnik]

Hello Michael,

Thank You for the fast reply and for the hint how to improve the situation.

I did the very simple test: I started 2 PCANView applications, one using PCAN USB FD and another using PCAN USB Chip
I disconnected the bus and sent one message using PCANView from USB FD to USB Chip.
When I connected the bus again - I see several errors and one transmitted message at the end - everything works as You explained
I did few tests and I have not seen errors - after bus reconnection the USB Chip gets as many messages as there were sent from USB FD

But in the opposite direction it goes wrong

When I have sent one CAN message from disconnected USB Chip and reconnect the bus - I see like hundert of repeated messages
I have updated PCANView, driver and firmware to the latest versions
Trace is attached

Unfortunately Your proposal is only the workaround and it would be nice to have the real fix.
As You mentioned the Peak Firmware might recognize the busheavy after 16 retransmissions, but the device is sonnected to USB bus using polling as usual
and in reality the application will need some 5-10 additional miliseconds before calling CAN_Unitialize, I do not know how fast will CAN_Unitialize stop the retransmission.

Thank You in advance
Fedor