FX PLC编程口调试助手：Qt串口组帧校验与批量轮询

简介面向Qt上位机与三菱FX3U PLC编程口通信学习的示例工程适合工业自动化方向的上位机开发者、PLC初学者及需要理解串行通信流程的工程人员参考。压缩包共7个文件约12KB以cpp、h源码为主另有ui界面与pro工程配置便于导入Qt Creator查看工程组织。已有1004人学习下载说明其在PLC编程口通信入门场景中具有一定参考价值。源码围绕QSerialPort串口参数配置、数据收发及readyRead信号处理展开并涉及FX系列FINS指令解析、通信失败重试与数据包格式设计等环节。读者可借此梳理Qt与FX3U PLC建立连接、发送读写请求、处理返回数据的完整思路理解串口通信协议分层与异常处理方式为开发远程监控、程序下载或数据采集类上位机应用打下基础。1. 现场只有一只编程口这台 FX 到底在跑什么数电柜里那台 FX 系列 PLC编程口被触摸屏占着想插上去看一眼 D100 到底存了什么、M20 有没有置位得先把屏的线拔了。手里只有通用串口助手它不会替你拼软元件地址不会算累加和校验回上来一串十六进制还得自己一位一位数——这种时候最想要的是一个“知道 FX 编程口长什么样”的工具。FX_serial_asst 就是干这个的Qt 写的编程口调试助手选好串口填软元件地址读 D/M/X/Y/T/C、写单点、连续地址批量轮询、原始报文十六进制上屏。适合三类人现场维护要临时查值的、上位机刚入门想搞懂这套帧格式的、准备自己写采集网关拿它当参照系的。后面按“它由什么组成 → 一帧怎么拼 → 收发怎么跑 → 哪里会翻车 → 怎么改成自己的东西”的顺序拆边看边能对着代码改。2. 技术选型与目录结构Qt QSerialPort 撑起的调试器骨架2.1 目录结构与模块分层这类小工具最容易写成一个大 MainWindow 文件几千行改一处牵全身。这个项目的目录分得比较克制四层界面、协议、传输、数据模型互不越界。传输层不知道 FX 协议长什么样只负责“把一串字节发出去、把回来的字节攒齐”协议层只管拼帧解帧碰不到 QSerialPort界面层连字节都不碰只认结构体。FX_serial_asst/ ├── FX_serial_asst.pro # qmake 工程也能用 CMakeLists 等价替换 ├── main.cpp # 组装UI 线程 串口线程 ├── ui/ │ ├── mainwindow.h/.cpp # 主窗口串口配置、寄存器表、日志区 │ └── mainwindow.ui ├── protocol/ │ ├── fxprotocol.h/.cpp # 组帧、校验、解帧、软元件地址换算 │ └── fxdevice.h # 软元件描述表位/字、进制 ├── transport/ │ ├── serialworker.h/.cpp # 住在子线程负责 open/write/read/超时 │ └── requestqueue.h # 请求排队一帧一发 ├── model/ │ └── registertable.h/.cpp # 地址-值-类型供 QTableWidget 取数 └── log/ └── framelog.h/.cpp # 报文日志带时间戳和方向标记值得说的是model这一层单独抽出来的理由。寄存器表既被轮询模块写、又被表格控件读还可能是将来导出 CSV 的数据源放在窗口类里以后想做后台采集就得复制一遍。抽出来之后改成无界面的采集进程只要把ui/整个删掉protocol transport model照样编译。这个切分是我在类似项目里被返工逼出来的习惯——先想清楚“哪部分将来要脱离界面活着”再决定文件怎么放。2.2 Qt 侧技术栈与线程模型选 Qt 不是为了跨平台主要是三件事QSerialPort 把 Windows 和 Linux 的串口差异抹平了QTableWidget 拿来就是寄存器监视表省掉自己画windeployqt 打包完拷到现场电脑上双击就能跑不用装运行时。这对设备调试场景很重要你不能要求产线那台 Win7 一体机装一堆东西。层面选型说明语言/标准C11够用现场老编译器也能过框架Qt 5.15 / Qt 6.xQSerialPort 在 Qt6 里是独立模块.pro 要加 serialport串口QSerialPort QSerialPortInfo枚举端口、事件驱动收数并发QThread moveToThread串口对象只在子线程里创建和销毁定时QTimer子线程内轮询周期、超时重发配置QSettings串口参数、上次的地址列表线程模型是最容易做错的地方。新手常见写法是把QSerialPort在主线程 new 出来然后waitForReadyRead()死等界面直接白掉。这里的做法是 worker 对象moveToThread串口所有操作都在子线程的槽函数里发生主线程只发信号。// main.cpp串口对象在子线程里生、在子线程里死 QThread *serialThread new QThread(this); SerialWorker *worker new SerialWorker; // 构造函数里不 new QSerialPort worker-moveToThread(serialThread); // 跨线程传自定义结构体必须先注册否则信号槽排队时会静默丢包 qRegisterMetaTypeRequest(Request); qRegisterMetaTypeQByteArray(QByteArray); connect(serialThread, QThread::finished, worker, QObject::deleteLater); connect(this, MainWindow::openPortRequested, worker, SerialWorker::openPort); connect(worker, SerialWorker::frameReady, this, MainWindow::onFrameReady); serialThread-start();要点在moveToThread之前不能给 worker 传任何带父对象的指针QSerialPort必须在openPort()这个槽里才new父子关系挂在 worker 上。qRegisterMetaType那两行如果漏了编译期毫无提示运行期信号发出去对方收不到查起来能耗掉一下午——这是 Qt 跨线程最经典的隐蔽问题。另外deleteLater要接在QThread::finished上窗口关闭时先quit()再wait()顺序反了会崩在退出那一刻。2.3 串口参数为什么是 9600-7-E-1编程口这套协议帧里全是 ASCII 字符STX、命令字、地址、数值、校验都是可打印字符加两个控制字符最高位永远是 0所以 7 位数据位足够多出来那一位拿去做偶校验抗现场干扰。常见配置就是 9600 波特、7 数据位、偶校验、1 停止位。有些 USB 转 422 的转换器芯片根本不支持 7 位数据位设了也按 8 位发这时候退成 9600-8-E-1 通常也能通因为第 8 位是 0但反过来如果 PLC 侧配的是 8 位、你按 7 位发收到的字符最高位会被截掉症状是偶发校验错而不是全错很难判断。bool SerialWorker::openPort(const QString name, int baud, int dataBits, int parity) { if (m_port) { m_port-close(); delete m_port; m_port nullptr; } m_port new QSerialPort(this); m_port-setPortName(name); m_port-setBaudRate(baud); // 9600 m_port-setDataBits(static_castQSerialPort::DataBits(dataBits)); // 7 或 8 m_port-setParity(static_castQSerialPort::Parity(parity)); // Even m_port-setStopBits(QSerialPort::OneStop); m_port-setFlowControl(QSerialPort::NoFlowControl); // 422 不需要软硬流控 m_port-setReadBufferSize(4096); if (!m_port-open(QIODevice::ReadWrite)) { emit portError(m_port-errorString()); // 被占用、驱动没装都走这里 return false; } connect(m_port, QSerialPort::readyRead, this, SerialWorker::onReadyRead); return true; }setFlowControl(NoFlowControl)这一行别省某些转换器默认协商 RTS/CTSPLC 侧不接这两根线结果就是发得出去收不回来。open()失败最常见的原因不是参数错而是端口被别的软件占着触摸屏组态软件、另一个串口助手errorString()里会写 PermissionError 或“设备忙”看到这个先查占用别急着重装驱动。至于物理层编程口是 MD8 圆头、4 线差分RXD/RXD-/TXD/TXD-/SG普通 USB-TTL 的 232 电平接上去是收不到的必须用 422 转换器这一点在买线之前就得确认清楚。3. 协议层拆解一帧 FX 编程口报文从拼装到校验的完整链路3.1 帧结构六个字段决定成败把一帧拆开看无非是帧头、命令字、软元件地址、点数、帧尾、校验六段。真正的难点不在结构在每段的表示方式地址是 ASCII 字符串不是二进制点数是两位字符校验是“算出来的一个字节再转成两位十六进制字符”。新手最容易在这上面犯迷糊明明算出 0x66却把 0x66 这一个字节塞进帧里PLC 那边等的是字符6 6两个字节长度对不上直接被丢。字段长度内容说明STX1 字节0x02帧起始命令字1 字符0 读 / 1 写ASCII软元件地址4 字符如D100、X010字母 数字X/Y 用八进制点数2 字符如01、08十进制字符一帧别超 8 点数据区写命令才有每点 4 字符16 位值的十六进制 ASCIIETX1 字节0x03帧结束校验2 字符累加和低 8 位命令字到 ETX 之前逐字节累加举个能对上号的例子读 D100 起 1 点帧体是0D10001逐字节 ASCII 相加 48684948484849 358取低字节 0x66转成字符66。整帧发出去就是02 30 44 31 30 30 30 31 03 36 36。各家实现里命令字后面有时还跟一位固定字符或站号字段顺序也会有小出入所以改协议层的时候对着抓包改常量比对着文档猜快得多——文档版本和固件版本经常对不上。3.2 组帧与校验两个函数撑起协议层协议层的接口设计成“进去是结构体出来是 QByteArray”这样界面层完全不用知道字符编码的事。读和写走同一个入口靠Request::isWrite分流减少调用方判断。// 累加和对 body命令字到 ETX 之前逐字节相加取低 8 位转两位大写十六进制 ASCII QByteArray FxProtocol::calcSum(const QByteArray body) { quint8 sum 0; for (char c : body) sum static_castquint8(c); return QByteArray::number(sum, 16).rightJustified(2, 0).toUpper().toLatin1(); } QByteArray FxProtocol::buildFrame(const Request req) { QByteArray body; body.append(req.isWrite ? 1 : 0); // 命令字 body.append(deviceAddress(req.device, req.addr)); // 软元件地址X/Y 走八进制 body.append(QByteArray::number(req.count).rightJustified(2, 0)); // 点数 if (req.isWrite) { for (quint16 v : req.values) // 每点 4 字符不足补 0 body.append(QByteArray::number(v, 16).rightJustified(4, 0).toUpper()); } QByteArray frame; frame.append(char(0x02)); frame.append(body); frame.append(char(0x03)); frame.append(calcSum(body)); // 校验不含 STX 和 ETX return frame; }rightJustified(4, 0)这两个参数都是有讲究的不补零值 5 会变成5一个字符PLC 按 4 字符切数据区后面的全错位用toUpper()是因为有的固件只认大写十六进制。calcSum里QByteArray::number(sum, 16)返回的是小写同样要转大写否则偶发校验失败——我第一次写这段时就漏了现象是十个字节里错一两个特别像干扰其实是自己算的校验和 PLC 算的不一样。3.3 解帧与响应判定响应帧的骨架跟请求帧一样STX 开头、ETX 结尾、两位校验。区别在帧体读命令回来的是数据区写命令回来的是确认字符。正常响应首字符是0非0就是错误码需要查表翻译成人话地址越界、命令不支持、PLC 忙之类。位软元件和字软元件的解析分支必须分开字软元件每点 4 个字符组成一个 16 位值位软元件按点回 1 个字符。如果抓包发现位数据是打包成字节返回的就说明这批固件的约定不一样把parseBits分支改掉即可别去动组帧逻辑。bool FxProtocol::parseResponse(const QByteArray body, QVectorquint16 out, QString err) { if (body.isEmpty()) { err 空响应; return false; } if (body.at(0) ! 0) { // 0 正常其余是错误码 err QString(PLC 返回错误码: %1).arg(body.at(0)); return false; } const QByteArray data body.mid(1); // 去掉状态字符 if (m_isBitDevice) { for (char c : data) out.append(c 1 ? 1 : 0); } else { for (int i 0; i 4 data.size(); i 4) out.append(data.mid(i, 4).toUShort(nullptr, 16)); } return out.size() m_expectCount; // 数量对不上也算失败交给上层重试 }最后那个数量校验是我后来加的。早期只判return true结果某次线接触不良回来半帧数据表格里后面几行显示 0现场以为寄存器真被清零了白排查两小时。数量对不上就当失败丢给重试逻辑比展示一个假值安全得多。3.4 软元件地址换算X/Y 是八进制这一条必须单独拎出来说。D、M、T、C、S 的编号都是十进制你怎么填就怎么发但 X 和 Y 是八进制编号PLC 面板上写着 X10指的是第 8 个输入点不是第 10 个。地址换算写错读回来的值就整体错位而错位后的值往往还是个合法数值肉眼根本看不出来。// X/Y 输入输出继电器按八进制编号其余按十进制 QByteArray FxProtocol::deviceAddress(const QString dev, quint16 logicalAddr) { const bool octal (dev X || dev Y); const int radix octal ? 8 : 10; return (dev QString::number(logicalAddr, radix).rightJustified(3, 0)).toLatin1(); }界面上用户填的是“第几个点”这种逻辑序号比如第 9 个输入点填 9协议层负责转成X011。这样填表和换算分开改起来不容易乱。反过来如果界面直接让用户填X011这种物理地址那就别再做一次换算两种约定只能选一种混用是错位问题的根源。4. 核心模块实战收发线程、请求队列与批量轮询怎么配合4.1 收数缓冲区切帧而不是一次读完串口是流式的一次readyRead可能给你半帧也可能给你一帧半加一堆噪声。所以收数必须用缓冲区 循环切帧的方式不能假设“读一次就是一帧”。切帧的锚点就是 STX 和 ETX中间那段是帧体ETX 后面两个字符是校验。void SerialWorker::onReadyRead() { m_buf.append(m_port-readAll()); while (true) { const int stx m_buf.indexOf(char(0x02)); if (stx 0) { m_buf.clear(); return; } // 没有帧头全是噪声 if (stx 0) m_buf.remove(0, stx); // 丢掉帧头之前的脏数据 const int etx m_buf.indexOf(char(0x03)); if (etx 0) return; // 帧体没完等下次 readyRead if (m_buf.size() etx 3) return; // 校验两字符还没到齐 const QByteArray body m_buf.mid(1, etx - 1); const QByteArray sum m_buf.mid(etx 1, 2); m_buf.remove(0, etx 3); // 出队处理下一帧 if (FxProtocol::calcSum(body) ! sum) { emit frameError(body, sum); continue; } emit frameReady(body); } }mid(1, etx - 1)这个参数从索引 1跳过 STX开始长度是etx - 1正好是 STX 到 ETX 之间的字节数。m_buf.size() etx 3判断的是校验两位是否到齐少一位就去解析会拿到半个校验值然后误报校验错。缓冲区要设上限比如 8KB超了就清空重来否则现场干扰大时会一直涨。4.2 请求队列一次只发一帧编程口是串行应答的你连发两帧回来的数据黏在一起切帧时第二帧的 STX 可能被当成数据的一部分。稳妥做法是请求排队发一帧、等响应或超时、再发下一帧。写操作和读操作进同一个队列保证写不会被轮询插队打断。void SerialWorker::execNext() { if (m_busy || m_queue.isEmpty()) return; const Request req m_queue.dequeue(); m_pending req; m_busy true; m_retry 0; m_port-write(FxProtocol::buildFrame(req)); m_timeout-start(req.timeoutMs); // 常见 300~500ms点位多适当放宽 } void SerialWorker::onTimeout() { if (m_retry kMaxRetry) { // 3 次不过就放弃别死磕 m_busy false; emit requestFailed(m_pending, 响应超时); execNext(); return; } m_port-write(FxProtocol::buildFrame(m_pending)); // 重发同一帧 m_timeout-start(m_pending.timeoutMs); }超时值不是拍脑袋定的一帧 8 个点的读9600 波特下大约 20~30ms加上 PLC 扫描周期300ms 已经非常宽松。给太短会误判超时给太长会让界面点一下要等一秒才有反应。重试三次是我的习惯值因为连续三次不通基本就是线或者参数问题再重试只是拖时间。4.3 批量合并把 8 次通信压成 1 次轮询一张 32 个 D 寄存器的表如果每个地址单独发一帧一轮就是 32 次往返按每次 30ms 算接近 1 秒界面刷新肉眼可见地卡。做法是把地址排序后合并成连续区间一帧读一段。连续区间内多读几个点比多跑几次通信划算得多。// 输入乱序地址集合输出合并后的 [起始, 点数] 区间单帧点数上限 kMaxPerFrame QVectorQPairquint16, quint16 mergeRanges(QVectorquint16 addrs, int maxPerFrame 8) { std::sort(addrs.begin(), addrs.end()); QVectorQPairquint16, quint16 out; int i 0; while (i addrs.size()) { int j i; while (j 1 addrs.size() addrs[j 1] addrs[j] 1 (j 1 - i 1) maxPerFrame) j; out.append({addrs[i], static_castquint16(j - i 1)}); i j 1; } return out; }maxPerFrame取 8 是个折中帧越长单帧出错重发的代价越大而且部分型号对单帧点数有上限。合并之后要注意回填顺序——返回的数据是按起始地址顺序排的得按原来的地址映射写回寄存器表不能按用户填表顺序。QTimer 的轮询周期一般设 300~500ms别低于 200ms否则队列会堆积界面上看到的是“越刷越慢”。5. 联调避坑编程口通信里最容易翻车的五个现场问题5.1 串口打开成功一个字节都收不到现象open()返回 truewrite()也没报错但readyRead永远不触发日志区干干净净。原因物理链路问题占了九成。编程口是 4 线差分很多人拿 USB-TTL 或者 232 转换器直接怼上去电平不匹配根本收不到也有人只接了 RXD 两根线指望两线半双工能通实际这套是全双工差分接不全就是单向哑巴。还有一种是 MD8 圆头压线的时候引脚顺序记反了TXD 接到 RXD看着整齐实际收发对不上。解决先用回环自测转换器本身——把转换器的 TXD 和 RXD 短接、TXD- 和 RXD- 短接发什么应该原样回什么这一步过不了就别怀疑 PLC。回环通了再查线序用万用表量通断比肉眼数针脚可靠。接好之后第一件事是发一帧最简单的读命令把原始报文打到日志里看到 0x02 0x03 才能谈后面的解析。5.2 能收到数据但校验一直错现象缓冲区里有东西切出来的帧体看着也像模像样就是calcSum对不上十次里错七八次。原因串口参数不匹配。7 位数据位配成 8 位、偶校验配成无校验、波特率偏差都会让字符在传输中被改掉某一位。另外还有一个隐蔽的某些转换器不支持 7 位数据位你设 7 位它按 8 位发帧头帧尾都对中间的数字字符偶尔错——这种情况最像“干扰”其实是参数问题。解决按 9600-8-E-1、9600-7-E-1、9600-8-N-1 的顺序挨个试每次试完看重发的成功率别只看一帧。全都不行再怀疑线长和接地差分线超过几十米又没屏蔽误码率会明显上去。校验错的时候一定要把原始字节和算出来的校验都打到日志里只打印“校验失败”四个字等于什么都没说。5.3 X/Y 读出来的位置整体错位现象读 X0 到 X17 这一段值能读到但跟实际输入指示灯对不上感觉整体平移了几位。原因X 和 Y 按八进制编号逻辑序号第 9 个点对应的是 X11不是 X9。如果代码里直接用十进制转换第 8 个点之后全部错位。更麻烦的是错位后读到的仍然是合法的 0/1界面上完全看不出异常。解决地址换算在协议层统一做界面只填逻辑序号转换函数里对 X/Y 用radix 8。验证方法是找一个确定的输入点——手动按下接在 X10 上的按钮看表格里第 8 行逻辑序号 8有没有变 1变了说明换算对了。5.4 连续写多个寄存器只有第一个生效现象一次写 8 个 D 寄存器PLC 里只有起始那个变了其余保持原值也不报错。原因写命令的数据区长度和点数不匹配。每点固定 4 个字符8 点就是 32 个字符少写一个字符整帧就废了PLC 会按自己的解析规则截断。另一种可能是单帧点数超过了型号允许的上限超出的部分被静默丢弃。解决组帧时用循环拼数据区不要手写发之前把帧长度打出来跟“6 4×点数 3”算一遍对一下。点数超过 8 就拆成多帧帧之间留 20ms 间隔别连着灌。写操作做完一定要回读一次确认只信写命令的应答是不够的。5.5 界面点几下就卡住像死机现象开始轮询后界面失去响应鼠标变成转圈过几秒又活过来反复发作。原因串口读写跑在主线程waitForReadyRead或者同步等待响应把事件循环堵死了。另一种是轮询周期设得太短队列越堆越长主线程一直在处理回来的信号画表格都排不上队。解决串口对象整体搬到子线程主线程只接信号更新表格轮询周期不低于 300ms队列长度设个上限超了丢最旧的请求而不是无限增长。表格更新也别每帧刷一次攒 200ms 批量刷一次肉眼完全看不出差别CPU 占用能降一大截。6. 二次开发把寄存器表改成你自己的采集器想把它从“调试助手”变成“采集器”改动其实集中在三个点软元件描述表、数据出口、运行方式。软元件描述表现在是写死在fxdevice.h里的几个分支改成配置驱动会好用很多加新软元件不用改代码。我一般这么写struct DeviceDesc { QString code; bool isBit; int radix; QString alias; }; // 配置里读出来或者直接写死也行关键是集中在一处 static const QVectorDeviceDesc kDevices { {D, false, 10, 数据寄存器}, {M, true, 10, 内部继电器}, {X, true, 8, 输入继电器}, // 注意八进制 {Y, true, 8, 输出继电器}, {T, false, 10, 定时器当前值}, {C, false, 10, 计数器当前值}, };有了这张表isBit决定解析分支radix决定地址换算界面上的下拉框也能直接由它生成加一个软元件只改一行。加完之后记得拿一个已知值的点位验证别一次加五六个再一起试。数据出口是最容易加的部分。registertable里加个只读快照接口采集侧起一个QTimer每秒取一次写进 SQLite 或者拼成 JSON 发出去界面完全不用动。我习惯把快照做成值拷贝而不是把内部容器指针往外给省得后面多线程访问出问题。输出侧再加一层节流值没变就不发长时间跑下来数据量能小一个数量级。改造点涉及文件大致工作量增加软元件类型protocol/fxdevice.h十几行配置化后更少数据落库或上报model/registertable 新建输出模块半天取决于目标格式去掉界面做后台服务删 ui/改 main.cpp 组装方式半天到一天支持多站号轮询transport/requestqueue 协议层一天以上要看现场拓扑有个技巧值得单独说调协议的时候别拿真 PLC 反复试用虚拟串口对一个写一个读的那种做一个假的 PLC 应答端行为固定、可注入错误故意错一个校验位、故意延迟 5 秒、故意只回半帧比在现场反复插拔线高效得多。这个假端我一般就写两百行收到帧按配置回跑通之后再接真设备出问题能立刻分清是协议写错了还是现场环境的问题。最后一句经验早些年我调这类通信总喜欢先做界面再调协议结果界面改一次协议就得跟着调一次来回折腾。从那以后我每次接新的现场总线都先把原始报文打到日志里、用最小可运行代码把一帧跑通再往上堆界面和功能。现在这个习惯让我省下的时间比任何调试技巧都多。希望帮到你。本文还有配套的精品资源点击获取