威纶通 cMT 接平板调试：断线心跳保护这...

cMT 系列触摸屏，由于支持安卓 / iOS 客户端通过无线连接远程操作，在国内自动化项目中应用极多。但有一个隐患长期存在：
我们在 HMI 上做轴的 Jog 按钮时，由于 Jog 必须持续触发才能保证电机按预期运行。一旦在按钮按下后，触摸屏 / 客户端断线，Jog 按钮就会一直保持触发状态，电机一直运行——轻则撞机报警，重则损坏机械结构。
这个问题并不只出现在 cMT 系列上，其他触摸屏同样存在。但 cMT 的通讯架构模型让这个问题变得极难解决。下面我们来分析一下这个问题。
二、问题分析
2.1 自复位按钮（按 1 松 0）是如何实现的
在 HMI 上实现"按 1 松 0"很简单：
首先，网络不是我们接线的电平 IO。并不存在"断线电平就变化"的过程。它的工作方式是：客户端 / 主机发起一个指令，服务器 / 从机接收到指令后，响应指令请求。
同时，指令是不能一直发送的，不然就会堵塞整个网络。
所以，实际的"按 1 松 0"是如下行为：按钮按下时，HMI 发送一帧报文告诉 PLC"将变量写为 TRUE"；按钮松开时，HMI 再发送另一帧报文告诉 PLC"将变量写为 FALSE"。PLC 收到后做对应动作。

本质上，HMI 发送报文是一个事件触发的过程：向 PLC 发送"松开"报文，只会在按钮松开事件产生后发送一次（或根据配置重试若干次），然后对 HMI 来说这件事就结束了。

2.2 隐患不止是完全断线：只要现场网络环境不稳定，这个问题大概率被触发
假如按钮按下时，PLC 收到写 TRUE 的报文并执行；但在按钮还没松开时，HMI 与 PLC 通讯断线了——PLC 还能知道按钮已经松开了吗？答案是不能的。HMI 已经没有能力把"松开"事件告诉 PLC 了。
关键点：不需要真的断线，只要网络环境不稳定，在松开按钮的事件产生时刚好通讯不通畅，就会导致 PLC 一直保持相关变量为 TRUE。当这个变量是 Jog 按钮时，电机就会一直运行。
2.3 传统 HMI 怎么解决：心跳检测
传统 HMI 面对这个问题，方案其实很简单：在 PLC 和 HMI 之间做一个心跳标志，用来判断通讯是否中断；只要通讯中断，直接把 HMI 操作的变量清 FALSE 即可。

【图注】图 1　传统 HMI 通讯架构（看点：单链路直达，心跳覆盖全程，断线立即可知）
2.4 cMT 为什么难解决：通讯架构变了
但到了 cMT 上，这套"PLC ↔ HMI 心跳"的传统方案失效了——不是心跳思路错了，而是 cMT 的通讯架构里多出了一条 PLC 感知不到的链路。我们先看它的通讯架构：

【图注】图 2　cMT 通讯架构（看点：链路①可监控、链路②是盲区，传统心跳只覆盖到链路①）
看图 2，cMT 的通讯模型有两个关键特征：
① 通讯内核（协议网关）与 UI 会话层分离：cMT 本体内部的"通讯内核"是协议网关，直接与 PLC 通讯；本体的屏幕、连接的平板 / 手机 App、cMT Viewer 等都是一个个"会话层"。多个会话层共享一个通讯内核，这就是 cMT 的"一机多屏"。
② 存在两条链路：
· 链路① PLC ↔ cMT 本体（通讯内核）：传统的 Modbus TCP / 串口链路，PLC 这边能监控，心跳能覆盖。
· 链路② cMT 本体 ↔ 各客户端（会话层）：无线 / 有线网络，PLC 协议层面无法感知，心跳覆盖不到。
也就是说：我们在平板上按下 Jog 按钮，在松开之前平板断线，操作人员几乎只能看着撞机。因为 PLC 这边只能感知链路①的状态，根本不知道链路②上的客户端已经失联。
2.5 会话层限制：客户端侧做不了心跳
那能不能在客户端（平板 / 手机）上自己实现一个心跳呢？这就要说到威纶通 cMT 的底层架构模型了。
从操作和表现来看，威纶通应该是把通讯内核和 UI 会话层分开，在平板上运行的 App 本质上只是一个会话层，本体上的界面也是会话层；多个会话层对应一个通讯内核，实现一机多屏。
但会话层有一个关键限制：在威纶通的会话层上，局部变量（PLB 为位型、PLW 为字型，只在本会话层 / 客户端生效）无法通过定时任务、循环执行等方式操作。也就是说，至少暴露给用户配置的会话层是纯事件驱动型的；而常规的心跳实现方案，正好需要客户端定时向服务端发送数据（比如说累加一个数，或取反一个值）。所以，我们没办法在客户端上的会话层上自己跑一个心跳通讯。
官方只有一个 LW-11839 标记了客户端连接数量。LW-11839 不可用的原因有两点：
① 假设我连了 2 个客户端（最常见的场景：你电脑上跑一个客户端，调机人员手上拿一个平板），其中一个断线了，PLC 并不知道是哪一个断线了。
② 即使是客户端连接数量，也得等客户端断线 10 秒左右后才检测出来。对 Jog 保护来说，这个时间太慢了。而且如果是不稳定的现场通讯，刚好在松开按钮的时候网络波动了，可能根本不会触发 LW-11839 的计数变化，但松开按钮的事件已经被漏了。
还有一条路也走不通：即使由 PLC 主动发起心跳请求（比如 PLC 定时把某个变量置 1，等 HMI 回应后清 0），由于 cMT 是"单通讯内核 + 多会话层"机制，回应只能放在通讯内核 / 全局层面，PLC 依旧分辨不出回写来自哪一个会话层。
最典型的场景：HMI 本体必然有一个会话层，它基本是稳定在线的；而平板是另一个会话层，操作大概率由平板发起——平板挂了，本体的会话层照样会回应 PLC，PLC 依然不知道链路②已经断开。
所以，链路② 的断线检测似乎变得无法实现。

而 cMT 和平板的连接走的是以太网，现场整线调试时 IP 冲突、WiFi 干扰都会让通讯中断 / 延迟。这个隐患在很多现场已经从"理论风险"变成了"实际撞机事故"，是必须解决的问题。

三、问题解决方案
在现场查看了无数次手册、试验了许多次后，终于找到了突破口：威纶通在 cMT 客户端上支持"动作触发"功能，和安全设置里面的"使用寄存器状态 / 数值"功能组合，它允许 HMI 响应通讯产生的事件（变量变化）；而且安全功能里面的寄存器，可以用 PLB 或 PLW 等会话内的局部寄存器。
3.1 核心思路：把心跳拆成"事件触发"
既然客户端做不了定时心跳，那就让 PLC 把心跳信号变成"事件"推到客户端，再让客户端在"事件发生"时把心跳写回 PLC。分三步来走：

【图注】图 3　断线保护心跳方案（看点：PLC 制造事件 → 客户端事件驱动回传 → 超时强制复位，全程不依赖客户端定时任务）
3.2 实现思路
① PLC 侧：定时器周期取反"心跳源变量"
在 PLC 上做一个定时器，按设定周期（如 200~500ms）对一个全局变量取反一次。具体周期与超时参数建议，下期给出。这个变量每变化一次，HMI 端就会产生一个"变量变化触发事件"——它会被广播到所有客户端。
② cMT 客户端（会话层）：PLB 标志 + 变量触发功能
在客户端上用一个局部变量 PLB 记录"本会话的 Jog 按钮是否被按下"。当 PLB = TRUE 时，利用"变量触发"功能（在心跳源变量变化时触发）将另一个变量"返回心跳变量"取反，然后写回 PLC。这样既绕开了会话层无法跑定时任务的限制，又实现了"事件驱动"的心跳返回，通过"谁按下、谁响应心跳"，正好能区分出断线的是不是正在操作 Jog 的那个客户端。
③ PLC 侧：监测返回心跳，超时即安全复位
PLC 持续监测"返回心跳变量"，若超过若干个周期没有变化，即判定该客户端断线，强制把 Jog 等操作变量置为 FALSE，电机安全停止。
这套机制利用了威纶通 cMT 的"动作触发"（变量变化触发）能力，绕开了会话层局部变量无法定时运行的限制，在不动 PLC 现有业务逻辑的前提下，给每个客户端都加上了一道"断线保险"。

这个方案有一个盲区：如果有两个客户端同时操作同一个 Jog，两边都会响应心跳事件——其中一个断线时并不会触发停止，因为另一个客户端还在正常回心跳。所以实际落地还需要一个多屏操作互锁机制。多屏互锁有很多现成可用的方案，这里就不展开了

下期预告 cMT 触摸屏断线保护 · 实操教程 关注微信公众号：PLC_张侠 第一时间获取更新

本文为原创首发于微信公众号「PLC_张侠」，欢迎关注交流。