Canopen 节点卡在 preop 状态答案

【问题标题】：Canopen node become stuck in preop stateCanopen 节点卡在 preop 状态
【发布时间】：2019-01-24 03:40:56
【问题描述】：

我在使用 canopen 的 can 总线上有 2 个节点（x 和 y）。使用临时节点“z”，我发送一条 nmt 消息将所有节点置于 preop 状态，然后发送一条命令将 y 置于操作状态。然后我在总线上发送一堆扩展 id 消息，用于节点 y，节点 x 在其字典中不知道这些消息。在发送到 y 期间，节点 x 上的节点监控表明它处于 preop 状态。一切似乎都很好。完成向节点 y 发送数据后，我发送命令将所有节点置于操作状态。节点 x 根据其 nmt 状态代码卡在 preop 状态。调试我发现canopen x中的rx fifo溢出了。在 preop 模式下应该忽略所有这些扩展消息吗？我什至在停止模式下尝试了与卡住 x 相同的结果。这是怎么回事？

【问题讨论】：

标签： embedded communication can-bus canopen

【解决方案1】：

对于任何 CAN 总线节点，您必须连续读取所有传入消息并忽略不感兴趣的消息。 CAN 控制器中的过滤器设置可能会有所帮助，但要构建坚固的应用程序，您必须始终准备好随时出现任何带有任何 ID 的 CAN 消息。确保这一点的最佳方法是始终连续读取 rx fifo 缓冲区，并且每次都继续读取直到它为空。

只要有错误，CANopen 节点就会保持运行前状态。可选地，它可以发送一条说明错误性质的 EMCY 消息，然后在清除错误时发送另一个所有位都设置为零的消息。在这种情况下，NMT master 应该等到 EMCY 清除消息，然后再发送启动远程节点。

【讨论】：

谢谢伦丁。我假设在 canopen NMT 状态下，例如 preop 或 stop 自动忽略所有消息，除了状态允许的其他消息，即 preop 忽略 PDO，这是不正确的吗？无论如何，我正在通过中断处理所有罐头消息，因此缓冲区永远不会满……我没有看到任何 EMCY 消息……也许我在堆栈之外还有其他问题。如果通过 EMCY 发出错误，是否只有通过发送 NMT 消息（例如 go to reset communication）来清除它？
@Michael Rx FIFO 溢出的级别低于 CANopen，介于 CAN 驱动程序和 CANopen 堆栈之间。也许在堆栈中适应某个控制器。 CANopen 堆栈确实应该在预操作模式下忽略 PDO，但那是在应用程序级别。正如我所说，EMCY 消息是可选的。但是，如果您预计会出现某些错误，它们可以帮助控制流程。应该以有意义的方式清除错误。如果某个节点出现内部错误，其他节点无法清除，但需要处理该错误。
事实证明，为 STM32 提供的 CANopen 驱动程序假设任何扩展的 id 消息都通过硬件过滤器过滤掉。这导致我的扩展 ID 消息被读取为未初始化的标准 ID 消息，即 ID = 0 又名 NMT 消息。这导致了异常行为。感谢您的指导。
@Michael 好的，这很奇怪。我听说 ST 的 CAN 驱动程序总体上不好。显然有很多错误。