EtherCAT Diagnostics 诊断

一、EtherCAT 错误是怎么检测到的?

EtherCAT 通常具有“即扫即用”的特性，扫描网络、启动系统，所有组件就运行起来了。绝大多数情况下不需要设置任何参数。

发现EtherCAT网络的通讯问题，典型的情况是因为以下原因：

• 机器停止工作，或者控制项目 (PLC 程序, NC 任务…) 接收到的数据值明显与实测值不一致。

示波器测到信号为True，而PLC变量值为False.

• 在TwinCAT项目中显示了错误（典型的情况是在Master Online页面或者TwinCAT Logger）

二、EtherCAT 网络中的错误类型

能影响到EtherCAT网络的错误分为2大类：

1.硬件错误

• 物理介质中断：数据帧无法达到所有从站，或者根本不能回到主站。
• 信息破坏： 数据帧到达网络中的所有从站并回到了主站，但有一些内容改变了。

2.软件错误

• 启动时从站达不到OP状态，因为来自主站的一个或多个初始化的命令被检测到不正确
• 由于在操作过程中检测到错误，一个正常工作的从站突然脱离OP状态

EtherCAT 分别从硬件和软件层面提供了丰富的诊断信息， 诊断信息可以按下图归类：

三、周期性同步诊断

周期性同步诊断 – Working Counter

Working Counter 是和过程数据（Process Data）一起的周期性送回主站的唯一诊断信息，所以这是最早能被主站和用户程序检测到的报警标记。

一个EtherCAT数据帧中的每个数据报文都以一个16位的Working Counter (WKC)结尾，WKC 每经过一个数据报文中指定的从站就会递增，递增的原则如下：

• Read-only 命令(xRD): 如果从站内存可读，则 WKC+1.
• Write-only 命令(xWR): 如果从站内存可写，则 WKC+1.
• Read+Write 命令(xRW): 如果从站内存可读 WKC+1，可写则 WKC+2 (i.e. 如果读写都成功则 WKC+3).

1.主站检查返回的每个数据报文的WKC值

• 返回主站的数据报文中的WKC 当前值 ＝ 预期值 →WKC有效，数据报文中的输入数据转发给控制程序(PLC, NC, …)

每个总线周期主站都会验证 Working Counter.

• 返回主站的数据报文中的WKC 当前值 ≠ 预期值 →WKC无效，数据报文中的输入数据被丢弃 (PLC/NC 使用旧的数据)

本页是WKC验证有效的情况

• 验证的结果就在每个同步单元Sync Unit的从站的WcState信息中标记，验证成功则WcState为0，验证失败则WcState为1
• 这就是为什么一个同步单元Sync Unit会共享同一个WcState标记，而任一从站读写不成功都会导致整个数据报文都无效。
• 读写不成功的原因：从站没有成功增加WKC，有可能因为物理上数据帧就没有到达，或者因为它不在OP状态，或者其它可能的原因。

在最新版的TwinCAT 3.1中，可以把单个从站（左图）或者全部网络从站（右图）配置为：主站把 无效的输入数据全部置 0 而不是废弃之。

这个功能更加危险，如果开发人员考虑不周，可能性会引起程序误动作。慎用！

2.Working Counter 相关信息:

• 很少能检测到具体是哪个或者哪些从站没有成功处理数据报文（数据报文中指定地址的从站没能成功增加数据报文的WKC）。
• 不会报告错误原因（从站没有成功增加WKC，有可能因为物理上数据帧就没有到达，或者因为它不在OP状态，或者其它可能的原因）。
• WKC与数据帧同步到达，主站以最快的速度作出故障响应，立即向控制程序或者用户提供一个故障标记位。
• WKC的有效标记位通常还需要与硬件或者软件诊断信息同时使用，这些诊断信息可以 由主站发送命令读取回来，并帮助定位故障位置和故障原因。

Working Counter 的主要目的是立即检测出通讯错误， (i.e. 为了主站快速做出反应), 而不是为了精准分析通讯错误

四、Working Counter 和 Sync Units（WKC和同步单元）

1.SyncUnits（同步单元）

把从站分为不同的组，每个组使用不同的数据报文，所以每个同步单元具有独立的 WKC。

对于伺服驱动器，为了精确定位故障点，可以把每个伺服都设置为独立的同步单元。对于IO模块，可能把一个耦合器及所带的IO模块，配置为一个同步单元。

为了优化的目的，Sync Unit 的配置是一个可选的步骤。关于如何分配同步单元，并没有一个黄金法则，因为这是由项目决定的：通常来讲，工作时紧密相关的从站应该分配到同一个同步单 元，而功能相对独立的从站应该放到独立的同步单元。

2.在 TwinCAT中指定 SyncUnit

TwinCAT为不同的Sync Units（同步单元）创建独立的数据报文，每个报文拥有自己 Working Counter 计数器

五、硬件诊断

1.硬件状态速览

主站的 Online 页面，提供了诊断网络硬件问题的最佳方法

系统上电时候可能产生硬件错误，并在TwinCAT中累加，而通常这些错误并不代表有问题。所以，查找可能的硬件问题时，建议清除程序启后的所有错误计数，这样才能监视到运行过程中 发生的实际错误次数。

2.初步检查 – 拓朴错误

VPRS = Vendor ID, Product Code, Revision Number, Serial Number: 网络启动时主站扫描到的拓朴结构与TwinCAT 配置文件的朴拓结构不符。此类错误的原因，可能只是简单地插错网线。

3.初步检查 – 接地和屏蔽

发生硬件错误时，建议必须检查EtherCAT网络设备是否共用同一个接地（因为不同接地之间的 环流可能导致数据损坏）。

关于EtherCAT网络安装的更完整、全面的描述信息，请参考ETG文档 ETG.160 “EtherCAT Installation Guidelines” ，可以从ETG官网www.ethercat.org.下载。

4.初步检查 – EBUS 电流

每个 EL 模块都会消耗若干 EBUS 电流，硬件故障发生时，建议必须检查每个I/O组的可用Ebus电流。

根据经验，EBUS耗电量大的模块，比如网关模块EL6xxx，在保证其EBUS供电足够的前提下，建议散放在耗电量小的模块( 比如普通DI／DO模块）之间，所以尽量不要几个网关模块挨在一起，也不要紧挨着控制器或者耦合器放置。这是从散热的角度考虑。

电流消耗达到限值时，应插入一个 EL94xx 模块。

EL9100电源模块不仅可以接入负载电源，还有散热的作用，是最便宜的发热量最小并且能传递EBUS的模块。相同价格的还有EL9186/EL9187等电位分接模块。

5.Emergency Scan（紧急扫描）

Emergency Scan （紧急扫描ÿ