1. 项目背景与整体思路拆解1.1 为什么是“C# 串口 松下PLC”这个组合工业上位机开发里C#和PLC通信几乎是绕不开的活。我最早做这块的时候接的就是一台松下FP系列PLC通信方式要求走串口上位机用C#写。那会儿最大的困惑是协议资料有但网上讲得碎片化严重报文格式、地址换算、校验算法这些细节翻半天才能拼出个大概。等自己把第一帧“读DT寄存器”的报文完整调通、能从PLC里读到真实数值的那一刻整条链路才算真正通了。这个组合之所以常见是因为C#开发上位机界面效率高串口在短距离、小数据量的设备通信里依然非常可靠而松下PLC在中小型自动化设备里的存量很大很多旧设备、定型设备就只留了串口通信口。学会用C#通过串口和松下PLC通信本质上是在解决“PC上位机怎么跟现场设备对话”这个通用问题掌握了协议封装、串口收发、数据处理这些核心能力换任何品牌PLC都只是换一套命令格式的问题。这篇内容适合谁看刚接手工业通信项目的上位机开发人员被松下PLC的MEWTOCOL协议弄得一头雾水的人以及想把“读PLC数据”“写PLC数据”这类功能做成通用方法的人。我尽量按照实际项目的推进顺序来写先讲协议原理再给可直接用的C#代码最后把调试中容易踩的坑一次性说透。1.2 整体通信方案的设计逻辑做这个项目时我先明确了一个原则在能满足需求的前提下通信方案越简单越不容易出错。C#通过串口与松下PLC通信核心链路是上位机C#程序通过串口发送请求报文PLC收到报文后执行读/写操作PLC返回响应报文上位机解析出数据很多人问为什么不直接上Modbus等更通用的协议。答案很简单松下PLC的串口默认运行在MEWTOCOL协议你只要把MEWTOCOL的报文格式搞明白所有字寄存器、触点的读写都能覆盖如果额外加一层Modbus协议转换反而多了设备和配置环节。当然如果现场有多品牌PLC混用统一Modbus是有价值的但单品牌、单机通信场景下直接用原生协议最直接。串口参数的选择也要在早期定下来。我用的参数是波特率9600如果数据量大可以改成19200但PLC侧和上位机侧必须一致数据位8停止位1校验位None这里有个易错点不同型号、不同端口的出厂默认参数可能不一致比如有些通信口默认偶校验、停止位是2。实际调试时以PLC系统寄存器里的设置或官方编程软件的通信设置界面为准先把两边参数对齐再谈后面的协议。2. 先搞懂松下PLC的MEWTOCOL协议再动手2.1 协议帧结构拆解MEWTOCOL协议是松下FP系列PLC串口通信的基础它是一种“请求-响应”式协议上位机发一帧请求PLC回一帧响应一问一答非常简洁。帧结构可以用一张表说清楚字段说明示例帧头%表示请求帧#表示响应帧%或#站号2个ASCII十六进制字符默认0101命令码2到3个ASCII字符代表操作类型RDS、WDS数据段变长由具体命令决定地址、个数、数值等BCC校验2个ASCII十六进制字符37终止符\r回车\r站号是PLC的通信地址。单机直连时如果PLC站号是1报文里就写01如果有多个PLC挂在同一条串口总线上站号就是区分目标设备的唯一标识。命令码决定了这条报文要做什么比如RDS代表读取数据寄存器WDS代表写入数据寄存器。校验和终止符则是保证一帧数据“完整可靠”的关键。这里我强调一个理解关键点协议里所有数值除了BCC本身是二进制数转十六进制文本其余地址、数量、数据都是以ASCII十六进制字符的形式传输的。比如数值1234在报文里就是字符1、2、3、4而不是二进制字节。很多新手在这上面栽了跟头直接把数字当成二进制发出去PLC当然不认。2.2 命令码与寄存器地址映射掌握了帧骨架接下来就是命令码和地址的对应关系。我实际项目中用得最多的有4个命令RDS读取数据寄存器DT的值WDS写入数据寄存器DT的值RCS读取触点状态对应X、Y、R这类位地址WCS写入触点状态数据寄存器DT是字寄存器每个DT占16位取值范围0~65535是最常用的数据交换区域。比如PLC程序里把当前温度、压力、产量写到DT100上位机就能用RDS把它读回来。地址映射是整个协议里最容易让人发懵的部分。我的经验是报文中的地址 PLC编程软件里显示的寄存器编号直接转成4位十六进制ASCII文本。举个例子DT100 → 100 0x0064 → 报文地址填0064DT300 → 300 0x012C → 报文地址填012C有些资料里会提“字地址要乘以2再转十六进制”这说的是协议内部的物理地址偏移处理。但在实际和FP系列PLC通信时我用“寄存器编号直接转十六进制”的方式是可以正常读到数据的。如果你手头的型号读不出正确数据再观察一下PLC侧是否有地址偏移或者用官方编程软件里的地址表核对一遍这也是排查方向之一。读取触点的地址规则就要注意分组了。触点是位地址但报文里是以“字”16个触点为一组为最小单位传输的。比如X0这个输入触点对应到协议里是按位放在某一组数据的bit0上。实际项目中我建议能不碰触点就先用DT寄存器等寄存器通信稳定了再根据官方地址表去换算触点的组号可以少踩很多坑。2.3 BCC校验的手工计算与常见误区BCC校验是MEWTOCOL协议的可靠性保障计算方法很简单从站号开始到数据段结束所有字符的ASCII码按字节逐位异或得到一个字节再把这个字节转成2位大写的十六进制文本。我拿一个真实例子手算一遍读取DT100开始的10个字。报文数据段为01RDS0064000A逐字符取ASCII码异或十六进制0x30 ^ 0x31 0x010x01 ^ 0x52 0x530x53 ^ 0x44 0x170x17 ^ 0x53 0x440x44 ^ 0x30 0x740x74 ^ 0x30 0x440x44 ^ 0x36 0x720x72 ^ 0x34 0x460x46 ^ 0x30 0x760x76 ^ 0x30 0x460x46 ^ 0x30 0x760x76 ^ 0x41 0x37最后BCC结果是37所以完整请求帧是%01RDS0064000A37\r这里有一个非常关键的边界BCC只从站号算到数据段结束只算01RDS0064000A这一段不要包含前导的%也不要包含后面的终止符\r。我用C#的SerialPort调试时曾因为把%也带进去算校验导致PLC始终报错折腾了很久才发现是这个问题。还需要注意校验结果转十六进制时要大写9A写成9a在某些固件版本里会判错。代码里统一用ToString(X2)就能保证大小写正确下面给完整代码时也会体现。3. C#串口通信环境搭建与核心代码实现3.1 串口参数配置与初始化C#操作串口有现成封装核心就是System.IO.Ports.SerialPort这个类。项目里新建一个控制台应用或WinForms应用都可以关键是通信核心代码要独立成一个类方便复用。下面是我常用的初始化方式using System; using System.IO.Ports; using System.Text; public class PanasonicPlcClient { private SerialPort _port; public void Connect(string portName, int baudRate 9600) { _port new SerialPort(portName, baudRate, Parity.None, 8, StopBits.One); _port.ReadTimeout 1000; _port.WriteTimeout 1000; _port.DataReceived OnDataReceived; _port.Open(); } public void Disconnect() { if (_port ! null _port.IsOpen) { _port.Close(); } } private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { // 接收事件后面详细展开 } }这里几个细节值得说道打开串口前一定要确认串口号存在且没被其他程序占用否则会抛UnauthorizedAccessException。读写超时时间必须设置工业生产环境串口偶尔会卡住不设超时可能导致界面线程永久等待。DataReceived事件是异步触发的线程池线程不是UI线程。后面要更新界面必须用Invoke或BeginInvoke回到UI线程否则会报线程间非法操作。打开串口后最好先清空接收缓存_port.DiscardInBuffer()把历史残留数据丢掉避免干扰第一帧响应判断。3.2 BCC校验与报文封装核心代码BCC计算和报文封装是整个通信的核心我直接给出可以复用的代码。注意这里所有拼装都用StringBuilder做字符串拼接避免频繁创建中间对象。public static string CalcBcc(string content) { byte bcc 0x00; foreach (byte b in Encoding.ASCII.GetBytes(content)) { bcc ^ b; } return bcc.ToString(X2); } public static string BuildReadDt(int startAddr, int count) { string body $01RDS{startAddr:X4}{count:X2}; return $%{body}{CalcBcc(body)}\r; } public static string BuildWriteDt(int startAddr, string[] values) { int count values.Length; StringBuilder sb new StringBuilder(); sb.Append($01WDS{startAddr:X4}{count:X2}); foreach (string v in values) { sb.Append(v); } string body sb.ToString(); return $%{body}{CalcBcc(body)}\r; }用的时候string cmd BuildReadDt(100, 10); _port.Write(cmd);这条命令读的就是DT100到DT109共10个字的数值。注意startAddr:X4会自动把100转成0064count:X2把10转成0A。如果地址是200就自动转成00C8代码里完全不需要手工换算十六进制这就是把逻辑封装进函数的好处。3.3 帧接收与解析的完整处理收到PLC响应后不能直接假设一帧数据一次全到齐。串口通信和TCP一样会有粘包、半包的问题尤其波特率较高时会特别明显。我的处理方式是用一个临时字节列表缓存按协议里的终止符\r来切帧。读DT寄存器的响应帧结构是固定的# 01 RDS 数据段(4字符×字数) BCC(2字符) \r总共长度 1 2 3 4n 2 1 9 4n 字节n为读取字数。知道了长度就可以准确判断累计收到的字节数是否足够完整取出一帧。private Listbyte _recvBuffer new Listbyte(); private readonly object _lock new object(); private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { int bytesToRead _port.BytesToRead; byte[] buffer new byte[bytesToRead]; _port.Read(buffer, 0, bytesToRead); lock (_lock) { _recvBuffer.AddRange(buffer); } // 每收一次数据尝试解析一次 TryParseFrame(); } private void TryParseFrame() { lock (_lock) { // 找终止符 \r (0x0D) int endIndex _recvBuffer.IndexOf(0x0D); if (endIndex 0) return; // 数据还不完整继续等 byte[] frame _recvBuffer.Take(endIndex 1).ToArray(); _recvBuffer.RemoveRange(0, endIndex 1); string frameStr Encoding.ASCII.GetString(frame); // 交给业务解析 ParseResponse(frameStr); } }核心逻辑是收到数据先追加到缓冲区然后找\r一找到就切出包含\r在内的完整数据。这样就算一帧数据被拆成3段到达也能正确拼起来。切出响应帧后还要确认命令码是否带!错误标记。MEWTOCOL协议里如果命令执行出错PLC会返回!开头的错误码比如!01RDS E2 // 命令格式错误这种响应数据里不会有正常的寄存器数值必须根据错误码判断异常然后给出对应的提示信息而不能傻傻地去解析后面的数据。4. 完整实操读写松下PLC的DT数据寄存器4.1 读DT寄存器报文拼装到数据解析现在把上面几段代码串起来走一遍完整流程。目标是读取PLC中DT100开始的10个字寄存器。第一步用BuildReadDt(100, 10)拼出报文%01RDS0064000A37\r第二步把这个字符串写入串口string cmd BuildReadDt(100, 10); _port.Write(cmd);第三步PLC返回的响应帧形如#01RDS000100020003000400050006000700080009000A37\r这里数据段格式是每个寄存器数值用4个十六进制字符表示连续排列。解析时就按每4个字符切一组private void ParseReadDtResponse(string cmd, string dataPart, int count) { Listint values new Listint(); for (int i 0; i count; i) { string hex dataPart.Substring(i * 4, 4); values.Add(Convert.ToInt32(hex, 16)); } // 此时 values[0] 对应DT100的值values[1]对应DT101以此类推 }这里要注意区分有符号和无符号。松下DT寄存器本身是无符号16位整数范围0~65535。如果你的PLC程序里存的是负数实际是以补码形式存储上位机读取时需要自己判断比如大于32767就做减法。这个细节在处理温度、位移等带符号工程值时很关键。如果PLC程序里改过寄存器的值上位机读到的应该立即变化。我在调试时习惯先在PLC侧用一个固定的计数器或定时器把DT100的值持续刷新上位机读回来后做个简单的趋势变化就能确认通信链路没问题。4.2 写DT寄存器数据格式与注意事项写入操作比读取多一个环节要把数值拼到报文里。比如要把DT200写成1234DT201写成5678报文就是string cmd BuildWriteDt(200, new string[] { 1234, 5678 });拼出来是%01WDS00C800021234567830\rPLC如果接收正确会返回一个不带数据的简短响应#01WDS30\r写操作有几个容易踩的坑数值必须是4位十六进制ASCII12要写成0012不能偷懒写成12。一次写入的数量要和控制字对应。比如我要写6个字count:X2就是06后面的数据段也必须有24个十六进制字符数量不对PLC会回错误码。写入地址不要越界。不同型号的FP系列PLCDT保持区域范围可能到DT59999但普通DT区一般只到DT9999。写入超出范围通信层没问题PLC执行时会报错最好在代码里做个范围校验。写完还可以马上用读命令把数值读回来验证等于形成一个闭环自检。我在项目里就封装了一个WriteThenVerify的方法先写再读比对不一致就重试一次这样能及时发现通信链路不稳定或寄存器地址不连续的问题。4.3 实操验证流程不接PLC也能先测协议如果PLC不在手边或者不想在PLC程序里临时加通信测试代码可以用虚拟串口的方式先把协议调通。我说的虚拟串口就是成对创建的串口比如COM3和COM4是一对数据从COM3发出COM4能收到。实际操作流程是C#程序连接COM3。用串口调试工具打开COM4。C#程序发送读DT指令在调试工具里看收到的原始报文确认格式是%01RDS0064000A37\r。手动在调试工具里输入PLC应有的响应帧比如#01RDS000100020003000400050006000700080009000A37\r发给C#程序看解析结果是否变成1、2、3……10。这套验证方式能把协议封装和PLC错误区分开协议层有问题虚拟串口阶段就能暴露接线或PLC设置有问题也只需要在联机后单独排查不用同时面对两堆问题。我强烈建议所有上位机通信开发都先用这种方法做一遍冒烟测试。5. 常见问题与排查技巧实录5.1 超时无响应的几个排查方向通信没反应是新手最头疼的问题。根据我的经验按以下顺序排查基本能覆盖大部分情况首查串口参数。波特率、数据位、停止位、校验位要和PLC侧完全一致一个对不上就没有响应。PLC的通信口默认参数不一定都是9600 8 N 1有的型号扩展通信口默认是19200、偶校验。次查站号和接线。站号写错PLC会把报文当作别人的消息直接丢弃。接线要确认设备是RS232还是RS485RS232是3线TXD、RXD、GNDRS485是2线A、B收发串口线交叉接对。再查PLC通信协议模式。松下PLC的通信口需要工作在MEWTOCOL协议模式下有的PLC程序里可以改通信设置如果把协议改成了别的模式比如专用协议或计算机链路上位机发MEWTOCOL报文就完全没反应。我遇到过一台设备被人改成其他模式后一直没响应最后对PLC系统寄存器重新初始化才好。5.2 BCC校验错误的根源校验错误通常表现为PLC返回!开头的错误帧或者在调试工具里看到PLC完全没反应。最常见的原因是校验的范围算错了。记住一条原则BCC只算报文中间那段从站号开始、到数据段结束不包含前导%、不包含终止符\r。如果你用整个请求帧去异或结果一定和PLC算出来不一致。第二常见的问题是十六进制大小写。校验结果转成字符串时一定要大写比如9F不能写成9f。C#里ToString(X2)天然就是大写但如果你手动拼字符串就要留意。第三确认异或的对象是ASCII码的十六进制值而不是直接对十六进制字符串做异或。很多人把A当成10去异或得到的结果完全错误。正确的做法是用ASCII码0x41参与计算而不是数值10。5.3 粘包、脏数据与残帧处理串口通信是流式的没有天然的“消息边界”。我总结了一套处理策略接收端用缓冲区累积数据不要每收到几个字节就立刻去解析识别内容。帧以\r为终止。收到\r表示一帧完整消息结束可以切出来交给上层处理。切完一帧后如果缓冲区里还有多余数据继续循坏找下一个\r这就是粘包的正常处理。程序刚打开串口时如果缓冲区有历史残留半包数据会造成第一帧处理异常。解决方案是在Open后调用一次DiscardInBuffer或者把缓冲区在连接时清空一次。还有一点经验值得分享工业环境的电磁干扰会导致个别字节被干扰、变成乱字符。数据解析时最好加一个“类型检查”比如读DT响应里数据段应当全是十六进制字符0-9A-F如果出现其他字符直接判定本帧异常并丢弃同时进行重发。不要强行走完解析流程否则可能得到莫名其妙的大数影响业务判断。5.4 通信速度与指令间隔的平衡最后说一个很实际的问题指令发多快合适。PLC串口通信不是无限快的CPU处理每一帧都需要时间而且时序要求严格通常是“发一帧等响应收到后再发下一帧”。我习惯在每一次请求之间做最多3次重试每次等待时间200~500ms。如果持续超时就要考虑PLC是否处于停止模式或通信口被占用而不只是盲目加速重发。指令间隔太短会导致响应队列堆积、丢帧严重时还会让PLC通信口进入异常状态。稳妥的节奏是上位机发起请求 → 等待响应 → 超时则重试 → 连续失败则抛出通信异常并提示用户检查设备。这种做法比一味提高循环频率可靠得多。6. 最后再分享几点实操体会我在几次项目里用这套方案读写过多个型号的松下PLC最大的感受是协议本身不复杂复杂的是各种细节边界。现在回头看真正让我省时间的不是某个高深的技巧而是把“BCC计算、地址转换、帧拼接、响应解析”这四个步骤全部封装成独立、可单测的公共方法。一旦哪个环节出了问题我可以直接单独测这个函数不用每次拿到整条链路上去猜。另外通信调试中一定要先抓原始报文再看解析结果。不要一上来就盯着解析出来的数字对不对——数字不对往往意味着报文已经错了而报文的完整内容才是第一现场。用调试工具把收发帧完整的看一遍85%的问题都能定位。如果你想把这个内容继续扩展下一步可以考虑做批量读写的自动化测试、增加重试机制和看门狗逻辑甚至把松下通信层抽成独立的动态库供多个上位机项目共用。只要底层的协议封装稳定往上加任何业务逻辑都会很顺手。