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 （紧急扫描）操作，可以发送预定数量的探测数据帧，用于快速测试物理连接 (TwinCAT 应处在 Config Mode):

Emergency Scan 能够快速检查EtherCAT网络的永久硬件问题 (设备、电缆或者接头损坏)。用Emergency Scan的方法很难检测到随机的/不定时的干扰，处理这种干扰，应该进行完整的error counter analysis （错误计数分析）。

6.EtherCAT 端口的硬件诊断

为了进行更深入的分析，从站提供了基于端口的（port-specific）硬件错误计数。

EtherCAT 定义了端口号 0 to 3 (端口 0 总是输入口)，而TwinCAT 中通常把这些端口依次叫做A 到 D (A 总是输入口)，两种端口定义方式是等效的：

Master的Online页面，可以在线看到CRC校验错误计数。大部分从站是两个数字，耦合器EK1100有3个数字，而分支模块EK1122则会有4个数字。

7.Link Lost （连接丢失）错误计数器

有时候两个EtherCAT从站之间的物理连接可能会完全中断：信号完全无法到达相邻的从站。

Link loss（连接丢失），最有可能的原因是：

• 电缆或接头损坏（电缆连接），接触弹片不够力或者氧化（ Ebus连接）。
• 一个或者几个从站掉电。

一个端口上的物理连接中断，从站就会把该端口的 Link Lost Counter(连接丢失计数器) 加 1。

Register 内存地址	长度	含 义
0x0310	1 字节	port 0 的连接丢失次数
0x0311	1 字节	port 1 的连接丢失次数
0x0312	1 字节	port 2 的连接丢失次数
0x0313	1 字节	port 3 的连接丢失次数

物理连接的状态发生久性或暂时性的改变，在TwinCATLogger消息区中都会报告（并且保存在Windows Log 中）。

8.Link/Activity （连接/活动）指示灯

连接的永久中断很容易检查出来，不用分析连接丢失计数器（ Link Lost Counters ），只需要简单查看主站的Online页面：

9.无效帧（Invalid frame）错误计数器

有时候，即使硬件信号到达了相邻的从站，接收到的信号却与最初发送的不一致：

数据包发生损坏，最有可能的原因是：

• 如果该错误计数零星增加，极可能是由于外部 EMC 干扰。
• 如果该错误计数快速且稳步增加，极可能是由于设备损坏。

一个端口上的数据帧破坏，从站就会把该端口的 InvalidFrameCounter(无效帧计数器)加 1。

RX 错误计数器 和 CRC 校验错误计数器，都意味着硬件接收到的数据帧损坏，表征信息非常相近，但是二者分别是在从站架构的不同层面检测到的，其含义也略有不同。

10.物理介质上的信号传输

0和1的逻辑序列要在物理介质上传输，需要编码成预定义的电压/电流 电平（或者电平转换）。

• 电流/电压 值的序列叫做 symbols（符号）.
  • 基于特定的硬件编码标准，电流/电压值的可能序列并不是全都具有含义，这样就有了 有效符号和无效符号的分别。
  • 物理介质上符号是连续传输的，既在Ethernet数据帧内也在数据帧外（数据帧外的符
    号序列是为了让接收方及时检测到可能发生的连接丢失错误）
• 通讯由符号序列组成
  • 携带着有含义的信息的符号序列，就是Ethernet数据帧。
  • 两个Ethernet数据帧之间传输的符号序列，就是 数据帧间隔

硬件错误分为两种类型，都在无效帧计数器中累计。

• RXErrors:
  • 个别符号错误 (被特定的硬件解码器识别为无效）.
  • 在数据帧内部或者外部都可能发生(即使是在没有数据帧传输的时候，每个物理接口都
    会传输 idle 即表示空闲的符号)
  • → RXErrorCounters (无效帧计数器的高字节)
• CRCErrors:
  • 整个数据帧的循环冗余校验（CRC）错误.
  • 在数据帧内发生 (只有Ethernet 数据帧才进行校验).
  • → CRCErrorCounters (无效帧计数器的低字节)

11.RX 和 CRC 错误的类比

硬件通讯介质上的数据传输可以用标准的语言书写来打个比方：

• RX 和 CRC 错误 在解释上具有细微的差别，例如：

CRC校验只检查数据帧（Frame）内语义是否正常，但并不能发现网络帧间隔的非法字符。RX校验所有字符是否非法。

• CRC 错误 – 什么情况下会检测出来?

12.链接丢失(Lost Link)错误的简单监视

• 在EtherCAT主站的Online页面可以监视到链接丢失（Link Lost）

只要在主站的Advanced Setting中启用累加计数“Show Change Counters”即可：

添加这些操作是不需要重启TwinCAT软件的

此计数表示与从站的物理连接丢失的次数（1表示首次连接，>1表示在运行期间至少出现过1次 物理连接丢失）。

• 在EtherCAT主站的Online页面可以监视到数据帧错误（Frame error）

即从站的RX Error计数寄存器的低字节，错误计数如下：

从站的Frame Error计数器中保存着自TwinCAT启动以来的累计出错次数，点击“Clear CRC”所有从站的CRC计数清零，并重新累计。

13.怎样正确跟踪硬件错误计数

为了追踪硬件错误计数，建议进行以下设置:

• 在主站的Advanced Setting中 不要勾选 “Log CRC Counters” 标记。

• 在Online视图中添加注册字 0x0300÷0x030A 和 0x0310÷0x0312。

• 激活并重启 TwinCAT 配置:

• 重启TwinCAT后，清空所有错误计数:

• TwinCAT 中，EtherCAT主站的 Online 页面总是以 word-oriented 的方式显示计数值。

• 等待，直到错误补检测到：捕捉到的错误次数越多越好 (关闭项目或者重启TwinCAT就会清除计数，而最小化项目或者切换窗口则不会清除计数). 记录的值可以导出，以供进一步分析。

错误计数采集完成后，记得应把 “Log CRC Counters” 重新勾选上。(TwinCAT 需要重启).

14.怎样定位一个错误?

为了从显示的CRC错误计数分析出网络中的故障点分布情况，建议:

逻辑上沿着网络数据帧传播的方向确定从站端口执行CRC校验的顺序(根据 前述信息 previous information):

根据前面确定的顺序检测第一个报告RX Error Counter >0 的端口:

• 在网络中定位第一个报告RX Error的故障点：

报告无效错误计数器不为零的第一个端口 → 极有可能就是故障点。

15.在故障点采取什么措施?

在上页定位到故障点 previously located 后，应进行以下操作 :

• 检查与上个从站之间的连接电缆：
  • EtherCAT网线的走向是否靠近电源线或者干扰源?
    • 是否自制电缆的接头做工很差?
    • 电缆的屏蔽层是否接地良好?
  • 检查故障点的站和前一个从站：
    • 是否供电不足 (供给本站的电流太小, 例如：EBUS 电流)?
    • 两个从站的接地点不是等电位？
  • 试着替换该从站和前一个从站，或者交换二者的顺序，以查看错误是跟随某个从站还 是出现在原先的位置。

对于 EMC 干扰, 应该会导致 RX 和 CRC 错误都有增加 (即使二者增加的机率可能不同), 因为外部干扰不可能与通讯同步，于是在Ethernet 数据帧内部和外部都会破坏数据。

完全不平衡的计数值 （RX错误很多，而没有CRC错误，或者很CRC错误而没有RX错误）可能意味着其中一个从站的内部硬件错误。

16.深入了解 - CRC 错误的转发机制

部分从站还额外支持 转发CRC错误计数器（Forwarded CRC Error Counters）: 第1个检查出CRC错误的从站，其CRC 错误计数器（Register 0x0300）增加，第2个及之后再检查出CRC错误的从站则增加其转发CRC错误计数器（Register 0x0308）而CRC 错误计数器保持不变。

并非所有从站都支持 转发CRC错误计数器（Forwarded CRC Error Counters） 功能 (该特性为可选项) ，所以该计数应视为补充信息: 有助于定位出错的第1个设备，但不是关键指标。

17.深入了解 – 转发CRC错误的计数器

TwinCAT 中， EtherCAT主站的 Online 页面总是以 word-oriented 的方式显示计数值，所以转发CRC错误计数器（ Forwarded CRC Error Counter ）的说明如下：

18.主站错误计数

此外，EtherCAT 主站 也提供硬件错误 计数：

EtherCAT 主站支持两种不同的错误计数器 :

• RxErrors: 与从站侧的 RX 错误计数器类似，由网卡统计符号错误的次数 (发生在数据帧内和数据帧外的错误).
• Lost数据帧: 由于EtherCAT闭环在某处中断未能返回主站的数据帧和返回了但CRC校验错误的数据帧 TwinCAT 都视作丢失的“lost“。在TwinCAT中，如果丢失一个数据帧，则该数据帧包含的所有数据报文（Datagram，即Sync Unit同步单元）都会报Working Counter 错误，显示为所有从站的WcState为Invalid。

分别考虑不同的数据帧类型：

• Cyclic: 周期性数据帧 发送要交换的过程数据（ Process Data）:

• Queued: 排队等候的数据帧，包括所有非周期性的数据帧：
  邮箱 Mailbox,
  状态机 State Machine,
  注册字访问 Register access

19.在线查看拓扑结构

大部分硬件诊断信息，可以在 Topology View 界面监视

Topology View 是个 ActiveX 插件，可以导出到任何独立于TwinCAT 开发环境的 Windows 应用。

六、Software Diagnostics 软件诊断

1.软件层面的错误 – EtherCAT 状态机

软件层面的诊断信息，通常与EtherCAT 状态机操作有关: 一旦从站不能按主站要求进入正确的状态， 就会在从站的注册字（Register 0x0134）中报告AL状态代码（AL Status Code）。
在 TwinCAT Logger 中也会显示状态机错误:

TwinCAT 默认总是试图清除状态机错误，并且把所有从站切回OP状态。此时, 要在主站的Advanced Settings中取消选中该标记。

2.状态机切换异常（ Unexpected State Transitions ）的简单监视

在EtherCAT主站的Online页面可以监视从站状态机异常切换的次数，只要在主站的Advanced Setting中启用该计数即可显示：

此计数表示与从站的状态机切换异常的次数（1表示首次切换，>1表示在运行期间至少出现过1 次状态切换异常）。

3.EtherCAT 状态机错误的类型

EtherCAT 状态机错误可以归为2个大类:

• 初始化错误 (启动时从站不能进入OP状态): 状态机切换过程中，主站根据 ESI 文件的内容向从站发送初始化命令. 如果从站检测到一个或者几个 start-up 参数无效，就会拒绝相应的状态机切换。
  典型 的初始化错误:

此时 Register 0x0134 的值显示为：

• • 0x0003 : Invalid Device Setup (BK1xxx上配置的KL模块顺序不正确)
  • 0x001D : Invalid Output Configuration (配置的输出过程数据无效)
  • 0x001E : Invalid Input Configuration (配置的输入过程数据无效)
  • 0x0035 : Invalid Sync Cycle Time (在 DC 模式中设置的Cycle Time不支持)
• 运行时错误 (从站退出OP到更低级的状态)： 配置正确的从站成功进入OP状态以后，在运行过程中检测到错误，并因此执行切换到更低级的状态。
  典型的运行时错误:

此时 Register 0x0134 的值显示为：

• • 0x001A : Synchronization error (网络的抖动导致从站的同步丢失)
  • 0x001B : Sync manager watchdog (从站未接收到周期性数据的时间，持续超过了watchdog时间)
  • 0x002C : Fatal SYNC error (ESC 再未收到 SYNC 硬件中断)

4.发生初始化错误 – 怎么办?

从站的 ESI 文件应包含TwinCAT在网络中正确配置该从站所需要的全部信息。如果使用从ESI读取的默认设置来激活配置 （而不做任何手动修改）, 从站应该能进入OP状态而不报错。

如果发生了初始化错误:

1. 确保 ESI 文件复制到了 包含所有从站描述文件的TwinCAT统一路径（ESI 文件中的Product
   Code 和 Revision Number 与CoE对象 0x1018 中显示的信息相匹配）。
2. 检查从站的默认设置是否改动过，如果改过就删除该从站再在TwinCAT配置中手动添加。
   (以恢复默认设置)
3. 对模块化的从站(For modular slaves) ，检查“Slots” 页面配置的模块与实际连接的模块在型
   号、数量、顺序上是否严格一致。
4. 对具有分布时钟同步功能的从站设备(For DC-Synchronous devices)，检查主站的Jitter或者Sync Shift Time的设置是否会妨碍从站正确实现DC同步。

如果是这种情况 ，只是检查并不能解决问题，必须联系从站的制造商。

5.发生运行时错误 – 怎么办?

从站成功进入OP状态以后，在运行时不会无故退出OP状态。

如果发生了运行时错误：

1. 如果从站发生了 watchdog 错误，检查TwinCAT 软件任务 (PLC 程序, NC 任务, …)是否正确运行，因为在TwinCAT中总是由上述任务触发数据帧的周期性发送和接收。
2. 检查主站设备的Jitter表现（抖动范围）是否能证明发生了同步丢失。(最大的Jitter超过通讯
   周期的20－30%时，很容易发生同步错误)。
3. 检查是否发生了硬件错误，比如物理连接丢失，这种错误可能间接导致Watchdog动作，或 者同步丢失 ( 参考“物理层问题的硬件诊断 ”)。

如果是这种情况 ，只是检查并不能解决问题，使用 Wireshark 进行追踪会是个有用的办法。

6.保存和导出软件错误

状态机错误保存在 Windows Log 中，可以导出，以便在即使TwinCAT Logger已经关闭或者不可用的时候，还可以进一步分析:

7.历史诊断信息（Diagnose History Object）

对于所有应用相关的错误，部分 CoE从站设备支持“历史诊断信息”功能 （Diagnosis History Object ） Register 0x10F3.

如果从站支持该功能，TwinCAT 就会额外显示一个页面 “Diag History” :

8.邮箱协议错误（Mailbox Protocol Errors）

邮箱协议错误（ Mailbox protocol errors ）是一个指定类的一般性软件错误，它不是厂家自定义的，不影响 EtherCAT 状态机，不会阻止也不会导致意外的状态切换。仅当执行某个特定的邮箱协议所禁止的动作时，才会发生邮箱协议错误。

在 ETG.1000.6 规范中，公布了每个邮箱协议支持的错误代码及描述信息。

9.发生了邮箱协议错误（Mailbox Protocol Errors ）– 怎么办?

根据特定的邮箱协议，可能的错误原因是：

•CoE

-主站试图读写从站的对象字典（Object Dictionary）中并不存在的对象

-主站试图对从站的某个“只读” 对象执行“写入”操作。

-主站试图以“完全访问”的方式访问从站的某个对象，而从站并不支持该功能。

•FoE

-文件名错误 (例如, 缺少扩展名*.xxx).

-从站需要密码, 但未被正确设置

-文件大小超出了从站能接受的范围

-从站不在 Bootstrap 状态

•EoE

-主站试图把从站的 IP-Add（Internal Use）ress 配置为末位为0的值（比如“x.y.z.0”），而EoE从站的Tcp/Ip 协议栈拒绝此设置。

注意：

•TwinCAT 仅在以下时段 读/写 CoE 参数:

-在初始化阶段(Startup 命令)

-CoE-Online 页面打开时

•如果错误信息显示TwinCAT试图间歇性地读写CoE参数，很可能这是PLC程序的动作。

七、TwinCAT PLC 中编写EtherCAT 诊断程序

1.在PLC程序中系统地诊断 EtherCAT 状态

对于EtherCAT 网络, TwinCAT 自动提供了大量诊断信息，可以在PLC程序中用于检测总线通讯

的错误, 以便自动做出响应并报告给用户。

用户总是倾向于在PLC程序中实现最少的EtherCAT诊断，因为这样有助于通讯错误发生时节约

大量的操作时间。

TwinCAT PLC 程序可以混合使用 2 种不同的诊断信息 :

• 周期性信息 : 默认包含在EtherCAT网络的周期性过程映像数据中的 输入数据, 可以直接映射
  到相应的PLC输入变量 (AT %I*).
• 非周期性信息 : PLC程序调用默认库文件(TcEtherCAT.lib)中指定的功能块，可以获取这些非周期性的EtherCAT诊断信息 。

2.TwinCAT 中的周期性诊断信息

注意：至少所有从站的 WcState 和 State 变量应链接到 PLC 程序，以便应用程序可以对 EtherCAT 进行最基本的诊断。

3.周期性信息 - FrmXWcState 变量

允许 PLC 检查每个报文的 Working Counter 信息：

• 每个配置的Frame都具有一个16位的诊断变量 FrmXWcState
• FrmXWcState 的每个位对应Frame中的特定报文
• 如果对应报文的Working Counter错误，这个位就会变为TRUE

4.周期性信息 - WcState 变量

• • 这是每个从站的过程数据中都具有一个布尔型变量
  • 如果报文的Working Counter 错误，报文中所有从站的WcState 变量都会被置位，
  • 所以，如果一个从站的 WcState = 1, 也并不表示它本身发生了错误。 （内部使用） 进一步的信息需要查看这些 WcState 为 1 的从站的16位状态变量 State

5.周期性信息 - State 变量

EtherCAT Master汇总从网络收集的诊断信息，周期性地更新State变量，对应几种错误情况：

6.周期性信息 – State 变量
状态变量报告的错误诊断信息如下：

7.非周期性信息 – TcEtherCAT PLC Library

在TC2和TC3的默认安装中都免费提供TcEtherCAT.lib库， 该库包含若干功能块，可以对EtherCAT网络进行非周期 性诊断

• • • • Frame 分析
      • CRC 分析
      • 从站识别
      • 配置从站的数量和列表
      • 实际从站的数量和列表

该库原则上允许PLC程序自动读取在TwinCAT开发环境中 在线显示的所有信息。

• 功能块FB_EcGetSlaveTopologyInfo

功能块FB_EcGetSlaveTopologyInfo返回关于不同从站的端口如何相互连接的信息，以及（配置的）网络拓扑结 构的信息，（如果配置了热连接组，则它们将列在阵列的末尾）。

• 功能块FB_EcGetConfSlaves

功能块 TwinCAT 离线配置，知道 EtherCAT 网络包含哪些从站。

• 功能块 FB_ecgetscannedsaves

功能块 FB_ecgetscannedsaves 使 PLC 可 以 获 取EtherCAT网络在线检测的实际从站信息，以便和使用FB_EcGetConfSlaves 获得的离线配置的从站信息进行比较。

• 功能块 FB_ecgetscannedsaves

功能块FB_ecgetallslavercerrors可以周期性调用，以判断一个或多个从站是否报告CRC错误。这样就可以只对 这些出错的从站调用FB_ecgetslavecercerrorex，以获取进一步的故障信息。

• 功能块FB_ecgetslavecercerrorex

功能块 FB_ecgetslavecercerrorex 使 PLC 可 以 获 取EtherCAT主站记录的特定从站的CRC错误信息，这些信息与TwinCAT 开发环境中的 EtherCAT 监视界面显示的信息一致。

• 功能块FB_EcMasterFrameStatistics

功能块 FB_EcMasterFrameStatistics 使PLC可以获取EtherCAT主站检测到的Frame丢失等情况，这些信息与TwinCAT 开发环境中的 EtherCAT 监视界面显示的信息一致。

• 功能块FB_EcGetAllSlaveAbnormalStateChanges

功能块FB_EcGetAllSlaveAbnormalStateChanges，统计每个从站 从 OP 退至 SafeOP 的异常状态切换，但并不报告每次异常切换时相关的特定AL 状态码。

• 功能块FB_EcGetLastProtErrInfo

功能块 FB_EcGetLastProtErrInfo 允许覆盖上一次邮箱协议错误 Mailbox protocol error (例如, CoE协议的SDO退出代码).

对同一从站的下一次正确邮箱访问会清除此前记录错误信息的内存区。

八、附件:使用 Wireshark 进行诊断

1.如果软件诊断还不够 – 使用 Wireshark

Wireshark 并不是用以取代TwinCAT中的诊断功能 。对于用户来说，应当在使用了其它诊断方法都无法找到故障点的时候，才使用这个“终极武器”。

使用ET2000 可以在Wireshark中获得最好的捕捉效果

为了执行 Wireshark 抓包，有多种不同的硬件配置。

2.Wireshark 抓包的硬件配置 1

• 不支持 Windows CE
• 没有精确的时间戳

3.Wireshark 抓包的硬件配置 2

• 不支持 Windows CE
• 有精确的时间戳

4.Wireshark 抓包的硬件配置 3

• 支持 Windows CE
• 有精确的时间戳

5.Wireshark 示例

Wireshark 允许追踪每个 EtherCAT 数据帧的 list, structure and content of (在一轮捕捉过程中，每个数据帧会被捕获两次!).

下图显示了捕获的一个周期性数据帧：

6.Wireshark – 时间戳协议( 仅当使用ET2000时 )

使用ET2000时，为了在Wireshark中获取到极为精确的时间戳（time-stamping）信息, 应当启用对ESL协议的解析功能。Wireshark Version 2 支持此功能。

7.Wireshark – 时间戳协议( 仅当使用ET2000时 )

…在早期的 Wireshark Version 1中操作如下：

8.Wireshark – 显示时间的格式

使用Wireshark追踪时，用户可以选择最合适的 时间信息 显示格式:

9.Wireshark – 部分过滤选项（Filter Options）

捕获的数据帧可以使用过滤功能，可用的过滤选项包括:

• 仅捕获周期性数据帧（CyclicFrame）
  Filter: (ecat.cmd == 0x0a) || (ecat.cmd == 0x0b) || (ecat.cmd == 0x0c)
• 仅捕获邮箱通讯（mailboxcommunication）
  Filter: ecat_mailbox Filter: ecat_mailbox.coe Filter: ecat_mailbox.soe Filter: ecat_mailbox.foe Filter: ecat_mailbox.eoe

仅访问特定的注册字或者注册字区间 （register or register range）
Filter: ecat.ado == <register_Add（Internal Use）ress>
Filter: (ecat.ado >= <lower_Add（Internal Use）ress>) && !(ecat.ado >= <upper_Add（ Internal Use）ress>)

10.Wireshark – 部分过滤选项（Filter Options）

仅捕获特定一个从站或者几个连续地址的从站的数据报文

Filter: ecat.adp == &lt;slave_Add（Internal Use）ress&gt;

过滤选项还可以自由组合 成逻辑表达式：

Operator	Meaning
&&	AND
||	OR
!	NOT
==	equal
>=	greater or equal
<=	smaller or equal
>	greater
<	smaller

其它过滤选择可参考：https://www.wireshark.org/docs/dfref/e/ecat.html

点击“Apply as Filter”，可以从追踪记录中直接提取过滤选项。

11.Wireshark – 颜色标记的规则 （Coloring Rules）

为了更好显示不同的信息类型，可以为特定的过滤协议指定颜色标记规则（ colouringrules ）。

例如：可以用指定的颜色标记携带邮箱通讯（Mailbox communication）的数据帧 ，或者所有离开的数据帧 (以区别于进入的数据帧).

—旦定义了颜色标记规则， 此后这台PC 上所有的Wireshark追踪都会应用这套规则。通过导出和导入功能， 一台机的颜色标记规则还可以移植到另一台PC上。

12.Wireshark – 缩小保存的捕捉记录文件

在开始捕捉之前，可以设置Wireshark把捕获的信息到指定大小的独立文件，而不是把所有数据帧保存在一个单独的文件里面：

捕捉完成后, 还可以只保存选择的部分数据帧: