FX系列PLC编程口通信协议解析与Qt串口助手实战

发布时间：2026/11/6 6:08:50
FX系列PLC编程口通信协议解析与Qt串口助手实战

简介：本资源是面向工业自动化初学者与QT嵌入式开发者的三菱FX3U系列PLC编程口通信实践项目，聚焦上位机与PLC的串行通信实现，解决QT环境下FINS协议解析、串口参数配置、寄存器读写及基础错误处理等核心问题。压缩包共7个文件，含2个关键cpp源码（实现QSerialPort通信逻辑与FINS指令封装）、2个h头文件（定义通信结构体与状态枚举）、1个ui界面文件（提供串口配置与数据交互可视化控件），另含pro工程配置及user用户设置文件，整体仅12KB，轻量易读，适合快速导入学习。已有1006人学习下载，资源结构简洁、模块职责明确，读者可直接复用串口初始化、readyRead信号响应、FINS命令组包与应答解析等完整代码片段，并通过实际调试掌握RS-232通信时波特率9600/8N1等关键参数匹配要点及异常重连机制设计思路。

1. 一个连PLC编程口都“认不全”的串口助手：为什么你用普通串口工具调不通FX系列PLC？

某开发者在调试一台刚上电的三菱FX3U PLC时，手握USB转RS232线、打开常规串口调试助手（比如XCOM、SSCOM），发00FF0000指令——没响应；换01FF0000——超时；再换波特率从9600试到38400，RTS/CTS/DTR全手动拉高拉低……最后发现PLC的LED灯根本没亮过。不是线坏了，不是PLC坏了，而是他压根没意识到：FX系列PLC的编程口通信不是标准UART透传，而是一套带校验、有帧头帧尾、严格时序约束的私有协议（俗称“编程口协议”或“FX link protocol”）。FX_serial_asst.rar就是专为这个黑匣子设计的轻量级实操工具：它不依赖GX Works，不打包庞大运行时，用Qt写成单文件可执行程序（含源码），能真正发出去01 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ......这种真实PLC能解析的帧，还能自动加BCC校验、处理ACK/NACK、显示寄存器原始值。它适合两类人：一是刚接触FX系列PLC通信的现场工程师，想绕过GX Works快速验证接线和基础读写；二是嵌入式/上位机开发者，需要一个可调试、可逆向、可嵌入自己Qt项目的协议样板。这不是万能PLC配置工具，但它能让你第一次发出去的指令，就被PLC真正“听懂”。

2. 架构与技术栈：为什么用Qt而不是Python或C#？——一个面向工业现场的轻量级选择

2.1 整体分层设计：从UI到底层协议的四层映射

FX_serial_asst的代码结构非常干净，没有过度抽象，但每一层职责明确。整个项目是单进程、单线程（主线程处理UI+串口事件）、无后台服务的桌面应用，符合工业现场对“开箱即用、不装依赖、不占资源”的硬性要求。其分层逻辑如下：

  • UI层（Qt Widgets）：主窗口MainWindow+ 串口配置面板 + 寄存器操作区 + 命令历史列表。所有控件均使用QComboBox、QLineEdit、QPushButton等原生部件，无第三方UI库。
  • 控制层（Controller）：SerialPortManager类封装全部串口操作（打开/关闭/设置参数/读写），并提供信号槽机制通知UI状态变更（如“已连接”“接收超时”）。
  • 协议层（Protocol Core）：FxProtocol类是核心，负责将用户输入的“读D100”“写M20 ON”等语义，转换为符合FX编程口规范的二进制帧，并完成BCC校验、帧头（05）、帧尾（03）、重传逻辑（默认1次）。
  • 数据模型层（Data Model）：RegisterMap结构体数组，静态定义FX系列常用地址空间（X/Y/M/S/D/R等）的起始地址、长度、字节序（FX默认高位在前）、读写权限。不依赖XML或JSON配置文件，全部硬编码在头文件中，启动零加载延迟。

提示：这种“扁平化+硬编码”设计不是偷懒，而是工业场景下的血泪经验——现场PLC型号固定（比如全是FX3U）、寄存器规划早已固化，动态加载配置反而增加出错点和启动时间。你改一个D区地址，编译重跑就行，不用担心配置文件路径错、格式错、权限错。

2.2 Qt版本与编译约束：为什么必须用Qt 5.15.2而非Qt 6？

项目.pro文件明确指定：

QT += core widgets serialport CONFIG += c++17 QT_VERSION = 5.15.2

原因很实际：

  • QSerialPort在Qt 5.15.2中已完全稳定，支持Windows/Linux/macOS全平台，且对RS485半双工模式（需控制DE引脚）有成熟setRequestToSend()接口，而Qt 6初期版本对该接口支持不一致，某次升级后导致某客户现场PLC批量失联。
  • FX编程口协议对时序极其敏感：发送完一帧后，必须在严格≤10ms内拉高RTS（用于RS232转RS485方向控制），否则PLC返回NACK。Qt 5.15.2的QSerialPort::write()是同步阻塞调用，配合QTimer::singleShot(0, ...)可精准控制电平翻转时机；Qt 6的异步写入模型在此类微秒级协同中反而引入不确定性。
  • 所有UI控件（如QComboBox下拉框）在Qt 5.15.2中渲染更“钝感”，不易因频繁刷新导致界面卡顿——这点在老旧工控机（赛扬J1900）上尤为关键。

如果你手头只有Qt 6环境，不要强行升级。我一般会新建一个Qt 5.15.2 Kit（MinGW 7.3或MSVC2019均可），专门编译此类工业小工具。Qt官网仍提供5.15.2离线安装包，下载链接在“Previous Releases”页，搜“qt-opensource-windows-x86-5.15.2.exe”即可。

2.3 串口底层驱动适配：Windows下为何必须用winmm.dll而非CreateFile直驱？

SerialPortManager.cpp中有一段被注释掉的代码：

// Windows only: use winmm for precise timing #ifdef Q_OS_WIN #include <windows.h> #include <mmsystem.h> #pragma comment(lib, "winmm.lib") #endif

并在openPort()中调用：

#ifdef Q_OS_WIN timeBeginPeriod(1); // set timer resolution to 1ms #endif

这是关键玄学点。FX编程口要求主机发送帧后，在精确1.5ms±0.2ms内检测PLC返回的ACK（06）或NACK（15）。Windows默认系统定时器精度为15.6ms，用QTimer或std::this_thread::sleep_for根本无法满足。timeBeginPeriod(1)强制将系统最小计时粒度压到1ms，配合QSerialPort::bytesWritten()信号触发read()，才能稳定捕获PLC响应。实测：未调用timeBeginPeriod(1)时，超时率高达37%；启用后降至0.2%。Linux下无需此操作，select()+termios已足够精准。

3. 核心协议实现：FX编程口帧结构与BCC校验的逐字节拆解

3.1 FX编程口通信帧标准（以读D100为例）

FX系列PLC编程口采用ASCII字符帧（非二进制），但实际传输时需转换为HEX字节流。标准帧结构如下：

字段长度值（HEX）说明
STX1 byte05帧头，固定为ENQ字符
CMD1 byte00命令码：00=读，01=写，02=监控
ADDR_H1 byte00地址高位（D100 →0064→00）
ADDR_L1 byte64地址低位
LEN_H1 byte00读取长度高位（读1个字→0001→00）
LEN_L1 byte01读取长度低位
BCC1 byte??异或校验：05 XOR 00 XOR 00 XOR 64 XOR 00 XOR 01=60
ETX1 byte03帧尾，固定为ETX字符

所以完整发送帧为（HEX）：05 00 00 64 00 01 60 03
对应ASCII字符串："\x05\x00\x00d\x00\x01\x03"（注意：d是0x64`的ASCII字符）

注意：很多开发者误以为FX协议是纯ASCII（如发字符串"RD100"），这是典型误区。它本质是带ASCII外壳的二进制协议——地址、长度、命令码都是二进制值，仅用ASCII字符表示HEX，但传输时必须按字节发送，不能发成字符串"00"（两个字符'0','0'）。

3.2FxProtocol::buildReadFrame()源码逐行解析

QByteArray FxProtocol::buildReadFrame(quint16 addr, quint16 len) { QByteArray frame; frame.reserve(8); // 预分配8字节：STX+CMD+ADDR_H+ADDR_L+LEN_H+LEN_L+BCC+ETX // 1. 帧头 frame.append(0x05); // 2. 命令码：00=读 frame.append(0x00); // 3. 地址高位/低位：addr为D100=100，转为大端序 frame.append(static_cast<char>((addr >> 8) & 0xFF)); frame.append(static_cast<char>(addr & 0xFF)); // 4. 长度高位/低位：len为1，同理 frame.append(static_cast<char>((len >> 8) & 0xFF)); frame.append(static_cast<char>(len & 0xFF)); // 5. BCC校验：从STX开始，异或所有字节（不含BCC自身和ETX） quint8 bcc = 0x05; // STX bcc ^= 0x00; // CMD bcc ^= static_cast<quint8>((addr >> 8) & 0xFF); bcc ^= static_cast<quint8>(addr & 0xFF); bcc ^= static_cast<quint8>((len >> 8) & 0xFF); bcc ^= static_cast<quint8>(len & 0xFF); frame.append(bcc); // 6. 帧尾 frame.append(0x03); return frame; }

关键参数说明：

  • addr：寄存器地址，必须是PLC内部物理地址。例如D100传入100，X000传入0（不是0x000），Y010传入10（Y000=0, Y001=1,...,Y010=10）。FX系列X/Y地址是8进制编号，但协议层统一转为十进制处理，RegisterMap中已做映射。
  • len：读取长度，单位为字（Word），即16位。读D100单个字，len=1；读D100~D103共4个字，len=4。不可填字节数！
  • reserve(8)：避免QByteArray动态扩容导致内存碎片，工业环境追求确定性。

3.3 BCC校验的坑：为什么你的校验总是错？——三个致命细节

  1. 校验范围包含STX，但不包含BCC自身和ETX
    错误做法：bcc = 0x00; for(int i=1;i<frame.size()-1;i++) bcc ^= frame[i];→ 漏了STX（索引0）
    正确做法：显式列出所有参与校验的字节（见上例），或用for(int i=0; i<6; i++)（前6字节固定）。

  2. 地址/长度必须用大端序（Motorola格式）
    D100 = 十进制100 =0x0064→ 高位0x00在前，低位0x64在后。若用小端序（0x64在前），PLC直接返回NACK。

  3. BCC是字节异或，不是字符串异或
    曾有开发者把"05000064..."当字符串算校验，结果'0' XOR '5' XOR '0'...→ 完全错误。BCC永远是对二进制字节运算。

4. 运行与调试：从解压到读出D0值的完整链路

4.1 环境准备：三步确认法（比看文档快10倍）

不要先急着双击exe。按顺序执行以下三步，90%的“打不开”问题当场解决：

  1. 查串口是否存在且权限正确（Windows）：

    • 打开设备管理器 → 端口（COM和LPT）→ 找到你的USB转串口设备（如“Silicon Labs CP210x USB to UART Bridge”）→ 右键属性 → 端口设置 → 高级 → 把“COM端口号”手动设为COM3（避开COM1/COM2等系统保留端口）

    • 提示：某些山寨CH340芯片在Win11下需额外安装VCP驱动，官网搜“CH341SER.ZIP”，解压后设备管理器更新驱动。

  2. 测物理连通性（万用表档）：

    • RS232线：用万用表通断档，测PLC编程口DB9针脚2（RXD）、3（TXD）、5（GND）与USB转接头对应针脚是否导通。重点查GND是否虚焊——这是最常见“有发送无接收”原因。
    • RS485线：测A/B线间电阻应为120Ω（终端电阻），若为∞则断路，若为0则短路。

  3. PLC状态确认：

    • PLC必须处于STOP模式（RUN模式下编程口被禁用）
    • 编程口开关拨到“ON”（FX3U侧面小拨码开关）
    • 电源LED常亮，ERROR LED熄灭

做完这三步，再打开FX_serial_asst.exe，成功率从30%提升到95%。

4.2 首次运行：5分钟内读出D0当前值

  1. 启动程序 → 点击【串口设置】按钮
  2. 在弹窗中：
    • “串口号”选COM3（与设备管理器一致）
    • “波特率”选9600（FX默认，勿改）
    • “数据位”7、“校验位”Even、“停止位”2（这是FX硬性要求，错一个就失败）
    • “流控”选None
  3. 点击【打开串口】→ 底部状态栏显示“串口已打开”
  4. 在主界面“寄存器操作区”：
    • “类型”选D（数据寄存器）
    • “地址”填0（即D0）
    • “长度”填1
    • 点击【读取】
  5. 观察：
    • 左下角“发送帧”显示05 00 00 00 00 01 ?? 03（??为计算出的BCC）
    • “接收帧”几毫秒后显示06（ACK）→ 表示PLC已收到
    • “返回数据”显示00 00（D0当前值为0）或00 0A（D0=10）

注意：如果点击【读取】后“接收帧”长时间为空，不是程序卡死，而是PLC没响应。此时立即按【停止】，检查上述三步，不要反复点击——FX协议有防刷机制，连续3次NACK后会锁死编程口10秒。

4.3 写操作实战：控制M0输出（点亮PLC指示灯）

PLC输出点M0对应物理Y0，要让Y0得电，需向M0写0001（ON）：

  1. “类型”选M（辅助继电器）
  2. “地址”填0（M0）
  3. “长度”填1
  4. “写入值”填1（注意：这里填十进制1，程序内部自动转为2字节00 01）
  5. 点击【写入】

此时PLC的Y0指示灯应立刻亮起。若不亮：

  • 检查PLC输出端子是否接24V电源
  • 用万用表测Y0与COM之间电压是否为24V
  • 在GX Works中确认M0未被其他程序复位

5. 常见问题排查：那些让你怀疑人生却只需改一行代码的坑

5.1 现象：点击【读取】后，“接收帧”始终为空，串口灯不闪

原因：串口参数中“校验位”设成了None或Odd，而FX强制要求Even。PLC收到奇偶校验错误的帧，直接丢弃，不回ACK也不回NACK。
解决：回到【串口设置】，将“校验位”明确选为Even，重新打开串口。

5.2 现象：“接收帧”显示15（NACK），且重复出现

原因：地址超出PLC允许范围。例如在FX1S上读D1000（D区最大只到D999），或在FX3U上读R10000（R区最大为R8191）。PLC固件校验地址越界，返回NACK。
解决：查PLC型号手册，确认目标寄存器是否存在。FX1S/D区：D0-D999；FX3U/D区：D0-D7999；R区统一为R0-R8191。

5.3 现象：能读D区，但读X/Y区返回15

原因：X/Y地址在协议中需转换为十进制，但开发者误用了8进制。例如Y010，8进制是010=十进制8，应填8；若填10（十进制10），则对应Y012，越界。
解决：记住口诀——“X/Y地址去掉前缀，按8进制转10进制”。Y000→0，Y001→1，Y007→7，Y010→8，Y017→15，Y020→16...

5.4 现象：写M0成功，但PLC输出灯不亮；用GX Works监控发现M0为OFF

原因：PLC程序中M0被其他逻辑复位（如RST指令）。FX_serial_asst写入的是PLC的“软元件映像”，但最终输出由扫描周期中的程序逻辑决定。
解决：在GX Works中搜索RST M0，或临时将PLC程序清空（仅保留END），再试写入。

5.5 现象：程序在Win10能用，Win11双击无反应

原因：Win11默认禁用“旧版应用程序兼容模式”，而FX_serial_asst.exe依赖Qt 5.15.2的VC++2015运行库。
解决：右键exe → 属性 → 兼容性 → 勾选“以兼容模式运行这个程序” → 选“Windows 8”；再勾选“以管理员身份运行此程序”。重启生效。

6. 二次开发指南：如何把FX通信模块嵌入你自己的Qt项目

6.1 模块剥离：三文件即走，零依赖移植

FX_serial_asst的协议核心完全解耦，只需提取以下三个文件，即可集成到任意Qt项目：

文件路径作用是否必须
fxprotocol.h/src/protocol/fxprotocol.hFxProtocol类声明，含buildReadFrame()等公有接口✅ 必须
fxprotocol.cpp/src/protocol/fxprotocol.cpp所有帧构造、BCC计算、响应解析逻辑✅ 必须
registermap.h/src/model/registermap.hRegisterMap结构体及FX地址映射表（X/Y/M/S/D/R）⚠️ 可删减，按需保留

提示：registermap.h中定义了kRegisterTypes数组，包含每个寄存器类型的起始地址、长度、字节序。如果你只用D区，可删掉X/Y/M等无关项，减少编译体积。

6.2 接口改造：从“GUI操作”到“API调用”

原项目通过信号槽与UI交互，二次开发需暴露同步API。在fxprotocol.h末尾添加：

// 新增同步读取接口（阻塞调用，适合后台线程） bool readRegisters(QSerialPort *port, RegisterType type, quint16 addr, quint16 len, QByteArray &data, int timeoutMs = 1000); // 新增同步写入接口 bool writeRegisters(QSerialPort *port, RegisterType type, quint16 addr, const QByteArray &data, int timeoutMs = 1000);

对应fxprotocol.cpp中实现（关键逻辑复用原有buildXXXFrame()）：

bool FxProtocol::readRegisters(QSerialPort *port, RegisterType type, quint16 addr, quint16 len, QByteArray &data, int timeoutMs) { // 1. 构造读帧 QByteArray frame = buildReadFrame(addr, len, type); // type用于查registermap获取物理地址偏移 // 2. 发送 if (port->write(frame) != frame.size()) return false; // 3. 等待ACK（06） if (!waitForResponse(port, QByteArray(1, 0x06), timeoutMs)) return false; // 4. 等待数据帧（STX + 数据 + ETX） QByteArray resp = waitForResponse(port, QByteArray(1, 0x03), timeoutMs); // 等ETX if (resp.isEmpty() || resp.at(0) != 0x02) return false; // 数据帧STX=02 // 5. 提取有效数据（跳过STX/ETX，取中间字节） data = resp.mid(1, resp.size()-2); return true; }

调用示例（在你自己的Worker线程中）：

// 假设已创建好QSerialPort *m_port; FxProtocol proto; QByteArray d100Value; if (proto.readRegisters(m_port, kDRegister, 100, 1, d100Value)) { quint16 value = (static_cast<quint8>(d100Value[0]) << 8) | d100Value[1]; qDebug() << "D100 =" << value; }

6.3 性能优化：从“单次读”到“批量轮询”的工程实践

原项目每次操作都开闭串口，工业现场需24小时轮询。我在某产线项目中做了如下改造：

优化点原实现改造后效果
串口生命周期每次读写都open()/close()启动时open()，退出时close()，全程保持连接避免串口反复初始化导致的100ms延迟
轮询策略手动点击启用QTimer，间隔200ms自动读D0-D9、M0-M7CPU占用<1%，实时性达标
异常恢复返回错误即停检测到NACK/超时后，自动发05 02 00 00 00 00 ?? 03（监控命令）重置PLC通信状态连续运行30天无通信中断

关键代码（轮询Timer）：

// 在构造函数中 m_pollTimer = new QTimer(this); connect(m_pollTimer, &QTimer::timeout, this, &MyPlcManager::pollAllRegisters); m_pollTimer->start(200); // 200ms一轮 void MyPlcManager::pollAllRegisters() { static quint16 dAddr = 0; QByteArray data; if (m_proto.readRegisters(m_port, kDRegister, dAddr, 1, data)) { m_dValues[dAddr] = parseWord(data); // 存入缓存 dAddr = (dAddr + 1) % 10; // 轮询D0-D9 } else { // 尝试重置通信 m_proto.sendMonitorCommand(m_port); } }

从那以后我每次接手PLC通信项目，都强制走一遍“三文件剥离+同步API封装+轮询Timer”流程，哪怕只是临时脚本。因为PLC通信不是写Hello World，一次成功的读写背后，是时序、校验、地址映射、异常恢复的整套工程闭环。希望帮到你。

本文还有配套的精品资源，点击获取