简介松下PLC配套的Modbus通信C#实例源码包面向工业自动化开发人员及PLC上位机初学者解决通过Modbus协议与松下PLC建立通信读取运行时间、停止时间、故障时间、故障次数、C/T及设备状态等关键数据的实用问题方案中已包含状态统计字段的完整处理逻辑。压缩包共41个文件大小仅547KB包含6个C#源码文件、6个可直接运行的exe、配套dll与pdb调试符号以及项目工程文件、配置和资源文件结构紧凑适合直接打开工程参考或二次修改。已有1564人学习下载说明该实例在同类需求中具备较高的参考价值。源码包含完整窗体界面与通信实现可帮助读者快速理解松下PLC的Modbus地址映射、数据读取和状态解析流程新手可对照运行结果上手有经验者也能直接复用其中的通信封装与排错思路。1. 松下PLC的Modbus通道为什么C#上位机先别找官方SDK看到“松下PLC 通讯(modbus)C#实例源码”这个标题多半是产线或设备改造项目的现场需求PLC已经跑了好几年上位机要接过去读温度、压力、计数值或者下发配方和启停信号。常见的误区是以为松下一定有自己的官方SDK绕一大圈发现要么版本对不上要么授权麻烦。我的经验是把PLC侧配成Modbus从站C#侧按标准Modbus协议组帧收发这样最通用、最容易被验证也最能复用现成的调试工具。这套方案适合两类人一类是刚转C#上位机开发的软件工程师手里没有PLC手册也看不完协议文档另一类是现场电气工程师被领导要求“用C#把数据读出来”。本文就按我实际调试的顺序把选型、报文、代码、参数和反复踩到的坑一次写完。2. 先定通讯模型RTU串口还是TCP、松下地址怎么换算成寄存器2.1 RTU与TCP现场选型不是拍脑袋Modbus本身是应用层协议到了物理层主要分成两条路基于RS485串口的Modbus RTU和基于以太网的Modbus TCP。松下PLC老型号通常靠本体上的通讯口或扩展通讯单元走RTU新型号或者外加以太网模块后可以直接走TCP。选型依据其实很实际如果上位机就在电控柜附近距离二三十米内设备数量也就是一台两台用RS485最省钱一个USB转485头加两根线就能开工如果PLC分散在不同电控柜或者上位机在车间中控室、办公室就优先TCP一根网线就能过交换机跨车间也不用担心线缆衰减。还有一种情况我遇到过不少现场布线已经固定强电电缆和485线走同一个线槽电磁干扰大的时候TCP反而比串口抗干扰能力好。反过来也有距离短、设备少时硬上TCP还得给PLC配以太网模块成本不值。看一眼实际拓扑再决定不要为了“先进”而选型。维度Modbus RTU (RS485)Modbus TCP物理层屏蔽双绞线A/B差分以太网RJ45 / 交换机典型速率9600 / 19200 bps10/100 Mbps拓扑一主多从手拉手星型为主跨交换机硬件成本低线转换头略高PLC侧要加模块排障重点接线、终端电阻、校验IP、端口、从站模式注意RS232口不要强行拉长线超过15米后丢帧率会明显上升。RS485理论距离远得多但实际布线不按规范来照样频繁超时。2.2 松下PLC的地址区域和Modbus寄存器映射先画一张表在松下FP系列里程序里看到的是R0、DT0、WX、WY这类地址但Modbus不认这个命名它只认线圈区和寄存器区。常见做法是把松下PLC的数据寄存器映射到Modbus的保持寄存器用功能码03去读把输出线圈映射到Modbus线圈区用功能码01和05去操作模拟量输入通道则映射到输入寄存器用功能码04读。Modbus区对应松下区域常用功能码数据方向0区 线圈内部继电器 / 输出01读、05写单线圈上位机到PLC1区 离散输入X区输入端子02读PLC到上位机3区 输入寄存器模拟量输入通道04读PLC到上位机4区 保持寄存器DT / R数据寄存器03读、06写单个、16写多个双向这里最容易翻车的不是功能码而是地址偏移。不同通讯单元、不同系列PLC把“DT0”映射到Modbus地址0还是地址100并不是统一的。我一般会把偏移量做成配置文件里的一个int变量而不是在代码里写死。调换PLC型号时只改配置不动逻辑。// 地址换算伪代码偏移量从配置读取不要拍脑袋写死 int offset ReadConfigint(ModbusOffset); int modbusAddr dtNumber - offset; byte[] req BuildReadRequest(1, (ushort)modbusAddr, 1);这个偏移量具体是多少别听网上说也别完全信旧项目代码。新接一台PLC时先用调试工具扫一遍地址把“已知值”找出来再反推偏移。这个环节在第5章的排查部分还会重点讲。2.3 配置路径通讯单元的DIP开关与PLC侧协议设置PLC侧配置不规范C#代码写得再对也没用。常见操作顺序是三步先把通讯单元或通讯板卡插到PLC对应槽位按手册拨DIP开关设定波特率和校验方式然后在FPWIN GR软件的系统寄存器里把该通讯口指定为“通用串行通讯”或“Modbus从站”模式最后设好站号确认和C#程序里写的从站地址一致。整个过程里DIP开关拨码表最容易被忽略我强烈建议把它拍下来存档。后面调试时如果有人动过拨码没有原始照片只能靠回忆非常被动。走以太网时则要确认三样东西IP地址、端口502、以及“Modbus TCP从站”功能是否启用。注意不少松下以太网模块默认跑的是自己的MC协议不在PLC侧改成Modbus从站模式C#发03功能码读保持寄存器报文再标准也不会得到回应。这种“不回帧”比报错更难查。3. 最小可跑实例C#串口读松下保持寄存器的完整代码3.1 工程准备目标框架、串口库与CRC16校验函数新建一个.NET控制台项目就能做原型目标框架用.NET Framework 4.7.2或.NET 8都行C#上位机开发里这两种最常见。串口部分直接用System.IO.Ports.SerialPort不需要额外库。TCP部分可以引用NuGet上的NModbus4或其后续维护版本但如果RTU也完全依赖库报文结构不透明出了问题很难判断是库的错还是参数配错。Modbus RTU报文要求帧尾带两个字节的CRC16校验。网上有各种校验码在线计算工具但自己写一遍最稳妥也能离线自测拿已知字符串算一次和工具结果比对确认函数没问题再上设备。下面这个函数是我一直在用的版本基于Modbus标准的多项式0xA001反射算法static byte[] Crc16(byte[] data) { ushort crc 0xFFFF; for (int i 0; i data.Length; i) { crc ^ data[i]; for (int j 0; j 8; j) { if ((crc 1) ! 0) crc (ushort)((crc 1) ^ 0xA001); else crc 1; } } return new byte[] { (byte)(crc 0xFF), (byte)(crc 8) }; }函数返回的两个字节中第一个是CRC低字节第二个是高字节。Modbus RTU发送时低字节在前所以这个返回顺序可以直接追加到报文末尾不用再交换位置。这是最常见的低级失误点校验值算对了但字节序反了帧发出去设备完全不认。3.2 读保持寄存器请求帧构造与响应解析的完整代码读保持寄存器用功能码03。请求帧固定8字节从站地址、功能码03、起始地址高字节、起始地址低字节、寄存器数量高字节、寄存器数量低字节、CRC低字节、CRC高字节。下面先构造请求帧再写一个带超时的收发函数static byte[] BuildReadRequest(byte slaveId, ushort startAddr, ushort count) { if (count 1 || count 125) throw new ArgumentOutOfRangeException(nameof(count), Modbus单次最多读125个寄存器); byte[] frame new byte[8]; frame[0] slaveId; frame[1] 0x03; frame[2] (byte)(startAddr 8); frame[3] (byte)(startAddr 0xFF); frame[4] (byte)(count 8); frame[5] (byte)(count 0xFF); byte[] crc Crc16(frame.Take(6).ToArray()); frame[6] crc[0]; frame[7] crc[1]; return frame; }count上限设为125是Modbus协议本身的限制超过这个值从站会返回异常码。接下来是发送并读取响应。串口数据是分块到达的不能发了请求后立刻Read一整个数组要用时间片轮询把字节拼完static byte[] SendAndRead(SerialPort sp, byte[] req, int timeoutMs) { sp.DiscardInBuffer(); sp.Write(req, 0, req.Length); // 响应长度 从站地址1 功能码1 字节数1 数据2*count CRC2 int count (req[4] 8) | req[5]; int expectedLen 5 2 * count; Listbyte buffer new Listbyte(); Stopwatch sw Stopwatch.StartNew(); while (sw.ElapsedMilliseconds timeoutMs buffer.Count expectedLen) { if (sp.BytesToRead 0) { byte[] tmp new byte[sp.BytesToRead]; int n sp.Read(tmp, 0, tmp.Length); buffer.AddRange(tmp.Take(n)); } else { Thread.Sleep(5); } } if (buffer.Count expectedLen) throw new TimeoutException($只收到 {buffer.Count}/{expectedLen} 字节); return buffer.ToArray(); }这个函数的关键是按“期望字节数”提前退出而不是固定Sleep几毫秒再读。波特率不同、寄存器数量不同响应耗时差别很大固定延时要么太慢要么读不完整。接下来解析响应读到的数据是两个字节一组的大端整数static ushort[] ParseReadResponse(byte[] resp) { if (resp.Length 3 || resp[1] ! 0x03) throw new Exception(响应异常功能码不是03看异常码定位原因); int byteCount resp[2]; ushort[] values new ushort[byteCount / 2]; for (int i 0; i values.Length; i) { values[i] (ushort)((resp[3 i * 2] 8) | resp[4 i * 2]); } return values; }生产环境里这里还要再算一次CRC校验响应帧我为了演示从简。调用端初始化串口时波特率、校验位必须和PLC侧拨码一致常见默认是9600、8位数据、偶校验、1位停止位写成Parity.Even如果PLC侧拨成无校验就改成Parity.None。using SerialPort sp new SerialPort(COM3, 9600, Parity.Even, 8, StopBits.One); sp.ReadTimeout 300; sp.Open(); byte[] req BuildReadRequest(0x01, 0, 10); byte[] resp SendAndRead(sp, req, 500); ushort[] values ParseReadResponse(resp); foreach (ushort v in values) Console.WriteLine(v);如果响应帧的功能码变成0x83说明从站报了异常异常码1表示功能码不支持2表示起始地址非法3表示寄存器数量越界。先看异常码比傻等超时高效得多。3.3 加一个TCP版本用库把连接拉起来TCP侧不需要自己拼帧和CRC这些由NModbus4内部处理。连接和读取的核心代码可以很简练using var tcp new TcpClient(192.168.1.10, 502); tcp.ReceiveTimeout 500; tcp.SendTimeout 500; var factory new ModbusFactory(); var master factory.CreateModbusIpMaster(tcp); ushort[] values master.ReadHoldingRegisters(1, 0, 10);三个参数分别是从站地址、起始地址、寄存器数量。TCP报文里的MBAP头本身带了单元号但很多松下PLC从站仍然要求这个值写成1和RTU保持一致能减少切换成本。这里有一个经验TcpClient要作为长连接复用不要每个读周期都new一个否则短时间内大量断连重建到后面会出现“能连接但读取不响应”的怪现象。原因多半出在PLC以太网模块的会话资源耗尽要么等几分钟恢复要么重启模块现场非常尴尬。4. 写深一层线圈写、32位寄存器与浮点字序、轮询调度骨架4.1 写单个线圈与写多个寄存器控制输出和批量下发的两条命令读数据只是上位机的一半需求真正让方案值钱的是“能控制”。Modbus写单个线圈用功能码05请求帧里的对应值是固定的ON必须写0xFF00OFF必须写0x0000写成0xFFFF或者0x0001都会让PLC判定为非法值。这是协议约定不是由我们随便定的。批量下发用功能码16也就是0x10适合一次写入设备参数、报警阈值或配方数据。请求帧结构比读请求复杂多了字节数统计和要写入的数据区static byte[] BuildWriteMultipleRequest(byte slaveId, ushort startAddr, ushort[] values) { if (values.Length 1 || values.Length 123) throw new ArgumentOutOfRangeException(nameof(values), Modbus单次最多写123个寄存器); int byteCount values.Length * 2; byte[] frame new byte[9 byteCount]; frame[0] slaveId; frame[1] 0x10; frame[2] (byte)(startAddr 8); frame[3] (byte)(startAddr 0xFF); frame[4] (byte)(values.Length 8); frame[5] (byte)(values.Length 0xFF); frame[6] (byte)byteCount; for (int i 0; i values.Length; i) { frame[7 i * 2] (byte)(values[i] 8); frame[8 i * 2] (byte)(values[i] 0xFF); } byte[] crc Crc16(frame.Take(frame.Length - 2).ToArray()); frame[^2] crc[0]; frame[^1] crc[1]; return frame; }收到响应后先判断功能码是不是0x10正常响应只有8字节原样回显从站地址、功能码、起始地址和数量不会再返回写入的数据。如果返回0x90说明写入的地址或数量越界。批量下发时寄存器数量上限是123因为要控制整个RTU报文不超过256字节超了就拆成多包顺序发。4.2 32位寄存器与浮点转换松下的低字在前要被单独拎出来PLC里的单精度浮点数和32位整数在Modbus里需要占两个连续的保持寄存器。Modbus规定单个16位寄存器内部是大端字节序但两个寄存器的先后顺序由设备厂商决定这里正是C#上位机最容易翻车的区域。松下FP系列里32位数据和32位浮点常见排布是“低16位字在前、高16位字在后”也就是说起始地址对应低字下一地址对应高字。如果按西门子那种习惯去拼读到的数值会变成一个完全不可信的天文数字。// raw[0] 是低16位寄存器raw[1] 是高16位寄存器 ushort low raw[0]; ushort high raw[1]; uint raw32 (uint)((high 16) | low); float value BitConverter.ToSingle(BitConverter.GetBytes(raw32), 0);BitConverter.GetBytes拿到的是一个4字节的uint表示在小端机器上转float不需要额外调整。验证字序有一个笨但可靠的办法在PLC里放一个已知浮点数比如1.5然后去读两个连续寄存器。1.5的IEEE 754表示是0x3FC0 0000高位部分是0x3FC0低位部分是0x0000。如果读到第一个寄存器是0x0000、第二个是0x3FC0说明低字在前反过来则说明这个型号是高字在前。用这个方法实测一次比翻手册猜省事得多。另外还要注意缩放因子。很多温度变送器或PLC内部工程量不是原值比如寄存器值1200实际代表120.0摄氏度。这类倍率参数也应该做成配置不要写在业务代码里。4.3 轮询调度与超时重试不让上位机卡死的通讯骨架现场跑起来后上位机不可能只读一次数据通常每秒要刷新一组寄存器还要处理断线重连。最容易犯的错是给每个表项开一个Timer几个线程同时去操作同一个串口。RS485是半双工总线两个请求同时在物理线路上发送等于互相干扰最终两个请求都超时。正确做法是整个总线只有一个串口队列所有读写操作串行执行。我习惯用一个SemaphoreSlim锁把“组帧、发送、等待、解析”整段保护起来轮询循环里逐个读取各寄存器组private readonly SemaphoreSlim _busLock new SemaphoreSlim(1, 1); public async Task PollLoop(CancellationToken ct) { while (!ct.IsCancellationRequested) { await _busLock.WaitAsync(ct); try { // 依次读温度、压力、计数值等寄存器组 // 每组独立try/catch一组失败不影响其他组 } finally { _busLock.Release(); } await Task.Delay(100, ct); } }轮询周期不是越小越好。一个寄存器组读一次大约几十毫秒串行轮询时总周期至少是“所有组超时上限之和”。如果从站离线每组要耗掉一个超时时间这时要立即重试两次然后标记离线而不是无限等待把后续寄存器组全部拖死。断线自动重连也要放在这个循环里串口断开时重新OpenTCP断开时重新new TcpClient并加一个延迟退避比如失败后等2秒再试避免疯狂刷异常日志。这个骨架搭好后上位机界面只管显示最近一次快照通讯逻辑完全独立不容易被UI卡住拖累。5. 高频翻车点排查从无响应、CRC错到触摸屏和上位机打架下面这些坑都是实际调过的按“现象、原因、解决”的顺序写。碰到问题时先对照现象别急着改代码。5.1 报文看着都对PLC就是不回帧现象用调试工具或C#发了标准的03功能码请求CRC也算了串口指示灯也在闪但PLC像没收到一样没有任何答复。原因按顺序查第一站号不匹配PLC侧站号是2程序里写的是1第二PLC通讯口没有被配置成Modbus从站模式还停留在默认的编程口通讯第三波特率和校验位对不上设备拨码第四报文本身没问题但把RTU帧错发到了TCP端口上。解决我一般会先用现成的Modbus调试工具从站号1开始逐个试确定外部工具能通之后再回到C#代码。调试工具的成功报文要截图存下来和C#打出来的Hex帧逐字节对比。很多“看似没回”实际是CRC低字节高字节顺序反了人眼看不出但设备拒收。5.2 CRC和BCC校验混用老款FP系列通讯单元的一个老坑现象在同一套代码下一部分设备正常另一部分老款松下FP系列完全不理会或者刚上电时正常运行一段时间后偶发不响应重发一次又好了。原因部分老款FP系列通讯单元默认使用BCC校验也就是对报文逐字节异或而不是Modbus标准的CRC16。帧头帧尾结构一样但校验区算法不同PLC按BCC算出来不匹配直接丢弃这一帧。解决首选方案是查通讯单元的拨码或PLC参数把通讯模式固定为“Modbus模式CRC16”。如果现场设备被其他人改过配置不方便纠正可以在程序里加一个自动切换逻辑先用CRC16发一次超时后用同一帧内容但把最后两个字节换成正向异或的结果再发一次。这个试探逻辑只用于初期联调投产前必须固定为一种模式否则链路行为不可预测。校验方式计算规则常见场景CRC16多项式0xA001反射运算标准Modbus RTUBCC每字节异或部分老款FP系列通讯单元无校验固定填充0非标透传5.3 能握手但读到的值恒为0地址映射和字内位序的偏差现象通讯完全正常请求有响应寄存器个数也对但无论换哪个地址读上来的值都是0或者偶尔读到个别寄存器有值而大部分是0。原因最常见的是地址映射偏差。松下PLC把DT寄存器和Modbus地址的对应关系受型号、通讯板卡和系统寄存器设置影响DT0并不天然等于Modbus地址0。另一个原因是读错区域比如把线圈区当成保持寄存器来读线圈本来就是0和1的状态量。解决在PLC程序里写一个固定的已知值比如把整数100传到DT100然后用调试工具从地址0开始逐步往后读直到找到那个值等于100的地址反推出偏移。随后把这个偏移量写进配置文件。验证“值是0”的问题时先确认PLC里这个寄存器真的有值再怀疑程序问题往往能省掉很多无用功。5.4 偶发超时和整链路罢工485接线、终端电阻和共地现象设备距离短时一切正常线缆拉长或者车间有大设备启停通讯就开始偶尔超时严重时完全断掉。换了一台电脑问题还在。原因A、B线如果接反链路完全不通缺少终端电阻会导致信号反射距离短时看不出来线一长就丢帧RS485的SG参考地没有和上位机共地共模电压漂移会让接收端把电平误判。解决A、B线反接用万用表在通讯空闲时量A对B的电压正常应该为正的2到5伏如果为负就是接反了。终端电阻按RS485标准在总线两端各并一个120欧姆。屏蔽层单端接地即可不要两端都接更不要直接把屏蔽层接到变频器的动力大地上。5.5 触摸屏和上位机同挂一条总线的“打架”问题现象PLC一侧挂着MCGS触摸屏一侧挂着C#上位机。单独测任一个都正常两边同时运行后触摸屏偶尔弹通讯错误上位机也会收到不完整的帧数据刷新出现毛刺。原因触摸屏和上位机都把自己当成主站RS485半双工总线上同时有两个主站发作请求报文在物理线上碰撞两个请求都被破坏两边都认为是对方设备有问题。解决常见做法是只保留一个主站。让触摸屏在PLC侧配置成从站由C#上位机统一轮询或者把触摸屏改成以太网口单独走交换机和Modbus串口总线隔离。如果现场条件不允许做任何改动只能把上位机轮询周期拉长让两个主站撞车的概率降低但这只是缓解不能根除。6. 联调验证的收口技巧用Modbus Poll先证链路再用日志倒查时序6.1 四步把链路从头到尾钉死整个方案值不值得投入最终要看联调效率。我自己的联调顺序从来没有变过四步走完基本能定位九成问题。第一步用Modbus Poll做外部工具验证把站号、波特率、校验位设成和PLC侧拨码一致读一个已知寄存器外部工具通了再认为是C#代码的问题不要反着来。第二步在PLC程序里放一个已知测试值比如把10.0写入某个寄存器C#读回这个值就同时验证了地址映射、字序和倍率三项。第三步连续挂机两小时记录失败率期间故意拔插一次串口或断开网线观察程序能否自动重连。第四步记录每次请求的平均耗时和最大耗时为以后增加寄存器组预留轮询周期余量。这套顺序最值钱的是第二步它把协议层、地址层、业务换算层一次验证完而不是逐个猜。6.2 一个日志习惯把Hex帧留下来出问题才有后悔药间歇性故障最让人头疼的是“现场复现不了”等日志打出来时已经过去了。我习惯在收发函数里加一行落盘把时间、原始帧和耗时一起写进文件File.AppendAllText(modbus.log, ${DateTime.Now:HH:mm:ss.fff} $TX:{BitConverter.ToString(req)} $RX:{BitConverter.ToString(resp)} ${sw.ElapsedMilliseconds}ms\r\n);注意正常运行时不建议全量记录每秒几十条日志文件会涨得很快。加一个Debug开关只在联调期开启或者在失败分支里记录。这个日志习惯帮我在一次现场事故中省了大半天当时上位机和触摸屏一起读故障间隔完全随机靠日志发现失败帧的字节数和正常响应差4个字节才定位到两个主站抢总线的问题。现在我接手任何松下PLC通讯项目第一天就做三件事拍通讯单元拨码、在PLC里放已知测试值、把Hex日志开关打开。这三件事做完剩下只是照章办事。希望帮到你。本文还有配套的精品资源点击获取