三菱FX5U以太网通信实战：MC协议与SLMP帧解析

简介本资源面向工业自动化与上位机开发人员提供一套基于C#与WinForm实现三菱FX5U PLC以太网通信的完整示例工程重点解决3E帧报文构造、连接建立与数据读写等核心问题适用于自动化立体仓库等场景下的上位机开发学习。压缩包共35个文件约79KB以cs源码为主辅以config配置、resx与resources资源、csproj与sln工程文件及exe可执行程序结构完整可直接在Visual Studio中打开运行。目前已有465人学习下载。读者可从中获取3E帧报文封装、网络接口筛选、指令收发与错误重试等关键实现思路并参考WinForm界面与业务逻辑结合方式快速搭建可复用的PLC通信框架减少从零调试通信协议的时间成本。1. 三菱FX5U上位机以太网通信从一根网线到稳定读写车间里一台 FX5U 已经跑了半年PLC 程序没人动但上位机那边天天喊“读不到数”。到现场一看网线插在 CPU 本体自带的以太网口上上位机用 MC 协议按 Q 系列的地址格式去读 D 区结果全是超时。把地址换成 FX5U 的软元件编码、端口确认是 5000 之后数据立刻就上来了。这类问题在 FX5U 上位机以太网通信里非常典型硬件没问题、网络通、ping 也通卡在协议细节和地址映射上。这篇笔记讲的就是三菱 FX5U 通过内置以太网口和上位机做数据交互这件事。它解决的是“上位机怎么稳定读写 FX5U 的 D/M/X/Y 软元件”适合做设备数据采集、产线看板、C#/Qt 上位机开发、以及用 Python 做快速验证的工程师。下面按“协议怎么选 → 报文怎么拼 → 代码怎么写 → 坑在哪 → 怎么验证”的顺序展开每一步都给到能直接抄的参数和命令。2. 先定协议再动手MC 协议、SLMP 与 FX5U 的以太网口2.1 为什么 FX5U 上位机通信优先选 MC 协议而不是 Modbus TCPFX5U 本体自带以太网口支持两种主流上位机通信方式一是三菱自家的 MC 协议也叫 SLMPSeamless Message Protocol二是通过扩展模块或内置功能做 Modbus TCP。很多人一上来就想用 Modbus TCP理由是“通用、库多”但在 FX5U 这个场景里MC 协议才是第一选择。原因很直接。FX5U 的 D、M、X、Y、T、C 这些软元件在 MC 协议里是原生寻址的你写 D100 就是 D100不需要像 Modbus 那样先查一张“软元件到保持寄存器”的映射表。Modbus TCP 在 FX5U 上要么依赖扩展模块要么用内置的 Modbus 功能做映射地址偏移和数据类型转换会额外引入一层心智负担。对于只做数据采集和少量写入的上位机MC 协议报文结构固定、响应快、没有映射歧义。代价是 MC 协议是三菱私有协议你得自己拼二进制报文或者用现成的库。常见做法是 C# 用 HslCommunication、Python 用 pymcprotocol 或自己按 SLMP 帧格式封装。选型上我的建议是如果上位机只跟三菱设备打交道直接上 MC 协议如果现场还有西门子、汇川混在一起再考虑用 Modbus TCP 统一但 FX5U 这边要接受映射带来的额外配置。2.2 FX5U 以太网参数IP、端口和二进制/ASCII 的选择动手前先把 FX5U 侧的网络参数确认清楚。用 GX Works3 打开工程在“模块参数 → 以太网端口设置”里看这几项参数典型值说明IP 地址192.168.1.10与上位机同网段避免跨网段子网掩码255.255.255.0常规默认网关按现场同网段通信可不填通信数据代码二进制强烈建议报文更短端口号5000MC 协议常用可改但要一致打开方式MC 协议对应 SLMP这里有两个容易翻车的点。第一是“通信数据代码”如果设成 ASCII报文里所有数值都是 ASCII 字符长度翻倍解析逻辑完全不同新手经常拿二进制示例去连 ASCII 端口怎么都对不上。第二是端口号FX5U 默认 MC 协议端口常见是 5000但有些工程被改成 5001 或别的值上位机不改就一直连不上。确认完这些再确认上位机 IP 和 FX5U 在同一网段用ping 192.168.1.10先通一下。2.3 最小连通性验证先 ping 再 telnet 端口不要一上来就写代码。先用系统自带工具确认网络层和传输层都通# 1. 确认网络可达 ping 192.168.1.10 # 2. 确认 MC 协议端口开放Windows 可用 Test-NetConnection # PowerShell: Test-NetConnection 192.168.1.10 -Port 5000 # Linux/macOS: nc -vz 192.168.1.10 5000ping通只说明 IP 层没问题不代表 5000 端口在监听。Test-NetConnection或nc返回成功才说明 FX5U 的 MC 协议服务已经起来。如果端口不通回到 GX Works3 检查以太网端口设置是否下载进 PLC、PLC 是否处于 RUN 状态、有没有别的设备占用了这个端口。这一步花两分钟能省掉后面半小时的“代码明明没错”的自我怀疑。3. 把报文拼对SLMP 帧结构、软元件编码与批量读取3.1 SLMP 二进制帧的组成从副头部到结束代码MC 协议SLMP的二进制请求帧结构是固定的以 3E 帧QnA 兼容 3E为例一次批量读 D 区的请求大致长这样字段长度典型值含义副头部2 字节0x50 0x003E 帧固定网络号1 字节0x00站内PLC 号1 字节0xFF固定请求目标模块 IO2 字节0xFF 0x03上位机访问请求目标模块站号1 字节0x00站内请求数据长度2 字节变长后续字节数监视定时器2 字节0x0010单位 250ms指令2 字节0x0401批量读子指令2 字节0x0000字单位首软元件编号3 字节变长小端软元件代码1 字节0xA8D 区软元件点数2 字节变长读取个数响应帧在请求基础上把“指令/子指令”之后换成“结束代码 数据”。结束代码 0x0000 表示成功非零就是出错比如 0xC059 是软元件指定错误0xC056 是点数超限。理解这张表你就能看懂任何一份 SLMP 抓包也能在库不好用的时候自己拼。3.2 FX5U 软元件代码对照D/M/X/Y 分别对应哪个字节FX5U 的软元件代码和 Q 系列基本一致但地址范围不同。常用对照如下软元件代码说明读写D0xA8数据寄存器16 位读写M0x90内部继电器位读写X0x9C输入位只读Y0x9D输出位读写T0xC2定时器当前值读C0xC5计数器当前值读位软元件M/X/Y按位读时子指令用 0x0001返回的是按位打包的数据按字读时用 0x0000一次读 16 位。新手最容易错的是把 X/Y 当成字来读结果数据错位。另一个坑是软元件编号的字节序SLMP 里首软元件编号是 3 字节小端比如 D100 要写成0x64 0x00 0x00不是0x00 0x00 0x64。3.3 用 Python 跑通一次批量读 D 区先用脚本验证协议比直接上 C# 工程快得多。装pymcprotocolpip install pymcprotocol然后写最小读取脚本import pymcprotocol # 参数说明 # type3e 对应 SLMP 3E 帧FX5U 内置以太网口常用 # host/port 必须与 GX Works3 里的以太网设置一致 plc pymcprotocol.Type3E() plc.connect(192.168.1.10, 5000) # 批量读 D100 开始的 10 个字 # 返回是一个列表每个元素是 0~65535 的整数 values plc.batchread_wordunits(headdeviceD100, readsize10) print(values) # 批量读 M0 开始的 16 个位 bits plc.batchread_bitunits(headdeviceM0, readsize16) print(bits) plc.close()逻辑说明Type3E封装的就是 3E 帧batchread_wordunits对应子指令 0x0000batchread_bitunits对应 0x0001。headdevice直接写D100、M0这种软元件名库内部会转成软元件代码和 3 字节编号。参数上readsize不要超过 FX5U 单次允许的点数字单位一般一次别超过 960 个位单位别超过 7168 个超了会返回 0xC056。如果连接报错先看 IP/端口再看type是不是选错有的老设备用 1E 帧。3.4 写入 D 区和 M 点子指令与数据格式写入和读取结构类似指令换成 0x1401批量写。用同一个库import pymcprotocol plc pymcprotocol.Type3E() plc.connect(192.168.1.10, 5000) # 写 D200 开始的 3 个字值必须在 0~65535 plc.batchwrite_wordunits(headdeviceD200, values[1234, 5678, 90]) # 写 M10 开始的 4 个位值用 0/1 plc.batchwrite_bitunits(headdeviceM10, values[1, 0, 1, 1]) plc.close()写入时要注意数据范围字单位是 16 位无符号写负数要先转成补码比如 -1 写成 65535。位单位只接受 0 和 1。如果写入后 PLC 里没变化先确认这些软元件没有被 PLC 程序里的其他逻辑覆盖尤其是 M 点经常被程序当中间变量反复刷新。D 区如果被用作系统区域或掉电保持区也要确认写入权限。4. 上位机工程化C# 与 Qt 的通信封装和线程处理4.1 C# 上位机用 HslCommunication 连接 FX5UC# 上位机开发是热词里出现频率很高的方向现场也确实是 C# 居多。用 HslCommunication 连 FX5U 的 MC 协议using HslCommunication; using HslCommunication.Profinet.Melsec; // 参数说明 // ip/port 与 PLC 以太网设置一致 // 构造函数最后一个参数指定数据格式二进制用 DataFormat.Binary var plc new MelsecMcNet(192.168.1.10, 5000); plc.ConnectTimeOut 3000; // 连接超时毫秒 plc.ReceiveTimeOut 3000; // 接收超时毫秒 OperateResult connect plc.Connect(); if (!connect.IsSuccess) { Console.WriteLine(连接失败: connect.Message); return; } // 读 D100 开始 10 个字 OperateResultshort[] read plc.ReadInt16(D100, 10); if (read.IsSuccess) { foreach (var v in read.Content) Console.WriteLine(v); } // 写 D200 plc.Write(D200, new short[] { 1234, 5678 }); plc.ConnectClose();逻辑说明MelsecMcNet默认走 3E 帧二进制ReadInt16按有符号 16 位读如果数据是无符号的用ReadUInt16。ConnectTimeOut和ReceiveTimeOut一定要设默认值偏长网络抖动时界面会卡死。参数上ReadInt16(D100, 10)的第二个参数是点数不是结束地址。写入时Write会自动判断软元件类型D 区按字写M 区按位写。4.2 Qt 上位机通信把 MC 协议读写放到独立线程Qt 上位机通信的典型问题是把 socket 读写放在 UI 线程网络一慢界面就假死。正确做法是把通信封装成一个 QObjectmoveToThread 到工作线程// 通信类头文件片段 class PlcWorker : public QObject { Q_OBJECT public slots: void doConnect(const QString ip, quint16 port); void doReadD(int start, int count); signals: void connected(); void dValuesReady(QVectorquint16 values); void errorOccurred(QString msg); private: QTcpSocket *socket nullptr; };// 连接与读取实现片段 void PlcWorker::doConnect(const QString ip, quint16 port) { socket new QTcpSocket(this); connect(socket, QTcpSocket::connected, this, PlcWorker::connected); connect(socket, QTcpSocket::errorOccurred, this, [this](QAbstractSocket::SocketError){ emit errorOccurred(socket-errorString()); }); socket-connectToHost(ip, port); // 连接超时用 QTimer 单独控制避免阻塞 } void PlcWorker::doReadD(int start, int count) { if (!socket || socket-state() ! QAbstractSocket::ConnectedState) { emit errorOccurred(未连接); return; } QByteArray req buildSlmpReadD(start, count); // 按 3.1 帧结构拼 socket-write(req); socket-waitForReadyRead(3000); QByteArray resp socket-readAll(); QVectorquint16 vals parseSlmpWordResponse(resp); emit dValuesReady(vals); }逻辑说明buildSlmpReadD和parseSlmpWordResponse需要自己按 SLMP 帧结构实现或者引入第三方库。关键点是 socket 的waitForReadyRead只在工作线程里调用UI 线程通过信号槽拿结果。参数上waitForReadyRead的超时要和 PLC 的监视定时器匹配PLC 侧设 4 秒0x0010 × 250ms上位机侧给 3 秒比较稳。如果现场网络质量差把超时放大到 5 秒同时加断线重连。4.3 轮询周期与批量策略别一个点一个请求上位机采集最常见的性能问题是“一个变量发一次请求”。FX5U 的 MC 协议单次请求有开销100 个 D 点如果分 100 次读周期会拉到几百毫秒甚至更久。正确做法是按连续地址批量读把要采集的 D 点按地址排序合并成连续区间比如 D100~D199 一次读 100 个。不连续的区间分开请求但尽量控制在 3~5 个请求以内。轮询周期根据工艺定一般 100~500ms太快没意义PLC 扫描周期本身也有延迟。位软元件和字软元件分开批量读不要混在一个请求里。如果上位机还要显示波形热词里有人问“有没有什么能给上位机显示波形好用点的库”C# 可以用 ScottPlot、Qt 可以用 QCustomPlot数据源就是批量读回来的数组不要在绘图库里直接发通信请求。5. 避坑与排查FX5U 以太网通信最常见的 5 个翻车点5.1 现象ping 通但连接超时原因FX5U 的以太网端口设置没下载进 PLC或者端口号不是 5000或者 PLC 处于 STOP 状态。还有一种情况是上位机用了 1E 帧去连只支持 3E 的端口。解决GX Works3 里重新确认“以太网端口设置”下载后断电重启一次用Test-NetConnection确认端口把帧类型统一成 3E 二进制。5.2 现象读回来的数据全是 0 或明显错位原因软元件代码写错比如把 D 区代码 0xA8 写成 0xA9或者首软元件编号字节序搞反或者位/字单位用错。解决对照 3.2 的软元件代码表逐项核对用抓包工具看请求帧的软元件代码和编号位软元件确认子指令是 0x0001。5.3 现象写入成功但 PLC 里值马上变回去原因该软元件被 PLC 程序里的逻辑覆盖M 点尤其常见或者写的是掉电保持区PLC 上电时被初始值覆盖。解决在 GX Works3 里监控该软元件看是不是被其他指令驱动换一个没被程序占用的 D 区做测试确认掉电保持范围。5.4 现象运行一段时间后连接断开重连才能恢复原因FX5U 的 MC 协议连接有超时机制上位机长时间不发请求或请求间隔过大PLC 侧会主动断开也可能是网络交换机或网线质量导致丢包。解决上位机加心跳每隔几秒发一次读请求加断线重连逻辑检测到 socket 断开后自动重连换屏蔽网线避开变频器干扰。5.5 现象批量读点数多时报 0xC056原因单次请求点数超过 FX5U 允许上限字单位一般 960 点、位单位 7168 点。解决把大区间拆成多次请求每次控制在 500 点以内更稳或者优化采集点表只读需要的地址。6. 进阶验证用抓包和压力测试确认通信真的稳协议调通只是第一步现场要的是“连续跑一周不出问题”。我一般会做两件事抓包和压力测试。抓包用 Wireshark过滤tcp.port 5000看请求和响应的时序。重点看三件事一是响应时间是否稳定正常应该在几毫秒到几十毫秒二是结束代码是否始终为 0x0000三是有没有 TCP 重传。如果看到大量重传说明网络链路有问题先换网线或交换机别急着改代码。压力测试写一个循环脚本按实际轮询周期连续读写 24 小时import time import pymcprotocol plc pymcprotocol.Type3E() plc.connect(192.168.1.10, 5000) fail 0 start time.time() while time.time() - start 86400: # 跑 24 小时 try: vals plc.batchread_wordunits(headdeviceD100, readsize100) plc.batchwrite_wordunits(headdeviceD300, values[int(time.time()) % 65535]) except Exception as e: fail 1 print(异常:, e) try: plc.close() plc.connect(192.168.1.10, 5000) except Exception: pass time.sleep(0.2) # 200ms 轮询 print(总失败次数:, fail) plc.close()参数说明readsize100模拟实际采集规模sleep(0.2)对应 200ms 轮询周期fail统计异常次数。跑完之后看失败次数如果是个位数且都能重连恢复说明通信基本稳定如果失败频繁回到第 5 章逐条排查。这个脚本我一般会在项目上线前跑一遍比在界面上点一天靠谱得多。最后说个习惯每次改完 PLC 以太网参数我一定会在上位机侧重新抓一次包确认帧结构和端口都对得上再继续。血泪经验是很多“代码 bug”其实是 PLC 侧参数被人改过。希望帮到你。本文还有配套的精品资源点击获取