第6篇_PLC 里写 MQTT，最难的不是报文，而是状态机

这一篇站在架构层看 FB_MqttClient，重点讲主状态机为什么才是系统骨架、iConnected 为什么是调度中心、接收链和发送链为什么必须拆开，以及异常为什么统一收口到 iTcpDisconnect。

适合谁收藏

正在做 CODESYS / PLC / MQTT 项目的人
想把 MQTT 从报文真正看到 ST 代码的人
正在排查 QoS1 / QoS2 超时、掉线、重连问题的人

如果你已经把前几篇都看完了，大概率会有一种感觉：

MQTT 报文其实不算太难，难的是这些报文怎么在 PLC 里有秩序地跑起来。

这个感觉是对的。

对 PLC 来说，真正决定一个 MQTT 客户端是“能跑”还是“跑稳”的，往往不是某个字节写错没写错，而是：

状态怎么分
状态怎么跳
ACK 谁来发
超时谁来判
接收和发送怎么不互相卡死

这一篇我们就专门讲这件事。

先给结论：

报文是骨头，状态机才是筋。

一、先看 FB_MqttClient 的主状态全貌

直接上总图。

Mermaid

flowchart TD
    A[iDisconnected] --> B[iTcpConnect]
    B --> C[iConnect]
    C --> D[iConnAck]
    D --> E[iConnected]

    E --> F[iPublish]
    F --> G[iPubAck]
    F --> H[iPubRec]
    H --> I[iPubRel]
    I --> J[iPubComp]

    E --> K[iSubscribe]
    K --> L[iSubAck]

    E --> M[iUnsubscribe]
    M --> N[iUnsubAck]

    E --> O[iPingReq]
    O --> P[iPingResp]

    E --> Q[iDisconnect]
    B --> R[iTcpDisconnect]
    C --> R
    D --> R
    F --> R
    G --> R
    H --> R
    I --> R
    J --> R
    L --> R
    N --> R
    P --> R
    Q --> R

这张图先记住一个原则：

这个状态机不是按“代码文件夹”分的，而是按“协议动作链”分的。

也就是说：

连接是一条链
发布是一条链
订阅是一条链
心跳是一条链
异常恢复是一条统一收口链

二、为什么 iConnected 是整个系统的调度中心

很多人第一次看状态机，会误以为 iConnected 是个“空闲态”。

其实恰恰相反。

在这个客户端里，iConnected 不是静止状态，而是 运行调度中心。

它至少要处理下面这些事：

有没有新的 Publish
有没有新的 Subscribe
有没有新的 Unsubscribe
有没有待发送的即时 ACK
接收缓冲区里还有没有完整帧
inflight 有没有超时项
KeepAlive 有没有到期
用户是不是主动拉低 bConnect

所以更准确地说：

iConnected 是 MQTT 客户端的主循环枢纽。

三、为什么不能把所有收发逻辑都塞进一个状态里

有些 demo 风格实现，喜欢把事情写成这样：

连上后就在一个大状态里处理全部逻辑
收到了什么就现场回
要发什么就直接发

这种写法短期看起来省事，长期非常容易出问题。

为什么？

因为 MQTT 至少有 3 类动作在同时发生：

主动动作

CONNECT
PUBLISH
SUBSCRIBE
UNSUBSCRIBE
PINGREQ

被动动作

对端发 PUBLISH 过来，你要回 PUBACK/PUBREC
对端发 PUBREL 过来，你要回 PUBCOMP

后台动作

inflight 超时扫描
KeepAlive 计时
自动重连

如果这三类动作全堆在一个无边界的大状态里，后果通常就是：

某个 ACK 被拖延
某个超时条件没及时触发
某个等待状态迟迟不释放

四、为什么接收链和发送链必须分开

这是 MQTT 客户端设计里非常关键的一点。

发送链负责什么

主动构包
主动发出去
建立“我接下来在等谁”的等待关系

接收链负责什么

从接收缓冲区解析完整 MQTT 帧
判断报文类型
推进等待状态
必要时生成即时协议响应

把这两层拆开之后，你的代码脑子会清楚很多：

发送链决定“我要做什么”。

这个库里，这个分层就很明确：

职责	主要位置
主状态机总控	`FB_MqttClient.st`
报文发送构造	`处理发送报文`
报文接收解析	`M_ProcessReceive`
接收缓冲循环消化	`M_ProcessPendingFrames`

五、M_ProcessPendingFrames 为什么很关键

这个方法代码不长，但架构价值很高。

iecst

WHILE uiRxLength > 0 DO
    IF NOT M_ProcessReceive() THEN
        EXIT;
    END_IF
    bProcessed := TRUE;

    IF xPendingImmediateTx THEN
        EXIT;
    END_IF
END_WHILE

这段逻辑体现了 2 个重要思路：

只要缓冲区里还有完整帧，就持续消化
如果在处理中途生成了必须立刻回的 ACK，就先停下来，让主状态机优先把 ACK 发出去

这正是前面 QoS1 / QoS2 高频稳定性的关键之一。

如果你这里不分层、不分优先级，就容易出现：

入站帧堆在缓冲区
ACK 迟迟发不出去
对端认为你超时了

六、为什么 iTcpDisconnect 是统一异常收口

一个成熟状态机，不会让每个异常都各自散落结束。它通常会有一个统一异常收口状态。

在这个客户端里，就是：

text

iTcpDisconnect

所有严重问题最终都可能导到这里，比如：

TCP 连接超时
CONNECT / PUBLISH / SUBSCRIBE 发送失败
CONNACK / PUBACK / SUBACK 等待超时
即时 ACK 发送失败

这类设计的好处是：

断线清理逻辑集中
自动重连入口统一
诊断路径更清楚

这也是为什么现场你经常看到“最后都掉到 iTcpDisconnect”，但根因其实各不相同。

七、为什么高频场景主要在压 iConnected

前面我们一直在说高频 QoS1 / QoS2 最容易暴露问题。如果从架构层面看，本质上就是在压 iConnected。

因为在这个状态里，客户端要同时协调：

收
发
等 ACK
发即时 ACK
扫 inflight
处理心跳

只要调度策略不清晰，这里就会先出问题。

所以判断一个 MQTT 客户端是否成熟，有个很实用的角度：

看它的 iConnected 是不是一个真正可调度、可回收、可让出优先级的运行态。

八、为什么说报文只是局部正确，状态机才决定整体正确

举个很实际的例子：

场景 1

你 PUBLISH 构包完全正确。但 PUBACK 来了之后，状态机没有及时释放 xWaitingForAck。

结果：

报文没错
连接还是可能超时

场景 2

你 SUBSCRIBE 构包也完全正确。但 SUBACK 收到后，状态没切回 iConnected。

结果：

报文没错
功能块外观看起来“卡死”

这就是为什么：

局部方法正确，只能说明“这块没写歪”。

九、读这套源码，最推荐的顺序是什么

如果你要真把 FB_MqttClient 看懂，我最建议按这个顺序读：

第一步：先看主状态骨架

FB_MqttClient.st

先建立“全局有哪些状态，状态怎么跳”的大图。

第二步：看 3 条主链

CONNECT / CONNACK
PUBLISH / QoS1 / QoS2
SUBSCRIBE / UNSUBSCRIBE

第三步：回头看辅助机制

M_ProcessPendingFrames
M_InflightCheckTimeout
M_IsValidTopicFilter

第四步：最后再看方法细节

否则一上来扎进方法内部，很容易只见树木，不见森林。

十、把主状态机的职责再压成一张表

状态段	核心职责
`iDisconnected -> iConnAck`	建立 MQTT 会话
`iConnected`	运行态调度中心
`iPublish -> iPubComp`	发布与 QoS 确认链
`iSubscribe -> iSubAck`	订阅链
`iUnsubscribe -> iUnsubAck`	退订链
`iPingReq -> iPingResp`	长连接保活
`iTcpDisconnect`	异常收口与恢复入口

这张表对排障特别有用。因为它让你一眼就知道：当前问题大概率属于哪一条链。

十一、这一篇你最该记住的 5 句话

报文决定局部动作，状态机决定整体行为。
iConnected 不是空闲态，而是客户端运行调度中心。
发送链和接收链必须分开，否则高频场景很容易互相阻塞。
M_ProcessPendingFrames 这种小方法，往往决定客户端能不能把 ACK 时序跑顺。
成熟 MQTT 客户端的标志，不是状态多，而是状态边界清楚、异常收口统一。

十二、下篇预告

下一篇我们直接从工程现场最关心的视角切：

为什么会超时、掉线、重连、订阅丢失，到底该怎么查

也就是把前面所有报文、ACK、状态机知识，真正落到排障路径上。

这篇会非常实战。

完整 ST 代码

复制使用说明

这部分给出的是与本篇主题直接对应的完整 ST 代码，不是零碎片段。
如果你只是想先跑通，优先整段复制，不要只摘几行变量或几条赋值语句。
如果是 METHOD，请确认它仍然属于 FB_MqttClient；如果是 PROGRAM，请确认相关 DUT、GVL、FB 已一并导入。

代码阅读重点

先按 报文结构 -> 状态机入口 -> 关键变量 -> 返回结果 的顺序看。
再把正文里的十六进制拆解和这里的字节写入、字节解析语句一行行对上。
最后回到在线调试，重点盯 uiTxLength、uiRxLength、eState、xWaitingForAck 这类状态量。

完整代码 1：FB_MqttClient

对应源码路径：10 MQTT/MqttClient_V1_0/Device/Application/MQTT/POUs/MqttClient NBS/FB_MqttClient.st
复制使用说明：这一篇的核心就是整个主功能块本体。只看零碎方法理解不了状态机，必须把整个 FB_MqttClient 连起来看。
阅读重点：优先看 VAR_INPUT/VAR_OUTPUT、CASE eState OF、超时定时器、TCP 三个子方法调用。你会看到所有报文方法最终都是被主状态机统一调度的。