QT与VS2019下三菱PLC通讯实现：MC协议3E帧解析与工程避坑

简介：面向工业自动化上位机开发的Qt与三菱PLC通讯实例资源，基于MX Component组件，在QT 5.12.9、VS2019与MX Component S4.19环境下完成通讯功能，实现上位机与三菱PLC的数据交互。程序可提示通讯是否成功，并正确显示当前PLC型号，适合需要快速搭建PLC通讯界面或进行C++二次开发的工程师参考，也可用于设备监控、产线数据采集等场景。资源包共70个文件，压缩后体积47.52MB，以cpp/h源代码、Qt界面文件（ui、qrc）、VS工程配置（vcxproj、sln、filters）和编译中间产物（obj、tlog、pdb、log）为主，同时附有可直接运行的exe，便于直接验证或继续修改；压缩包为RAR格式，源码、配置与输出文件分区存放，便于按模块查阅。目前已有2091人浏览学习。工程结构包含QtWidgetsApplication2完整项目，并通过MELSEC类型库封装实现寄存器读写调用，可帮助读者理清从MX Component配置、界面绘制到函数调用的实现路径，是进行PLC通讯排错与功能扩展的实用参考。

1. 三菱PLC通讯不是 write 一串字节那么简单

把一个Socket连上、write 一串帧、readAll 收回来——这是很多 QT+VS2019 接触三菱PLC通讯的新手最常见的错觉。真实场景里，D寄存器读出来是错的、偶发超时、连上没反应，大多不是 socket 的问题，而是 MC 协议帧结构、长度字段和字节序的问题。这篇想说的就是：用 QT + VS2019 实现与三菱PLC的通讯，核心不是“能不能发出去”，而是“帧怎么构造、响应怎么切、坑在哪里”。适合正在写设备数据看板、电气调试工具或 MES 采集程序的人。跟着走一遍，能拿到一个可运行的最小通讯类，也能避开那些看抓包才能发现的鬼问题。

2. VS2019 + QT 环境搭建：装对 Qt 组件比写代码更省时间

这套组合在工控上位机里很常见：VS2019 负责 C++ 工程和调试习惯，QT 负责界面、网络和串口 API。选型理由也简单——很多老产线技术栈就是 Visual Studio，QT 则给上位机一个跨平台的后路，哪天要把采集端换到 Linux 工控机上，界面和通讯代码能平移一大半。

但环境搭建的头号翻车点不是代码，而是 Qt 安装时选错了编译器组件。VS2019 默认用 MSVC 2019 编译，Qt 安装包里对应的是msvc2019_64组件。如果图省事选了 MinGW 版本，后面在 VS2019 里链接时就是一堆 “无法解析的外部符号”，而且错误信息指向的库文件让你根本猜不到是组件装错了。

2.1 版本匹配：装对组件是后面所有工作的前提

进入 Qt 安装器选择组件时，重点看三块：编译器组件、模块、版本。编译器组件选MSVC 2019 64-bit，这个选项在不同 Qt 版本里名字略有差异，Qt 5.15 系列叫msvc2019_64，Qt 6 系列直接叫MSVC 2019 64-bit。模块方面，Widgets、Network 是必须的，如果计划走串口通道（FX 系列 PLC 常用），还要勾选 SerialPort 模块。

我一般会顺手把 Qt 源码也装上，方便调试时直接跳进 QTcpSocket 和 QSerialPort 内部看行为。这不算必须，但遇到“为什么收不到 readyRead”这种问题时，能少很多猜谜时间。

版本选择上，工控项目优先选 LTS 版本。Qt 5.15 和 Qt 6.x 对本文的通讯代码影响很小，核心类 QSerialPort、QTcpSocket 的 API 基本一致。如果你手头有旧项目依赖 Qt 5 的 QNetworkAccessManager、QRegExp 这类老 API，就直接用 5.15，不折腾。

2.2 VS2019 里创建最小 QT 工程：从扩展安装到空窗口

常见做法是先给 VS2019 装 Qt VS Tools 扩展，然后在扩展菜单里配置 Qt 版本路径，让它指向qmake.exe所在目录。配置好以后新建项目时能找到 “Qt Widgets Application” 模板。

具体步骤拆开是这样：

1. VS2019 菜单栏选“扩展 → 管理扩展”，在线搜索 Qt Visual Studio Tools，安装后重启。
2. 打开“扩展 → Qt VS Tools → Qt Versions”，添加你刚装的 Qt 路径，路径要定位到msvc2019_64组件目录，比如C:\Qt\5.15.2\msvc2019_64，VS C++ 编译器自动识别。
3. 新建项目，选“Qt Widgets Application”，生成后确认.pro文件里包含QT += core gui widgets network serialport。
4. 解决方案平台切到 x64，直接编译运行，看到空窗口说明环境通。

这里有个习惯值得养成：新建工程后先加一行QT += serialport。很多人第一步只写 widgets 和 network，等到写串口代码时发现QSerialPort头文件找不到，再回头改.pro，虽然不费事，但容易在排查环境问题上浪费十分钟。

2.3 用 CMake 也能搭：最小 CMakeLists 与路径参数

如果你不想依赖 VS 的 Qt 扩展，CMake 是更干净的备选方案，尤其适合团队里有人用 Qt Creator、有人用 VS2019 的混合环境。最小可用的 CMakeLists.txt 长这样：

cmake_minimum_required(VERSION 3.16) project(PlcReader) set(CMAKE_CXX_STANDARD 17) # 改成你本机 Qt msvc2019_64 的安装路径 set(CMAKE_PREFIX_PATH "C:/Qt/5.15.2/msvc2019_64") find_package(Qt5 COMPONENTS Widgets Network SerialPort REQUIRED) add_executable(PlcReader main.cpp MainWindow.cpp ) target_link_libraries(PlcReader PRIVATE Qt5::Widgets Qt5::Network Qt5::SerialPort )

这套配置的关键参数是CMAKE_PREFIX_PATH，它告诉 CMake 去哪找 Qt5Config.cmake。路径写错最常见，而且 CMake 的报错只提示找不到 Qt5，不提示具体哪里错。

VS2019 打开这个目录后，要手动在配置管理器里选 “x64-Release” 或 “x64-Debug”，然后生成。生成成功后，运行 exe 之前要确保 Qt 的 DLL 在路径里，否则会弹 “找不到 qwindows.dll”。解决方式是把msvc2019_64\bin加入系统 PATH 临时环境变量，或者用 Qt 自带的windeployqt.exe把运行库拷到 exe 目录。

2.4 编译通过后还要做的事：windeployqt 与运行库

部署这一步很多新手会忽略。QT 程序不像纯 Win32 程序那样一个 exe 就能跑，它依赖 Qt5Core.dll、Qt5Gui.dll、Qt5Widgets.dll，以及 platforms 目录下的 qwindows.dll 平台插件。发布时最省事的方式是打开“Qt 5.15.2 (MSVC 2019 64-bit)”命令行，进到 exe 所在目录执行：

windeployqt PlcReader.exe

它会自动拷贝 Qt 依赖库、平台插件，以及 VS2019 运行时对应的 VC 运行库。执行完在设备上看，如果仍然提示缺 MSVC 运行库，那就去装vc_redist.x64.exe。注意 Debug 版本依赖 Debug 版 Qt DLL，发布用 Release 版本部署，不要混。

这套环境检查下来，工程本身还没写一行业务代码，但后面所有通讯联调都建立在“编译环境是干净的”这个前提下。环境不对，后面遇到通讯问题时会分不清是代码问题还是库的问题，排查成本直接翻倍。

3. 看懂 MC 协议 3E 帧：报文结构、读 D 寄存器的最小请求与响应解析

三菱PLC的以太网通讯，主流并不是裸 TCP 数据流，而是走 MC 协议。MC 协议有 3E 帧、4E 帧、ASCII 模式和二进制模式之分。实际做上位机，我建议直接学二进制模式的 3E 帧：它结构紧凑、计算量小、抓包时一眼能看到数据内容，而且 Q/L/iQ-R 系列的内置网口和以太网模块基本都支持。

这章解决两个问题：读 D 寄存器的请求帧怎么凑出来，响应帧怎么解析。把这两个函数写对了，读写 M 线圈、X/Y 输入输出、批量读写就只是换子命令和软元件类型码的事。

3.1 帧协议比 socket 更值得花时间

很多教程让人上来就connectToHost然后write("MELSEC")或者随便发一串十六进制，结果 PLC 根本不回。原因就是 MC 协议对帧格式要求严格：帧头、网络号、PC 号、IO 编号、站号、长度、监视定时器、子命令、地址、点数，哪个字段错一位，轻则超时，重则返回错误码 C0 或 0xFFFF。

3E 帧的三层模型是：TCP/IP 是传输层，MC 协议的帧结构是表示层，D 寄存器地址映射是应用层。三层各管各的。TCP 层只保证字节流完整到达，不保证业务数据语义正确；帧结构层负责把业务请求包装成 PLC 认识的格式；地址映射层决定你问的是 D100 还是 D120。

联调时养成一个习惯：先用一个十六进制查看工具把要发送的帧完整列出来，对照帧结构表逐个字节核对，再进代码。这个习惯能省下数小时的试错时间。

3.2 3E 帧请求结构：每个字段的常见取值与含义

以二进制模式读 D 寄存器为例，完整请求帧字段如下：

网络号、PC 号、IO 编号、站号这四个字段在单 PLC 直连场景下基本照抄固定值就行，不用深究含义。需要多 PLC 通讯时，站号字段才会真正用到，那时候以现场 PLC 模块参数为准，否则连不上就是这些字段的问题。

请求数据长度这个字段最容易算错。它的长度是从“CPU 监视定时器”字段开始，到请求帧最后一个字节结束，不包含帧头到长度字段之前的部分。下面的代码里用“先占位、后回填”的方式，就是为了避免手工数长度。

3.3 构造读 D 寄存器的最小请求：一个函数搞定

直接给一个可用的构造函数，输入起始寄存器编号和点数，输出完整的请求帧：

#include <QByteArray> // 构造 MC 协议 3E 帧二进制模式的读字请求 // startNo: D 寄存器编号，比如 D100 就传 100 // count: 要读取的字数 QByteArray buildReadWordRequest(quint16 startNo, quint16 count) { QByteArray req; // 帧头固定 req.append(0x50); req.append(0x00); // 网络号、PC号、IO编号、站号，单机直连按固定值发送 req.append(0x00); req.append(0x00); req.append(0xFF); req.append(0xFF); req.append(0x03); req.append(0xFF); req.append(0x00); req.append(0x00); // 请求数据长度，先占两个字节，稍后回填 int lenPos = req.size(); req.append(0x00); req.append(0x00); // CPU 监视定时器，0x0010 表示 4 秒 req.append(0x00); req.append(0x10); // 子命令 0401：读字 req.append(0x04); req.append(0x01); // 起始地址：两字节编号（小端在前）+ 一字节类型码 req.append(char(startNo & 0xFF)); req.append(char(startNo >> 8)); req.append(0xA8); // 0xA8 是 D 寄存器的软元件类型码 // 点数：两字节小端 req.append(char(count & 0xFF)); req.append(char(count >> 8)); // 回填请求数据长度：从监视定时器字段开始到结尾 quint16 dataLen = req.size() - lenPos - 2; req[lenPos] = char(dataLen >> 8); // 长度字段高位在前 req[lenPos + 1] = char(dataLen & 0xFF); return req; }

代码逻辑分三块：固定头部、地址与点数、长度回填。注意长度字段是三菱风格的“高位在前”，这一点和起始地址的小端格式不一样，写错会直接超时或者收到 0xFFFF。

类型码 0xA8 是 D 寄存器的，换成别的软元件要一起换：M 线圈是 0x90，X 输入是 0x9C，Y 输出是 0x9D，R 文件寄存器是 0xAF。地址编号部分按各自软元件的编号规则填，比如 M100 就传 100，X 输入按八进制编号时需要注意转换。

3.4 响应帧解析：结束码与数据体的完整切分

PLC 响应帧结构和请求对应，前 6 个字段一样，然后是两个字节的响应数据长度、两个字节的结束码，之后才是真正的数据体。结束码 0x0000 表示正常，其他值表示请求有问题，常见的有 0xC105 和 0xC102，前者多半是地址超范围，后者多半是命令不合法。

#include <QVector> #include <QByteArray> // 解析 3E 帧响应，提取 count 个 16 位有符号整数 // 返回 true 表示结束码为 0 且数据长度足够 bool parseReadWordResponse(const QByteArray &resp, quint16 count, QVector<qint16> &out) { if (resp.size() < 14) return false; // 结束码在两字节长度字段之后，高字节在前 quint16 endCode = (quint8(resp[12]) << 8) | quint8(resp[13]); if (endCode != 0x0000) return false; // 校验数据区长度是否足够 if (resp.size() < 14 + count * 2) return false; out.clear(); for (int i = 0; i < count; ++i) { // 数据是大端字节序 quint16 raw = (quint8(resp[14 + i * 2]) << 8) | quint8(resp[15 + i * 2]); out.push_back(static_cast<qint16>(raw)); } return true; }

这里的关键是数据体每个 16 位字都是“高字节在前”。如果把字节直接按主机序 memcpy 到 quint16，读出来的数值会整体交换，这是最常见的“翻车”原因之一。

结束码解析后如果返回 false，不要直接断开连接，先把结束码打印出来。0xC105 十有八九是 D 寄存器编号和点数组合超出了实际范围，比如 D 区一共才 200 个字，你一把读 512 个字，PLC 直接拒绝。

3.5 写寄存器和位软元件的差异：改哪几个字段就行

写字请求和读请求几乎同构，差异只有两点：子命令从 0x0401 换成 0x1401，点数字段后面追加要写入的数据，每字两字节、大端在前。下面是一个最小写请求的构造框架：

// 写 D 寄存器请求，子命令 1401 QByteArray buildWriteWordRequest(quint16 startNo, quint16 count, const QVector<quint16> &values) { QByteArray req; // 前半部分和读请求完全一样，子命令换成 0x14 0x01 // 省略固定头填充，直接到长度字段 int lenPos = req.size(); req.append(0x00); req.append(0x00); // 长度占位 req.append(0x00); req.append(0x10); // 监视定时器 req.append(0x14); req.append(0x01); // 写字命令 req.append(char(startNo & 0xFF)); req.append(char(startNo >> 8)); req.append(0xA8); req.append(char(count & 0xFF)); req.append(char(count >> 8)); for (int i = 0; i < count; ++i) { req.append(char(values[i] >> 8)); req.append(char(values[i] & 0xFF)); } // 长度字段 = 监视定时器 + 命令 + 地址 + 点数 + 数据体 quint16 dataLen = req.size() - lenPos - 2; req[lenPos] = char(dataLen >> 8); req[lenPos + 1] = char(dataLen & 0xFF); return req; }

写命令直接操作现场设备，联调前务必备份 PLC 程序，或者先把写入目标改成临时测试区。批量写比单点写更容易踩地址边界，建议先写一个寄存器验证，再扩大到批量。

4. 通讯类落地：TCP 轮询、串口接入与定时刷新的完整路径

协议层会构造和解析之后，接下来是把这些零散函数封装成一个能长期运行的通讯类。这里我给一个常见做法：一个PLCMitsubishiComm类，内部同时支持 TCP 和串口两种传输方式，对外只暴露connectDevice()、readDWords()、writeDWords()这几个方法。

选择这种设计的原因很实际：现场改需求时，可能今天用网口，明天换成串口给老机型用，传输方式变化不影响上层逻辑。

4.1 通讯类头文件：传输层与协议层分离

类成员包含传输方式枚举、TCP 套接字、串口对象、接收缓冲区和一组配置参数。

#include <QObject> #include <QTcpSocket> #include <QSerialPort> class PLCMitsubishiComm : public QObject { Q_OBJECT public: enum Transport { TCP, Serial }; explicit PLCMitsubishiComm(QObject *parent = nullptr); // 配置 TCP 方式，端口常见 4999 或 6000，以 PLC 模块实际设置为准 void setTcpEndpoint(const QString &ip, quint16 port); // 配置串口方式 void setSerialParams(const QString &portName, qint32 baud = 9600, QSerialPort::DataBits dataBits = QSerialPort::Data8, QSerialPort::Parity parity = QSerialPort::NoParity, QSerialPort::StopBits stopBits = QSerialPort::OneStop); bool connectDevice(); void disconnectDevice(); // 读 D 寄存器，成功返回 true bool readDWords(quint16 startNo, quint16 count, QVector<qint16> &out, int timeoutMs = 1000); private: Transport m_transport = TCP; QString m_ip; quint16 m_port; QString m_portName; qint32 m_baud; QSerialPort::DataBits m_dataBits; QSerialPort::Parity m_parity; QSerialPort::StopBits m_stopBits; QTcpSocket m_tcp; QSerialPort m_ser; QByteArray m_buffer; // 收包缓冲区，用于粘包处理 };

串口参数里，FX 系列老机型常见配置是 9600、8、无校验、1 停止位，但这不是所有型号的默认值。有些 FX3U 的编程口默认是 7 位、偶校验、2 停止位，具体以 PLC 侧通信参数为准。现场最怕的就是两边参数不一致导致收发全乱，而且串口不像 TCP 有什么握手报错，表现出来就是“发出去没响应”。

4.2 以太网连接与最小请求发送：同步等待与超时控制

TCP 方式下，连接、发送、等待响应的完整流程如下：

#include <QThread> bool PLCMitsubishiComm::connectDevice() { if (m_transport == TCP) { if (m_tcp.state() == QAbstractSocket::ConnectedState) return true; m_tcp.connectToHost(m_ip, m_port); return m_tcp.waitForConnected(3000); } m_ser.setPortName(m_portName); m_ser.setBaudRate(m_baud); m_ser.setDataBits(m_dataBits); m_ser.setParity(m_parity); m_ser.setStopBits(m_stopBits); return m_ser.open(QIODevice::ReadWrite); } bool PLCMitsubishiComm::readDWords(quint16 startNo, quint16 count, QVector<qint16> &out, int timeoutMs) { // 连接不存在时先建立连接 if (m_transport == TCP && m_tcp.state() != QAbstractSocket::ConnectedState) { if (!connectDevice()) return false; } QByteArray req = buildReadWordRequest(startNo, count); m_buffer.clear(); if (m_transport == TCP) { m_tcp.write(req); if (!m_tcp.waitForBytesWritten(timeoutMs)) return false; // 等待并累积响应，直到足够一帧或超时 int waited = 0; while (waited < timeoutMs) { if (m_tcp.waitForReadyRead(50)) { m_buffer += m_tcp.readAll(); // 简单判断：至少收到结束码才算开始解析 if (m_buffer.size() >= 14 && m_buffer.size() >= 14 + count * 2) { break; } } waited += 50; } } else { // 串口方式：同样发送后等待 readyRead m_ser.write(req); int waited = 0; while (waited < timeoutMs) { if (m_ser.waitForReadyRead(50)) { m_buffer += m_ser.readAll(); if (m_buffer.size() >= 14 + count * 2) break; } waited += 50; } } return parseReadWordResponse(m_buffer, count, out); }

waitForReadyRead(50)是每 50ms 检查一次，循环直到超时。这种写法是同步阻塞的，好处是逻辑直观，适合定时器驱动的小规模采集；坏处是如果一次要读上千个寄存器，或者 PLC 响应极慢，主线程会被卡住。常见做法是把通讯类放进 QThread，或者改成异步状态机，这部分在最后一章展开。

参数timeoutMs建议 1000ms 起步。3E 帧里的监视定时器设 4 秒，上位机等待时间如果短于 PLC 实际执行时间，就会频繁误报超时。生产环境我一般给 1500ms 到 2000ms，宁可多等一点，也不要让“超时重连”把现场数据搞乱。

4.3 定时轮询：QTimer 驱动，失败不发信号

现场一个典型需求是：每秒刷新一次 D100 到 D119 的 20 个字，显示在表格里。用 QTimer 实现最简单：

#include <QTimer> // 假设 comm 是 PLCMitsubishiComm 实例 auto *timer = new QTimer(&app); QObject::connect(timer, &QTimer::timeout, [&]() { QVector<qint16> values; if (comm.readDWords(100, 20, values, 1500)) { // 更新界面，比如发给 QTableView 或 QLabel emit dataArrived(values); } else { // 失败时界面保留旧值，累计失败次数 failCount++; } }); timer->start(1000); // 每秒触发一次

失败时不发信号，界面就保留了上一次成功的数据，不会闪烁或者变成 0。这个细节对看板类界面很重要，因为它避免把“通讯暂断”误显示成“设备数值归零”。

真正要上产线时，建议用信号槽把数据从通讯对象传到主窗口，而不是在主窗口槽函数里直接调用通讯方法。这样后续把通讯类挪到线程，界面代码不用改。

4.4 串口方式的对照与参数差异

串口方式的帧协议和 TCP 不同，FX 系列老机型走的是专用 ASCII 帧，帧头、软元件号、校验码的规则跟 3E 帧不一样，但传输层处理逻辑几乎一致：打开串口、write 请求、waitForReadyRead 收响应、按帧长度切包。上面readDWords里串口分支已经给出了完整流程，直接把buildReadWordRequest换成 FX 专用帧构造函数即可。

串口联调优先级最高的一件事是确认参数完全一致。PLC 侧参数通常在一个通信设置页里，上位机侧所有参数要与之一一对应，任何一处不匹配都会表现为“没反应”。先用串口调试助手手工发一帧确认 PLC 回复，再交给程序，能少走很多弯路。

5. 三菱PLC通讯联调避坑：粘包、字节序、连接残留的5条血泪经验

协议能跑通之后，真正消耗时间的是那些“偶尔出一次”的诡异现象。下面五条是我在联调中反复踩过的坑，按现象、原因、解决三个层次说清楚。

5.1 TCP 粘包与半包：偶发解析错乱的真凶

现象：第一次请求正常，跑一段时间后某次返回的结束码变成 0xFFFF，或者读出来的数据整体错位。重启程序后又能正常一阵子，像“偶尔犯病”。

原因：TCP 是字节流，一次readAll()里可能包含了两次请求的响应（粘包），也可能只读到半个响应（半包）。直接拿readAll()的结果去解析，长度不对时解析函数返回 false，表面上像超时，实际上帧切错了。

解决：维护一个接收缓冲区，每次readyRead都往里追加数据，然后按帧长度字段判断是否收满一帧，收满就切出来解析，剩余字节留给下一帧。

// 在 readyRead 槽里统一处理粘包 void onReadyRead() { m_buffer += m_tcp.readAll(); while (m_buffer.size() >= 12) { // 响应长度字段在字节偏移 10-11，大端 int dataLen = (quint8(m_buffer[10]) << 8) | quint8(m_buffer[11]); int totalLen = 12 + dataLen; // 12 是帧头到长度之后的固定长度 if (m_buffer.size() < totalLen) { // 半包，等下一批数据 break; } QByteArray frame = m_buffer.left(totalLen); m_buffer.remove(0, totalLen); // 把 frame 交给解析函数 } }

这个坑最常见，也最隐蔽。第一版通讯代码如果不用缓冲累积，十有八九会在不稳定网络下偶发翻车。

5.2 字节序与浮点数：寄存器数值翻倍的玄学现场

现象：读 D 寄存器，无符号整数显示成几万，明明现场值是 0；或者读浮点数时数值大得离谱，像被乘以了一个奇怪的倍数。

原因：MC 协议数据区是“高字节在前”，而 Windows/x86 主机是小端。直接把收到的高字节做低字节、低字节做高字节放进quint16，数值就整体交换了。浮点数更复杂，三菱 PLC 的 32 位浮点存放在相邻两个 D 寄存器里，但字顺序和 Windows 内存布局相反。

解决：整数读取用qFromBigEndian或者像 3.4 节那样手动拼。浮点数需要“字交换”再转：

#include <QtEndian> // 将两个相邻 D 寄存器的值拼成 32 位浮点数 float dWordPairToFloat(quint16 lowWord, quint16 highWord) { // 三菱风格：先交换字顺序，再按 IEEE754 解释 quint32 raw = (quint32(highWord) << 16) | lowWord; float value; memcpy(&value, &raw, sizeof(value)); return value; }

这里的核心提醒是：如果现场是上位机和触摸屏同时读同一批 D 区，触摸屏显示正常而你的程序偏差巨大，先怀疑字交换和字节序，不要再重复排查协议字段。

5.3 重复连接导致 PLC 端连接资源耗尽

现象：程序连续运行几小时没问题，重启上位机几次之后，connectToHost成功但响应全无，PLC 侧连接数打满。

原因：每次请求都新建连接，或者调试时崩溃后旧 socket 没有释放，PLC 以太网模块的连接资源被占满，不再接受新连接。

解决：通讯类里做成长连接，启动时连接一次，整个运行周期复用同一个 QTcpSocket。程序退出时调用disconnectFromHost()，不要直接靠进程结束释放连接。调试时也要留意任务管理器里有没有残留的旧进程还在占着连接资源。

void PLCMitsubishiComm::disconnectDevice() { if (m_transport == TCP) { if (m_tcp.state() == QAbstractSocket::ConnectedState) m_tcp.disconnectFromHost(); } else { m_ser.close(); } }

这个坑在开发机上不容易暴露，因为开发机每次都是重启调试器后自动清理连接；产线设备长期运行时才会发现资源耗尽。

5.4 USB 转串口换口后 COM 号漂移

现象：昨天程序还能打开 COM4，今天插同一个 USB 口变 COM5，程序报打开失败。换了台电脑问题更明显，COM 号全乱。

原因：Windows 按 USB 设备描述符分配 COM 号，插入不同 USB 口会生成新号，旧号留在注册表里不释放。

解决：在设备管理器里为那块 USB 转串口芯片固定 COM 号，操作路径是“端口 → 右击属性 → 端口设置 → 高级 → COM 端口号”。另一个保险做法是程序启动时让操作人员手动选择 COM 口，并把上次成功使用的端口记住，下次启动默认尝试，失败再弹选择框。

5.5 一读就超时，重启上位机就好

现象：第一次编译下载后通讯正常，调试运行几分钟后必超时，重启程序恢复，过一会儿又超时。

原因：调试器每次启动会重建进程，但 PLC 侧旧连接可能还处于半开状态；或者代码里某个分支在请求后没有正常释放 socket，导致同一站号被旧连接占着。

解决：每次启动连接前先主动disconnectFromHost()，清除残留连接；再把重连逻辑加上指数退避，比如第一次失败等 1 秒，第二次等 2 秒，最大 30 秒。不要一失败就立刻重连，高频重连反而会加剧 PLC 侧连接资源问题。

6. 进阶：把通讯从“能通”变成“稳跑”的四个习惯

通讯链路通起来只是起点，真正让现场稳定运行的往往是代码之外的习惯。这里讲四个我在项目里持续受益的做法。

第一个习惯是给每一次收发留底。用 QFile 按天写日志，时间戳加方向加十六进制帧加解析结果。现场出问题时有据可查，而不是靠“重启试试”。日志文件注意控制大小，每次打开追加一行后立即 flush，避免程序崩溃时丢失最近内容。

第二个习惯是超时分级与状态机。不要一次超时就立刻判定设备离线。我的做法是分三档：单次超时只是重发一次；连续三次超时标记节点“疑似离线”；连续十次超时才真正上报故障。恢复时只要成功一次就回到在线状态。这套逻辑能过滤掉绝大多数网络瞬时抖动，避免看板数据误报警。

第三个习惯是把寄存器表配置化。D100 是温度、D120 是压力这类映射，不要在代码里散落十几个魔法数字。常见做法是维护一张配置表，比如用 JSON 描述每路数据的寄存器号和显示名称，程序启动时读取，界面列头和数据绑定全部由配置驱动。改成扩点位时，改配置不动代码，现场维护成本降一大截。

第四个习惯是通讯对象实例化后与界面彻底解耦。一个通讯类实例对应一台 PLC，界面只认信号槽，不直接操作 socket。多台 PLC 时，多个实例挂在同一个调度器里做轮询，每个实例的站号、IP、端口各自独立。将来要拆分线程或改成冗余切换，影响面都在通讯层内。

我现在的习惯是，每个通讯项目先把日志框架和报文构造器写好，再开始谈连设备。没有这两样东西，现场出一堆“偶发问题”，连从哪里入手查都不知道。希望帮到你。

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