企业官网建设流程全解析

简介：本资源是面向工业自动化初学者与QT嵌入式开发者的三菱FX3U系列PLC编程口通信实战项目，聚焦上位机与PLC的串行通信实现，解决QT环境下FINS协议解析、串口参数配置、寄存器读写及通信稳定性保障等核心问题。压缩包共7个文件，含2个核心cpp源码（实现QSerialPort通信逻辑与FINS指令封装）、2个h头文件（定义协议结构与设备接口）、1个ui界面文件（提供串口配置与数据交互可视化控件），另含pro工程配置及user用户设置文件，整体仅12KB，轻量易读，结构清晰便于快速理解通信流程与模块职责。已有1006人学习下载，适合希望掌握PLC底层通信原理、QT串口开发实践及工业协议对接能力的工程师与学生。读者可直接复用通信框架，深入理解波特率/校验位配置、readyRead信号处理、FINS命令构造（如读取D寄存器）及基础错误重试机制，为后续扩展HMI或数据采集系统打下扎实基础。

1. 一个连不上PLC的串口调试器，凭什么被某高校实验室当“通信底座”复用三年？

你手头有台老款三菱FX系列PLC——比如FX1S、FX2N或FX3U，想用PC实时读写D寄存器、M继电器、定时器状态，甚至下发梯形图下载指令。但Windows自带的“设备管理器+超级终端”根本跑不通：发一串HEX过去，PLC没反应；换几个波特率试，COM口灯都不闪；用GX Works2能连，可它不开源、不提供API、没法嵌进你的上位机界面里。这时候，有人甩给你一个叫FX_serial_asst.rar的压缩包，解压后只有4个文件：FXSerialAssist.exe、libserial.dll、config.ini和一份手写的README.txt。它没图标、没安装程序、双击就弹窗——但就是这个“土味工具”，在某高校自动化实验室的三台教学实验台上稳定跑了三年，成了学生做课程设计时默认的串口通信验证桩。它不碰以太网、不搞Modbus TCP，只死磕RS-232物理层+三菱编程口协议（即所谓的“FX系列专用通信协议”，非标准Modbus RTU），把最底层的帧格式、校验算法、超时重试逻辑全写死了。如果你正卡在“PLC串口通信第一步”，它不是万能解药，但绝对是照着文档能跑通的第一块真实砖。

2. 架构拆解：从EXE到DLL，看清楚它怎么把“编程口协议”焊进Windows串口驱动里

这个项目本质是一个轻量级串口协议桥接器：前端是Qt做的图形界面（负责用户输入地址/数据/命令类型），后端是C++封装的串口通信模块（负责组帧、发帧、收帧、校验、重试）。它不依赖任何PLC厂商SDK，所有协议细节来自三菱公开手册《FX系列编程口通信协议说明》（文档号SH-080090），核心逻辑全部硬编码在DLL中。整个结构极简，没有网络层、没有数据库、不存历史数据，纯粹做“请求-响应”透传。

2.1 目录结构与文件职责：4个文件，各司其职

解压后看到的4个文件，不是随意堆放，而是有明确分工：

提示：libserial.dll是本项目真正的技术核心。它没用第三方串口库（如QextSerialPort或libserial），而是直接调用Windows APICreateFile(),SetCommTimeouts(),WriteFile(),ReadFile()，对串口进行底层控制。这意味着它对系统兼容性要求低（Win7~Win11均可用），但也意味着——你改错一个超时参数，整条链路就卡死。

2.2 协议帧结构：为什么发0x54 0x00 0x00 0x00 就能读D0？

三菱FX编程口协议是ASCII+HEX混合帧，不是纯二进制。libserial.dll中最关键的组帧函数，对应的是手册里定义的“读D寄存器”命令（Function Code00）：

// libserial.cpp 中关键片段（伪代码还原） std::vector<BYTE> BuildReadDFrame(int addr, int count) { std::vector<BYTE> frame; // 起始符：STX (0x02) frame.push_back(0x02); // 命令码：READ_D = "00" frame.insert(frame.end(), {'0','0'}); // 地址：D寄存器地址，左补零至4位ASCII，如D0 → "0000", D100 → "0100" char addr_str[5]; sprintf_s(addr_str, "%04d", addr); // 注意：这里addr是十进制数值，不是寄存器编号本身！D100传入100 frame.insert(frame.end(), addr_str, addr_str + 4); // 数据长度：读取个数，左补零至2位，如读1个→"01"，读10个→"10" char len_str[3]; sprintf_s(len_str, "%02d", count); frame.insert(frame.end(), len_str, len_str + 2); // 结束符：ETX (0x03) frame.push_back(0x03); // CRC16校验：从命令码开始，到ETX前一字节，计算CRC16-IBM（多项式0x8005） WORD crc = CalcCRC16(&frame[1], frame.size() - 2); // 跳过STX，不包含ETX // CRC转为4位ASCII大写十六进制，如0x1234 → "1234" char crc_str[5]; sprintf_s(crc_str, "%04X", crc); frame.insert(frame.end(), crc_str, crc_str + 4); return frame; }

这段代码解释了三个玄学点：

• 为什么D100要传100而不是10000？因为协议里D寄存器地址是十进制表示，不是偏移地址。D0=0, D100=100, D1000=1000。
• 为什么地址要补零成4位？协议强制规定地址字段固定4字符，不足补0。发"100"会校验失败。
• CRC为什么从命令码开始算？手册明确定义校验范围：[Command][Addr][Len][ETX]，不包括STX，也不包括CRC自身。

发出去的完整帧（读D0）是：02 30 30 30 30 30 31 03 31 30 33 34（ASCII码），对应字符串"\x02000001\x031034"。如果用串口助手发这个HEX串，PLC真能回数据——这证明协议实现是准确的。

2.3 Qt GUI层如何与DLL交互：不是信号槽，是标准C接口

FXSerialAssist.exe是Qt写的，但和DLL通信不用Qt的QPlugin或QMetaObject，而是最原始的LoadLibrary+GetProcAddress。这是为了确保DLL能被其他语言（如C#或Python）直接调用，也避免Qt版本冲突。

// mainwindow.cpp 中调用DLL的关键代码 typedef int (__stdcall *SEND_CMD_FUNC)(LPCSTR port, DWORD baud, LPCSTR frame, BYTE* resp, DWORD* resp_len, DWORD timeout_ms); HMODULE hDll = LoadLibrary(L"libserial.dll"); if (hDll) { SEND_CMD_FUNC pSend = (SEND_CMD_FUNC) GetProcAddress(hDll, "SendCommand"); if (pSend) { BYTE response[256]; DWORD resp_len = sizeof(response); // 构建frame字符串（如上面BuildReadDFrame返回的ASCII HEX串） std::string frame_str = BuildReadDFrame(0, 1); int ret = pSend("COM3", 9600, frame_str.c_str(), response, &resp_len, 1000); if (ret == 0) { // 成功，response里是PLC返回的ASCII HEX字符串，如"020000000103A1B2" ui->textEditRecv->append(QString::fromLocal8Bit((char*)response)); } } }

注意两点血泪经验：

• DLL导出函数必须用__stdcall调用约定，否则Qt调用时堆栈会乱；
• response缓冲区必须由调用方（EXE）分配并传入，DLL只往里填数据，不负责内存管理——这是C风格DLL的铁律。

3. 运行实操：从零配置COM口到成功读出D0值的完整链路

别急着双击EXE。这个工具对硬件连接和PLC状态极其敏感。我当年在某公司产线调试时，光是连通就花了两天，踩了至少7个坑。下面步骤按真实操作顺序写，每一步都带验证动作。

3.1 硬件准备：一根线，两个开关，三个确认点

线缆：必须是原装FX编程电缆（如SC-09）或严格兼容的USB转RS232适配器（芯片需为FTDI FT232RL或CP2102，Prolific PL2303已普遍失效）。普通CH340转接板大概率失败——因为FX协议对电平翻转时序要求苛刻，CH340驱动在Win10/11下常丢字节。

PLC侧设置（以FX3U为例）：

• 将PLC侧面的“RUN/STOP”拨动开关拨到RUN位置（这是最容易忽略的！STOP状态下PLC不响应编程口命令）；
• 检查PLC前面板“POWER”灯亮，“RUN”灯亮，“ERR”灯不亮（ERR亮=程序错误或电池没电）；
• （可选但推荐）用GX Works2连接一次，确认PLC固件版本≥2.00（旧版可能不支持某些命令）。

PC侧确认：

• 设备管理器中找到对应COM口（如COM4），右键→属性→端口设置→勾选“RTS流控”和“DTR流控”（FX协议需要DTR信号作为握手）；
• 波特率必须设为9600（FX系列编程口默认且唯一支持速率，其他如19200会直接无响应）；
• 数据位=7，停止位=2，校验位=偶校验（E）——这是协议硬性规定，错一个就全盘失败。

验证动作：打开设备管理器，插拔编程电缆，观察COM口号是否变化；用万用表测SC-09电缆DB9端第4脚（DTR）和第7脚（RTS）对地电压，插入瞬间应有+12V跳变（表明PC正确发出握手信号）。

3.2 软件配置：config.ini不是摆设，是救命配置

首次运行FXSerialAssist.exe，它会读取同目录下的config.ini。如果文件不存在，它会创建一个默认的，但默认值大概率不对。必须手动编辑：

[Serial] Port=COM4 BaudRate=9600 DataBits=7 StopBits=2 Parity=E [PLC] TimeoutMs=1000 RetryCount=3

重点说明：

• Port：必须和设备管理器里看到的完全一致，大小写敏感，不能写Com4或com4；
• Parity=E：必须是大写E，小写e会被忽略，导致校验失败；
• TimeoutMs=1000：PLC响应通常在200ms内，设1000ms足够，太短（如100ms）易误判超时；
• RetryCount=3：协议允许重试，但超过3次仍失败，基本可判定物理层有问题。

编辑完保存，再双击EXE。主界面右上角会显示“COM4:9600,E,7,2”，说明配置加载成功。

3.3 发送第一条命令：读D0，看返回是否含“0000”

界面布局极简：

• 左上：下拉框选COM口（已由ini预设）；
• 中上：“寄存器类型”下拉选D（数据寄存器）；
• 中左：“起始地址”填0（D0）；
• 中右：“读取数量”填1；
• 右侧大按钮：“READ”（不是SEND）；
• 下方大文本框：接收区。

点击“READ”，等待1秒。如果一切正常，接收区会刷出类似：

02 00 00 00 01 03 A1 B2

或（如果启用了ASCII显示模式）：

\x02\x00\x00\x00\x01\x03\xa1\xb2

关键验证点：

• 开头02是STX，结尾03是ETX，说明帧结构完整；
• 第2-3字节00是命令码（READ_D），正确；
• 第4-7字节0000是地址D0，正确；
• 第8-9字节01是读1个，正确；
• 最后4字节A1B2是CRC16校验值，需用在线CRC计算器验证（输入000001，多项式0x8005，初始值0x0000，结果应为0xA1B2）。

如果收到02FF00000103XXXX（FF开头），说明PLC返回了错误码：FF代表“命令不可识别”，大概率是地址格式错或PLC未在RUN状态。

4. 避坑指南：那些让开发者凌晨三点还在抓头发的5个真实问题

这个工具小而专，但正因为专，它的报错机制极其原始——没有日志、不弹详细错误框、失败就静默。以下是我在某跨平台系统集成项目中记录的真实踩坑清单，每一条都附带Wireshark抓包验证过的根因。

4.1 现象：点击READ按钮，接收区一直空，10秒后才显示“Timeout”

原因：config.ini中TimeoutMs设为100（百毫秒），但PLC实际响应时间在150~300ms之间。Wireshark抓串口（需用USB转TTL+逻辑分析仪）显示：PC发帧后220ms PLC才回帧，但程序100ms就放弃监听。
解决：将TimeoutMs改为1000，并确认PLC RUN灯常亮。若仍超时，检查USB转接板驱动是否为最新版（尤其FTDI驱动，旧版有100ms硬超时bug）。

4.2 现象：接收区显示02FF00000103XXXX，反复出现

原因：PLC处于STOP状态，或内部程序有严重错误（如除零、数组越界）导致监控程序挂起，无法处理编程口请求。FF是协议定义的“未定义命令”错误码，但FX系列实际用它泛指“PLC忙/不可用”。
解决：先用GX Works2连接PLC，看能否在线监控；若GX Works2也连不上，则重启PLC（断电10秒再上电）；若GX Works2能连，但本工具不行，检查PLC参数设置→PLC系统参数→“编程口通信”是否启用（默认是启用的，但曾有客户误关）。

4.3 现象：发送WRITE_M命令写M100，PLC M100灯亮，但再次READ_M100返回00（未写入）

原因：FX系列M继电器分“普通型”和“保持型”。M0~M499是断电不保持，但WRITE_M命令写入的是当前扫描周期值，PLC下一个扫描周期会根据梯形图逻辑覆盖该值。若梯形图中M100被其他触点复位，它就会立刻变0。
解决：改用WRITE_MH（写保持型M寄存器，M500~M1023），或在梯形图中确保M100有自锁逻辑；更可靠的做法是——用READ_M确认写入后立即读，若读回01则证明写入成功，后续是否变0是逻辑问题，非通信问题。

4.4 现象：同一台PC，换了个USB口，工具就报“Access Denied”

原因：Windows对不同USB控制器（如Intel xHCI vs ASMedia ASM1083）的串口权限管理不同。新USB口对应的COM号（如COM5）被系统标记为“受限设备”，普通用户进程无法打开。
解决：以管理员身份运行FXSerialAssist.exe；或进入设备管理器→对应COM口→属性→端口设置→高级→勾选“使用特殊的PCI中断”，重启后重试。根本解法是统一使用主板原生USB2.0口（非扩展坞）。

4.5 现象：用Python调用libserial.dll的SendCommand，总是返回-1（失败）

原因：Python的ctypes默认传递字符串为c_char_p，但DLL期望的是LPCSTR（即const char*）。如果Python字符串含中文或特殊符号，ctypes会尝试UTF-8编码，而DLL内部按ANSI处理，导致帧内容错乱。
解决：在Python中显式编码为GBK（Windows默认ANSI）：

frame_bytes = frame_str.encode('gbk') # 不是utf-8！ buf = ctypes.create_string_buffer(frame_bytes) ret = send_func(b'COM3', 9600, buf, response_buf, ctypes.byref(resp_len), 1000)

5. 二次开发：把libserial.dll嵌进你的Qt/C#上位机，绕过EXE直接调用

这才是本项目最大的价值——它不是一个“玩具工具”，而是一套经过产线验证的、开箱即用的FX通信协议栈。你不需要重写CRC、不用研究超时重试逻辑，只要把libserial.dll当做一个“通信原子”，焊进你的工程里。下面以Qt和C#为例，给出可直接粘贴的调用模板。

5.1 Qt项目中集成：比调用QSerialPort更简单

假设你正在用Qt Creator开发一个设备监控系统，需要在某个DeviceManager类里添加FX PLC读取功能：

// device_manager.h #include <QLibrary> #include <QByteArray> class DeviceManager { private: QLibrary m_libSerial; typedef int (__stdcall *SEND_FUNC)(LPCSTR, DWORD, LPCSTR, BYTE*, DWORD*, DWORD); SEND_FUNC m_sendCmd; public: bool initSerialLib(); int readDRegister(const QString& port, int addr, int count, QByteArray& data); }; // device_manager.cpp bool DeviceManager::initSerialLib() { m_libSerial.setFileName("libserial.dll"); if (!m_libSerial.load()) { qWarning() << "Failed to load libserial.dll"; return false; } m_sendCmd = (SEND_FUNC)m_libSerial.resolve("SendCommand"); return m_sendCmd != nullptr; } int DeviceManager::readDRegister(const QString& port, int addr, int count, QByteArray& data) { // 复用前面2.2节的BuildReadDFrame逻辑，生成frame_str std::string frame_str = buildReadDFrame(addr, count); // 自己实现此函数 QByteArray response(256, 0); DWORD resp_len = response.size(); int ret = m_sendCmd( port.toLocal8Bit().constData(), // COM3 9600, frame_str.c_str(), (BYTE*)response.data(), &resp_len, 1000 ); if (ret == 0 && resp_len > 0) { data = response.left(resp_len); return 0; // success } return ret; }

关键点：

• QLibrary自动处理DLL生命周期，无需手动FreeLibrary；
• toLocal8Bit()确保字符串编码与DLL期望的ANSI一致；
• response用QByteArray管理内存，安全且Qt友好。

5.2 C#项目中调用：一行DllImport搞定

在.NET Framework或.NET 6+ WinForms/WPF项目中，声明DLL导入极其简洁：

using System; using System.Runtime.InteropServices; using System.Text; public class FXCommunicator { [DllImport("libserial.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi)] private static extern int SendCommand( string port, uint baud, string frame, byte[] response, ref uint responseLength, uint timeoutMs); public static int ReadD(int addr, int count, out string response) { response = ""; byte[] buf = new byte[256]; uint bufLen = (uint)buf.Length; // 构建frame，例如读D0："\x0200000001\x031034" string frame = BuildReadDFrame(addr, count); int ret = SendCommand("COM3", 9600, frame, buf, ref bufLen, 1000); if (ret == 0 && bufLen > 0) { response = Encoding.ASCII.GetString(buf, 0, (int)bufLen); } return ret; } }

注意：CharSet = CharSet.Ansi是关键，它告诉CLR用系统默认ANSI编码（即GBK）传递字符串，避免UTF-16乱码。

5.3 改造libserial.dll：增加新命令的实操路径

项目原文没提扩展性，但libserial.dll的源码结构是开放的。如果你需要新增“读取PLC型号”命令（协议中为01），只需三步：

1. 在DLL头文件中声明新函数：

   // libserial.h extern "C" __declspec(dllexport) int __stdcall ReadPLCModel(LPCSTR port, DWORD baud, char* model, DWORD* model_len, DWORD timeout_ms);

2. 在CPP中实现（复用现有串口句柄和超时逻辑）：

   // libserial.cpp int __stdcall ReadPLCModel(LPCSTR port, DWORD baud, char* model, DWORD* model_len, DWORD timeout_ms) { // 组建命令帧：02 01 0000 0003 XXXX （01=读型号，地址0000，长度0003） std::string frame = "\x020100000003"; WORD crc = CalcCRC16((BYTE*)frame.c_str()+1, frame.length()-2); char crc_str[5]; sprintf_s(crc_str, "%04X", crc); frame += crc_str; // 复用现有Send/Receive逻辑... return SendAndReceive(port, baud, frame.c_str(), (BYTE*)model, model_len, timeout_ms); }

3. 重新编译DLL：用VS2019打开solution.sln（假设存在），配置为Release x64，生成新DLL。旧EXE无需修改，因为新增函数不影响原有导出表。

从那以后我每次接手PLC通信需求，都强制走一遍“用本工具先连通”的流程——哪怕客户说“我们有现成SDK”。因为FX编程口协议就像一个黑匣子，只有看到02...03帧真实进出，才能确信物理层、电气层、协议层全通。它不炫技，但稳；不花哨，但准。希望帮到你。

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