Academic Company Events NI Developer Zone Support Solutions Products & Services Contact NI MyNI
1 ratings:
 4 out of 5     Rate this Document

Bus Off Error When Trying to "Wake-up" a CAN Device

Hardware: Industrial Communications>>CAN

Problem:
After my CAN device idle and my controller attempts communication, I receive a Bus Off Error. How can I send a single wake-up frame to my CAN device after it enters idle state using NI-CAN?

Solution:
Solution for Problem:

To prevent a Bus Off Error, send a single wake-up frame (just one time) with a delay following to allow the device to become active. Then you can continue normal communication. It is important to realize that when a device becomes idle, it actually relies on the fact that a CAN controller will send frames multiple times. That is, the first frame received when a device is idle is NOT processed. The sudden voltage change on the bus caused by a frame transmission is sensed by a CAN device and will cause it to resume active operating conditions. Because of this, the frame which initiates the wakeup cannot be processed since the hardware misses the data in the frame and only detects the change in voltage. Thus, if you have a mechanism for sending a single activation frame, and then delay until all devices (or at least the one you intend to communicate with) wake up, you can resume normal communications while knowing deterministically that subsequent commands should/will be processed by the target CAN device.

In the NI-CAN API, the way to transmit a single frame - one time only - is by setting the Single Shot Transmit attribute to 1 (using the set attribute function: in LabVIEW use the ncSetAttr.vi for the Frame API and CAN Set Property.vi for the Channel API). For Frame API users, the Network Configuration object (programmed explicitly) can be used, where of course you must stop and start the task (using ncAction.vi) around the attribute setting. The sequence of events would generally be: Network Config (should have happened anyway at some point), Network Open, Stop, Set Attribute, Start, Write "wakeup frame," proceed with the program after sufficient delay. Please note that the required delay may be very small; the "10 second" wake-up time suggested for a device above is much longer than a normal device's "wake-up period". Of course, the baud rate used on a given network will factor into how many frames can be sent by a controller in a given period, and therefore how fast a corresponding error counter will increment as a result of unacknowledged frames.

Attached is an example, which will write a single "wake-up" frame using the technique described above, where the write will take place when a "Wake-Up" button is clicked.

 

Cause of the Problem:

Many CAN devices will become ide after some predetermined period of inactivity (not receiving a frame). In such cases, the device usually becomes active after seeing a frame on the bus.  However, the amount of time it takes to go from the idle state to active state will inevitably vary from device to device.

For example, suppose the controller on a CAN network sends a frame to a device which is idle.  This CAN device takes 10 seconds to become active. By definition in the CAN standard, frames which are not acknowledged will be retransmitted. Also in the CAN standard is the requirement that a device or controller implement transmit and receive error counters in order that a non-responsive device or controller can be ignored if it continues to generate errors.

The Bus Off Error State, which occurs when the error counter exceeds 255 causes this problem. If a device takes a long time to become active, the controller will send, and subsequently resend, the frame while it attempts to communicate with the idle device. Since the controller's transmit error counter will increase by 8 for each frame sent but NOT acknowledged, and it will continue sending frames until acknowledged.  The controller reaches a Bus Off Error state before the device fully activates and responds. This can be prevented by the above mentioned solution.

For more information about the CAN standard, see Appendix B of the NI-CAN Hardware and Software Manual linked in the Related Links section below.



Related Links: Product Reference: NI-CAN Hardware and Software Manual

Attachments:


SendSingleWakeUpFrame.vi - SendSingleWakeUpFrame.vi



Report Date: 07/26/2005
Last Updated: 03/31/2009
Document ID: 3NP9MD4B

Your Feedback! poor Poor  |  Excellent excellent   Yes No
 Document Quality? 
 Answered Your Question? 
  1 2 3 4 5
Please Contact NI for all product and support inquiries.submit