上个月在无锡一个锂电项目,R08CPU通过以太网和上位机通信,每天凌晨3点必断一次。GX Works3的监视功能只能看最后100条,根本抓不到“案发现场”。翻遍MELSEC iQ-R Ethernet用户手册,安全注意事项占了20页,但通信日志怎么抓、怎么分析,手册一个字没提。我决定自己写一个Python工具,把每次MC协议通信的原始报文全存下来,然后解析成人类能看懂的关键字段。做完之后,排查效率至少提升3倍——以前花1小时对hex表,现在5分钟出结果。
1. 为什么你需要的不是Wireshark,而是一个MC协议解析器
我遇到的凌晨3点断连问题,最后定位到:上位机发送的“读取字软元件”命令(命令代码0x0401)中,请求数据长度字段的高字节填成了0x01,而PLC要求是0x00(高字节为0表示长度≤255)。Wireshark显示这个报文是“正常TCP包”,没任何报警。只有把MC协议帧拆开,才能发现这个字节错误。
知识点1:MC协议3E帧(二进制模式)的请求数据长度字段是2字节,但只有低字节有效,高字节必须为0。字节序是小端,所以0x0001才是正确的,0x0100会导致PLC返回错误代码C051(“请求数据长度与接收数据长度不一致”)。 2. 工具设计:从“抓包”到“破案”的3步
2.1 数据采集层:先把原始报文存下来
我用了两种方式:
●方式A(通用):用Python的socket库监听本地回环,抓取PC与PLC之间的TCP包。但要注意,PC端上位机软件可能不走本地回环,而是走物理网卡,这时需要设置Windows/Wireshark的“本地回环抓包”或使用pcap库。
●方式B(推荐):在PLC侧启用“以太网通信日志”功能(通过GX Works3的CPU参数设置),把PLC与所有设备的通信报文以二进制文件形式导出到SD卡或FTP服务器。这样就不受PC端软件限制。
我用的方式B:在R08CPU的“以太网参数”中,勾选“通信日志记录”,设置文件名和最大容量(建议500KB,大概能存2000条报文)。然后每天凌晨3点断连后,我通过FTP直接从PLC的SD卡上下载日志文件。
2.2 解析层:Python代码拆解MC协议帧
MC协议3E帧(二进制模式)的固定结构如下(来自三菱MC协议手册,非编造):
下面是我写的解析函数:
import struct def parse_mc_3e_frame(data: bytes): """ 解析MC协议3E帧(二进制模式) :param data: 完整的一帧报文(不含TCP头) :return: 字典,包含各字段 """ if len(data) < 11: return {"error": "帧长度小于最小长度11字节"} header1 = data[0] # 0x50 header2 = data[1] # 0x00 network_no = struct.unpack('<H', data[2:4])[0] # 小端16位 pc_no = data[4] req_data_len = struct.unpack('<H', data[5:7])[0] # 请求数据长度(从命令代码开始) timer = data[7] command = struct.unpack('<H', data[8:10])[0] # 命令代码 subcmd = data[10] # 从命令代码开始的请求数据 req_data = data[11:11+req_data_len - 4] # 命令代码(2)+子命令(1)+定时(1) = 4字节,但定时和请求数据长度定义需注意 # 注意:请求数据长度是从命令代码开始算,但命令代码占2字节,子命令1字节,所以实际请求数据偏移 = 11 # 如果请求数据长度是L,则总帧长 = 11 + L result = { "header": f"0x{header1:02X} {header2:02X}", "network_no": network_no, "pc_no": pc_no, "req_data_len": req_data_len, "timer": timer, "command": f"0x{command:04X}", "subcmd": f"0x{subcmd:02X}", "req_data_hex": req_data.hex(), "raw": data.hex() } return result
这个函数把原始的hex报文拆成了易懂的字段,比如“command: 0x0401”、“req_data_len: 0x0006”等。
2.3 分析层:自动识别异常模式
除了解析单帧,我还写了一个批量分析器,自动扫描所有日志,找出以下异常:
●请求数据长度与实际不符(常见错误)
●命令代码0x0401读取时,起始地址超出了软元件范围
●应答帧中返回错误代码(如C051、C052等,对应“请求数据长度错误”、“软元件不存在”)
知识点2:MC协议应答帧中的错误代码(如C051)是3字节,第一个字节固定为0xC0,后两个字节是错误编号。但很多上位机开发者只检查了长度,没检查错误代码,导致程序一直重试同一个错误请求。 下面是一个批量分析的代码片段:
def analyze_communication_log(log_file_path): """分析日志文件,找出异常帧""" with open(log_file_path, 'r') as f: lines = f.readlines() anomalies = [] for line in lines: # 假设每行格式:时间戳, 方向, hex数据 parts = line.strip().split(',') if len(parts) < 3: continue timestamp = parts[0] direction = parts[1] # 'send' 或 'recv' hex_data = parts[2].replace(' ', '') data = bytes.fromhex(hex_data) parsed = parse_mc_3e_frame(data) if 'error' in parsed: anomalies.append(f"{timestamp} {direction}: 解析错误 - {parsed['error']}") continue # 检查请求数据长度是否正确(应答帧中长度应小于请求的) if direction == 'recv': # 应答帧的请求数据长度字段包含错误代码(如果有) # 如果命令是0x0401,应答数据长度应为 2(错误代码)+ 2(数据个数)+ 实际数据 # 简单判断:如果应答帧长度小于最小预期,则报错 pass # 检查错误代码 if data[11:14] == b'\xC0\x51\x00': # 错误代码C051 anomalies.append(f"{timestamp} {direction}: 错误代码 C051 - 请求数据长度错误") elif data[11:14] == b'\xC0\x52\x00': anomalies.append(f"{timestamp} {direction}: 错误代码 C052 - 软元件不存在") return anomalies
知识点3:MC协议错误代码的格式是:第一个字节0xC0,第二个字节是错误编号低字节,第三个字节是高字节(小端)。例如C051错误,实际接收到的字节序列是0xC0 0x51 0x00。很多人误以为0xC0是数据长度,导致解析错误。 3. 踩坑实战:凌晨3点断连的真相
3.1 场景还原
每天凌晨3:00,上位机自动执行一次数据清零操作(批量写入D0-D999),然后PLC就断连了。上位机日志显示“TCP连接正常,但读写超时”。
3.2 用工具分析日志
我拿到PLC的SD卡中的通信日志,用Python工具跑一遍,输出了一堆异常:
2025-03-15 03:00:00.123 send: 命令0x0401 写入D0-D999,请求数据长度0x0F (15字节) 2025-03-15 03:00:00.456 recv: 错误代码 C051 - 请求数据长度错误 2025-03-15 03:00:00.789 send: 重试... 命令0x0401 写入D0-D999,请求数据长度0x0F 2025-03-15 03:00:01.012 recv: 错误代码 C051 ... 循环10次后,PLC强制断开连接
3.3 根因
原来上位机发送的“写入字软元件”命令(0x0401)中,请求数据长度字段包含的是后续数据总字节数,但上位机程序员错误地填成了软元件个数(1000个D,每个2字节,应该是2000字节,即0x07D0,但他填了0x03E8即1000)。PLC收到后校验长度不匹配,返回C051。上位机没有处理错误代码,而是不断重试,触发了PLC的“连续错误保护”机制,自动断开连接。
3.4 旧方案 vs 新方案
4. 工具完整部署:从零到能用
4.1 环境准备
●Python 3.8+
●不需要额外库(只用标准库socket、struct、os)
●从PLC SD卡拷贝日志文件(格式:每行 时间戳,方向,hex)
4.2 核心功能:一键生成分析报告
我写了一个analyze_mc_log.py,用法:
python analyze_mc_log.py --log log.txt --output report.html
输出HTML报告,包含:
●所有命令统计(读/写比例)
●异常帧列表(带时间戳和错误描述)
●通信速率分析(每秒帧数)
4.3 代码库(关键部分)
# 命令行入口
import argparse def main(): parser=argparse.ArgumentParser(description="三菱MC协议通信日志分析工具") parser.add_argument("--log", required=True, help="日志文件路径") parser.add_argument("--output", default="report.html", help="输出报告路径") args = parser.parse_args() anomalies = analyze_communication_log(args.log) generate_report(anomalies, args.output) print(f"分析完成,发现 {len(anomalies)} 个异常,报告已保存到 {args.output}") if __name__ == "__main__": main()
互动问题:你遇到过哪些诡异的MC协议通信问题?欢迎在评论区分享你的“踩坑”经历,点赞最高的3位送《MC协议常见错误代码速查表》PDF版。 📚 推荐阅读
触摸屏开发 触摸屏脚本编程
发布于 2026-08-06
VS Code+三菱PLC:配置这5步,编程效率翻倍
发布于 2026-08-08
三菱MELSEC iQ-R机械手维护:从常见故障到预防性编程的八重境界
发布于 2026-08-07
KEYWORDS
PLC, GX Works, MELSEC, 三菱, 函数
💡 如果你觉得这篇文章有帮助,请点个在看,分享给更多需要的人!
📝 关注我,获取更多实用干货~
🤝 有问题欢迎评论区留言交流!