简介这份《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 个通讯口Port0A 口到 Port3D 口。帧从 Port0 进入经过 EtherCAT Processing Unit 处理再从其他端口出去。手册里给了一张表说明不同端口数量下帧的通讯顺序通讯口个数EtherCAT 数据帧顺序20→Processing Unit→1 / 1→030→PU→1 / 1→2 / 2→0用 port0,1,2或 0→PU→3 / 3→1 / 1→0用 port0,1,340→PU→3 / 3→1 / 1→2 / 2→0这张表的价值在于当某个端口没接设备时该端口自动锁闭信号继续往下传。所以一个 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% 给 TwinCAT20% 留给 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/FB2CX5020 是带 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 EK1100RUN 灯的闪烁节奏就是状态机EK1100 是 EtherCAT 耦合器把 100BASE-TX 报文转成 E-bus 信号。它的 RUN 绿灯直接对应 EtherCAT 状态机RUN 灯状态含义灭INIT慢闪PREOP闪一次SAFEOP亮OP快闪BOOT固件更新现场看到 RUN 慢闪或闪一次说明从站没进 OP先查配置和前面模块而不是查这个模块本身。LINK/ACT X1 对应前一个 EtherCAT 设备X2 对应后一个设备E-Bus 灯对应后端端子总线。三个灯分开看能判断断点在“进线”“出线”还是“后端”。3.3 BK1250I/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 个总线端子模块的格式错误”n5闪 5 次对应“总线端子模块 n 寄存器通信的 K 总线错误”。结论是后端第 5 个模块有问题。拆掉该模块重新上电故障消失。这张闪烁码表值得抄在现场记录本上闪烁次数含义连续慢闪EMC 问题1 次EEPROM 校验错误 / 代码缓冲区溢出 / 未知数据类型2 次编程配置有不正确表项n 为总线端子模块号3 次K 总线命令错误4 次K 数据错误超出总线耦合器或端子模块 n5 次总线端子模块 n 寄存器通信的 K 总线错误14 次第 n 个总线端子模块格式错误15 次总线端子模块个数不正确16 次K 总线数据长度不正确注意数闪烁次数时用手机慢动作录像现场灯光下肉眼数 14 次和 15 次很容易错差一次就是另一个模块。4. 软件诊断的四个抓手WKC、主站状态字、从站状态字、TcSyslog硬件灯只能告诉你“哪一段”软件状态字才能告诉你“哪一个”。这一章按从粗到细的顺序排先看同步单元和 WKC再看主站状态字再看从站状态字最后用 TcSyslog 留证据。4.1 WorkingCounter 与 Sync unit把“通讯坏了”拆成“哪一组坏了”默认情况下整个系统是一个同步单元所有从站的读写都算进一个 WorkingCounter读一次 1写一次 2读写一次 3。主站把收到的 WKC 和“ShouldBe”值比较相等则 WcState0不等则 WcState1。问题是一个 WcState1 只告诉你“这组里有问题”不告诉你是哪个柜子、哪个模块。所以手册建议划分多个同步单元原则有四条按柜子的物理地址分别设通讯模块单独设特殊模拟量模块如编码器单独设客户需要单独监测的模块单独设。划分后每个同步单元有自己的 WKCFrm0WcState 的每一位对应一个同步单元的 WcState。在 PLC 程序里判断时Frm0WcState 的位定义如下Bit含义0 (0x0001)第 1 个 EtherCAT 命令 WKC 错误1 (0x0002)第 2 个 EtherCAT 命令 WKC 错误……14 (0x4000)第 15 个 EtherCAT 命令 WKC 错误15 (0x8000)整个帧丢失一个 EtherCAT Frame 最多传 16 个命令所以 16 位刚好覆盖。手册提到某主控系统设了 6 个同步单元、8 个命令全部在一个 Frame 里传PLC 里逐位判断就能知道哪个同步单元失败。还有一个行为细节某个同步单元 WcState1 时DI/AI 值保持上一周期不变DO/AO 值在该模块 state8 时仍按 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 resetbit5 看门狗触发bit8 至少一个设备在 INITbit9 至少一个在 PREOPbit10 至少一个在 SAFEOPbit11 至少一个设备报错bit12 分布式时钟不同步。看到 bit8 到 bit11 同时亮说明有站掉了接下来去从站状态字里找。4.3 从站状态字WcState 与 Slave State 的配合同一个同步单元、同一个命令下可能有多个子站主站只报这个命令无效时你还不知道是哪个子站。这时逐个看从站的两个量WcState1 bit和 Slave State16 bit。WcState0 表示该从站数据交换正确WcState1 表示刷新 Inputs 或 Outputs 时 WKC 不正确。Slave State 正常工作时等于 8OP不为 8 就说明该从站有故障同时它的 WcState 也会变 1。所以排查顺序是先找 Slave State 不等于 8 的站再看它所在同步单元的 WcState。Slave State 的 16 位里低位直接对应状态机0x___1 是 INIT0x___2 是 PREOP0x___4 是 SAFEOP0x___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 把 WcState1 当成“这个模块坏了”现象某个同步单元 WcState1直接换掉该单元第一个模块故障依旧。 原因WcState1 只说明这个同步单元内有站不在 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/FB2EK1100 看 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 注释里。同步单元一多位和柜子的对应关系很容易忘故障时翻注释比翻记忆可靠。从那以后我每次上电前都强制走一遍“读灯—看计数—对拓扑”的三步哪怕看起来一切正常也希望这套顺序能帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/28 19:53:44 · 阅读 1.2k EtherCAT-TwinCAT故障排查实战：从产线停机到快速定位的完整指南
简介这份《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 个通讯口Port0A 口到 Port3D 口。帧从 Port0 进入经过 EtherCAT Processing Unit 处理再从其他端口出去。手册里给了一张表说明不同端口数量下帧的通讯顺序通讯口个数EtherCAT 数据帧顺序20→Processing Unit→1 / 1→030→PU→1 / 1→2 / 2→0用 port0,1,2或 0→PU→3 / 3→1 / 1→0用 port0,1,340→PU→3 / 3→1 / 1→2 / 2→0这张表的价值在于当某个端口没接设备时该端口自动锁闭信号继续往下传。所以一个 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% 给 TwinCAT20% 留给 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/FB2CX5020 是带 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 EK1100RUN 灯的闪烁节奏就是状态机EK1100 是 EtherCAT 耦合器把 100BASE-TX 报文转成 E-bus 信号。它的 RUN 绿灯直接对应 EtherCAT 状态机RUN 灯状态含义灭INIT慢闪PREOP闪一次SAFEOP亮OP快闪BOOT固件更新现场看到 RUN 慢闪或闪一次说明从站没进 OP先查配置和前面模块而不是查这个模块本身。LINK/ACT X1 对应前一个 EtherCAT 设备X2 对应后一个设备E-Bus 灯对应后端端子总线。三个灯分开看能判断断点在“进线”“出线”还是“后端”。3.3 BK1250I/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 个总线端子模块的格式错误”n5闪 5 次对应“总线端子模块 n 寄存器通信的 K 总线错误”。结论是后端第 5 个模块有问题。拆掉该模块重新上电故障消失。这张闪烁码表值得抄在现场记录本上闪烁次数含义连续慢闪EMC 问题1 次EEPROM 校验错误 / 代码缓冲区溢出 / 未知数据类型2 次编程配置有不正确表项n 为总线端子模块号3 次K 总线命令错误4 次K 数据错误超出总线耦合器或端子模块 n5 次总线端子模块 n 寄存器通信的 K 总线错误14 次第 n 个总线端子模块格式错误15 次总线端子模块个数不正确16 次K 总线数据长度不正确注意数闪烁次数时用手机慢动作录像现场灯光下肉眼数 14 次和 15 次很容易错差一次就是另一个模块。4. 软件诊断的四个抓手WKC、主站状态字、从站状态字、TcSyslog硬件灯只能告诉你“哪一段”软件状态字才能告诉你“哪一个”。这一章按从粗到细的顺序排先看同步单元和 WKC再看主站状态字再看从站状态字最后用 TcSyslog 留证据。4.1 WorkingCounter 与 Sync unit把“通讯坏了”拆成“哪一组坏了”默认情况下整个系统是一个同步单元所有从站的读写都算进一个 WorkingCounter读一次 1写一次 2读写一次 3。主站把收到的 WKC 和“ShouldBe”值比较相等则 WcState0不等则 WcState1。问题是一个 WcState1 只告诉你“这组里有问题”不告诉你是哪个柜子、哪个模块。所以手册建议划分多个同步单元原则有四条按柜子的物理地址分别设通讯模块单独设特殊模拟量模块如编码器单独设客户需要单独监测的模块单独设。划分后每个同步单元有自己的 WKCFrm0WcState 的每一位对应一个同步单元的 WcState。在 PLC 程序里判断时Frm0WcState 的位定义如下Bit含义0 (0x0001)第 1 个 EtherCAT 命令 WKC 错误1 (0x0002)第 2 个 EtherCAT 命令 WKC 错误……14 (0x4000)第 15 个 EtherCAT 命令 WKC 错误15 (0x8000)整个帧丢失一个 EtherCAT Frame 最多传 16 个命令所以 16 位刚好覆盖。手册提到某主控系统设了 6 个同步单元、8 个命令全部在一个 Frame 里传PLC 里逐位判断就能知道哪个同步单元失败。还有一个行为细节某个同步单元 WcState1 时DI/AI 值保持上一周期不变DO/AO 值在该模块 state8 时仍按 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 resetbit5 看门狗触发bit8 至少一个设备在 INITbit9 至少一个在 PREOPbit10 至少一个在 SAFEOPbit11 至少一个设备报错bit12 分布式时钟不同步。看到 bit8 到 bit11 同时亮说明有站掉了接下来去从站状态字里找。4.3 从站状态字WcState 与 Slave State 的配合同一个同步单元、同一个命令下可能有多个子站主站只报这个命令无效时你还不知道是哪个子站。这时逐个看从站的两个量WcState1 bit和 Slave State16 bit。WcState0 表示该从站数据交换正确WcState1 表示刷新 Inputs 或 Outputs 时 WKC 不正确。Slave State 正常工作时等于 8OP不为 8 就说明该从站有故障同时它的 WcState 也会变 1。所以排查顺序是先找 Slave State 不等于 8 的站再看它所在同步单元的 WcState。Slave State 的 16 位里低位直接对应状态机0x___1 是 INIT0x___2 是 PREOP0x___4 是 SAFEOP0x___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 把 WcState1 当成“这个模块坏了”现象某个同步单元 WcState1直接换掉该单元第一个模块故障依旧。 原因WcState1 只说明这个同步单元内有站不在 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/FB2EK1100 看 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 注释里。同步单元一多位和柜子的对应关系很容易忘故障时翻注释比翻记忆可靠。从那以后我每次上电前都强制走一遍“读灯—看计数—对拓扑”的三步哪怕看起来一切正常也希望这套顺序能帮到你。本文还有配套的精品资源点击获取