工控现场待久了谁手里都得备几个趁手的工具。前段时间客户现场一台老设备还在用三菱FX系列PLC编程口是RS422圆口没有触摸屏调试参数全靠临时做个上位机工具去读写D寄存器。项目本身不算复杂但三菱FX编程口协议、RS422圆口接线、C#串口通信这几块叠在一起确实有几个容易翻车的细节。这篇文章就从这个C#测试工具的开发过程出发把协议帧结构、圆口引脚定义、串口通信实现、常见坑位全部过一遍。如果你正要写FX系列PLC的上位机通信或者刚接触编程口协议想快速跑通一个测试工具这篇应该能帮你省不少事。1. 项目到底在解决什么问题1.1 应用场景老设备、新工具PLC在产线上跑了十年八年很常见FX系列尤其多。这类设备往往没有触摸屏或者触摸屏只显示固定画面操作工想改个温度目标值都得找厂家。上位机工程师过去调试最朴素的需求就是插上一根线打开一个工具直接看D寄存器当前值改几个关键参数。我这次遇到的情况正是如此。现场是一台小型包装设备FX3U的CPU程序里十几个D寄存器存着温度、速度、计数这些运行时数据。设备厂商提供的程序加密了看不到内部逻辑但软元件地址是公开的所以只要能通信就能知道设备实时状态。这类测试工具的核心价值就一句话把PLC内部软元件变成肉眼可见的数据。它不是说拿来做产品交付更多是给调试工程师自己用的——设备联机前验证通信是否正常调试时批量读写参数排查问题时抓通信报文。也正因为如此工具界面不需要花哨协议正确、收发稳定、日志清晰才是第一位的。1.2 方案为什么选编程口协议当时我盘了一下可选方案。最常见的是编程口协议直接通信其次是加一块FX-485BD扩展板走专用协议或者上FX3U-ENET以太网模块跑MC协议。老设备做改造加模块要订货、要拆机箱、要改线现场等不起。编程口协议的优势就在这里CPU上自带一个RS422圆口不需要任何额外硬件一根转换线就能把PC和PLC连起来。协议本身是公开的网上资料不少帧格式简单用C#的SerialPort类就能实现。虽然9600波特率不算快但读写一批D寄存器也就几十毫秒的事情做参数调试和状态监视完全够用。另外有个很现实的原因编程口协议不会干扰PLC现有的运行逻辑。它不需要你改PLC程序也不需要设置通信参数——FX系列CPU的编程口默认就是固定参数上位机只要按默认参数去连基本不会出现配不上的情况。这种“不加料、不改参、不侵入”的特点决定了它是现场应急调试的首选。1.3 测试工具的功能定位明确了通信方案工具的边界也就清晰了。我把它定位成一个纯粹的软元件读写测试器不做复杂的业务报表不做趋势曲线专注于以下几件事串口连接管理选择COM口号、设置波特率校验位、打开关闭串口D寄存器批量读写最常用的功能读温度、读速度、写参数都靠它M继电器批量读取与单点置位/复位调试设备动作时用来强制某个中间继电器收发日志完整记录每一帧的十六进制数据和原始ASCII数据协议出了问题能直接对报文响应时间统计连续读几次看平均耗时判断通信链路质量有了这个工具现场调试80%的需求就覆盖了。剩下20%比如读写S状态继电器、T定时器当前值这些场景底层协议是同一套扩展起来很快。2. 三菱FX编程口协议关键细节2.1 帧结构从STX到校验码三菱FX编程口协议本质上是一个基于ASCII字符的查询/响应协议帧结构非常规整。PC发给PLC的每一帧命令都遵循这个模板STX (0x02) 命令码 数据区 ETX (0x03) 校验码2个ASCII字符STX是起始字符ETX是结束字符中间是命令和参数。真正容易写错的是最后那两位校验码。校验码的计算方式从STX后面第一个字符开始一直累加到ETX含ETX把ASCII码求和取累加和的低8位再转换成2位大写的十六进制文本。注意STX本身不参与累加。举个例子。我要读取D0开始的2个寄存器命令码是0D0的地址编码是1000读取点数02那么待发送的ASCII数据区就是01000002。逐字符累加0是481是49后面四个0各48再一个0是482是50ETX是3。全部加起来等于390取低8位得到134转十六进制就是86。所以完整发送帧的十六进制报文是02 30 31 30 30 30 30 30 32 03 38 36PLC成功响应时回帧格式是STX 数据区 ETX 校验码。同样以D0/D1为例如果两个寄存器当前值分别是0x0064100和0x00C8200那响应数据区就是006400C8加上校验后完整回帧是02 30 30 36 34 30 30 43 38 03 41 38失败时PLC返回NAK0x15加2字符错误码比如NAK后跟着04就表示校验和错误。理解这个帧结构工具就等于完成了一半。剩下的所有命令构造都只是在这个模板上填入不同的命令码和数据区而已。2.2 常用命令码一览FX编程口协议的命令码不多我最常用的是下面这几个命令码功能数据区格式0批量读取字软元件起始地址4位Hex 点数2位Hex1批量读取位软元件起始地址4位Hex 点数2位Hex2批量写入位软元件起始地址4位Hex 点数2位Hex 各点数据3批量写入字软元件起始地址4位Hex 点数2位Hex 各点数据7单字写入地址4位Hex 数据4位Hex8单位写入地址4位Hex 数据0或1批量读取D寄存器用命令0这是测试工具里出现频率最高的命令。读取M继电器状态用命令1强制M点置位/复位用命令8。命令3用于批量写D比如下载一组配方参数。批量写入的帧会稍微长一点。比如用命令3往D100写入2个字假设值是0x0001和0x0002数据区就是起始地址1064 点数02 数据00010002串起来是3106400200010002。这些命令在写工具的时候封装成函数就行但理解每个字段的含义是必要的——否则报文对不上查错会非常痛苦。批量读取位软元件命令1响应数据区是每一位对应一个ASCII字符0代表OFF1代表ON。比如读M0开始的8个点响应数据区就是8个字符的0/1序列例如10100101表示M0和M2和M5和M7为ON。这样解析起来直观但要注意数量别超过PLC实际分配的软元件范围否则会返回NAK。2.3 软元件地址映射与编码技巧命令码解决了“读/写什么”的问题地址编码解决的是“读写哪个软元件”的问题。FX系列在编程口协议里每个软元件都被映射到一个十六进制地址段。这个映射表是工具开发中的关键参考软元件类型起始地址说明M0x0000中间继电器十进制编号直接加偏移S0x0080状态继电器X0x00C0输入继电器注意八进制编号换算Y0x00E0输出继电器注意八进制编号换算T0x0100定时器触点位C0x0180计数器触点位D0x1000数据寄存器以D寄存器为例D0对应地址0x1000D100对应0x1000 100 0x1064。地址编码规则就是0x1000加上D编号的十六进制值超出这个基本规律的情况非常少。M寄存器也是一样M0对应0x0000M15对应0x000F。但这里有一个细节M编号是十进制的而X和Y是八进制的。X0对应的地址是0x00C0X7对应0x00C7但X10对应的是0x00C8因为八进制10等于十进制8。我第一次写工具的时候就在这栽了个跟头用Convert.ToInt32(X10, 10)直接解析结果地址差了两位读到的是完全错误的软元件。对于定时器和计数器还要区分“触点状态”和“当前值”两种数据。用位读取命令1读T0读到的是触点的ON/OFF用字读取命令0能否读T0当前值取决于具体型号的地址映射FX系列不同派生型号差异比较大。我在工具里只默认暴露安全的部分D、M、X、YT和C的高级功能留了扩展接口但默认隐藏避免小白用户选到不支持的组合返回NAK后一脸茫然。另外一点地址映射表在不同芯片型号之间确实有小差异。FX1S/FX1N/FX2N/FX3U/FX3G这几个系列的软元件范围不同但常用地址段的编号规则基本一致。工具开发时建议默认按FX3U来写其他型号用户自己按手册微调。3. RS422圆口接线与硬件准备3.1 圆口8针怎么认FX系列CPU上的编程口是一个圆形的8针插座行业内习惯叫“圆口”。这个接口的电气标准是RS422四线差分支持全双工通信。RS422的好处现场工程师都知道收发独立、抗干扰强、传输距离远几十米的通信线完全不在话下。但圆口的引脚定义是第一个容易搞混的地方。网上能找到的FX圆口定义图版本很多1脚3脚正负不统一不同批次甚至存在差异。我这里给出一份比较常见的定义但请务必以你手头PLC型号对应的硬件手册为准引脚号信号名方向相对PLC1RDBPLC发送数据正2RDB-PLC发送数据负3SDBPLC接收数据正4SDB-PLC接收数据负5SG信号地65V供转换器取电电流很小7未用一般NC8未用一般NC把这个表读明白接线的本质就一句话电脑的发送对要接到PLC的接收对电脑的接收对要接到PLC的发送对。也就是RS422的TXD接PLC的RDBRXD接PLC的SDB。方向接反的症状是发出去的帧没有任何响应而且PC端转换器上的TX灯会闪RX灯完全不亮。顺带一提6脚虽然有个5V但只能给某些专用适配器提供很小的电流指望它给一个USB转RS422模块供电是不现实的。常规做法还是用转换器自带USB供电。3.2 转换器选型与线序确认市面上常见的转换方案有两种。一种是用原厂或兼容的专用连接线插头直接做成圆口个另一端USB即插即用。另一种是用通用的USB转RS422模块自己压接圆口端子。我个人的建议是如果只是偶尔调一台设备买专用线最省心如果经常跑现场手头备一个通用USB转RS422模块加一盘圆口端子灵活性更高。通用模块接线时需要注意几点。首先把模块上的收发接口找对通常标着TXD、TXD-、RXD、RXD-、GND这五根线。TXD接PLC的3脚和4脚SDB、SDB-RXD接PLC的1脚和2脚RDB、RDB-GND接5脚SG。线序确认好后建议用标签纸把对应关系贴在模块外壳上免得下次换个现场又得重新查。其次是屏蔽和接地。RS422虽然是差分信号不接地也可能通信成功但工业现场的电机变频器干扰很厉害。差分线用双绞屏蔽线屏蔽层单端接地同时把SG接上基本上能避免绝大多数偶发通信失败。我吃过一次亏当时图省事没接SG测试工具跑简单读写没问题但设备一启动频繁超时接了SG以后一切恢复正常。3.3 串口参数设置注意事项三菱FX编程口的串口参数是固定的9600波特率8位数据位偶校验Even1位停止位无流控。这个“偶校验”是很多人容易漏掉的细节。C#的SerialPort类默认参数不是这个组合必须显式设置。尤其注意校验位如果设置成无校验NonePC发出的帧本身不含奇偶校验位PLC收到后按照“偶校验”来解析会直接认为字符错误。症状就是通信毫无反应或者偶尔返回NAK错误码。反过来PLC侧没有配置界面让你改这些参数——FX编程口就是固定的9600/8/E/1上位机必须迁就它。另外要注意波特率的坑。某些老型号的FX系列PLC可以通过DIP开关修改通信参数如果之前有人动过DIP开关编程口可能已经不是9600了。遇到完全不通的情况可以逐个尝试2400、4800、19200这几个常见波特率同时把校验位也换着试一遍。4. C#上位机实现与关键代码4.1 搭建工程与串口初始化C#实现这个工具最简单快捷的方式是WinForms。新建一个.NET Framework 4.7.2的WinForms项目开发效率高部署也方便——目标机器装的是Windows拷过去就能跑。如果你用的是.NET 6或.NET 8需要额外NuGet引用System.IO.Ports包。串口初始化代码很直接关键是参数别写错using System.IO.Ports; SerialPort _sp new SerialPort(); _sp.PortName COM3; // 实际端口 _sp.BaudRate 9600; _sp.DataBits 8; _sp.Parity Parity.Even; // 偶校验别漏 _sp.StopBits StopBits.One; _sp.Handshake Handshake.None; _sp.ReadTimeout 1000; _sp.WriteTimeout 1000; _sp.Open();SerialPort打开后DataReceived事件会在后台线程触发。很多初学者喜欢在事件里直接更新UI控件结果报跨线程操作异常。更稳妥的做法是把接收数据交给一个队列或锁保护UI控件通过Invoke或者定时器刷新。不过我的工具最终采用的是同步收发模式DataReceived事件只用来做“收到数据置标志”的辅助真正读取用同步读逻辑更直接。4.2 协议帧构造与校验计算方法协议层的核心代码我把它们封装成一个静态类方便复用。D寄存器地址计算、M寄存器地址计算、校验和运算、帧组装都是纯函数不依赖界面后续做控制台测试或者扩展成类库都没问题。public static class FxProtocol { // 批量读取D寄存器 public static byte[] ReadD(ushort start, ushort count) { string address (0x1000 start).ToString(X4); string data 0 address count.ToString(X2); return BuildFrame(data); } // 批量写入D寄存器 public static byte[] WriteD(ushort start, int[] values) { string address (0x1000 start).ToString(X4); string data 3 address values.Length.ToString(X2); foreach (int v in values) data v.ToString(X4); return BuildFrame(data); } // 批量读取M继电器 public static byte[] ReadM(ushort start, ushort count) { string address (0x0000 start).ToString(X4); string data 1 address count.ToString(X2); return BuildFrame(data); } // 单M点置位/复位 public static byte[] SetM(ushort start, bool value) { string address (0x0000 start).ToString(X4); string data 8 address (value ? 1 : 0); return BuildFrame(data); } // 通用的帧组装 校验码计算 private static byte[] BuildFrame(string data) { Listbyte frame new Listbyte(); frame.Add(0x02); // STX frame.AddRange(Encoding.ASCII.GetBytes(data)); frame.Add(0x03); // ETX int sum 0; for (int i 1; i frame.Count; i) sum frame[i]; string chk (sum 0xFF).ToString(X2); frame.AddRange(Encoding.ASCII.GetBytes(chk)); return frame.ToArray(); } }这个实现里有一个细节校验和的ToString(X2)默认就是大写十六进制正好符合协议要求。如果协议手册要求小写那就需要额外处理但FX是用大写的直接用就行。D寄存器读取时如果数据超过65535比如某个寄存器存的是带符号的负数响应解析时要把ushort转成short再显示。这一点在工具里体现为“无符号/有符号”显示切换虽然只是UI层的小功能但排查负值数据时会舒服很多。4.3 响应接收与超时处理发送帧构造好了以后怎么可靠地收响应是工具稳定性比拼的关键。我的方案很简单发送前清空接收缓冲区发送后循环读取直到凑够一个完整帧或者超时。完整帧的判断规则分两种情况如果首字节是NAK0x15帧长度就是3字节NAK 2位错误码如果首字节是STX0x02则必须找到ETX0x03并且ETX之后还有2位校验码public byte[] Transact(byte[] frame, int maxRespLen) { lock (_lock) { _sp.DiscardInBuffer(); _sp.Write(frame, 0, frame.Length); Listbyte resp new Listbyte(); Stopwatch sw Stopwatch.StartNew(); while (sw.ElapsedMilliseconds 1000 resp.Count maxRespLen) { while (_sp.BytesToRead 0) resp.Add((byte)_sp.ReadByte()); if (IsFrameComplete(resp)) break; Thread.Sleep(5); } if (resp.Count 0) throw new TimeoutException(无响应检查接线和串口参数); return resp.ToArray(); } } private bool IsFrameComplete(Listbyte resp) { if (resp.Count 0) return false; if (resp[0] 0x15) // NAK响应 return resp.Count 3; if (resp[0] 0x02) // 正常响应 { int idx resp.IndexOf((byte)0x03); return idx 0 resp.Count idx 3; } return true; }这个同步收发方法配合单线程定时器完全够用。如果在UI线程里连续多次调用可以在调用外面包一层Task.Run避免界面卡顿。我的工具里实际是每次点击“读取”按钮时把整个Transact过程丢到后台线程执行完成后通过Invoke回UI线程更新RichTextBox和TextBox。还有一个细节DiscardInBuffer在每次发送前执行是为了清掉上一轮通信可能残留的垃圾数据。但如果PLC响应速度极快可能在清空后又收到上一轮的迟到帧那就会当作本轮响应来处理。稳妥的做法是在发送前加一个50ms的空闲等待确保线路干净。实测下来这个等待对9600波特率下的通信没有多少性能影响。4.4 测试工具界面与功能布局工具界面我分成四个区域逻辑清晰现场操作不费脑。左上角是串口连接区一个COM口下拉框、一个波特率下拉框默认9600、连接/断开按钮。连接成功后按钮状态会切换同时日志区打印当前使用的串口参数。左下角是软元件操作区。类型下拉框可选D寄存器或M继电器地址输入框用NumericUpDown限制范围数量输入框同样限位。对于D类型“读取”按钮会把值列表显示在中间的一个ListView里列名是地址、数值Hex、数值Dec。“写入”按钮则把一个TextBox里的逗号分隔数值解析后批量写入D。对于M类型“读取”按钮直接把返回的0/1序列显示出来“置位”和“复位”按钮分别对指定地址做强制置ON/OFF。右侧是日志区用一个RichTextBox显示。发送的帧和接收的帧分别打印带时间戳和方向标识发送帧有颜色规整要求就用普通颜色但可以同时显示十六进制串和ASCII原文。十六进制串是排查协议问题的第一依据ASCII原文方便人眼直接看出命令码和地址。底部状态栏放三个计数器发送帧数、接收帧数、最近一次响应耗时。响应耗时超过500ms就标黄显示方便快速发现链路劣化。这类工具不建议一开始就加很多高级功能。把D读取、M读取、D写入、M置位这四个核心操作做稳定就可以拿到现场用了。我在第一版工具里还加了一个“连续监视”功能定时每500ms读一组D并且把数值变化用不同的背景色标出来——这个功能在调试温度PID参数时特别好用人眼扫一遍就能看出趋势。5. 实测过程、踩坑与排查记录5.1 联机前的自检清单工具写好了硬件也接了直接插上PLC就跑十有八九不会一次成功。我每次联机前都过一遍自检清单顺序很重要PLC供电正常RUN灯亮或者STOP灯亮也行编程口在STOP状态同样能通信USB转RS422模块驱动安装完成设备管理器里能看到COM口号转换器到PLC圆口的线序确认过尤其是TXD/RXD交叉关系串口参数设为9600/8/Even/1先发一条最简单的读命令比如读取D0单点确认有响应如果读D0都没响应不要急着改代码。先用串口助手直接发原始十六进制帧看PLC回不回。这是区分“协议代码写错了”还是“硬件链路不通”的最快方法。我见过不少同行拿着调试好的工具去现场连新设备结果换了线序就完全不通问题往往出在硬件而非代码。串口助手发这个测试帧就行02 30 31 30 30 30 30 30 31 03 44 44等一下这个校验码需要重算。读取D0单点数据区是01000001累加和是48494848484848493345345取低8位89转十六进制是59不是44。完整的测试帧应该是02 30 31 30 30 30 30 30 31 03 35 39如果这条帧在串口助手发出去能收到正常响应就说明硬件链路没问题再把测试工具接上分析协议代码的问题。5.2 现场常见问题排查表把我在不同项目里踩过的坑整理成一张表按症状索引排查效率会高很多现象可能原因处理办法完全无响应TX灯闪、RX灯不闪收发线序接反对调TXD/RXD连接完全无响应TX和RX灯都不闪波特率或校验位设置不对尝试2400/4800/19200和Even/None组合时好时坏设备一启动就超时信号地SG未接或屏蔽层未接地连接SG到模块GND换双绞屏蔽线返回NAK 04校验和计算错误检查累加范围是否包含ETX检查大小写返回NAK 05命令码不识别检查命令码是否正确返回NAK 06地址或点数超出范围检查软元件地址映射和数量上限读M点正常读X/Y数据错乱X/Y八进制编号未转换为十进制用八进制解析后再加地址偏移NAK 04是写协议时最容易遇到的。很多人算校验和时要么忘了把ETX0x03加进去要么把STX也算进去了结果和PLC算出来的永远对不上。这个错误特别隐蔽因为单单肉眼看帧结构每个字符都对直到你逐字节去累加才发现差了1个或者多了2个。返回NAK 06也有一个新手容易踩的变体读取数量超过软元件范围。比如FX3U的M继电器范围是M0到M7679如果你发了M7500读取300个点超出的部分就会触发NAK 06。所以工具在界面层就要做范围校验而不是等PLC返回错误再去猜测。5.3 几条值得记住的经验把工具从“能用”打磨到“好用”我的个人经验集中在四个方面。第一协议解析层和UI层严格分离。协议层只负责构造字节流、解析字节流不依赖任何控件。这样以后把工具改成Windows服务、改成控制台程序或者集成到其他系统里协议层代码一行都不用动。我现在这个FxProtocol类已经复制到至少三个项目里用过了。第二日志功能一定要完整。收发帧的完整十六进制数据、时间戳、发送/接收方向、错误码全部记录下来。现场排查的时候很多问题不是当场能想明白的有一份完整的日志回去以后能慢慢分析。工具到后期甚至可以直接把日志导出成文本文件调试完发给设备厂商看省去大量口述沟通。第三连续监视功能比单次读写更有价值。单次读一个D寄存器看到的是瞬间值连续监视每隔500ms读一批才能看到数据变化趋势。调试PID参数时这条功能直接决定工具的实用度。我后来把连续监视做成了可配置的读写间隔、地址范围、终止条件都可以调。第四不要乱加Thread.Sleep强制延时。仿真和实验室设备响应很快现场设备经过长线缆和转换器响应会多几十毫秒。同步收发方法里只要超时时间设置合理用轮询等待返回就够了。我见过有人为了“稳定”每次发送前固定Sleep 300ms结果批量读写几十个参数要等半天完全没必要。还有一条很实用的小技巧工具连接PLC时如果打开串口报“拒绝访问”十有八九是别的软件占用了同一个COM口。现场调试经常同时开着串口助手、组态软件和自己的工具关掉其他占用程序就能解决。程序里也可以对打开失败给出更明确的提示文案而不是只弹一个Win32异常。写在最后的一点体会这个C#三菱FX编程口协议RS422圆口测试工具技术上不算高深但确实解决了我现场调试的一大痛点。回头复盘整个项目我最想强调的其实是“先确认硬件再调试软件”这个工作顺序。好几次卡了我一整天的所谓“协议问题”最后都是线序反了或者地线没接。RS422圆口接线说复杂不复杂说简单也不简单但只要耐心把引脚定义和收发交叉关系确认一遍再配合串口助手验证链路真正留给软件调试的时间其实很少。另外把校验和计算和地址映射这几块吃透FX系PLC的编程口通信基本就通关了。后续无论转换成什么形式的上位机系统——WinForms工具、WPF客户端、甚至Linux下的服务程序——核心都是这套帧构造和响应解析逻辑。希望这篇分享能帮你少踩几个我踩过的坑顺利把FX系列PLC的通信需求拿下。
