- 救命!S7-1513R 冗余系统。 运行中 A 机和 B 机居然同时亮了‘Primary’(主机)的灯。 然后现场所有的远程 IO(ET200SP)全部报错,因为它们不知道听谁的。 光纤链路检查了,是
- MT8102iE 触摸屏,存 24 小时的温度趋势图。 设置是每 1 秒采样一次。 奇怪的现象:每天凌晨 3 点左右,趋势图就会出现一段大约 10 分钟的空白(断线)。 检查了 PLC(三菱 Q 系列
- 遇到鬼了!一个液位计 4-20mA 入 PLC。 隔壁有个 55KW 的大变频器,它运行的时候,PLC 读数是 15mA(正常的)。 只要把这个变频器关掉(完全断电),PLC 的读数立马掉到 11mA
- 急!现场 1756 系列的双机热备冗余系统。 模拟测试的时候,拔掉 A 机 CPU,B 机能无缝切换。 但实战出问题了:昨天 A 机因为电源模块故障停机,B 机虽然切换过去了,但现场所有的 PID 调
- 求助:S7-1200 控制 V90 PN 伺服,走 EPOS 控制。 每次开机回零(Homing)都没问题。但奇怪的是,设备连续运行 48 小时左右,如果中间触发了一次急停,再重新回零,伺服就一直报错
救命!S7-1513R 冗余系统。 运行中 A 机和 B 机居然同时亮了‘Primary’(主机)的灯。 然后现场所有的远程 IO(ET200SP)全部报错,因为它们不知道听谁的。 光纤链路检查了,是
联系人:15612951024096
电话/手机:联系客服
发布时间:2026-04-15 12:03
浏览:15次
运行中 A 机和 B 机居然同时亮了‘Primary’(主机)的灯。
然后现场所有的远程 IO(ET200SP)全部报错,因为它们不知道听谁的。
光纤链路检查了,是通的。
系统日志里报:‘冗余链路心跳丢失’,但我换了光模块还是没用。
两台主机在同一个机架里‘打架’,这种双主现象怎么破解?重启都不管用,求大神指路!”



















































先给结论:
两台 CPU 之所以同时亮 Primary,是因为它们彼此“看不见对方的心跳”,各自都判定对方失效,于是同时抢主。
这时远程 I/O(ET200SP)就会出现“两个控制器同时要建立 AR(Application Relationship)”,结果就是全部掉站/报错。
你日志里那句 “冗余链路心跳丢失” 已经把方向说得很清楚了:问题不在光模块本身,而在心跳通道的完整路径或配置。
一、为什么会出现“双主”
S7-1500R/H 的判主逻辑本质是:
我能收到对方心跳 → 我当备用
我收不到对方心跳 → 我当主
如果出现下面任一情况:
A 收不到 B
B 也收不到 A
就会变成:
A:对方死了 → 我当主
B:对方死了 → 我当主
这就是你现在的状态。
二、你已经做了但“没解决”的点说明什么
你说:
光纤是通的
换了光模块
重启也没用
说明:
物理链路“有光” ≠ 冗余心跳“可用”
冗余链路要求的是:
双通道(R1 / R2)
正确的接口
正确的 IP / 子网 / 配置
正确的系统一致性
三、最常见的 5 个根因(现场经验排序)
① 冗余链路只“通了一半”(最常见)
比如:
R1 通
R2 断(或接错)
但你用电脑测,可能测的是:
Ping 通 → 误以为没问题
但冗余心跳要求:
两条链路都必须正常
有一条不通,就可能导致心跳异常
② 交换机配置问题(非常常见)
如果你冗余链路走交换机:
重点检查:
是否有 RSTP / STP
是否有 环网协议(MRP / ERPS)
是否有 风暴抑制 / 广播限制
是否 VLAN 隔离
问题表现:
平时正常
某个时刻丢心跳
→ 双主
很多 split-brain 都是交换机引起的
③ 冗余 IP / 接口配置不一致
检查:
两台 CPU 的 R1 / R2 IP
子网掩码
TIA 下载是否完全一致
是否做过 单边下载
如果出现:
A 配置新版
B 还是旧版
心跳解析失败 → 双主
④ 固件或项目版本不一致
S7-1500R 对版本一致性非常敏感:
CPU 固件版本
硬件配置版本
TIA 项目版本
只要有差异:
有可能“能运行,但同步不稳定”
⑤ CPU 负载或通信异常导致心跳超时
例如:
PROFINET 风暴
IO 设备异常刷包
CPU 负载过高
网络瞬时拥塞
结果:
短时间收不到心跳
→ 误判对方掉线
→ 双主
四、为什么 ET200SP 全部掉站
ET200SP 的逻辑是:
一个 IO Controller = 一个 Owner
现在你是:
两个 Primary 同时抢
结果:
AR 建立冲突
IO 断开
全部红灯
这是“结果”,不是原因
五、为什么“重启也不管用”
因为你重启后:
链路问题仍然存在
→ 两台再次互相看不见
→ 又双主
这是结构性问题,不是偶发
六、最有效的排查步骤(现场建议)
第一步:强制恢复单主(止血)
先把系统救回来:
断开其中一台 CPU 的冗余链路(R1/R2)
只保留一台运行:
A 正常运行
B 隔离
先恢复生产
第二步:检查冗余链路拓扑(重点)
画出实际连接:
CPU A R1 → ?
CPU A R2 → ?
CPU B R1 → ?
CPU B R2 → ?
确认:
是否直连(推荐)
是否经过交换机
是否存在环路
是否交叉接错
第三步:逐条验证链路
不要只看“有光”,要做:
拔掉 R1,看系统反应
拔掉 R2,看系统反应
单链路是否能稳定运行
第四步:检查交换机
如果经过交换机:
重点查:
STP 是否启用
是否有端口阻塞
是否有广播风暴
是否 QoS 限制
工业冗余链路建议:
尽量直连 或 使用专用冗余网络
第五步:在线看诊断缓冲区
在 TIA Portal 看:
冗余事件
心跳丢失时间
哪条链路丢失
这一步能直接定位是哪一侧的问题
第六步:重新下载一致配置
建议:
同时给 A / B 全量下载
不要单边下载
七、一个非常关键的经验
“光纤通了”是最容易误导人的
冗余链路真正要求的是:
实时、稳定、低延迟、双通道通信
不是“能 ping 通”。
八、我给你的判断优先级
按你描述:
换光模块无效 + 日志心跳丢失 + 双主
我会这样排:
冗余链路路径或接线错误(R1/R2)
交换机干扰(STP / 环网)
配置不同步(单边下载)
网络瞬时风暴
九、一句话总结
你这个问题本质就是:
冗余链路失效 → 两台互相认为对方死 → 同时抢主 → IO 全崩
不是 CPU “打架”,而是:
它们各自都觉得自己是唯一活着的那台
十、如果你想快速定位
你可以把这几个信息发我,我可以帮你直接判断是哪种情况:
R1 / R2 实际接线图(文字描述也行)
是否经过交换机(型号)
CPU 固件版本
TIA 项目是否最近只下载过一台
诊断缓冲区具体报错时间点
很多 1500R 双主问题,我基本可以 1~2 步帮你锁死原因。