干过现场调试的人都知道这样一个场景：设备跑得好好的，突然整条线停了，触摸屏上弹出报警——EtherCAT通讯故障。你赶紧打开CODESYS在线监控一眼，发现某个从站状态不对，或者干脆整条总线都掉下来了。最头疼的不是掉线本身，而是你不知道它是从哪一帧开始断的、断了多久、为什么断。所以在这篇文章里，我把常用的EtherCAT状态监测方案整理成了一份可以直接落地的ST语言程序，包含完整代码和使用思路。这套东西的核心就一句话：让PLC在断线发生的第一时间抓住现场证据，把故障节点、故障状态、故障时间全部锁存下来，该报警报警，该恢复恢复。
我建议做运动控制、多轴同步、远程IO站点的朋友都把这套逻辑存一份，真到现场冒烟的时候，它能帮你少走至少半天弯路。
1. 先搞懂：EtherCAT断线到底是怎么发生的
很多人一看到通讯故障就开始改程序、调参数，结果折腾一整天发现是水晶头压得不好。要写出靠谱的状态监测程序，你首先得理解EtherCAT断线的几种典型场景，因为不同原因导致的断线，现象完全不一样，后续处理逻辑也不一样。
1.1 断线现场最常见的3种现象
第一种是整体掉线。整条总线上一个从站都访问不到了，主站报通讯超时，所有从站的状态灯全异常。这种场景下，问题通常出在主站网卡、主站侧网线、或者给整条总线供电的电路上。也不排除极端情况，比如某个从站的输入端口短路，把整个段的总线电平拉崩了，造成“一个人感冒全家吃药”的效果。
第二种是单个从站掉线。总线上其他站都正常，就某站的ALStatus跳到了非OP状态，或者干脆在设备树里刷新不出来了。这种一般就是本段网线问题、这个从站的接线端子松了、或者这个从站本身供电出问题。也有遇到过从站硬件损坏的情况，但概率相对低，毕竟EtherCAT从站控制器芯片本身挺皮实的。
第三种最烦人，是偶发闪断。设备可能跑几小时、几天才掉一次，而且恢复后看起来一切正常，日志里啥也查不到。这种大多数和电磁干扰、供电纹波、网线屏蔽层接地不规范有关系，也有可能是DC时钟同步漂移导致的看门狗超时。
1.2 排查顺序：先物理后软件，别反着来
我自己踩过最大的坑，就是一遇到断线就钻进程序里找原因，结果浪费了一整天。后来总结出一个比较省时间的排查顺序，基本能覆盖八成以上的现场故障：
| 排查顺序 | 检查内容 | 常见故障源 |
|---|---|---|
| 1 | 网线和水晶头 | 压接不良、屏蔽层未接地、线序错误 |
| 2 | 从站供电 | 24V跌落、电源容量不足、共地问题 |
| 3 | 拓扑结构 | 分支不合理、超出单段距离、站间线缆过长 |
| 4 | 主站网卡与驱动 | 网卡驱动不稳定、实时补丁没打好 |
| 5 | 周期时间与看门狗 | 任务周期过短、看门狗配置过紧 没有使用DC同步、主站和从站时钟不同步 |
| 6 | 程序逻辑 | 状态字判断错误、输出映射漏配 |
这里想多提一句：现场“按下葫芦浮起瓢”的情况很多。你换了一根网线看似好了，过了两天又断，往往断的是同一个物理根源，只是表现位置变了。所以排查时一定把整个链路从主站到末端全部捋一遍，别只盯着报警的那个点。
2. 状态监测程序的整体设计思路
搞清楚断线是怎么发生的，下一步才是设计程序。这里有个关键选择要先说清楚：为什么状态监测用ST语言写，而不是用梯形图。
2.1 为什么用ST而不是梯形图
梯形图在逻辑控制里好使，但它不适合处理数组、循环、状态机这类结构化逻辑。EtherCAT状态监测的典型需求是：遍历一到十六个从站的状态字，逐个和期望值比较，任何一个不对就锁存故障。这在梯形图里要写一大片，而且不好维护。换成ST语言，一个FOR循环搞定，代码量少，可读性也高。
另外，ST语言对功能块封装的支持很好。你可以把整套监测逻辑封装成一个独立的FB，输入是启停、从站数量、检测周期、期望状态值，输出是通讯正常标志、故障标志、故障节点、故障状态、故障时间。这样不管项目是小型单机还是几十个站点的产线，调用方式完全一样，换项目只改参数，不动核心代码。
2.2 状态监测到底要“测”什么
EtherCAT的通讯状态不是简单的“通”和“断”，它分为几个阶段：Init、PreOp、SafeOp、Op，还有一些中间状态。标准的状态值定义如下：
| 状态值 | 状态名称 | 含义 |
|---|---|---|
| 0x01 | INIT | 从站刚上电，不能进行过程数据通信 |
| 0x02 | PREOP | 邮箱通信正常，参数可以读写 |
| 0x04 | SAFEOP | 输入有效，输出处于安全状态 |
| 0x08 | OP | 正常运行状态，输入输出均有效 |
| 其他 | BOOT/错误 | 或其他异常码 |
正常运行中，每个从站的ALStatus都应该是0x08。如果通讯断了，从站可能回到SAFEOP，甚至退回PREOP或INIT。你的状态监测程序要做的，就是周期性地把主站状态和所有从站状态都读一遍，一旦发现不等于期望值，立刻判断故障点。
除了ALStatus，还建议加上一个辅助判断：数据刷新心跳。拿一个实时变化的输入数据（比如伺服的实际位置或温度模块的测量值）做循环比较，如果连续几个周期都没变化，即使ALStatus还是OP，也要怀疑是不是主站已经收不到新数据了。这种情况在EMC干扰严重的现场遇到过，属于ALStatus还没来得及更新、数据已经停了，属于“隐形掉线”。
2.3 状态监测的“检测周期”怎么选
检测周期太短，CPU占用高，还可能因为读取瞬时抖动导致误报；检测周期太长，故障发生半天才反应过来，失去监测意义。我的经验是：20ms到200ms之间比较合适，具体看项目对实时性的要求。
如果你的系统周期是1ms或2ms，建议在独立的“慢任务”里跑这个监测功能块，不要在快速任务里做，否则会拉高扫描时间，反而增加掉线风险。我在一个现场就碰到过：把状态监测放到主任务里跑，任务周期从2ms涨到了3ms，结果触发了从站看门狗，反而导致频繁闪断。后来把监测挪到单独的10ms任务里，问题就消失了。
3. 核心代码实现：ST语言状态监测程序
这一节我直接给出完整的ST代码。为了让你能看懂每一步在干什么，我会先讲变量规划和地址映射，再讲功能块主体逻辑，最后讲自动恢复和扩展接口。
3.1 变量规划与地址映射
在CODESYS里，EtherCAT从站的ALStatus是可以映射成PLC地址的。操作路径大致是这样：设备树 → 选中EtherCAT主站 → 打开从站设备的“诊断信息”，把每个从站的ALStatus映射到连续的字节区（比如MB100开始），然后把主站状态映射到单独的一个字节（比如MB50）。不同版本菜单名称会有差异，但思路一致：把诊断对象映射成普通字节变量，供ST程序读取。
声明一个全局变量表：
VAR_GLOBAL g_bMasterState AT %MB50 : BYTE; // EtherCAT主站状态 g_abSlaveState AT %MB100 : ARRAY[1..16] OF BYTE; // 从站状态区，按拓扑顺序排列 END_VAR映射完成后，你在线监控里看到g_abSlaveState[1]的值是8，就说明1号从站工作在OP状态，一切正常。见到4、2、1之类的值，按状态表对照就知道它停在哪个阶段了。
3.2 功能块主体逻辑：故障捕捉与状态锁存
这个功能块是整个方案的核心。它负责周期检测主站状态和所有从站状态，捕获故障时刻，锁存故障节点，并统计故障次数。
FUNCTION_BLOCK FB_EcatMonitor VAR_INPUT bEnable : BOOL; // 总使能，TRUE开始检测 iSlaveCount : INT := 8; // 实际从站数量 byExpectedState : BYTE := 16#08; // 期望状态，默认OP tCheckCycle : TIME := T#200MS; // 检测周期 bAutoRecover : BOOL := FALSE; // 启用自动恢复请求 tRecoverDelay : TIME := T#5S; // 故障持续多久后触发恢复请求 END_VAR VAR_OUTPUT bCommNormal : BOOL; // 通讯正常 bFault : BOOL; // 通讯故障 uiFaultNode : UINT; // 故障节点：0=主站，1~n=从站 byFaultState : BYTE; // 故障时的实际状态 tFaultTime : TIME; // 故障发生时刻（PLC运行时间） tRecoverTime : TIME; // 故障恢复时刻 udiFaultCounter : UDINT; // 累计故障次数 bRecoverRequest : BOOL; // 自动恢复请求信号 END_VAR VAR bInit : BOOL := TRUE; bFaultActive : BOOL := FALSE; bResultOK : BOOL := TRUE; tNextCheck : TIME; tFaultStart : TIME; i : INT; uiTempNode : UINT; byTempState : BYTE; END_VAR实现部分：
IF NOT bEnable THEN bCommNormal := TRUE; bFault := FALSE; bRecoverRequest := FALSE; bFaultActive := FALSE; RETURN; END_IF // 上电或使能后初始化 IF bInit THEN bInit := FALSE; bFaultActive := FALSE; tFaultStart := T#0S; tNextCheck := TIME() + tCheckCycle; END_IF // 周期检测 IF TIME() < tNextCheck THEN RETURN; END_IF tNextCheck := TIME() + tCheckCycle; // ---------- 本轮检测 ---------- bResultOK := TRUE; uiTempNode := 0; byTempState := 0; // 1. 检查主站状态 IF g_bMasterState <> byExpectedState THEN bResultOK := FALSE; uiTempNode := 0; byTempState := g_bMasterState; END_IF // 2. 主站正常时，检查各从站状态 IF bResultOK THEN IF iSlaveCount > 0 THEN FOR i := 1 TO iSlaveCount DO IF g_abSlaveState[i] <> byExpectedState THEN bResultOK := FALSE; uiTempNode := INT_TO_UINT(i); byTempState := g_abSlaveState[i]; EXIT; END_IF END_FOR END_IF END_IF // ---------- 结果处理 ---------- IF NOT bResultOK THEN // 新故障发生，锁存信息 IF NOT bFaultActive THEN bFaultActive := TRUE; tFaultStart := TIME(); udiFaultCounter := udiFaultCounter + 1; uiFaultNode := uiTempNode; byFaultState := byTempState; tFaultTime := tFaultStart; tRecoverTime := T#0S; END_IF bCommNormal := FALSE; bFault := TRUE; // 自动恢复请求 IF bAutoRecover THEN IF (TIME() - tFaultStart) >= tRecoverDelay THEN bRecoverRequest := TRUE; END_IF END_IF ELSE // 通讯恢复 IF bFaultActive THEN bFaultActive := FALSE; tRecoverTime := TIME(); bRecoverRequest := FALSE; END_IF bCommNormal := TRUE; bFault := FALSE; END_IF这段代码的逻辑链很清晰：先查主站，主站正常再查从站；发现异常后用bFaultActive区分“新故障”和“故障持续中”，避免同一个故障反复锁存计数；等状态全部恢复正常后，再把bFault清除并记录恢复时间。
这里有一个细节值得注意：tFaultTime锁存的是“故障首次发生的时刻”，tRecoverTime记录的是“故障消失的时刻”。这两个时间戳对现场溯源非常有用，比如你能看到设备每天凌晨三点断了一次，结合交接班记录就能猜出是有人动过设备。
3.3 自动恢复逻辑：能用，但别乱用
bAutoRecover这个功能我默认设成FALSE，原因是自动恢复有风险。通讯断开的瞬间，从站输出可能进入安全状态或保持上一状态，如果你自动把总线重新初始化，输出会重新刷新，设备可能突然动作。在带伺服、气缸这类执行机构的现场，自动恢复前必须确认系统处于安全状态。
如果确实需要自动恢复，典型做法有两种。第一种是程序级恢复：把bRecoverRequest接到一个执行重启的功能块或设备树里的“重新启动从站”触发位上，让主站把掉线从站重新拉回OP状态。第二种是硬件级恢复：把bRecoverRequest接到一个中间继电器，驱动故障从站段的24V电源断开1到2秒再恢复，强制从站重新上电。硬件级恢复对网口卡死的从站特别有效，但动作粗暴，必须评估设备安全。
无论哪种方式，都建议在恢复动作之前确认系统处于安全停车状态，比如伺服使能已经被断开，或者有机械抱闸保护。
3.4 把状态数据送出去：HMI和PLC-Recorder
程序写完了，数据显示在哪里也是要提前想的。状态监测的几个核心变量（bFault、uiFaultNode、byFaultState、tFaultTime、tRecoverTime、udiFaultCounter）建议都在符号配置里标记成“可访问”，这样HMI可以直接绑定，上位机也能通过OPC UA或Modbus TCP读取。
如果项目里要用PLC-Recorder这类工具做数据追溯，那就把上述变量做成可发布的趋势变量，按秒或按事件触发记录。掉线前几秒的IO数据、速度指令、伺服实际位置全部记录下来，事后复盘会非常轻松。有些项目中还建了数据库表，用alongwu第三方库或ODBC接口把故障记录写到MySQL，留着后续做设备OEE分析。这块涉及不同第三方库接口差异，代码就不展开了，思路是：状态监测功能块只管采集和锁存，数据怎么消费由上层接口决定。
4. 实测验证：拔掉网线看看程序什么反应
代码写完了，得实际验证才知道逻辑到底靠不靠谱。我拿一个树莓派4B跑CODESYS Control SL做EtherCAT主站，外接两个从站模块来测试，这里面的过程基本涵盖了现场会遇到的所有情况。
4.1 搭建一个可复现的测试环境
主站方面，树莓派4B加一张Intel USB千兆网卡就能跑EtherCAT。也有不少人在正点原子RK3568这类ARM板卡上跑CODESYS Control SL，用板载或USB网卡做EtherCAT主站，原理一样。从站用一个步进驱动器和一个远程IO模块，最低配置一个从站也能测试，但建议至少两个，这样能验证“单个从站掉线”和“整条链路掉线”两种场景。
配置要点：
- 主站任务周期设为2ms，因为后面要测断线后的输出保持行为。
- 开启DC同步，从站工作在OP状态，确认两个从站的ALStatus都是8。
- 把你写的监视功能块放到一个10ms轮询任务里，
tCheckCycle设200ms。
把g_bMasterState、g_abSlaveState[1]、g_abSlaveState[2]拖到在线监控窗口，同时把功能块的输出变量也拖进去。一切都正常时，你应该看到主站状态是8，两个从站状态都是8，bCommNormal为TRUE，bFault为FALSE。
4.2 实测场景：拔线、恢复、再拔主站线
第一步，拔掉第一个从站到第二个从站之间的网线。预期结果：第一个从站的ALStatus立刻从8跳到4或者2，第二个从站因为连在第一个从站后面，也会掉线。功能块输出bFault变TRUE，uiFaultNode等于1，byFaultState显示非8状态，tFaultTime是当前运行时间，udiFaultCounter加1。
第二步，插回网线。主站会自动重新初始化从站，大约一两秒后两个从站重新进入OP状态，bFault变FALSE，tRecoverTime被刷新，bCommNormal变TRUE。
第三步，拔掉主站网线。这次是主站状态异常，g_bMasterState掉出OP，uiFaultNode应该等于0，表示主站故障。这时候即使从站本身的ALStatus还是8，也不能继续运行，因为主站已经失去通信能力了。这个逻辑在代码里通过“先查主站，再查从站”的顺序保证了优先级。
下面是测试中记录到的现象对照表：
| 测试场景 | uiFaultNode | byFaultState | bFault | tFaultTime | 说明 |
|---|---|---|---|---|---|
| 正常运行时 | 0 | 8 | FALSE | 0 | 无故障 |
| 拔从站1网线 | 1 | 4或2 | TRUE | 记录当前时间 | 从站1退到SAFEOP/PREOP |
| 插回从站1网线 | 0 | 8 | FALSE | 锁存保持 | 通讯自动恢复 |
| 拔主站网线 | 0 | 非8 | TRUE | 记录当前时间 | 主站掉出OP |
| 主站网线恢复 | 0 | 8 | FALSE | 锁存保持 | 从站随之恢复OP |
4.3 测试中最容易踩的几个细节
第一个坑是地址映射错位。有人把从站ALStatus映射到了MB100后面，但设备树的从站顺序和你程序里ARRAY[1..16]的索引对不上，结果明明掉线的是第三个站，程序报的是第二个。排查方法是在线监控里手动拨掉每个从站网线，验证uiFaultNode指向的到底是不是物理上的那个站，一次测完再交付。
第二个坑是BYTE和整数比较的隐式转换。CODESYS里16#08按BYTE存储，直接比较没问题，但如果你把期望状态写成了常量8而不是16#08，某些版本可能因为你声明成了BYTE类型导致语法检查不通过。建议统一用16进制写法，看着也直观。
第三个坑是检测周期与故障事件的竞争。如果你把tCheckCycle设成500ms，但掉线只持续300ms，程序可能根本检测不到。这时候不是逻辑问题，而是采样太慢。要么缩小检测周期，要么承认这种毫秒级瞬时闪断只能靠EtherCAT的分布式时钟和从站看门狗去捕捉，应用层监测程序抓不到是正常的。
5. 常见问题与避坑经验速查
代码和验证都过了，最后还是要把现场最常见的几个问题整理成清单，以后排查的时候按这个表走就行，省得东翻西找。
5.1 常见问题速查表
| 现象 | 可能原因 | 处理措施 |
|---|---|---|
| 整条链路全部掉线 | 主站网卡驱动异常、主站侧网线故障、总线供电异常 | 先查主站网线压接，再看网卡驱动，最后量24V电源 |
| 固定某一个从站掉线 | 从站网口损坏、该段网线异常、从站供电不足 | 替换该段网线，检查该从站网口，单独供电测试 |
| 掉线后恢复，运行一段时间又掉 | 从站供电容量不足、该段屏蔽层未接地 | 给从站增加独立供电，检查屏蔽接地 |
| 修改任务周期后掉线 | 周期过短，总线无法完成扫描 | 恢复原周期，优化任务划分 |
| 偶发闪断无法复现 | 电磁干扰、DC时钟同步不稳 | 检查布线、更换屏蔽网线、升级主站实时驱动 |
| 从站ALStatus是8，但数据不更新 | 数据链路阻塞、映射失效 | 用心跳变量辅助判断，检查映射和看门狗配置 |
这里想专门强调一下“从站供电不足”这个原因，因为它的隐蔽性特别强。表面看从站指示灯都正常，ALStatus也是OP，但一负载起来，比如伺服使能或IO全部输出，总线上电压跌落，从站控制器就复位了。测量时要看动态电压，不是空载电压。挂上示波器或者用带记录功能的万用表看24V在负载切换瞬间的跌落幅度，低于19V就需要注意了。
5.2 一点我的实操体会
状态监测程序这个东西，属于“平时看着不起眼，出事才知道真香”的典型。我后来接的每个带EtherCAT的项目，不管甲方有没有要求，都会把这个功能块预埋进去，不占多少资源，真到调设备的时候能救命。有一次现场设备半夜掉线，操作工说没碰任何东西，靠监测程序锁存的时间戳和节点号，发现掉线时间正好和隔壁产线大功率变频器启动的时间重合，顺藤摸瓜解决了困扰两周的干扰问题。
最后再分享一个小细节：如果你的现场有多个从站，建议在状态监测程序里额外加一个“首个故障从站索引”的输出，就是第一个报错的从站编号。因为EtherCAT主站重新初始化是很快的，有时候操作工按下复位，总线恢复，故障从站已经回到OP状态了，等你跑过去看监控，ALStatus全是8，啥也查不到。有了锁存功能，至少能看到“刚才1号站先掉，后面其他站跟着掉”这个先后顺序，对判断故障源头非常有帮助。这套程序后续还可以扩展成自动发短信、自动弹HMI页面，思路都是一样的，先把现场证据抓到手再说。
