尧图网页设计 
简介一套松下PLC通过Modbus协议与C#上位机通信的实例源码面向PLC入门开发者及有经验的工控人员。项目可实现与松下PLC建立通信链路读取运行时间、停止时间、故障次数、C/T计数器及设备状态等关键信息代码结构清晰适合作为二次开发或学习Modbus通信封装的原型参考。压缩包共41个文件包含6个C#源程序、6个可直接运行的exe、4个动态库dll及调试符号pdb另有界面资源resx、工程配置csproj与解决方案sln等整体仅547KB轻量且便于快速查看与复用。目前已有1564人学习浏览经过亲测验证有效。资源不仅提供完整的通信调用流程还包含WinForm界面与设备状态展示方式可帮助开发者快速理解松下PLC寄存器映射、报文拼接解析及异常处理思路缩短实际项目的调试周期。1. 松下PLC Modbus C#为什么上位机采集绕不开这个组合车间里被问得最多的组合之一就是“松下PLC Modbus C#”。一台松下FP系列PLC一条RS-485串口总线一个用C#写的上位机要把DT寄存器里的产量、温度、报警状态周期性拿回来供MES展示或者存数据库。这条路便宜、协议公开不依赖松下专用DLL抓包能看到每一个字节出了问题好排查。很多人一听“松下PLC通讯设置”“modbus rtu”就觉得要啃手册其实只要把PLC侧地址映射搞明白C#侧报文按规范填一个周末就能跑通最小可用版本。这篇笔记按“PLC侧配置→C#实例源码→踩坑→调试”的顺序展开适合第一次做松下采集也想把Modbus协议彻底弄懂的人。2. 松下PLC的Modbus从站配置与寄存器地址映射2.1 用Modbus TCP还是Modbus RTU先做第一个决定走串口还是走以太网。松下FP0R、FP-X这类老派机型CPU自带COM口默认是“计算机链接”协议把参数切到“Modbus RTU从站”就能用想走以太网就得加以太网模块或者直接上FP7这种新款PLC对外提供的是Modbus TCP。RTU和TCP的帧格式不一样C#这边拿错协议栈会非常头疼。绝大多数产线场景我推荐先上RTU。RS-485串口通讯抗干扰在车间够用波特率拉到9600每台PLC分配一个站号一条总线挂十几台设备很常见。RTU帧比TCP多一个CRC校验反而更容易定位问题。只有设备距离超过几百米或者上位机不在同一个电柜里我才会考虑以太网和Modbus TCP。TCP没有CRC定位错帧得依赖TCP层的校验现场调试仪器要求也更高。两种方式的取舍可以先看这张表对比项Modbus RTUModbus TCP物理层RS-232 / RS-485以太网典型速率9600 / 1920010/100M帧校验CRC16无独立CRC松下常见载体CPU自带COM口以太网模块 / FP7适用场景单电柜或几十米内跨楼层、接MES机房实际项目里我习惯先按RTU打通因为接线和排查都直观。等整个采集链路稳定了如果网络条件要求走TCP再在C#侧换一个ModbusTcpClient封装PLC侧地址映射不变改动成本很小。2.2 在FPWIN里把通信口设成Modbus从站很多人写了一天代码发现不通最后发现是PLC侧参数没设。用FPWIN GR或FPWIN Pro打开工程在左侧项目树里找到“系统寄存器”或“PLC参数”下的“通信设置”子项。找到COM口索引FP-X一般是COM0或COM1把通信模式从“计算机链接”改成“MODBUS RTU 从站”。站号我习惯设成1便于测试多台设备时按1到247分配。下面几项必须和C#串口打开参数完全一致波特率、数据位、校验位、停止位。我的默认组合是9600、8位数据位、无校验、1位停止位松下PLC侧也选“8位、无校验、1停止位”。如果现场要求偶校验两边都要改成Even只改一端就会一直收不到正常响应。参数修改完把工程下载到PLC然后断电重新上电一次。部分松下机型是“下载后生效”在线修改不会立刻激活这是很多调试现场翻车的原因。重上电后在FPWIN的监视模式里往DT100写一个888之类的已知数方便第二步上位机验证。2.3 地址映射DT、R怎么换算成Modbus地址Modbus协议只有两类寻址维度线圈和寄存器。松下PLC的DT数据寄存器对应保持寄存器R内部继电器对应线圈X/Y开关量能不能映射要看具体机型的通信手册。常见映射方向如下松下内部资源功能码对应Modbus区域DT16位数据寄存器0x03读 / 0x06、0x10写保持寄存器4x区R内部继电器0x01读 / 0x05、0x0F写线圈0x区X/Y输入输出0x02读离散输入1x区以FP0R常见通信手册为例DT0对应保持寄存器协议地址0DT100对应协议地址100上位机软件习惯记作40101R0对应线圈协议地址0。请求帧里地址字段填十进制100功能码0x03数量填1发出hex如下面第5章的报文例子。真正容易出问题的不是这步而是不同型号偏移不一样。有的型号DT从地址0开始有的有起始地址偏移甚至限定在某个系统寄存器里设置。我的习惯是打开该型号通信用户手册里的“MODBUS地址分配表”先确认DT0到底对应协议地址几再写程序。最笨但有效的验证方法PLC监视DT100写入888上位机把DT附近10个寄存器全部读回来看888落在哪个协议地址上偏移量瞬间就暴露了。提示这里说的“保持寄存器地址0”是Modbus协议帧里的地址字段上位机显示成“40001”是1号地址习惯两者差一个起始编号不要混在一起算。3. C#实例源码读取松下PLC保持寄存器的两套实现3.1 先决定用HslCommunication库还是手写Modbus RTUC#实现Modbus有两条主流路线直接引用HslCommunication这种工业通讯库或者自己动手写一个精简的RTU客户端类。做快速原型我一般直接上库它把打开串口、超时、地址解析都封装了但如果项目对第三方依赖敏感或者想彻底搞清楚协议本身手写一套也很有价值毕竟Modbus RTU的帧结构并不复杂。HslCommunication需要从NuGet引入类名在历史版本中有变化老版本是HslCommunication.ModBus.ModbusRtu新版本改叫过ModbusRtuClient以实际拉下来的包为准。手写方案只依赖.NET自带的System.IO.PortsFramework和Core都能编译。下面两套代码我都按“能直接跑、能改参数”来给。3.2 HslCommunication最小可运行代码10行读回DT寄存器假设PLC站号设成1DT100对应协议地址100保持寄存器地址用字符串“40101”传给库。连续读5个寄存器using System.IO.Ports; using HslCommunication; using HslCommunication.ModBus; ModbusRtu modbus new ModbusRtu(); modbus.SerialPort new SerialPort(COM3, 9600, Parity.None, 8, StopBits.One); modbus.Station 1; // 与PLC侧站号一致 OperateResult open modbus.Open(); if (!open.IsSuccess) { Console.WriteLine(串口打开失败: open.Message); return; } OperateResultushort[] read modbus.ReadUInt16(40101, 5); if (read.IsSuccess) { for (int i 0; i read.Content.Length; i) Console.WriteLine($DT{100 i} {read.Content[i]}); } else { Console.WriteLine(读取失败: read.Message); }逻辑不复杂Open()按指定串口参数打开端口ReadUInt16(40101, 5)表示从协议地址100开始连续读5个保持寄存器返回的Content是ushort[]。地址字符串写“40101”而不是“101”是为了让库知道走4x区功能码03直接写101可能被按线圈或者离散输入解析。参数就四个站号、串口号、波特率、地址字符串调起来很快。3.3 手写Modbus RTU完整类的读取与写入不依赖库时把读保持寄存器请求拼成8字节帧从站号、功能码0x03、起始地址占2字节、寄存器数量占2字节、CRC16占2字节。CRC计算我用位运算版本便于看清每一步public class ModbusRtuMaster : IDisposable { private readonly SerialPort _port; private readonly byte _slaveId; public ModbusRtuMaster(string portName, int baudRate, byte slaveId, Parity parity Parity.None, StopBits stopBits StopBits.One) { _slaveId slaveId; _port new SerialPort(portName, baudRate, parity, 8, stopBits) { ReadTimeout 500, WriteTimeout 500 }; _port.Open(); } public ushort[] ReadHoldingRegisters(ushort startAddress, ushort count) { if (count 125) throw new ArgumentException(Modbus一次最多读125个寄存器); byte[] request new byte[8]; request[0] _slaveId; // 从站号 request[1] 0x03; // 功能码读保持寄存器 request[2] (byte)(startAddress 8); // 起始地址高字节 request[3] (byte)(startAddress 0xFF); request[4] (byte)(count 8); // 数量高字节 request[5] (byte)(count 0xFF); byte[] crc CalculateCrc(request, 6); request[6] crc[0]; // CRC低字节在前 request[7] crc[1]; byte[] response SendAndReceive(request); if (response[0] ! _slaveId || response[1] ! 0x03) throw new IOException(响应帧头不匹配: BitConverter.ToString(response)); int byteCount response[2]; // 数据字节数 count * 2 ushort[] values new ushort[byteCount / 2]; for (int i 0; i values.Length; i) { // Modbus寄存器数据大端存储高字节在前 values[i] (ushort)((response[3 i * 2] 8) | response[4 i * 2]); } return values; } public void WriteSingleRegister(ushort address, ushort value) { byte[] request new byte[8]; request[0] _slaveId; request[1] 0x06; // 功能码写单个寄存器 request[2] (byte)(address 8); request[3] (byte)(address 0xFF); request[4] (byte)(value 8); request[5] (byte)(value 0xFF); byte[] crc CalculateCrc(request, 6); request[6] crc[0]; request[7] crc[1]; byte[] response SendAndReceive(request); if (response[0] ! _slaveId || response[1] ! 0x06) throw new IOException(写寄存器响应异常: BitConverter.ToString(response)); } private byte[] SendAndReceive(byte[] request) { _port.DiscardInBuffer(); _port.Write(request, 0, request.Length); byte[] buffer new byte[256]; int offset 0; int deadline Environment.TickCount 500; while (Environment.TickCount deadline) { int left _port.BytesToRead; if (left 0) { offset _port.Read(buffer, offset, Math.Min(left, buffer.Length - offset)); if (offset 5) { int expected 3 buffer[2] 2; // 帧头 字节数 CRC if (offset expected) break; } } else { Thread.Sleep(10); } } if (offset 5) throw new TimeoutException(响应超时帧不完整); byte[] result new byte[offset]; Array.Copy(buffer, result, offset); return result; } private static byte[] CalculateCrc(byte[] data, int length) { ushort crc 0xFFFF; for (int i 0; i length; i) { crc ^ data[i]; for (int j 0; j 8; j) { if ((crc 0x0001) ! 0) crc (ushort)((crc 1) ^ 0xA001); else crc 1; } } return new byte[] { (byte)(crc 0xFF), (byte)(crc 8) }; } public void Dispose() _port?.Dispose(); }代码重点有三处。第一CRC只对请求帧前6个字节计算低字节放前、高字节放后顺序颠倒会导致PLC直接丢弃帧。第二SendAndReceive根据响应第3个字节推测整帧长度把报文收完整再返回不是固定读多少个字节避免收到半截帧。第三寄存器数据在Modbus线路上是大端序高字节先到所以代码里左移8位再或低字节。调用方式很简单using (var master new ModbusRtuMaster(COM3, 9600, 1)) { ushort[] dt100 master.ReadHoldingRegisters(100, 8); master.WriteSingleRegister(200, 1); }这里的起始地址100就是PLC侧DT100对应的协议地址。现场有偏移时把偏移量统一加在一个转换函数里不要在业务代码中到处手算。这类串口工具类在多线程下有个天然问题SendAndReceive不是线程安全的。上位机如果用Timer或Task并发调用必须在外面加锁否则两帧数据混在一起PLC不会回应。说白了就是同一时刻只能有一个线程在操作这个串口对象。3.4 把寄存器拼回int/float注意字节序ReadHoldingRegisters返回的是ushort[]但PLC里的工艺值可能是32位整数或浮点数。松下PLC在16位模式下32位数据常占用两个连续DT寄存器字的顺序要看PLC程序怎么存放。常用的拼接方式是把两个寄存器按大端序合成一个32位数uint raw32 ((uint)values[0] 16) | values[1]; float f BitConverter.UInt32BitsToSingle(raw32); int i (int)raw32;真实项目中我一般先按“高字在前”解析如果读出来像是两个数被对调就把两个寄存器顺序反过来再拼一次。最直接的验证是在PLC里写入一个辨识度高的值比如1.5或者0x12345678然后上位机两种顺序各试一次立即能确定规则。4. 松下PLC Modbus通讯的5个典型坑和排查清单4.1 现象1PLC完全不回应帧发出去了石沉大海上位机把请求帧发到串口却一直等不到任何响应。这种问题大多不是C#代码的锅而是链路根本没通。常见原因有三种PLC的通信口还停在“计算机链接”模式没有切成Modbus从站串口参数两边不一致特别是数据位和校验位RS-485的A/B线接反了。我排查时会按顺序做三件事。先用FPWIN确认“通信设置”里已经切换到Modbus从站并且下载后重新上电。再核对上位机和PLC的波特率、数据位、校验位、停止位松下部分机型默认偶校验而上位机按无校验打开自然收不到。最后用万用表量RS-485的A、B线电压确认接线没反把A/B对调再试一次。很多所谓“玄学不通信”最后都落在这种基础项上。4.2 现象2数据读回来了值却完全不对上位机能收到正常响应帧但读出的数字和PLC监视窗口里看到的不一致。最常见的原因是地址映射没对准DT100并不等于协议地址100或者把保持寄存器起始地址填进了某个内部元件的区域。我的处理方式是在PLC监视模式下往DT100写入888然后让上位机把DT100附近10个寄存器全部读出来逐个打印找到888落在哪个协议地址上。偏移量一旦确定就写一个方法做地址换算所有读请求统一走这个方法不要在业务代码里一遍遍手算。另外还有一个隐蔽点如果读到的是0xFFFF或者0先确认PLC侧寄存器没有被程序清空或者是否启用了保持型区域。4.3 现象3写寄存器不生效上位机提示成功但PLC程序没反应上位机用功能码0x06写单个寄存器返回成功但PLC程序判断这个值或位时完全没变化。常见原因有三个。第一写的寄存器地址不是程序实际使用的地址比如程序使用的是DT200上位机却写了DT200附近的另一个地址。第二PLC扫描周期很短程序在某个逻辑里给DT重新赋值上位机写进去马上被覆盖。第三写的是RAM区掉电丢失程序也不把这块区域当作有效参数区。解决时要先看PLC程序里DT的赋值方向。若DT被程序写死就不能往上位机写这条地址若需要保存配方或参数一般写文件寄存器或保持型区域内这些细节要查对应型号手册。不要在没确认PLC逻辑前反复尝试写入那只会浪费时间。4.4 现象4通讯时好时坏跑一段时间就超时前期测试正常运行几分钟或几小时后出现偶发超时重试一次又恢复。这种间歇性故障比完全不通更让人头疼。多半是RS-485总线布线不达标网端没加终端电阻或者现场接线做成星型信号反射导致偶发错帧。也可能是上位机多线程没加锁两个线程同时往串口写PLC收到的报文被打断了。解决分两步。总线末端加120Ω终端电阻RS-485主干线要做手拉手串接尽量不搞星型拓扑。C#侧所有串口读写共用一把锁或者用一个独立发送队列保证每一帧请求只有一个线程能发。巡检周期也不要压得太短PLC处理Modbus从站请求需要时间轮询间隔低于200ms容易让从站来不及响应。4.5 现象5CRC一直校验不过响应帧内容看起来完全正确但调试工具一直提示CRC错误。原因不外乎三种CRC高低字节放反应该低字节在前计算范围弄错把CRC自身也当成数据参与计算响应帧长度判断有误读取时把CRC当数据解析了。我建议先离线自测。把请求帧01 03 00 00 00 01前6字节丢进CRC函数和Modbus调试助手算出来的结果对比。确认CRC函数正确后再联PLC不要一上来就对着PLC调那样没法分清是上位机打包问题还是PLC返回问题。5. 调试三板斧用报文验证你写对没有5.1 用Modbus调试助手核对请求帧代码跑通前先用串口调试助手或Modbus调试工具把帧验证一遍。读取协议地址100的一个保持寄存器按上面格式手算请求帧为01 03 00 64 00 01 C4 10。助手里发出这8个字节如果PLC在线且DT100有值会返回类似01 03 02 12 34 65 CE的帧其中1234就是寄存器内容。将上位机实际发出的帧和助手发出的帧做一次十六进制字符比对不一致就说明打包函数有bug不是PLC的问题。这一步能把排查范围缩到最小。5.2 先读一个再读一批参数固定成常量我习惯把端口号、波特率、站号、DT起始地址、寄存器数量全部提成常量或配置文件。现场调试时改一个值就生效不用重新编译。轮询周期先放到1秒只读5个寄存器跑稳定后再逐步缩短间隔。5.3 上线前的最后一步我会在C#程序里把每次请求和响应的十六进制报文写进日志保留最近一天。很多莫名超时事后都能在日志里找到蛛丝马迹是收到半帧、偶发CRC错误还是PLC响应时间突然变慢。这是我做串口通讯多年吃过的亏换来的习惯也算一条血泪经验。先调试后上线先把一条报文看明白再扩大采集范围希望帮到你。本文还有配套的精品资源点击获取 松下PLC与C#上位机Modbus RTU通讯：寄存器映射与调试实战
简介一套松下PLC通过Modbus协议与C#上位机通信的实例源码面向PLC入门开发者及有经验的工控人员。项目可实现与松下PLC建立通信链路读取运行时间、停止时间、故障次数、C/T计数器及设备状态等关键信息代码结构清晰适合作为二次开发或学习Modbus通信封装的原型参考。压缩包共41个文件包含6个C#源程序、6个可直接运行的exe、4个动态库dll及调试符号pdb另有界面资源resx、工程配置csproj与解决方案sln等整体仅547KB轻量且便于快速查看与复用。目前已有1564人学习浏览经过亲测验证有效。资源不仅提供完整的通信调用流程还包含WinForm界面与设备状态展示方式可帮助开发者快速理解松下PLC寄存器映射、报文拼接解析及异常处理思路缩短实际项目的调试周期。1. 松下PLC Modbus C#为什么上位机采集绕不开这个组合车间里被问得最多的组合之一就是“松下PLC Modbus C#”。一台松下FP系列PLC一条RS-485串口总线一个用C#写的上位机要把DT寄存器里的产量、温度、报警状态周期性拿回来供MES展示或者存数据库。这条路便宜、协议公开不依赖松下专用DLL抓包能看到每一个字节出了问题好排查。很多人一听“松下PLC通讯设置”“modbus rtu”就觉得要啃手册其实只要把PLC侧地址映射搞明白C#侧报文按规范填一个周末就能跑通最小可用版本。这篇笔记按“PLC侧配置→C#实例源码→踩坑→调试”的顺序展开适合第一次做松下采集也想把Modbus协议彻底弄懂的人。2. 松下PLC的Modbus从站配置与寄存器地址映射2.1 用Modbus TCP还是Modbus RTU先做第一个决定走串口还是走以太网。松下FP0R、FP-X这类老派机型CPU自带COM口默认是“计算机链接”协议把参数切到“Modbus RTU从站”就能用想走以太网就得加以太网模块或者直接上FP7这种新款PLC对外提供的是Modbus TCP。RTU和TCP的帧格式不一样C#这边拿错协议栈会非常头疼。绝大多数产线场景我推荐先上RTU。RS-485串口通讯抗干扰在车间够用波特率拉到9600每台PLC分配一个站号一条总线挂十几台设备很常见。RTU帧比TCP多一个CRC校验反而更容易定位问题。只有设备距离超过几百米或者上位机不在同一个电柜里我才会考虑以太网和Modbus TCP。TCP没有CRC定位错帧得依赖TCP层的校验现场调试仪器要求也更高。两种方式的取舍可以先看这张表对比项Modbus RTUModbus TCP物理层RS-232 / RS-485以太网典型速率9600 / 1920010/100M帧校验CRC16无独立CRC松下常见载体CPU自带COM口以太网模块 / FP7适用场景单电柜或几十米内跨楼层、接MES机房实际项目里我习惯先按RTU打通因为接线和排查都直观。等整个采集链路稳定了如果网络条件要求走TCP再在C#侧换一个ModbusTcpClient封装PLC侧地址映射不变改动成本很小。2.2 在FPWIN里把通信口设成Modbus从站很多人写了一天代码发现不通最后发现是PLC侧参数没设。用FPWIN GR或FPWIN Pro打开工程在左侧项目树里找到“系统寄存器”或“PLC参数”下的“通信设置”子项。找到COM口索引FP-X一般是COM0或COM1把通信模式从“计算机链接”改成“MODBUS RTU 从站”。站号我习惯设成1便于测试多台设备时按1到247分配。下面几项必须和C#串口打开参数完全一致波特率、数据位、校验位、停止位。我的默认组合是9600、8位数据位、无校验、1位停止位松下PLC侧也选“8位、无校验、1停止位”。如果现场要求偶校验两边都要改成Even只改一端就会一直收不到正常响应。参数修改完把工程下载到PLC然后断电重新上电一次。部分松下机型是“下载后生效”在线修改不会立刻激活这是很多调试现场翻车的原因。重上电后在FPWIN的监视模式里往DT100写一个888之类的已知数方便第二步上位机验证。2.3 地址映射DT、R怎么换算成Modbus地址Modbus协议只有两类寻址维度线圈和寄存器。松下PLC的DT数据寄存器对应保持寄存器R内部继电器对应线圈X/Y开关量能不能映射要看具体机型的通信手册。常见映射方向如下松下内部资源功能码对应Modbus区域DT16位数据寄存器0x03读 / 0x06、0x10写保持寄存器4x区R内部继电器0x01读 / 0x05、0x0F写线圈0x区X/Y输入输出0x02读离散输入1x区以FP0R常见通信手册为例DT0对应保持寄存器协议地址0DT100对应协议地址100上位机软件习惯记作40101R0对应线圈协议地址0。请求帧里地址字段填十进制100功能码0x03数量填1发出hex如下面第5章的报文例子。真正容易出问题的不是这步而是不同型号偏移不一样。有的型号DT从地址0开始有的有起始地址偏移甚至限定在某个系统寄存器里设置。我的习惯是打开该型号通信用户手册里的“MODBUS地址分配表”先确认DT0到底对应协议地址几再写程序。最笨但有效的验证方法PLC监视DT100写入888上位机把DT附近10个寄存器全部读回来看888落在哪个协议地址上偏移量瞬间就暴露了。提示这里说的“保持寄存器地址0”是Modbus协议帧里的地址字段上位机显示成“40001”是1号地址习惯两者差一个起始编号不要混在一起算。3. C#实例源码读取松下PLC保持寄存器的两套实现3.1 先决定用HslCommunication库还是手写Modbus RTUC#实现Modbus有两条主流路线直接引用HslCommunication这种工业通讯库或者自己动手写一个精简的RTU客户端类。做快速原型我一般直接上库它把打开串口、超时、地址解析都封装了但如果项目对第三方依赖敏感或者想彻底搞清楚协议本身手写一套也很有价值毕竟Modbus RTU的帧结构并不复杂。HslCommunication需要从NuGet引入类名在历史版本中有变化老版本是HslCommunication.ModBus.ModbusRtu新版本改叫过ModbusRtuClient以实际拉下来的包为准。手写方案只依赖.NET自带的System.IO.PortsFramework和Core都能编译。下面两套代码我都按“能直接跑、能改参数”来给。3.2 HslCommunication最小可运行代码10行读回DT寄存器假设PLC站号设成1DT100对应协议地址100保持寄存器地址用字符串“40101”传给库。连续读5个寄存器using System.IO.Ports; using HslCommunication; using HslCommunication.ModBus; ModbusRtu modbus new ModbusRtu(); modbus.SerialPort new SerialPort(COM3, 9600, Parity.None, 8, StopBits.One); modbus.Station 1; // 与PLC侧站号一致 OperateResult open modbus.Open(); if (!open.IsSuccess) { Console.WriteLine(串口打开失败: open.Message); return; } OperateResultushort[] read modbus.ReadUInt16(40101, 5); if (read.IsSuccess) { for (int i 0; i read.Content.Length; i) Console.WriteLine($DT{100 i} {read.Content[i]}); } else { Console.WriteLine(读取失败: read.Message); }逻辑不复杂Open()按指定串口参数打开端口ReadUInt16(40101, 5)表示从协议地址100开始连续读5个保持寄存器返回的Content是ushort[]。地址字符串写“40101”而不是“101”是为了让库知道走4x区功能码03直接写101可能被按线圈或者离散输入解析。参数就四个站号、串口号、波特率、地址字符串调起来很快。3.3 手写Modbus RTU完整类的读取与写入不依赖库时把读保持寄存器请求拼成8字节帧从站号、功能码0x03、起始地址占2字节、寄存器数量占2字节、CRC16占2字节。CRC计算我用位运算版本便于看清每一步public class ModbusRtuMaster : IDisposable { private readonly SerialPort _port; private readonly byte _slaveId; public ModbusRtuMaster(string portName, int baudRate, byte slaveId, Parity parity Parity.None, StopBits stopBits StopBits.One) { _slaveId slaveId; _port new SerialPort(portName, baudRate, parity, 8, stopBits) { ReadTimeout 500, WriteTimeout 500 }; _port.Open(); } public ushort[] ReadHoldingRegisters(ushort startAddress, ushort count) { if (count 125) throw new ArgumentException(Modbus一次最多读125个寄存器); byte[] request new byte[8]; request[0] _slaveId; // 从站号 request[1] 0x03; // 功能码读保持寄存器 request[2] (byte)(startAddress 8); // 起始地址高字节 request[3] (byte)(startAddress 0xFF); request[4] (byte)(count 8); // 数量高字节 request[5] (byte)(count 0xFF); byte[] crc CalculateCrc(request, 6); request[6] crc[0]; // CRC低字节在前 request[7] crc[1]; byte[] response SendAndReceive(request); if (response[0] ! _slaveId || response[1] ! 0x03) throw new IOException(响应帧头不匹配: BitConverter.ToString(response)); int byteCount response[2]; // 数据字节数 count * 2 ushort[] values new ushort[byteCount / 2]; for (int i 0; i values.Length; i) { // Modbus寄存器数据大端存储高字节在前 values[i] (ushort)((response[3 i * 2] 8) | response[4 i * 2]); } return values; } public void WriteSingleRegister(ushort address, ushort value) { byte[] request new byte[8]; request[0] _slaveId; request[1] 0x06; // 功能码写单个寄存器 request[2] (byte)(address 8); request[3] (byte)(address 0xFF); request[4] (byte)(value 8); request[5] (byte)(value 0xFF); byte[] crc CalculateCrc(request, 6); request[6] crc[0]; request[7] crc[1]; byte[] response SendAndReceive(request); if (response[0] ! _slaveId || response[1] ! 0x06) throw new IOException(写寄存器响应异常: BitConverter.ToString(response)); } private byte[] SendAndReceive(byte[] request) { _port.DiscardInBuffer(); _port.Write(request, 0, request.Length); byte[] buffer new byte[256]; int offset 0; int deadline Environment.TickCount 500; while (Environment.TickCount deadline) { int left _port.BytesToRead; if (left 0) { offset _port.Read(buffer, offset, Math.Min(left, buffer.Length - offset)); if (offset 5) { int expected 3 buffer[2] 2; // 帧头 字节数 CRC if (offset expected) break; } } else { Thread.Sleep(10); } } if (offset 5) throw new TimeoutException(响应超时帧不完整); byte[] result new byte[offset]; Array.Copy(buffer, result, offset); return result; } private static byte[] CalculateCrc(byte[] data, int length) { ushort crc 0xFFFF; for (int i 0; i length; i) { crc ^ data[i]; for (int j 0; j 8; j) { if ((crc 0x0001) ! 0) crc (ushort)((crc 1) ^ 0xA001); else crc 1; } } return new byte[] { (byte)(crc 0xFF), (byte)(crc 8) }; } public void Dispose() _port?.Dispose(); }代码重点有三处。第一CRC只对请求帧前6个字节计算低字节放前、高字节放后顺序颠倒会导致PLC直接丢弃帧。第二SendAndReceive根据响应第3个字节推测整帧长度把报文收完整再返回不是固定读多少个字节避免收到半截帧。第三寄存器数据在Modbus线路上是大端序高字节先到所以代码里左移8位再或低字节。调用方式很简单using (var master new ModbusRtuMaster(COM3, 9600, 1)) { ushort[] dt100 master.ReadHoldingRegisters(100, 8); master.WriteSingleRegister(200, 1); }这里的起始地址100就是PLC侧DT100对应的协议地址。现场有偏移时把偏移量统一加在一个转换函数里不要在业务代码中到处手算。这类串口工具类在多线程下有个天然问题SendAndReceive不是线程安全的。上位机如果用Timer或Task并发调用必须在外面加锁否则两帧数据混在一起PLC不会回应。说白了就是同一时刻只能有一个线程在操作这个串口对象。3.4 把寄存器拼回int/float注意字节序ReadHoldingRegisters返回的是ushort[]但PLC里的工艺值可能是32位整数或浮点数。松下PLC在16位模式下32位数据常占用两个连续DT寄存器字的顺序要看PLC程序怎么存放。常用的拼接方式是把两个寄存器按大端序合成一个32位数uint raw32 ((uint)values[0] 16) | values[1]; float f BitConverter.UInt32BitsToSingle(raw32); int i (int)raw32;真实项目中我一般先按“高字在前”解析如果读出来像是两个数被对调就把两个寄存器顺序反过来再拼一次。最直接的验证是在PLC里写入一个辨识度高的值比如1.5或者0x12345678然后上位机两种顺序各试一次立即能确定规则。4. 松下PLC Modbus通讯的5个典型坑和排查清单4.1 现象1PLC完全不回应帧发出去了石沉大海上位机把请求帧发到串口却一直等不到任何响应。这种问题大多不是C#代码的锅而是链路根本没通。常见原因有三种PLC的通信口还停在“计算机链接”模式没有切成Modbus从站串口参数两边不一致特别是数据位和校验位RS-485的A/B线接反了。我排查时会按顺序做三件事。先用FPWIN确认“通信设置”里已经切换到Modbus从站并且下载后重新上电。再核对上位机和PLC的波特率、数据位、校验位、停止位松下部分机型默认偶校验而上位机按无校验打开自然收不到。最后用万用表量RS-485的A、B线电压确认接线没反把A/B对调再试一次。很多所谓“玄学不通信”最后都落在这种基础项上。4.2 现象2数据读回来了值却完全不对上位机能收到正常响应帧但读出的数字和PLC监视窗口里看到的不一致。最常见的原因是地址映射没对准DT100并不等于协议地址100或者把保持寄存器起始地址填进了某个内部元件的区域。我的处理方式是在PLC监视模式下往DT100写入888然后让上位机把DT100附近10个寄存器全部读出来逐个打印找到888落在哪个协议地址上。偏移量一旦确定就写一个方法做地址换算所有读请求统一走这个方法不要在业务代码里一遍遍手算。另外还有一个隐蔽点如果读到的是0xFFFF或者0先确认PLC侧寄存器没有被程序清空或者是否启用了保持型区域。4.3 现象3写寄存器不生效上位机提示成功但PLC程序没反应上位机用功能码0x06写单个寄存器返回成功但PLC程序判断这个值或位时完全没变化。常见原因有三个。第一写的寄存器地址不是程序实际使用的地址比如程序使用的是DT200上位机却写了DT200附近的另一个地址。第二PLC扫描周期很短程序在某个逻辑里给DT重新赋值上位机写进去马上被覆盖。第三写的是RAM区掉电丢失程序也不把这块区域当作有效参数区。解决时要先看PLC程序里DT的赋值方向。若DT被程序写死就不能往上位机写这条地址若需要保存配方或参数一般写文件寄存器或保持型区域内这些细节要查对应型号手册。不要在没确认PLC逻辑前反复尝试写入那只会浪费时间。4.4 现象4通讯时好时坏跑一段时间就超时前期测试正常运行几分钟或几小时后出现偶发超时重试一次又恢复。这种间歇性故障比完全不通更让人头疼。多半是RS-485总线布线不达标网端没加终端电阻或者现场接线做成星型信号反射导致偶发错帧。也可能是上位机多线程没加锁两个线程同时往串口写PLC收到的报文被打断了。解决分两步。总线末端加120Ω终端电阻RS-485主干线要做手拉手串接尽量不搞星型拓扑。C#侧所有串口读写共用一把锁或者用一个独立发送队列保证每一帧请求只有一个线程能发。巡检周期也不要压得太短PLC处理Modbus从站请求需要时间轮询间隔低于200ms容易让从站来不及响应。4.5 现象5CRC一直校验不过响应帧内容看起来完全正确但调试工具一直提示CRC错误。原因不外乎三种CRC高低字节放反应该低字节在前计算范围弄错把CRC自身也当成数据参与计算响应帧长度判断有误读取时把CRC当数据解析了。我建议先离线自测。把请求帧01 03 00 00 00 01前6字节丢进CRC函数和Modbus调试助手算出来的结果对比。确认CRC函数正确后再联PLC不要一上来就对着PLC调那样没法分清是上位机打包问题还是PLC返回问题。5. 调试三板斧用报文验证你写对没有5.1 用Modbus调试助手核对请求帧代码跑通前先用串口调试助手或Modbus调试工具把帧验证一遍。读取协议地址100的一个保持寄存器按上面格式手算请求帧为01 03 00 64 00 01 C4 10。助手里发出这8个字节如果PLC在线且DT100有值会返回类似01 03 02 12 34 65 CE的帧其中1234就是寄存器内容。将上位机实际发出的帧和助手发出的帧做一次十六进制字符比对不一致就说明打包函数有bug不是PLC的问题。这一步能把排查范围缩到最小。5.2 先读一个再读一批参数固定成常量我习惯把端口号、波特率、站号、DT起始地址、寄存器数量全部提成常量或配置文件。现场调试时改一个值就生效不用重新编译。轮询周期先放到1秒只读5个寄存器跑稳定后再逐步缩短间隔。5.3 上线前的最后一步我会在C#程序里把每次请求和响应的十六进制报文写进日志保留最近一天。很多莫名超时事后都能在日志里找到蛛丝马迹是收到半帧、偶发CRC错误还是PLC响应时间突然变慢。这是我做串口通讯多年吃过的亏换来的习惯也算一条血泪经验。先调试后上线先把一条报文看明白再扩大采集范围希望帮到你。本文还有配套的精品资源点击获取