简介：这份《EtherCAT-TwinCAT故障排查手册》面向工业自动化领域的现场工程师、调试人员及具备一定总线基础的进阶学习者，聚焦EtherCAT实时以太网与倍福TwinCAT平台在实际项目中出现的通信异常与硬件故障，提供系统化的排查思路。资源包共1个PDF文件，大小约2.79MB，内容按概述、硬件诊断、软件诊断三大板块组织，便于按故障类型快速定位。手册先梳理EtherCAT通讯机制与TwinCAT软件平台，再针对CX5020嵌入式控制器、EK1100输入输出模块、BK1250背板等常见硬件的连接、电源与LED状态诊断逐一说明；软件层面则覆盖WorkingCounter作用与Sync unit同步单元设置、主从站状态字解读、TcSyslog日志抓取分析以及CRC、change count与Online state等诊断手段。已有2457人学习，适合作为现场排错时的案头参考，帮助读者建立从硬件到软件的完整故障定位路径，提升设备稳定运行与故障处理效率。

1. 从一次产线停机的 10 分钟说起：这份手册到底解决什么

凌晨两点，产线突然停了。PLC 程序没改过，接线没动过，但主站就是报错，从站状态从 OP 掉到 SAFEOP，重启一次能撑半小时，再重启就彻底起不来。现场工程师最怕这种“玄学”故障——没有明确报错点，没有日志，只能靠拔模块、换网线、猜。这份《EtherCAT-TwinCAT 故障排查手册》就是冲着这个场景来的：它不讲 EtherCAT 协议怎么优雅，而是把主站状态字、从站状态字、WorkingCounter、TcSyslog、CRC 与 change count、拓扑图、Emergency Scan 这些诊断入口一个个拆开，告诉你先看哪个、数值代表什么、怎么从一堆状态位里定位到具体那根线或那个模块。适合已经上手 TwinCAT、被现场故障卡过的人，也适合刚接触 EtherCAT 调试、想建立一套排查顺序的新手。它不替代官方 Information System，但能让你在半夜少翻半小时手册。

2. 先看懂 EtherCAT 的报文路径：故障为什么总在“返回”时暴露

EtherCAT 的故障排查有个反直觉的地方：很多问题不是主站发不出去，而是报文回不来。理解这一点，后面所有状态字和计数器才有意义。

2.1 从站端口与帧的转发顺序

每个 EtherCAT 从站有 4 个通讯口，Port0（A 口）到 Port3（D 口）。帧从 Port0 进入，经过 EtherCAT Processing Unit 处理，再从其他端口出去。手册里给了一张表，说明不同端口数量下帧的通讯顺序：

这张表的价值在于：当某个端口没接设备时，该端口自动锁闭，信号继续往下传。所以一个 2 口模块从左到右经过时，帧从 Port0 进、Port1 出；从右到左时，从 Port1 进、Port0 出。你在线型拓扑里看到的“信号方向”，其实是由端口占用情况动态决定的。

2.2 三种断线形态与主站的 INIT 回退

手册把连接失效分成三种典型形态，这是现场判断的骨架：

第一种，模块本身通讯有问题。此时有问题模块的前一个 EtherCAT 模块会自动闭锁通讯口 B，让报文原路返回。主站还能收到回复，但拓扑已经缩短，SlaveCount 会小于 CfgSlaveCount。

第二种，网线或其他原因导致 Tx 和 Rx 都断。向右传输通道整体不正常，报文在断点前面的模块处返回，表现和第一种类似，但断点位置更靠前。

第三种，Tx 正常、Rx 断。这是最容易误判的：主站能发报文，报文能一路发到拓扑最后一个模块，但返回时走 Rx 线，在中断处回不来。主站连续 10 个周期收不到发出的 Frame 的回复，就会把自己的 State 置为 INIT。现场看到主站反复进 INIT、从站却似乎“都在”，就要优先怀疑 Rx 线或某个端口的接收方向。

提示：第三种形态下，用万用表测网线通断往往测不出来，因为 Tx 对还能通。要看 Online State 和 CRC 的变化趋势，而不是只看通断。

2.3 TwinCAT 侧的两个基础配置

排查之前，先确认 TwinCAT 的运行状态和时基设置，否则你看到的“故障”可能只是配置模式。TwinCAT 系统服务在 Windows 启动时运行，任务栏图标颜色代表状态：红是停止，蓝是配置，黄是启动中，绿是运行。System-Configuration 里的 Auto boot 设为 RUN MODE 时，服务一启动就进运行模式；设为 Config MODE 则进配置模式。

Base time 最低可设 50 µs，它把 Windows 时间切成片，TwinCAT 在片内跑 PLC 和运动控制。CPU Limit 默认 80%，意味着 1 ms 里 80% 给 TwinCAT，20% 留给 Windows 进程。所有任务周期都是 Base time 的倍数：想要 500 µs 的 PLC 周期，可以把 Base time 设 500 µs、任务周期设 1 倍，或者 Base time 设 250 µs、任务周期设 2 倍。这个设置和通讯故障没有直接关系，但周期抖动大时，WKC 的瞬时异常会被放大，排查前先确认时基是稳的。

3. 硬件指示灯先过一遍：CX5020、EK1100、BK1250 的读灯顺序

软件诊断再细，也不如先花两分钟看灯。手册把三个常见模块的指示灯定义列得很全，现场按“电源→总线→端口”的顺序读，能快速缩小范围。

3.1 CX5020：先看 PWR 和 TC，再看 FB1/FB2

CX5020 是带 TwinCAT 2 PLC run-time 的嵌入式控制器。读灯顺序：

• PWR 绿灯：电源正常。
• TC 灯：绿为运行，红为停止，蓝为配置。如果 TC 是蓝的，先别查通讯，先确认是不是没切到运行模式。
• HDD 闪红：在读/写闪存，正常现象，但频繁闪要留意 CF 卡寿命。
• FB1、FB2 红灯：现场总线状态异常，这是通讯故障的第一指示。
• 两个 LAN 口的 LINK/ACT 绿灯闪烁表示有数据交换，SPEED 灯绿色为 10/100 Mbit、红色为 1000 Mbit。

E-bus 电源指示灯：Us 是 24 V CPU 模块电源，Up 是 24 V 端子模块电源，正常都是绿色。L/A 灯暗表示 E-bus 没连接，亮表示连接但无数据通信，闪表示连接且有数据通信。

3.2 EK1100：RUN 灯的闪烁节奏就是状态机

EK1100 是 EtherCAT 耦合器，把 100BASE-TX 报文转成 E-bus 信号。它的 RUN 绿灯直接对应 EtherCAT 状态机：

现场看到 RUN 慢闪或闪一次，说明从站没进 OP，先查配置和前面模块，而不是查这个模块本身。LINK/ACT X1 对应前一个 EtherCAT 设备，X2 对应后一个设备，E-Bus 灯对应后端端子总线。三个灯分开看，能判断断点在“进线”“出线”还是“后端”。

3.3 BK1250：I/O ERROR K-bus 的闪烁次数是故障码

BK1250 用在 EtherCAT 端子（ELxxxx）和标准总线端子（KLxxxx）混用的站点。它有两个关键故障灯：ERROR 红灯慢闪表示 PLC 错误或丢帧；I/O ERROR K-bus 红灯的闪烁次数直接编码故障类型。

手册给了一个真实排查例子：BK1250 上电后 I/O ERROR K-bus 红灯先闪 14 次，间隔约 1 秒再闪 5 次，然后高速闪烁，循环重复。查表：闪 14 次对应“第 n 个总线端子模块的格式错误”，n=5；闪 5 次对应“总线端子模块 n 寄存器通信的 K 总线错误”。结论是后端第 5 个模块有问题。拆掉该模块重新上电，故障消失。

这张闪烁码表值得抄在现场记录本上：

注意：数闪烁次数时用手机慢动作录像，现场灯光下肉眼数 14 次和 15 次很容易错，差一次就是另一个模块。

4. 软件诊断的四个抓手：WKC、主站状态字、从站状态字、TcSyslog

硬件灯只能告诉你“哪一段”，软件状态字才能告诉你“哪一个”。这一章按从粗到细的顺序排：先看同步单元和 WKC，再看主站状态字，再看从站状态字，最后用 TcSyslog 留证据。

4.1 WorkingCounter 与 Sync unit：把“通讯坏了”拆成“哪一组坏了”

默认情况下整个系统是一个同步单元，所有从站的读写都算进一个 WorkingCounter：读一次 +1，写一次 +2，读写一次 +3。主站把收到的 WKC 和“ShouldBe”值比较，相等则 WcState=0，不等则 WcState=1。问题是，一个 WcState=1 只告诉你“这组里有问题”，不告诉你是哪个柜子、哪个模块。

所以手册建议划分多个同步单元，原则有四条：按柜子的物理地址分别设；通讯模块单独设；特殊模拟量模块（如编码器）单独设；客户需要单独监测的模块单独设。划分后每个同步单元有自己的 WKC，Frm0WcState 的每一位对应一个同步单元的 WcState。

在 PLC 程序里判断时，Frm0WcState 的位定义如下：

一个 EtherCAT Frame 最多传 16 个命令，所以 16 位刚好覆盖。手册提到某主控系统设了 6 个同步单元、8 个命令，全部在一个 Frame 里传，PLC 里逐位判断就能知道哪个同步单元失败。

还有一个行为细节：某个同步单元 WcState=1 时，DI/AI 值保持上一周期不变；DO/AO 值在该模块 state=8 时仍按 PLC 程序输出，state 不为 8 时输出被置 0。这意味着故障时输出可能“看起来正常”，别用输出值反推通讯正常。

4.2 主站状态字：Frame State、SlaveCount 与 Device State Master

主站侧要看的四个量：

Frame State 是 UINT，每一位表示一个 EtherCAT 命令是否执行成功，0 成功、1 失败。例如 Frm0State 值为 0x0004，表示数据帧 0 的第 3 个命令失败。它和 Frm0WcState 的区别是：Frame State 看命令执行，WcState 看数据交换计数。

SlaveCount 和 CfgSlaveCount 是最直接的对比：CfgSlaveCount 是配置的从站数，SlaveCount 是实际收到的从站数。两者不等，就说明有从站在通讯中丢了。这个判断不需要任何额外工具，在 TwinCAT 里看一眼就能定性。

Device State Master 是一个 UINT 报警值，能快速发现“有从站不在 OP”，但不能定位。位定义里比较有用的几个：bit0 链路错误，bit1 链路错误后 I/O 锁定（需要 I/O reset），bit5 看门狗触发，bit8 至少一个设备在 INIT，bit9 至少一个在 PREOP，bit10 至少一个在 SAFEOP，bit11 至少一个设备报错，bit12 分布式时钟不同步。看到 bit8 到 bit11 同时亮，说明有站掉了，接下来去从站状态字里找。

4.3 从站状态字：WcState 与 Slave State 的配合

同一个同步单元、同一个命令下可能有多个子站，主站只报这个命令无效时，你还不知道是哪个子站。这时逐个看从站的两个量：WcState（1 bit）和 Slave State（16 bit）。

WcState=0 表示该从站数据交换正确；WcState=1 表示刷新 Inputs 或 Outputs 时 WKC 不正确。Slave State 正常工作时等于 8（OP），不为 8 就说明该从站有故障，同时它的 WcState 也会变 1。所以排查顺序是：先找 Slave State 不等于 8 的站，再看它所在同步单元的 WcState。

Slave State 的 16 位里，低位直接对应状态机：0x___1 是 INIT，0x___2 是 PREOP，0x___4 是 SAFEOP，0x___8 是 OP，更高位是错误标志。现场看到某个站停在 SAFEOP（值为 4），说明配置下发成功但输出没使能，常见原因是该站的前级模块没进 OP，或者过程数据配置不匹配。

4.4 TcSyslog：把“偶发”变成“可回看”的证据

偶发故障最麻烦的是现场复位后什么都没留下。TcSyslog 就是留证据的入口。手册给的步骤是：先开通 FTP 功能，再开启 TcSyslog 故障记录文件功能，然后通过 FTP 把 tcsyslog.txt 拷出来分析。

开通 FTP 的常见做法是在目标设备的系统设置里启用 FTP 服务，用标准 FTP 客户端连接控制器 IP，登录后进入系统目录找到 tcsyslog.txt。这个文件记录的是时间戳加事件，偶发掉站、看门狗触发、状态机跳变都会留痕。我的习惯是故障复现后先别急着重启，先把 tcsyslog.txt 拷出来再动，否则重启会把现场冲掉。

提示：FTP 账号权限和目录路径因控制器型号和系统版本不同会有差异，手册里写的是通用流程，具体路径以目标设备实际目录为准，别照抄路径。

4.5 CRC、change count 与 Online State：判断“线”还是“模块”

CRC 错误计数上升，通常指向物理层：网线、接头、屏蔽、端口。change count 变化则更多指向配置或状态切换。Online State 反映端口的连接状态。三者一起看：CRC 持续涨而 change count 稳定，优先查线和接头；CRC 稳定但 change count 频繁跳，优先查配置和电源；Online State 在某个端口反复跳变，基本可以锁定那个端口或它后面的那段线。

手册还提到 EtherCAT 拓扑图和 Emergency Scan 两个工具。拓扑图能直观看到实际扫描到的站顺序和配置顺序是否一致，Emergency Scan 用于抓取从站发出的紧急报文，适合定位那些“状态字正常但偶尔报错”的站。

5. 避坑与排查：五条现场踩出来的记录

5.1 只换模块不备份 CF 卡，换完参数全丢

现象：CX5020 故障，换上新控制器后 TwinCAT 起不来，配置全空。 原因：CF 卡里存的是系统镜像和 TwinCAT 配置，只换硬件不迁移数据，等于换了一台空机器。 解决：换模块前先按手册的 CF 卡数据备份流程做镜像备份，换完后恢复再上电。备份动作要放在故障处理流程的第一步，而不是最后一步。

5.2 看到 SlaveCount 少了就拔最后一根线

现象：SlaveCount 小于 CfgSlaveCount，现场直接从拓扑末端开始拔线。 原因：断点可能在中间，末端拔线只会让计数更少，而且反复插拔会引入新的接触问题。 解决：先用拓扑图对比实际站顺序和配置顺序，找到第一个不一致的位置；再结合 Online State 看哪个端口先掉。断点在中间时，断点前一个模块的 B 口会闭锁，这个特征比数模块个数可靠。

5.3 把 WcState=1 当成“这个模块坏了”

现象：某个同步单元 WcState=1，直接换掉该单元第一个模块，故障依旧。 原因：WcState=1 只说明这个同步单元内有站不在 OP 或 WKC 不匹配，可能是该单元里任何一个子站，也可能是前级模块导致。 解决：先在该同步单元内逐个看 Slave State，找不等于 8 的站；如果全部为 8 但 WcState 仍为 1，再查该单元的配置和 WKC 期望值。

5.4 数 BK1250 闪烁次数数错，拆错模块

现象：I/O ERROR K-bus 闪 14 次和 15 次肉眼难分，拆了第 15 个模块，问题还在。 原因：闪烁间隔短，现场灯光干扰，肉眼计数误差大。 解决：用手机慢动作录像逐帧数，或者先记录完整循环再对照码表。14 次是格式错误、15 次是个数不正确，处理方式不同，差一次就白拆。

5.5 故障后先重启，TcSyslog 被冲掉

现象：偶发掉站，重启后一切正常，等下次再发生时没有任何记录。 原因：重启会重置运行状态，tcsyslog.txt 里的现场信息被新日志覆盖或截断。 解决：故障复现后第一动作是 FTP 拷出 tcsyslog.txt，再做复位。养成“先取证、后复位”的顺序，偶发问题才有得查。

6. 把诊断做成固定动作：一套可复用的排查顺序与验证方法

手册的价值不在于读完，而在于把它变成一张现场卡片。我自己的做法是把排查顺序固化成五步，每次故障按顺序走，不跳步。

第一步，读灯。CX5020 看 PWR、TC、FB1/FB2；EK1100 看 RUN 的闪烁节奏；BK1250 看 I/O ERROR K-bus 的闪烁次数。两分钟内定性到“电源、配置、总线、后端”中的哪一类。

第二步，看计数。在 TwinCAT 里对比 SlaveCount 和 CfgSlaveCount，不等就是有站丢了；再看 Device State Master 的位，确认是 INIT、PREOP、SAFEOP 还是错误态。

第三步，定位同步单元。看 Frm0WcState 哪一位为 1，锁定同步单元；再在该单元内逐个查 Slave State，找不等于 8 的站。

第四步，区分线还是模块。看 CRC 计数是否持续上升、change count 是否频繁跳、Online State 是否在某个端口反复变。CRC 涨查线，change count 跳查配置和电源。

第五步，留证据。FTP 拷出 tcsyslog.txt，必要时做 Emergency Scan，把这次故障的时间线和状态跳变存档，下次同类问题直接比对。

验证方法上，有一个简单但有效的自检：在正常运行时人为断开拓扑中间一段网线的 Rx 方向（只断接收对），观察主站是否在约 10 个周期后进 INIT、SlaveCount 是否变化、CRC 是否上升。这个演练能让你在真正故障时一眼认出“Tx 正常 Rx 断”的形态，而不是把它误判成模块损坏。

还有一个习惯值得坚持：每次改动同步单元划分后，把 Frm0WcState 的位映射表更新到 PLC 注释里。同步单元一多，位和柜子的对应关系很容易忘，故障时翻注释比翻记忆可靠。从那以后我每次上电前都强制走一遍“读灯—看计数—对拓扑”的三步，哪怕看起来一切正常，也希望这套顺序能帮到你。

本文还有配套的精品资源，点击获取