简介：面向工控自动化初学者与PLC调试人员的入门资料，聚焦三菱MC协议如何开放PLC内部寄存器、实现外部设备与PLC的数据交互。文档围绕TCP/IP通信方式展开，讲解一发一收的通信机制、3E帧格式与二进制传输的选型理由，并给出PLC内置以太网端口的参数设置流程，无需额外编程即可完成配置。文中以向D7000写入H000C、读取连续5个软元件为例，逐字节解析发送帧与响应帧，同时整理软元件类型与代码对应关系、指令及子指令列表，以及错误返回帧的排查思路，便于读者对照手册定位问题。资源包共1个docx文件，大小约1.12MB，结构紧凑、示例完整。已有4095人学习，适合希望快速上手三菱MC协议通信配置与报文调试的读者参考。
1. 三菱 MC 协议：为什么它成了上位机读写 PLC 的“免编程通道”
车间里一台设备要接 MES，工程师第一反应往往是“加个采集网关”或者“让 PLC 程序里再写一段通讯逻辑”。但真到现场你会发现，很多三菱 PLC 根本不用改梯形图，只要在参数里勾几下、烧写一次配置，外部设备就能直接读写 D、M、W 这些软元件。靠的就是 MC 协议——它把 PLC 内部寄存器开放出来，外部设备主动发一帧、PLC 回一帧，一发一收，干净利落。
这份《三菱 MC 协议配置和使用简析》讲的正是这条链路：TCP/IP 下用 3E 帧、二进制格式，从 PLC 侧参数设置到收发帧逐字节拆解，再到软元件代码、指令列表和错误帧处理。适合两类人：一是要快速打通上位机与 PLC 数据通道的自动化从业者，二是被 ASCII 帧长度和字节序折腾过、想搞清二进制帧怎么拼的开发者。下面按“协议怎么立住 → 帧怎么拼 → PLC 怎么设 → 坑在哪”的顺序拆。
2. 3E 帧二进制：一帧数据从哪来、到哪去
2.1 为什么选 3E 帧 + 二进制，而不是 ASCII
MC 协议的帧格式有 3E、3C、4C、4E 几种，差异主要在帧头结构和是否带网络编号、PC 编号等字段。3E 帧是 TCP/IP 下最常用的一种，帧头固定、长度字段明确，解析起来最省心。通讯内容又分二进制和 ASCII 两种形式，两者传输的语义完全一致，区别只在编码：ASCII 把每个字节写成两个可读字符，一帧长度翻倍，还得做字符到数值的转换；二进制直接上字节，帧更短、无需转换，效率明显更高。
所以这份资料直接锁定“3E 帧 + 二进制”这个组合，是务实的选择。常见做法是：上位机侧用 socket 建 TCP 连接，按 3E 帧结构拼字节数组发出去，收到响应后按同样结构解析。选型上唯一要确认的是 PLC 型号和以太网模块支持的帧格式——老一些的模块可能只认 3C/4C，上机前翻一眼对应型号的通讯协议参考手册，别默认 3E 通吃。
2.2 发送帧逐字节拆解：写 D7000 = H000C 这一帧怎么来的
资料给的写软元件例子是向 D7000 写入 H000C，发送帧为：
50 00 00 FF FF 03 00 0E 00 10 00 01 14 00 00 58 1B 00 A8 01 00 0C 00这串字节要按字段切开看，不能整串背。3E 帧二进制格式的发送帧大致分几段：副头部（50 00）、网络编号（00）、PLC 编号（FF FF）、请求目标模块 I/O 编号（03 00）、请求目标模块站号（10 00 是占位示例，实际按站号填）、请求数据长度、CPU 监视定时器、指令号、子指令号、起始软元件编号、软元件代码、写入点数、写入数据。
这里有个必须刻进肌肉记忆的规则：两个字节的字段，低位字节在前、高位字节在后。比如请求数据长度 0E 00 表示 0x000E，即 14 字节；起始软元件编号 58 1B 00 表示 0x001B58，换算成十进制是 7000，正好对应 D7000；写入点数 01 00 表示 1 个点；写入数据 0C 00 表示 0x000C。指令号 01 14 对应“批量写入”，子指令 00 00 表示按字单位写。
拼帧时最容易翻车的就是字节序和软元件编号的换算。D7000 不是直接写 7000 的十六进制，而是 0x1B58，再按低字节在前排成 58 1B 00。很多新手在这里把 7000 直接转成 1B 58 就发出去，PLC 要么报错要么写到别的地址，血泪经验就是先拿一个已知地址做单点写入验证，通了再批量。
2.3 响应帧与读帧：0C 回读验证闭环
写操作的响应帧是：
D0 00 00 FF FF 03 00 02 00 00 00副头部变成 D0 00，请求数据长度 02 00 表示后面跟 2 字节，结束代码 00 00 表示正常结束。只要结束代码非零，就说明这一帧被 PLC 拒了，得去查错误码。
读操作的例子是读取 D7000 开始的连续 5 个软元件，发送帧：
50 00 00 FF FF 03 00 0C 00 10 00 01 04 00 00 58 1B 00 A8 05 00指令号 01 04 是批量读取，点数 05 00 表示读 5 个点。响应帧：
D0 00 00 FF FF 03 00 0C 00 00 00 0C 00 00 00 00 00 00 00 00 00结束代码 00 00 之后跟的是 5 个字的读回数据，第一个字 0C 00 正是上一次写入的 0x000C，后面四个字为 0。这个“写进去再读回来”的闭环，是验证帧拼得对不对最直接的办法，比盯着手册猜字段靠谱得多。
用 Python 拼这一帧，核心就是把各字段按小端序塞进 bytearray：
import socket def build_write_frame(addr: int, value: int, device_code: int = 0xA8) -> bytes: # 3E 帧二进制，批量写入字单位 frame = bytearray() frame += b'\x50\x00' # 副头部 frame += b'\x00' # 网络编号 frame += b'\xFF\xFF' # PLC 编号 frame += b'\x03\x00' # 请求目标模块 I/O 编号 frame += b'\x10\x00' # 请求目标模块站号 # 请求数据长度 = 后面从定时器到写入数据的字节数 body = bytearray() body += b'\x10\x00' # CPU 监视定时器 body += b'\x01\x14' # 指令 0114 批量写入 body += b'\x00\x00' # 子指令 0000 字单位 body += addr.to_bytes(3, 'little') # 起始软元件编号，3 字节小端 body += device_code.to_bytes(1, 'little') # 软元件代码，D 为 A8 body += (1).to_bytes(2, 'little') # 写入点数 body += value.to_bytes(2, 'little') # 写入数据 frame += len(body).to_bytes(2, 'little') frame += body return bytes(frame) s = socket.create_connection(('192.168.1.10', 4999), timeout=3) s.sendall(build_write_frame(7000, 0x000C)) resp = s.recv(1024) print(resp.hex(' ')) s.close()这段代码里几个参数要盯住：addr.to_bytes(3, 'little')是 3 字节小端，对应帧里 58 1B 00 这种排法；device_code对 D 寄存器是 0xA8，换 M 继电器、W 链接寄存器就得查软元件代码表；len(body).to_bytes(2, 'little')算的是请求数据长度，算错一个字节 PLC 直接回错误帧。端口 4999 是资料里的示例，实际以 PLC 参数里设的为准。
3. PLC 侧参数设置：不写一行梯形图把通道打开
3.1 内置以太网端口设置的三步走
资料给的设置路径很明确，不需要额外编程：在工程栏双击 PLC 参数，弹框里选内置以太网端口设置，设 IP、设通信数据代码、勾选“允许 RUN 中写入”；再点“打开设置”，第一栏选 TCP 协议、MC 协议，端口号按需填（示例 4999），一路设置结束，最后把新配置烧写到 PLC。
这里每一步都有实际含义。设 IP 是给 PLC 网口一个同网段地址，上位机才能连上；通信数据代码设置决定二进制还是 ASCII，要和上位机拼帧方式一致，选二进制就别在对面按 ASCII 解析；“允许 RUN 中写入”不勾，PLC 运行状态下写请求会被拒，调试时容易误以为是帧格式错。打开设置里的 TCP + MC 协议 + 端口号，等于告诉 PLC“在这个端口上按 MC 协议收帧”。
如果 PLC 本体没带网卡模块，就得在网络参数里选对应以太网设备做类似设置，流程基本一致，只是入口不同。烧写配置后建议断电重启或至少确认参数已生效，再开始发帧。
3.2 软元件代码与指令表：拼帧前先查这两张表
软元件代码是拼帧时第二个高频出错点。资料里给了基本型 QCPU 的软元件名称与代码对应关系，分 ASCII 和二进制两种情况，其他机型查对应手册。二进制下 D 是 0xA8，这是写 D 寄存器必须填对的值；换成 M、X、Y、W、R 等软元件，代码都不同，填错的表现往往是 PLC 返回错误帧或读到一片零。
指令及子指令列表同样要对着查：批量读是 01 04，批量写是 01 14，子指令 00 00 表示字单位、01 00 表示位单位。位软元件和字软元件的点数含义不一样，写 M 继电器时点数是位数，别拿字单位的习惯套上去。常见做法是把常用软元件的代码和指令做成一张小抄贴在代码注释里，比每次翻手册快。
| 字段 | 示例值 | 说明 |
|---|---|---|
| 副头部 | 50 00 | 请求帧固定 |
| 网络编号 | 00 | 单网络一般填 0 |
| PLC 编号 | FF FF | 站内直连常用 |
| 请求数据长度 | 0E 00 | 后续 body 字节数，小端 |
| 指令/子指令 | 01 14 / 00 00 | 批量写 / 字单位 |
| 起始软元件 | 58 1B 00 | D7000 的 3 字节小端 |
| 软元件代码 | A8 | 二进制下 D 寄存器 |
| 点数 | 01 00 | 写入 1 个点 |
3.3 错误帧怎么读：结束代码不是零就别猜
发送格式不对时，PLC 会回一帧带错误信息的响应，结束代码非零。资料提到错误描述要在对应 PLC 手册里查，比如 LCPU 系列有专门的错误码说明。实操里最省时间的做法是：先把响应帧的结束代码字段单独取出来，转成十六进制去手册错误码表里对，而不是盯着整帧猜哪里错了。
常见错误码指向的无非几类：帧长度和请求数据长度对不上、软元件代码不支持、点数超范围、RUN 中写入未允许、指令号写错。定位顺序建议从“长度字段 → 软元件代码 → 指令/子指令 → 权限设置”逐项排除，因为长度错会让 PLC 连解析都进不去，先排它最划算。
4. 避坑与排查：五个让帧发出去没反应的现场问题
4.1 字节序搞反，地址写到别处
现象：单点写 D7000，PLC 回正常结束帧，但读回来 D7000 没变，别的地址莫名多了值。原因：起始软元件编号按大端排了，7000 写成 1B 58 00 而不是 58 1B 00。解决：所有多字节字段统一走小端，地址换算先用计算器确认 7000 = 0x1B58，再按低字节在前排成 58 1B 00，写完立刻回读验证。
4.2 请求数据长度算错一个字节
现象：PLC 返回错误帧，结束代码指向帧格式异常，但字段看着都对。原因：请求数据长度字段统计的是从 CPU 监视定时器到帧尾的字节数，少算或多算一个字节，PLC 解析就越界。解决：不要手写常量，用代码里len(body)动态算，改点数、改指令时长度自动跟着变，避免改了一处忘了另一处。
4.3 软元件代码填成 ASCII 表里的值
现象：读 D 寄存器返回全零或错误帧，地址和长度都没问题。原因：软元件代码查的是 ASCII 那张表，二进制帧里填了 ASCII 对应的代码。解决：确认通讯数据代码设置为二进制，软元件代码只查二进制列，D 用 0xA8，换软元件类型时重新查表而不是沿用上一个。
4.4 没勾“允许 RUN 中写入”，写请求被拒
现象：读操作正常，一写就回错误帧，PLC 明明在运行。原因：内置以太网端口设置里“允许 RUN 中写入”没勾选，运行状态下写请求被 PLC 拒绝。解决：回参数设置勾上该项，重新烧写配置并确认生效；调试阶段也可以先停机写一次，区分是权限问题还是帧问题。
4.5 端口和协议对不上，连接都建不起来
现象：socket 连接超时或被拒，根本没收到任何响应帧。原因：打开设置里选的不是 TCP + MC 协议，或端口号和上位机代码里写的不一致，也可能是 IP 不在同一网段。解决：先 ping 通 PLC，再用端口探测确认 4999（或实际设置值）在监听，最后核对打开设置里的协议类型，三层都对了再谈拼帧。
5. 进阶：把单帧收发封装成可复用的读写函数
单点写通了只是开始，现场真正要的是稳定批量读写。我的习惯是把 3E 帧的拼装和解析抽成两个函数，读函数按点数循环或一次批量读，写函数支持一次写多个字，响应统一先校验结束代码再取数据。这样上层业务只管“读 D7000 起 5 个字”“写 D7000 = 0x0C”，不用每次碰字节。
一个实用的验证套路是：每次改完帧结构，先做“写一个已知值 → 读回同地址 → 比对”三步，再扩大到连续多点。批量读时注意响应帧里数据区长度 = 点数 × 2 字节（字单位），解析时按小端逐字取，别把整段当一个大整数。位软元件则要按位拆，点数含义和字单位不同，混用会读出错位数据。
| 封装层次 | 输入 | 输出 | 验证点 |
|---|---|---|---|
| 拼帧函数 | 地址、点数、指令、软元件代码 | 完整发送帧 | 长度字段与实际字节数一致 |
| 解析函数 | 响应字节流 | 结束代码 + 数据列表 | 结束代码为 0 才取数据 |
| 业务读写 | 软元件名、起始地址、值 | 成功/失败 + 数据 | 写后回读比对 |
还有一点值得提前做：把常用错误码和对应处理写进日志，结束代码非零时直接打印十六进制值和原始响应帧，排查时不用再抓包。端口号、IP、软元件代码这些易变参数抽到配置文件里，换现场只改配置不动代码。
从那以后我每次接新 PLC，都强制先走一遍“ping 通 → 端口通 → 单点写 → 回读比对 → 批量读”这条链路，任何一步不过就不往下写业务逻辑，省下的返工时间远比这一步多。希望帮到你。
本文还有配套的精品资源，点击获取
