[参考译文] AM2434：AM2434 的 EtherCAT 通信问题

尊敬的 Zekun：

感谢您提供详细信息。 上面共享的日志片段中的一个小说明：

在 Node2 中、我看到从第 18803 帧到第 18806 帧前向帧 (WKC = 7) 和返回帧 (WKC = 11)、但在红色框中、它显示为丢失帧。 您能解释一下在这种情况下丢失的帧吗？ 客户是否将第 53185 帧（来自节点 1）用作丢失的帧？

我们正在查看提供的详细信息和可能导致此类问题的参数。

此致、
Aaron

除此之外、他们是否可以共享所有 LRW 数据包、而无需过滤从 INIT 到 OP 的转换（即使从正常的设置也可以）？ 此外、是否可以从 TI 器件记录错误计数器 0x300 到 0x30F、以及在错误场景中记录错误计数器背后的计数器？

嗨、Aaron、Pratteesh

我还附加 Wireshark 捕获的 EtherCAT 软件包。

e2e.ti.com/.../7268.WiresharkLog.zip

谢谢

Zekun

这些日志文件由可再生产的软件包和不可重现的软件包组成。

尊敬的 Zekun：

感谢您的日志。 是的、我们看到可重新生产的软件包中发生了帧丢失、我知道主设备旨在当帧未返回到主设备时停止 EtherCAT 通信。

此外、是否可以从 TI 器件记录错误计数器 0x300 至 0x30F、以及错误场景中记录错误计数器背后的计数器？

能够共享错误计数器详细信息。

此致、
Aaron

嗨、Aaron

n Node2、我看到从第 18803 帧到第 18806 帧前向帧 (WKC = 7) 和返回帧 (WKC = 11)、但在红色框中、它显示为丢失帧。 您能解释一下在这种情况下丢失的帧吗？ 客户是否将第 53185 帧（来自节点 1）用作丢失的帧？

有一个错误的 scrren 射击。

正确的 思路是您可以在 节点 2（正常情况下）中看到、表明了下行和上行对。 一个下行对一个上行。

但是对于 Node1、您可以看到 6-11-6、因此之后没有上游、这意味着应该传递给主器件的软件包丢失。  

节点 1 与节点 2 没有关系、因为我们不能并行测试节点 1 和节点 2。  

我们只想显示节点 1 和节点 2 的情况。

节点 1、6 –11-6、错误。 它应该是 6 - 11 - 6 - 11 –11 –11

node2、是正确的情况。

有 2 个可能的原因。

1.从节点 1 到节点 2 的包丢失、因此节点 1 有下游但没有上游、但节点 2 是正确的。

2.从 Node2 到 Node 的包丢失,因此 Node 2 正常,但 Node 1 丢失上游。

谢谢

Zekun

大家好、Aaron、Pratheesh

请查看以下错误计数器屏幕截图。

在以下环境中也会出现此问题。

目前、​​对于此环境、客户只确认了错误计数器值 0x300 至 0x30F。
【主器件】-[IO]（5 个单元）-[E7B_1]-[E7B_2]-[E7B_3]

由于上部 PC 无法直接读取寄存器值、因此它们连接了 TwinCAT、以  在问题发生后确认寄存器。 然而、TwinCAT 可以读取并清除错误计数器值、因此结果可能无法反映​​出问题时的实际值。 这仅供参考。

E7B1

E7B2

E7B3

我还建议他们添加调试代码、以便 在使用调试代码获得寄存器值后提供寄存器值。

谢谢

Zekun

尊敬的 Zekun：

节点 1、6 –11-6、错误。 它应该是 6 - 11 - 6 - 11 –11 –11

node2、是正确的情况。

我明白。 感谢您的讲解。

因此有两个可能的原因。

是、正确。

[Main Device]-[IO]（5 个单元）-[E7B_1]-[E7B_2]-[E7B_3]

我的理解是、在这种环境中观察到帧丢失、错误计数器寄存器的捕获基于同样的环境？

因为上部 PC 无法直接读取寄存器值、因此它们连接了 TwinCAT 以  在问题发生后确认寄存器。 然而、TwinCAT 可以读取并清除错误计数器值、因此结果可能无法反映​​出问题时的实际值。 这仅供参考。

客户还可以在从 TwinCAT 读取错误寄存器时启用 Wireshark 捕获、以便我们可以从 TwinCAT 查看对错误寄存器的访问并实时观察错误计数器（无需预测 TwinCAT 是否清除这些寄存器）。

此致、
Aaron  

嗨、Aaron

根据我的理解、在这种环境中可以观察到帧丢失、并且错误计数器寄存器捕获基于同一种环境？

没错。

因此、根据当前情景、您是否有任何可能导致此问题的想法？

谢谢

Zekun

尊敬的 Zekun：

因此根据当前情形、您是否有任何可能导致此问题的想法？

我们已经尝试使用上表中提到的 PDO 值从我方重现此问题。 我们怀疑该问题可能与自定义设置中执行的 FMMU 配置有关。 我们尝试了在以下环境中组合 PDO 分配：

SOEM（主器件）<>ET2000 <>AM243x-LP（RxPDO 286 字节、TxPDO 516 字节）<>AM243x-LP（RxPDO 9 字节、TxPDO 17 字节）<>AM243x-LP（RxPDO 9 字节、TxPDO 17 字节）

通过这种配置、可以实现 没有发现帧丢失 。 附加日志以供参考： e2e.ti.com/.../SOEM_5F00_Frame_5F00_Loss_5F00_Debug_5F00_v0690_5F00_0530.zip

客户设置中的错误计数器寄存器将有助于进一步分析问题。

此致、
Aaron

嗨、Aaron

您是否需要客户 FMMU 配置文件、以便我们将其与 TI 的比较？

谢谢

Zekun

尊敬的 Zekun：

您是否需要客户 FMMU 配置文件、以便我们可以将其与 TI 的比较？

我们复制了上述 xls 文件中提供的 TxPDO/RxPDO 长度。 是的、我们可以比较客户是否有从主器件 (0x600 - 0x67F 和 0x800 到 0x83F) 进行 FMMU/SM 配置寄存器编程的详细信息。

此致、
Aaron

嗨、Aaron

客户重现问题并转储所需的寄存器、也转储正常情况下的版本。

执行以下操作：

1.为什么在 OK 和 NG 情况下存在错误计数?

2、AM243 0X30c 的定义与 Beckoff、的不同是寄存器是否仅存在于 TI ?

3.我要求客户也获取主控制器 FMMU 配置寄存器。

4.有什么想法来调试这个?

有一件事、  

此致

Zekun

嗨、Aaron

我很好奇,我们的处理逻辑和贝克夫逻辑,这两者有什么区别吗?

根据我的理解、我们根据 ETG 规则对 PRU-ISCCS 进行编程、此规则也由 Beckoff 提出。 它应该是一样的。

那么为什么拓扑会导致不同的场景呢?

可能的原因和原因背后的原理图是什么？

谢谢

Zekun

嗨、Aaron

SM 寄存器值（不使用 SM4~SM7）

不使用 FMMU、（FMMU2~FMMU7）

谢谢

Zekun

更新关于控制器的一件事：

此问题只能在特定 CNC 控制器上重现,如果选择 Beckoff 或 Omron ,则无法重现。  

现在有几个疑问可以分析:

(1) 寄存器 0x303 在正常和异常条件下有一个非常可疑的值 255。 除非这是一个 8 位寄存器、否则这不是正常值。

(2) AM2434 上正常情况和异常情况下的寄存器值没有明显差异。

(3) 正常和异常情况下都有相当多的错误。

(4) 在何种情况下、ESC 会停止转发数据？ 即使存在 CRC 错误、也应该转发数据吗？

谢谢

Zekun

尊敬的 Zekun：

感谢您提供详细信息。

错误计数器寄存器详细信息可在以下位置找到： TI EtherCAT 子器件控制器寄存器列表。   RX Error 在该问题中似乎发挥了关键作用。

由于 RX_ERR 在这些情况下似乎发挥着关键作用、因此获取 PHY 寄存器值也将显著帮助我们了解 PHY 的行为。

(3) 在正常和异常情况下都有相当多的错误。

没错。

(4) 在什么情况下 ESC 会停止转发数据？ 即使存在 CRC 错误、也是否应转发数据？

我无法想到 ESC 会在运行时不转发帧（此时 EtherCAT 网络已成功初始化）的情况。 即使 ESC 控件在处理任何数据报时卡住、也会在网络中观察到格式错误的数据包、因为帧头会转发到下一个节点。

此致、
Aaron

尊敬的 Zekun：

客户在这里有任何回应吗？

此致

你（们）好 Ashwani

日本客户正在通过另一个 E2E 与 TI 讨论。 挂起这个。

谢谢

Zekun

尊敬的 Zekun：

那么、您需要此线程保持打开还是关闭它以避免重复？

此致、
Aaron