结论UI 卡顿的直接原因是“故障日志同步写 PLC”不是Volatile.Read或递归。调用链如下实时采集结果通过Dispatcher.BeginInvoke回到 UI 线程执行StationControlViewModel.Realtime.cs。UI 线程调用PrintAuxControlErrorLog进入LogHelper.PublishStationLog。PublishStationLog同步执行注册的故障灯处理器。WriteFaultRunLightRedSolid连续调用三次同步 PLC 写入。PLC 写入经过EnqueueExecute锁和 Socket 收发失败时会等待超时Driver.cs、AuxPLC.cs。日志已经明确证明了这一点17:41:38.442 故障产生。17:41:59.453 红灯写失败约等待 21 秒。17:42:20.485 绿灯写失败再等待约 21 秒。17:42:41.545 黄灯写失败再等待约 21 秒。也就是说一条故障最多阻塞 UI 约 63 秒。5034、5035、5036 连续发生后UI 线程累计被阻塞约 171 秒。后续 5041、5043 在 PLC 已被判定断开后才快速返回所以日志时间相同。另外还有几个问题红灯写失败后仍继续写绿灯、黄灯放大了等待时间。只检查了红灯返回值绿灯和黄灯返回值被忽略。WriteFaultRunLightRedSolid实际调用的是WriteTowerRedBlinking名称和实际命令不一致。PublishFaultEvent在 PLC 三次写入之后才执行故障事件本身也会被延迟。建议的修复方向PublishStationLog中只投递故障灯请求不执行同步 PLC I/O。由每站一个后台单消费者队列处理灯塔写入并对同站故障进行合并/去重。三个连续地址尽量合并成一次 PLC 批量写入通讯失败后立即停止后续写入并标记 PLC 离线。按实际意图改为WriteTowerRedSolid并补充每次 PLC 写入的耗时和线程号日志。本次仅完成原因分析未修改代码。
结论UI 卡顿的直接原因是“故障日志同步写 PLC”不是Volatile.Read或递归。调用链如下实时采集结果通过Dispatcher.BeginInvoke回到 UI 线程执行StationControlViewModel.Realtime.cs。UI 线程调用PrintAuxControlErrorLog进入LogHelper.PublishStationLog。PublishStationLog同步执行注册的故障灯处理器。WriteFaultRunLightRedSolid连续调用三次同步 PLC 写入。PLC 写入经过EnqueueExecute锁和 Socket 收发失败时会等待超时Driver.cs、AuxPLC.cs。日志已经明确证明了这一点17:41:38.442 故障产生。17:41:59.453 红灯写失败约等待 21 秒。17:42:20.485 绿灯写失败再等待约 21 秒。17:42:41.545 黄灯写失败再等待约 21 秒。也就是说一条故障最多阻塞 UI 约 63 秒。5034、5035、5036 连续发生后UI 线程累计被阻塞约 171 秒。后续 5041、5043 在 PLC 已被判定断开后才快速返回所以日志时间相同。另外还有几个问题红灯写失败后仍继续写绿灯、黄灯放大了等待时间。只检查了红灯返回值绿灯和黄灯返回值被忽略。WriteFaultRunLightRedSolid实际调用的是WriteTowerRedBlinking名称和实际命令不一致。PublishFaultEvent在 PLC 三次写入之后才执行故障事件本身也会被延迟。建议的修复方向PublishStationLog中只投递故障灯请求不执行同步 PLC I/O。由每站一个后台单消费者队列处理灯塔写入并对同站故障进行合并/去重。三个连续地址尽量合并成一次 PLC 批量写入通讯失败后立即停止后续写入并标记 PLC 离线。按实际意图改为WriteTowerRedSolid并补充每次 PLC 写入的耗时和线程号日志。本次仅完成原因分析未修改代码。
