Embedded CANOpen网络负载高于预期

我正在做一个项目，一台主计算机通过CANOpen网络连接到4个从机

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

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

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

然而，我看到的是：

控制计算机测量约86%的负荷（最小值为68%，峰值为100%）

连接到网络的USB CAN总线分析仪记录通信量 消息的数量（按计数）大约是我名义上的一半 expect（即，每个周期发送4条，接收4条，持续50秒，将产生50k条消息，而我只看到18-25k条）。此外，我收到 每个周期1-2条从设备发出的错误消息 网络过载。在它被指出之前，甚至计算 作为流量的一部分，这些消息的大小不会接近 解释负载异常

---

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

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

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

综上所述，您将获得大约1132位/周期，这对于1Mbit/s总线和1000 Hz来说太多了

---

希望这能有所帮助。

我认为CANopen wikipedie页面并没有显示全部情况。看看这里：（）。CANopen框架基本上是绿色到红色的部分。但由于使用CAN协议作为传输，剩余的位仍然被传输。您在Wikipedia页面上共享了使用CAN协议的数据链路和物理层的状态（在顶部段落）。CRC位于数据链路层的一部分。CANopen位于第7层（应用层）。CAN仅为第1层和第2层（物理层和数据链路层）。CRC（几乎）总是在第2层上，排除了物理层上的问题。因此，您不会在CANopen中真正找到关于CRC的内容。但是当你计算总线负载（第1层）时，你必须考虑第2层要通过第1层传输的所有内容。特别是物理层。一条64位有效负载的CAN消息在总线上至少为111位。此外，可能还有“填充位”“。也就是说，每当有5个相同的位相邻时，就会注入一个不同的位。在web上也有一些总线负载计算器，您可以使用。@raggot忘记CANopen，这是在数据链路层上完成的。所有CAN帧都有15位CRC。虽然有些CANopen帧（如SDO）在有效负载中包含额外的校验和…但与计算总线负载无关。如果查看高层CANopen文档而不是CAN文档，您只会感到困惑。准确计算CAN总线负载不是一件小事。这是如何做到这一点的一个示例。此外，这不是一个真正的编程问题，因此它更适合@Lundin，因为实际上我正要问它在那里，但发现CAN和网络问题更常见，在这里回答得更清楚（参见两个站点上比较的相关标签）