尝试唤醒一个CAN设备时发生Bus Off的错误

硬件: Industrial Communications>>CAN

问题:

CAN设备进入了休眠状态后，控制器再尝试通信时收到了Bus Off的错误。当CAN设备进入休眠状态后，如何使用NI-CAN发送一个唤醒帧来唤醒CAN设备？

解答:

可以通过发送一个有一定延迟的唤醒帧来激活设备，以此来避免Bus Off的错误。这样就可以和设备正常通信了。需要注意的是，当设备休眠时，设备需要依靠CAN控制器多次发送帧直到确认帧收到。因此，当设备休眠时，第一帧是不会被处理的。

CAN设备会检测到总线上由于帧的发送而引起的瞬时电压变化，此时CAN设备会重新恢复到正常的工作状态。用来唤醒设备的第一帧不会被处理。这是由于CAN设备只会检测到用来唤醒设备的总线电压的变化，而硬件不会接收这个数据。因此通过发送一个唤醒帧，然后等待所有的设备恢复到正常状态来确保正常通信，此后的所有的帧都会被目标CAN设备接收。 CAN设备会检测到总线上由于帧的发送而引起的瞬时电压变化，此时CAN设备会重新恢复到正常的工作状态。用来唤醒设备的第一帧不会被处理。这是由于CAN设备只会检测到用来唤醒设备的总线电压的变化，而硬件不会接收这个数据。因此通过发送一个唤醒帧，然后等待所有的设备恢复到正常状态来确保正常通信，此后的所有的帧都会被目标CAN设备接收。

在NI-CAN API中，通过使用属性设置功能来设置Single Slot Transmit 属性值为1来发送一个只发送一次的帧。在LabVIEW中，对于Frame API使用ncSetAttr.vi，对于Channel API使用CAN Set Property.vi。对于Frame API，如果可以通过使用ncAction.vi来开始和停止任务，那么网络设置（Network Configuration）也可以使用。

事件的顺序为：设置网络，开启网络，停止，设置属性，开始，写入唤醒帧，延迟一定的时间。注意所需的时间延迟很短。设备所建议的10s唤醒时间比普通设备的唤醒时间要长。当然，网络的波特率会影响一个控制器在一定时间内发送的帧数，因此会影响由于unacknowledged帧而造成的错误计数器的增长速率。

附件显示了使用上述方法去写一个唤醒帧的例子，例子中当“Wake-up”按键被按下时才会发生写入的操作。

问题产生的原因

很多设备在一定的时间内不活动时会休眠，而当设备检测到总线上有帧时就会重新处于激活的状态。但是不同的设备从休眠到激活状态的时间时不一样的。

例如，CAN网络中的控制器发送一个帧给现在处于休眠状态的设备，这个设备需要花费10秒时间来变成激活状态。CAN标准的设计为，没有被收到的帧会一直被发送直到ACK或者错误发生。另外，CAN标准包括一个需求，设备或者控制器需要有一个发送和接收的错误计数器。这样的话，如果一个没有响应的设备或者控制器持续的发生错误时，他们会被忽略。

当错误计数器超过255时会产生Bus Off的错误状态。如果设备需要花费很长的时间来激活，控制器会一直发送用来和设备通信的帧。每次帧被发送而收不到ACK时，错误计数器会加8，直到收到ACK或者错误计数达到255.当设备被完全激活之前，控制器会一直处于Bus Off的错误状态。这个可以通过前面提到的办法来避免。

关于CAN标准的更多信息，可以参照下面链接NI-CAN Hardware and Software Manual中的Appendix B.

相关链接:
Product Reference: NI-CAN Hardware and Software Manual

附件: