1. 项目概述从“黑盒”到“白盒”的通讯探索在工业自动化领域三菱FX系列PLC堪称常青树以其稳定可靠、性价比高的特点广泛应用于各类中小型设备控制。对于大多数电气工程师和程序员而言使用GX Works2或GX Developer进行梯形图编程、通过专用的SC-09或USB-SC09-FX编程电缆连接PLC的COM口进行程序上下载是再常规不过的操作。但这个看似简单的“连接-下载”过程背后其实隐藏着一套完整的、由三菱定义的串行通讯协议。我们日常使用的编程软件正是这套协议的“官方客户端”。那么如果我们想绕开官方软件自己写一个程序来读取PLC的软元件状态比如D100的当前值、或者强制置位某个M点甚至进行远程的在线监控和调试该怎么办这就是“三菱FX系列PLC编程口通讯协议”要解决的问题。它不是一个公开的标准协议如Modbus而是三菱为其编程口通常是RS-422/RS-485接口设计的一套私有、高效的二进制通讯协议。掌握它就等于拿到了与FX系列PLC直接“对话”的钥匙能够实现高度定制化的数据采集、设备调试、上位机监控乃至轻量级SCADA系统的开发。这套协议的核心价值在于“直接”和“灵活”。你不再需要依赖三菱的中间件或OPC服务器一台带有串口或USB转串口的电脑加上自己编写的代码就能与PLC建立通讯。这对于开发嵌入式网关、定制化调试工具、或在资源受限的工控机/树莓派上集成PLC控制功能的场景来说意义重大。接下来我将结合自己多年在设备联网和数据采集项目中的实战经验为你层层拆解这套协议并提供可直接复用的代码实例和避坑指南。2. 协议基础与通讯环境搭建2.1 物理连接与端口认知首先我们必须明确通讯的物理基础。FX系列PLC的编程口通常是一个圆形的8针MINI-DIN接口标记为“PORT”或“RS-422”。其引脚定义是固定的引脚1: FG框架地引脚2: SD发送数据-引脚3: RD接收数据-引脚4: RTS请求发送引脚5: SG信号地引脚6: 5V电源通常不用于通讯引脚7: SD发送数据引脚8: RD接收数据注意这是一个RS-422接口本质上是差分信号抗干扰能力强于RS-232。我们常用的SC-09编程电缆内部集成了RS-422到RS-232的电平转换电路。如果你使用USB-SC09-FX则内部是RS-422转USB的芯片如FTDI或CP2102。要与电脑通讯你需要一条可靠的编程电缆。我强烈建议使用原装或口碑好的兼容电缆很多通讯不稳定的问题都源于劣质电缆的信号转换质量差。连接后在电脑的设备管理器中你会看到一个新增的COM口例如COM3这就是我们后续编程中需要操作的虚拟串口。2.2 核心协议帧格式解析三菱FX编程口协议采用基于字节的二进制帧结构遵循“主从问答”模式电脑作为主站PLC作为从站。每一轮完整的通讯都由主站请求帧和从站响应帧组成。一个标准的请求帧格式如下部件长度字节说明示例值ASCII/Hex起始符1固定为ASCII码的STX(0x02)0x02命令码1标识操作类型如读、写0(0x30)起始地址4要操作的软元件起始地址ASCII码表示D100表示为0444(ASCII:0,4,4,4)数据长度2要读/写的软元件数量ASCII码表示读1个表示为01(ASCII:0,1)数据区可变写操作时存放要写入的数据读操作时无此部分结束符2固定为ASCII码的ETX(0x03)0x03校验和2从命令码到ETX含所有字节的ASCII码值累加和取后2位十六进制数再转为ASCII码计算得出看起来有点复杂我们用一个具体的“读取D100寄存器”的例子来拆解。假设我们要读取1个寄存器即D100。确定要素命令码读寄存器命令为0(ASCII0x30)。起始地址D100。需要先将其转换为协议中的5位十进制地址。FX系列软元件有统一的地址编码规则D寄存器的基址是0x0A00。D100的偏移量是100十进制。协议中地址用5位十进制数表示计算方式为基址 偏移量 * 2。所以D100的地址 0x0A00 100 * 2 0x0A00 0x00C8 0x0AC8。将0x0AC8转换为十进制是2744。在帧中我们需要用4位ASCII码表示这个5位十进制数的后4位即“2744”。所以地址部分填充为ASCII码的2,7,4,4。数据长度读1个表示为“01”ASCII码0,1。构建帧起始符:0x02(STX)命令/地址等:0 2744 01- 对应的ASCII字节流:0x30, 0x32, 0x37, 0x34, 0x34, 0x30, 0x31结束符:0x03(ETX)计算校验和累加0x30 0x32 0x37 0x34 0x34 0x30 0x31 0x03 0x1A5。取后两位十六进制数A5。将A和5分别转换为对应的ASCII码0x41和0x35。所以校验和部分为0x41, 0x35。最终请求帧16进制表示02 30 32 37 34 34 30 31 03 41 35PLC收到正确的请求后会返回响应帧。响应帧的格式与请求帧类似但数据区包含了读取到的值。例如如果D100的值为十进制1234十六进制0x04D2响应帧可能类似于02 30 30 34 44 32 03 46 43。其中30 30可能表示正常状态34 44 32就是ASCII码表示的“4D2”即数据0x04D2。实操心得地址计算是新手最容易出错的地方。务必理解“5位十进制地址”的概念并且记住常用软元件的基址D寄存器为0x0A00M线圈为0x0100X输入为0x0080Y输出为0x00A0。写一个通用的地址转换函数是后续编程的关键。2.3 串口参数配置协议运行在串口之上必须使用正确的参数才能建立通讯。FX系列编程口通讯的串口参数是固定的波特率9600 bps数据位7位停止位1位校验位偶校验Even Parity流控制无None在任何串口调试助手或自行编写的代码中都必须严格按此配置。一个常见的错误是使用了8位数据位或无校验这将导致PLC完全不响应。3. 核心功能实现与代码拆解理解了协议格式我们就可以着手用代码实现。这里我以Python为例进行讲解因其语法简洁易于理解。在实际项目中C#、Java、C等语言原理完全相同。3.1 串口通讯基础模块首先我们需要一个可靠的串口操作类。Python中可以使用pyserial库。import serial import time import binascii class FXSerialComm: def __init__(self, portCOM3, timeout1): 初始化串口连接 :param port: 串口号如 COM3 或 /dev/ttyUSB0 :param timeout: 读超时时间秒 self.ser serial.Serial( portport, baudrate9600, bytesizeserial.SEVENBITS, parityserial.PARITY_EVEN, stopbitsserial.STOPBITS_ONE, timeouttimeout ) if self.ser.is_open: print(f成功打开串口 {port}) else: raise Exception(f无法打开串口 {port}) def close(self): 关闭串口 if self.ser and self.ser.is_open: self.ser.close() print(串口已关闭) def send_and_receive(self, frame_hex): 发送帧并接收响应 :param frame_hex: 十六进制字符串表示的帧如 0230323734343031034135 :return: 十六进制字符串表示的响应帧如 023030344432034643 # 将十六进制字符串转换为字节数据 data_to_send binascii.unhexlify(frame_hex) print(f发送: {frame_hex}) # 清空输入缓冲区避免旧数据干扰 self.ser.reset_input_buffer() # 发送数据 self.ser.write(data_to_send) # 等待并读取响应 # 协议响应时间通常很快但增加短暂延时确保数据接收完整 time.sleep(0.05) response_bytes self.ser.read_all() if response_bytes: response_hex binascii.hexlify(response_bytes).decode(ascii).upper() print(f接收: {response_hex}) return response_hex else: print(未收到响应) return None这个类封装了串口的初始化和基础的收发功能。注意read_all()的使用它读取当前输入缓冲区中的所有数据。在实际应用中更稳健的做法是根据ETX(0x03)来判断帧的结束但为了示例清晰这里采用简单方式。3.2 协议帧构造与解析器这是整个项目的核心负责将用户友好的“读D100”指令翻译成协议认识的二进制帧并把PLC返回的二进制数据解析成我们可以理解的数值。class FXProtocolParser: # 软元件类型基址映射表 (十六进制) DEVICE_BASE { X: 0x0080, # 输入继电器 Y: 0x00A0, # 输出继电器 M: 0x0100, # 辅助继电器 D: 0x0A00, # 数据寄存器 T: 0x00C0, # 定时器当前值 C: 0x00E0, # 计数器当前值 } staticmethod def calculate_address(device_type, device_number): 计算协议使用的5位十进制地址 :param device_type: 软元件类型如 D, M :param device_number: 软元件编号如 100 :return: 4位ASCII码字符串表示的地址5位十进制地址的后4位 if device_type not in FXProtocolParser.DEVICE_BASE: raise ValueError(f不支持的软元件类型: {device_type}) base_addr FXProtocolParser.DEVICE_BASE[device_type] # 计算实际地址基址 编号 * 2 (对于位元件编号就是点数对于字元件编号*2) actual_addr base_addr device_number * 2 # 转换为5位十进制数 dec_addr actual_addr # 取后4位格式化为4位字符串不足补零 addr_str f{dec_addr % 10000:04d} return addr_str staticmethod def build_read_frame(device_type, device_number, count1): 构建读取软元件的请求帧 :param device_type: 软元件类型 :param device_number: 起始编号 :param count: 读取数量 :return: 十六进制字符串格式的完整帧 # 1. 起始符 STX frame_bytes bytearray([0x02]) # 2. 命令码 0 (ASCII 0x30) 代表读 frame_bytes.append(0x30) # 3. 起始地址 (4位ASCII) addr_str FXProtocolParser.calculate_address(device_type, device_number) frame_bytes.extend(addr_str.encode(ascii)) # 4. 数据长度 (2位ASCII) count_str f{count:02d} frame_bytes.extend(count_str.encode(ascii)) # 5. 结束符 ETX frame_bytes.append(0x03) # 6. 计算校验和 checksum sum(frame_bytes[1:]) # 从命令码开始累加到ETX checksum_hex f{checksum 0xFF:02X} # 取低8位转为2位十六进制字符串 frame_bytes.extend(checksum_hex.encode(ascii)) # 转换为十六进制字符串返回 return binascii.hexlify(frame_bytes).decode(ascii).upper() staticmethod def parse_read_response(response_hex, count1): 解析读取操作的响应帧 :param response_hex: 十六进制字符串响应 :param count: 期望读取的数据个数 :return: 解析出的数值列表整数或错误信息 if not response_hex or len(response_hex) 10: return None, 响应帧过短或为空 try: response_bytes binascii.unhexlify(response_hex) except: return None, 响应帧非法的十六进制格式 # 基本结构检查 if response_bytes[0] ! 0x02: return None, 响应帧起始符错误 if response_bytes[-3] ! 0x03: # ETX应该在倒数第三位 return None, 响应帧结束符错误 # 校验和验证 received_checksum response_bytes[-2:].decode(ascii) calculated_checksum f{sum(response_bytes[1:-2]) 0xFF:02X} if received_checksum.upper() ! calculated_checksum.upper(): return None, f校验和错误: 收到{received_checksum}, 计算{calculated_checksum} # 检查命令/状态码 status_code chr(response_bytes[1]) if status_code ! 0: error_codes {1: PLC错误, 2: 奇偶校验错误, 3: 帧格式错误, 4: 和校验错误} error_msg error_codes.get(status_code, f未知错误码: {status_code}) return None, fPLC返回错误: {error_msg} # 提取数据部分 # 响应帧格式: STX(1) 状态(1) 数据(2*count字节ASCII) ETX(1) 校验和(2) data_start 2 data_end -3 # 排除ETX和校验和 data_ascii response_bytes[data_start:data_end].decode(ascii) # 数据是连续的ASCII字符串每4个字符代表一个16位寄存器值十六进制ASCII values [] for i in range(count): hex_str data_ascii[i*4:(i1)*4] if len(hex_str) ! 4: break # 将ASCII表示的十六进制字符串转换为整数 value int(hex_str, 16) # 注意协议返回的是16位无符号整数但D寄存器可能存储有符号数或浮点数 # 这里按无符号整数返回上层应用根据实际情况转换 values.append(value) return values, 成功这个解析器类包含了地址计算、帧构建和响应解析的核心逻辑。calculate_address方法是关键它封装了之前提到的地址转换规则。parse_read_response方法则严谨地检查了响应的每一个部分包括起始结束符、校验和以及PLC返回的状态码确保了通讯的可靠性。3.3 完整功能集成与测试现在我们将串口模块和协议解析器组合起来实现一个完整的读值示例。def main(): # 1. 初始化串口通讯 (请根据实际情况修改端口号) comm FXSerialComm(portCOM3) try: # 2. 构建读取D100的请求帧 device_type D device_number 100 read_count 1 request_frame FXProtocolParser.build_read_frame(device_type, device_number, read_count) print(f构建的请求帧: {request_frame}) # 3. 发送并接收 response_frame comm.send_and_receive(request_frame) if response_frame: # 4. 解析响应 values, message FXProtocolParser.parse_read_response(response_frame, read_count) if values is not None: print(f读取成功: D{device_number} {values[0]} (0x{values[0]:04X})) # 如果需要可以在这里进行有符号数转换 # signed_value values[0] if values[0] 32768 else values[0] - 65536 # print(f有符号值: {signed_value}) else: print(f读取失败: {message}) else: print(通讯失败未收到PLC响应。请检查) print( 1. 电缆连接是否牢固) print( 2. PLC是否上电并处于RUN/STOP状态非编程状态) print( 3. 电脑COM口选择是否正确) print( 4. 是否有其他软件如GX Works2占用了该串口) except Exception as e: print(f程序运行出错: {e}) finally: # 5. 关闭串口 comm.close() if __name__ __main__: main()运行这段代码如果一切正常你将在控制台看到类似“读取成功: D100 1234 (0x04D2)”的输出。这标志着你已经成功突破了官方软件的壁垒直接与PLC核心建立了对话。4. 协议高级应用与功能扩展掌握了基础的读取功能我们就可以在此基础上实现更复杂的操作构建一个实用的工具。4.1 批量读取与写入操作实际项目中我们很少只读一个点。批量操作能极大提高效率。协议本身支持在帧中指定数据长度。例如读取D100开始的10个寄存器只需将帧中的数据长度部分改为“10”。解析响应时我们需要循环解析每4个ASCII字符为一个数据。写入操作命令码为1 ASCII0x31的帧格式略有不同需要在数据长度后附加要写入的数据区。数据区同样需要将每个16位寄存器的值转换为4位ASCII码表示的十六进制数。例如向D100写入十进制1234数据区就是“04D2”。构建写帧的函数需要增加数据列表参数。staticmethod def build_write_frame(device_type, device_number, values): 构建写入软元件的请求帧 :param device_type: 软元件类型 :param device_number: 起始编号 :param values: 要写入的数值列表整数 :return: 十六进制字符串格式的完整帧 frame_bytes bytearray([0x02]) frame_bytes.append(0x31) # 命令码 1 代表写 addr_str FXProtocolParser.calculate_address(device_type, device_number) frame_bytes.extend(addr_str.encode(ascii)) count len(values) count_str f{count:02d} frame_bytes.extend(count_str.encode(ascii)) # 添加数据区 for val in values: # 将数值转换为4位十六进制ASCII字符串 hex_str f{val 0xFFFF:04X} # 确保是16位无符号数 frame_bytes.extend(hex_str.encode(ascii)) frame_bytes.append(0x03) # ETX checksum sum(frame_bytes[1:]) 0xFF checksum_hex f{checksum:02X} frame_bytes.extend(checksum_hex.encode(ascii)) return binascii.hexlify(frame_bytes).decode(ascii).upper()4.2 位元件X, Y, M的读写读写位元件如X0, Y10, M100与字元件D寄存器原理相同但寻址方式一致都是计算5位十进制地址。区别在于读位元件时返回的数据区中每4个ASCII字符表示的是16个连续位元件的状态0或1需要按位解析。写位元件时数据区也需要按此规则组织。这增加了处理的复杂度但协议框架不变。4.3 错误处理与通讯超时优化工业现场环境复杂稳定的通讯必须包含完善的错误处理。超时重试在send_and_receive方法中不应只读一次。可以设置一个循环在超时时间内未收到完整帧通过判断ETX则重试最多重试3次。响应完整性校验示例中我们用了read_all()这依赖于PLC一次性返回完整帧。更健壮的做法是循环读取直到收到ETX(0x03)字符并检查帧长度是否合理。PLC状态检查在发送读写帧前可以先发送一个简单的“设备诊断”请求协议中有对应命令确认PLC在线且处于可通讯状态非编程模式。日志记录所有发送和接收的原始帧、解析结果、错误信息都应记录到文件或数据库便于后期排查偶发性故障。4.4 构建简易上位机监控界面有了稳定的通讯底层用PyQt、Tkinter或Web框架如FlaskWebSocket快速搭建一个图形化监控界面就水到渠成了。界面可以包含连接配置区COM口、波特率等参数设置。数据点表以表格形式列出需要监控的软元件如D100, M200等并配置轮询周期。实时数据显示区以数值、进度条、指示灯等形式动态显示数据。手动控制区提供按钮或输入框用于对Y点或M点进行置位/复位或修改D寄存器的值。数据日志与曲线将关键数据随时间变化记录下来并绘制趋势曲线。这个自研的上位机可以根据项目需求高度定制摆脱了组态软件的束缚和授权费用在特定场景下非常有用。5. 实战避坑指南与常见问题排查基于大量项目经验我总结了一些最容易“踩坑”的地方和解决方法。5.1 硬件与连接问题排查表现象可能原因排查步骤与解决方案完全无响应发送后收不到任何数据1. 物理连接断开或错误2. 串口被其他程序占用3. PLC电源未接通或处于编程状态4. 电缆损坏或型号不对1. 检查电缆两端是否插紧确认是FX编程口。2. 关闭GX Works2等所有可能占用COM口的软件。3. 确认PLC POWER灯亮拨动RUN/STOP开关到STOP或RUN非编程模式。4. 尝试更换电缆确认是SC-09或USB-SC09-FX for FX系列。收到乱码或非预期响应1. 串口参数设置错误2. 电缆质量差信号干扰3. 接地不良1.反复确认波特率9600数据位7停止位1偶校验无流控。2. 使用带屏蔽层的优质电缆远离动力线。3. 确保PLC的FG端子和电脑机壳良好接地。偶尔通讯超时或数据错误1. 现场电磁干扰严重2. 波特率不匹配PLC侧被修改3. 程序轮询过快PLC处理不过来1. 增强屏蔽使用磁环采用双绞线电缆。2. 用编程软件连接一次确认通讯参数或通过PLC参数查看。3. 增加轮询间隔如从100ms增加到200ms避免总线拥堵。5.2 软件与协议层常见错误地址计算错误这是最高频的错误。务必使用我们封装好的calculate_address函数并确保传入的device_number是正确的十进制编号。例如M100的编号就是100。校验和计算错误校验和是累加ASCII码值而不是字符本身。计算范围是从命令码到ETX包括ETX。很多自己实现协议的开发者会漏加ETX导致PLC返回“和校验错误”。数据解析错位响应帧的数据区是连续的ASCII字符串。例如读取两个寄存器D100和D101返回值可能是04D20064需要正确分割为04D2和0064进行解析。忽略PLC错误码响应帧第二字节状态码不是0就是出错。必须解析这个代码常见的3帧格式错误和4和校验错误能快速定位问题在请求帧的构建上。字节序问题协议返回的16位数据高字节在前还是低字节在前三菱FX协议是高字节在前Big-Endian。例如返回的ASCII字符串04D2对应的16进制就是0x04D2直接转换即可。这一点在和某些习惯小端序的系统交互时要特别注意。5.3 性能优化与稳定性建议连接池与单例模式在需要频繁通讯的系统中串口连接的开销较大。应设计一个串口连接管理类单例模式避免反复打开关闭端口。异步通讯对于需要同时监控大量数据点且要求实时性的场景考虑使用异步IO如Python的asynciopyserial-asyncio或单独开一个通讯线程避免主线程被阻塞。心跳与断线重连定期向PLC发送一个简单的读命令如读一个固定的M点状态作为心跳包。如果连续多次失败则触发断线重连机制重新初始化串口连接。数据缓存与变化通知不是每次读取到数据都立刻刷新界面或上报。可以在内存中维护一个数据点缓存只有值发生变化时才触发后续处理能有效减少不必要的运算和网络传输。通过以上从原理到实践从基础到进阶的详细拆解相信你已经对三菱FX系列PLC的编程口通讯协议有了深入的理解。这套协议就像一把精准的螺丝刀让你能直接拧动PLC内部的“螺丝”。虽然它比Modbus这类通用协议更繁琐但带来的直接性和高效率是无可替代的。在实际项目中从简单的数据采集工具到复杂的设备运维平台这项技能都能让你在工业自动化的深水区游刃有余。最后记住调试阶段一个可靠的串口调试助手如AccessPort、格西烽火等是你的最佳伙伴它可以直观地对比你生成的帧和正常通讯的帧是排查协议问题的最快途径。