CANOpen 网络负载高于预期答案

【问题标题】：CANOpen network load higher than expectedCANOpen 网络负载高于预期
【发布时间】：2019-10-21 14:50:50
【问题描述】：

我正在使用通过 CANOpen 网络连接到 4 个从机的主计算机进行一个项目。

在每个时间步，计算机从每个从机接收测量消息，并向它们发送控制消息。每次采样总共收到 4 条消息，发送 4 条消息。

发送的消息是一个带有 6 个数据字节（包括 COB-ID 在内的 8 个字节）的 PDO 收到的消息是一个带有 8 个数据字节（包括 COB-ID 在内的 10 个字节）的 PDO

我的 CAN 网络配置为 1Mbit/s，我以 1000 Hz（1 ms 采样时间）运行我的程序。由于所描述的消息产生的总负载为 576 位/周期，因此网络中预期的总负载为 576kbit/s，即 57%。

然而，我看到的是：

控制计算机测量负载约为 86%（最小值为 68%，峰值为 100%）。
我连接到网络的 USB CAN 总线分析仪记录了一个流量消息（计数）大约是我名义上的一半期望（即每个周期发送 4 条，接收 4 条，持续 50 秒应该会产生 50k 条消息，而我只看到 18-25k 条）。此外，我收到每个周期来自从设备的 1-2 条错误消息网络过载。在指出之前，即使计算作为流量一部分的这些消息的大小不会接近解释负载异常。

我想知道的是我计算 CANOpen 网络负载的方法是否正确。例如，是否有任何特定于协议的握手、CRC 或任何类型的额外字节发送以使网络简单地工作？我在wiki page of CANOpen 中看不到任何内容，但我知道原始CAN bus 标准中的消息有这样的附录。

【问题讨论】：

【解决方案1】：

在 CAN 消息中，要传输的数据不止于此。还有仲裁 ID（11 位或 29 位，取决于您使用的是 CAN 2.0A 还是 2.0B）、15 位 CRC、7 位 EOF 标记、控制字段以及其他一些保留位。根据数据，也可能有填充位。

使用 CAN2.0B 并假设数据为 48 位（6 字节），您将获得大约 132 位的消息大小和大约 151 位的 64 位消息。

总结一下，每个周期大约 1132 位，这对于 1Mbit/s 总线和 1000 Hz 来说太多了。

希望对您有所帮助。

【讨论】：

我认为 CANopen 维基百科页面并没有显示完整的图片。看看这里：(en.wikipedia.org/wiki/CAN_bus#Base_frame_format)。 CANopen 帧基本上是绿色到红色的位。但是由于使用 CAN 协议作为传输，剩余的位仍然被传输。
您共享的维基百科页面（在顶部段落中）表明使用了 CAN 协议的数据链路和物理层。 CRC 是数据链路层的一部分。
CANopen 位于第 7 层（应用层）。 CAN 只有第 1 层和第 2 层（物理层和数据链路层）。 CRC（几乎）总是在第 2 层，排除了物理层上的问题。因此，您不会在 CANopen 中真正找到有关 CRC 的内容。但是当您计算总线负载（第 1 层）时，您必须考虑第 2 层想要在第 1 层上传输的所有内容。
检查 CAN 标准。尤其是物理层。一条具有 64 位有效负载的 CAN 消息在总线上至少有 111 位。也可能有“东西位”。 IE。每当有 5 个相同的位相邻时，就会注入一个不同的位。您还可以使用网络上的一些总线负载计算器。
@raggot 忘记 CANopen，这是在数据链路层上完成的。所有 CAN 帧都有一个 15 位的 CRC。虽然像 SDO 这样的一些 CANopen 帧包含一个额外的校验和作为有效载荷的一部分……但这与计算总线负载无关。如果查看高层 CANopen 文档而不是 CAN 文档，您只会感到困惑。