当前位置:首页>python>抓包3天,我用Python写了个MC协议解析器

抓包3天,我用Python写了个MC协议解析器

  • 2026-09-02 21:53:24
抓包3天,我用Python写了个MC协议解析器

上个月在无锡一个锂电项目,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协议手册,非编造):

偏移
字节数
内容
说明
0
1
帧头1
0x50(固定)
1
1
帧头2
0x00(固定)
2
2
网络号
通常0x0000
4
1
PC编号
通常0xFF(255)
5
2
请求数据长度
小端,从请求数据开始算
7
1
定时时间
通常0x00
8
2
命令代码
如0x0401(读取字软元件)
10
1
子命令
0x00或0x01
11+
可变
请求数据
软元件名、点数、起始地址等

下面是我写的解析函数:

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 新方案

对比项
旧方案(手动查hex)
新方案(Python工具)
定位时间
1.5小时(翻日志+查手册)
3分钟(工具自动标红)
错误发现率
50%(漏看小字节)
100%(自动检测C051)
可复现性
不能,日志状态与实时不同
可以,保存了原始报文

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, 三菱, 函数

💡 如果你觉得这篇文章有帮助,请点个在看,分享给更多需要的人!

📝 关注我,获取更多实用干货~

🤝 有问题欢迎评论区留言交流!

最新文章

随机文章