简介：一套C#与欧姆龙PLC（FINS协议）通信的完整源代码工程，面向工业自动化上位机开发者，适合新手入门及有经验工程师参考。工程演示通过以太网调用FINS协议与PLC交换数据，覆盖TCP/IP通信、命令帧构造、响应解析、多线程界面刷新及异常重试机制。压缩包共21个文件，大小仅26KB，以12个.cs源码文件为主，涵盖FINS协议封装、界面交互、程序入口等模块；另配.csproj工程文件、.resx资源文件、.sln解决方案及README说明，结构完整。已有908人学习浏览，在同类资源中具备一定参考热度。读者可获得可运行的通信程序骨架，深入理解FINS协议数据交互原理和C#网络编程技巧，代码中保留注释与文档，方便二次开发或移植到其他PLC协议。
1. 为什么需要一手C#通信源码：现场调设备的第一个坎
接过一个产线项目，设备清一色欧姆龙PLC，上位机是C#，现场调试第一天就被卡住：不知道PLC里的D区数据怎么才能读进WinForm界面。翻官方手册全是协议术语，网上找的代码要么调不通，要么只支持串口。折腾到半夜才明白，设备通讯这种事，只有手上有一份真正能改、能复现、能排错的C#通信源码，才算把主动权握在自己手里。这篇文章要说的，就是围绕“C#和欧姆龙PLC通信程序源代码”这个方向，把FINS/TCP这条最常用的网口通信链路从协议原理到代码落地、再从现场排错到回归验证完整讲透。适合正在被欧姆龙PLC和上位机联动折磨的C#开发，也适合刚接手设备接入项目的新手照着抄作业。
2. 读懂FINS协议：网口、数据帧与内存区映射
C#连欧姆龙PLC，常见做法就是用FINS协议走以太网，也就是FINS/TCP。你不需要把协议手册背下来，但三个事情必须在写代码之前落地：连接参数、一帧报文长什么样、PLC地址和C#变量怎么对应。这三个点认不清，后面的代码就算跑起来也是撞运气。
2.1 FINS/TCP连接三要素：IP、端口与节点号
欧姆龙PLC的FINS/TCP通信和普通Socket通信一样，IP和端口是第一道参数。PLC侧通常在CX-Programmer或Sysmac Studio的“单元设置”里绑定一个固定IP；端口默认是9600，这是FINS/TCP的标准端口。若有人改过端口，需要先从PLC侧读取，别想当然。
另一个容易被忽略的参数是FINS节点号。节点号不等于IP，但很多现场喜欢把两者设成一样的值，比如IP是192.168.1.10，节点号也填10。这个值在FINS报文里叫DA1，也就是目标节点地址。上位机电脑也有自己的源节点号，一般填0。如果你用CX-Simulator在线模拟器，DA1和SA1的对应关系又不一样。我的习惯是把节点号做成类的构造参数，换现场只改配置文件，不碰逻辑代码。
2.2 一封FINS请求帧长什么样：从“帧头”到“命令数据”
FINS/TCP的报文结构分两层。内层是FINS报文本身，外层是TCP封包时前边追加的4字节长度字段，这4字节用网络字节序保存整个内层报文的字节数，也就是大端序。C#里如果直接BitConverter转int，多半会得到反过来的数字。
内层FINS报文从固定10字节的帧头开始：ICF、RSV、GCT、DNA、DA1、DA2、SNA、SA1、SA2、SID。其中ICF用于区分命令帧和响应帧，GCT固定为0x02，DNA表示目标网络号，一般为0x00，DA1和SA1是我们上面提到的节点号，SID是发送序号，响应帧会原样带回。这个序号在排查“丢包”、“串包”时特别有用：发出去的是几号，回来的必须是几号。
真正我要读DM区数据，需要在10字节帧头之后追加命令码和参数。命令码0x01 0x01表示内存区读，后面跟内存区代码、起始地址、读取字数。这个结构看着简单，现场翻车多是因为地址或者字数写错。
2.3 内存区映射：D100在C#里到底对应什么
欧姆龙PLC的D区在FINS协议里不是简单写“100”就能读。FINS报文里的地址由“内存区代码 + 2字节地址”组成。以CP1H、CJ2M这些常见型号为例，DM区的内存区代码是0x82，D100对应的地址就是0x00 0x64，也就是十六进制的100。你读的是字，不是字节，所以后续解析C#数值时还要注意每个字占2字节。
很多新手在这里翻车：用BitConverter.ToUInt16直接解析收到的字节，出来的数值和PLC监视画面差了一大截，就是因为欧姆龙走的是大端序。你收到的0x01 0x02在C#里会被读成0x0201，不是0x0102。这个问题后面避坑章会单独讲，但写代码时最好从一开始就统一用BinaryPrimitives.ReadUInt16BigEndian这类方法，别等真机调试时再来猜。
提示：COIO区、W区、H区的内存区代码都不一样，本文后面代码以DM区为演示；换区域时请核对对应型号手册中的“FINS内存区代码表”，不要直接复用
0x82。
3. 用C#实现FINS/TCP收发：从建工程到拿回第一个字
原理说清了，这一章直接动手。目标是在Visual Studio里建一个控制台项目，用一份能编译的C#源码连上PLC，读出D100和D101两个字。代码会拆成三部分：连接与基础收发类、读命令的组装、主程序调用。每一步后面都有参数说明，照着抄就能跑通。
3.1 新建工程并封装FinsTcpClient基类
在Visual Studio里新建一个.NET控制台项目，.NET 6或.NET Framework 4.7.2都可以。下面这一段是通信核心类，只负责连接、发FINS帧、收响应、解析响应头：
using System; using System.IO; using System.Net.Sockets; namespace PlcMonitor { public class FinsTcpClient : IDisposable { private TcpClient _tcp; private NetworkStream _stream; private readonly string _ip; private readonly int _port; private readonly byte _da1; // 目标节点号：PLC的FINS节点 private readonly byte _sa1; // 源节点号：本机FINS节点 private byte _sid = 0x01; // 请求序号，每次自增 public FinsTcpClient(string ip, int port = 9600, byte da1 = 0, byte sa1 = 0) { _ip = ip; _port = port; _da1 = da1; _sa1 = sa1; } public void Connect() { _tcp = new TcpClient(); _tcp.Connect(_ip, _port); _stream = _tcp.GetStream(); _stream.ReadTimeout = 3000; // 读超时3秒，避免卡死 _stream.WriteTimeout = 3000; // 写超时3秒 } public byte[] SendFinsCommand(byte[] command) { using (var ms = new MemoryStream()) { // 10字节FINS帧头 ms.WriteByte(0x80); // ICF：命令帧 ms.WriteByte(0x00); // RSV：保留 ms.WriteByte(0x02); // GCT：网关数 ms.WriteByte(0x00); // DNA：目标网络号 ms.WriteByte(_da1); // DA1：目标节点 ms.WriteByte(0x00); // DA2：目标单元 ms.WriteByte(0x00); // SNA：源网络号 ms.WriteByte(_sa1); // SA1：源节点 ms.WriteByte(0x00); // SA2：源单元 ms.WriteByte(_sid); // SID：请求序号 ms.Write(command, 0, command.Length); var body = ms.ToArray(); // FINS/TCP要求：在报文前加4字节长度，大端序 byte[] lenBytes = new byte[4]; lenBytes[0] = (byte)(body.Length >> 24); lenBytes[1] = (byte)(body.Length >> 16); lenBytes[2] = (byte)(body.Length >> 8); lenBytes[3] = (byte)body.Length; _stream.Write(lenBytes, 0, 4); _stream.Write(body, 0, body.Length); } // 读取响应：先读4字节长度，再读响应体 byte[] lenBuf = ReadExactly(4); int respLen = (lenBuf[0] << 24) | (lenBuf[1] << 16) | (lenBuf[2] << 8) | lenBuf[3]; byte[] resp = ReadExactly(respLen); // FINS结束码在“帧头10字节 + 命令码2字节”之后，也就是偏移12和13 if (resp[12] != 0 || resp[13] != 0) { throw new IOException($"FINS错误码 0x{resp[12]:X2} 0x{resp[13]:X2}"); } // 响应数据从偏移14开始 byte[] result = new byte[respLen - 14]; Array.Copy(resp, 14, result, 0, result.Length); _sid++; // 序号递增，用于匹配请求和响应 return result; } private byte[] ReadExactly(int count) { byte[] buf = new byte[count]; int offset = 0; while (offset < count) { int n = _stream.Read(buf, offset, count - offset); if (n <= 0) throw new IOException("连接已关闭"); offset += n; } return buf; } public void Dispose() { _stream?.Dispose(); _tcp?.Dispose(); } } }这段代码的逻辑很清晰：Connect建立TCP连接并设置收发超时；SendFinsCommand负责把一段FINS命令拼上帧头发送，再读回响应，如果结束码不为0就直接抛异常，省得主程序里到处判断错误。参数方面，port默认9600，da1和sa1默认都填0，但真机调试时DA1一定要跟PLC侧节点号一致，否则PLC收到帧也可能不响应。
3.2 组装读DM区命令：01 01命令的地址与数量
有了发送通道，接下来写真正读数据的命令。FINS内存区读命令码是01 01，后面依次是内存区代码、2字节起始地址、2字节读取字数。下面是读DM区连续多字的封装：
public ushort[] ReadDm(int startAddress, int length) { if (length <= 0 || length > 128) throw new ArgumentOutOfRangeException(nameof(length), "FINS单次读取上限通常是128个字"); byte[] cmd = new byte[7]; cmd[0] = 0x01; // 命令码高位：内存区读 cmd[1] = 0x01; // 命令码低位 cmd[2] = 0x82; // 内存区代码：DM区 cmd[3] = (byte)(startAddress >> 8); // 起始地址高8位 cmd[4] = (byte)(startAddress & 0xFF); // 起始地址低8位 cmd[5] = (byte)(length >> 8); // 读取字数高8位 cmd[6] = (byte)(length & 0xFF); // 读取字数低8位 byte[] result = SendFinsCommand(cmd); // 每个字2字节，解析时统一用大端序 ushort[] values = new ushort[length]; for (int i = 0; i < length; i++) { values[i] = (ushort)((result[i * 2] << 8) | result[i * 2 + 1]); } return values; }这里的参数有一个容易踩的边界：起始地址不是字节地址，是字地址；length单位是“字”，不是“字节”。比如读D100和D101，startAddress传100，length传2，PLC返回4字节，每一对字节组成一个字。单次读取字数我限制到128，这是保守值，不同PLC型号上限不同，但别一次读几千个字，TCP包太大反而容易错。
3.3 组装写DM区命令：01 02命令的载荷结构
通信程序只读不写等于少了一条腿。FINS写单个字的命令码是01 02，报文比读命令多了要写入的数据。下面是一个连续写多字的实现：
public void WriteDm(int startAddress, ushort[] values) { if (values == null || values.Length == 0) throw new ArgumentException("写入内容不能为空"); // 命令码2 + 内存区代码1 + 地址2 + 字数2 + 数据N*2 byte[] cmd = new byte[7 + values.Length * 2]; cmd[0] = 0x01; // 命令码高位：内存区写 cmd[1] = 0x02; // 命令码低位 cmd[2] = 0x82; // 内存区代码：DM区 cmd[3] = (byte)(startAddress >> 8); cmd[4] = (byte)(startAddress & 0xFF); cmd[5] = (byte)(values.Length >> 8); cmd[6] = (byte)(values.Length & 0xFF); for (int i = 0; i < values.Length; i++) { int offset = 7 + i * 2; cmd[offset] = (byte)(values[i] >> 8); // 高位在前 cmd[offset + 1] = (byte)(values[i] & 0xFF); // 低位在后 } SendFinsCommand(cmd); }很多人会问写命令有没有返回值。FINS写操作的正常响应不带数据区，只有结束码，所以SendFinsCommand返回的数组长度是0，只要不抛异常就代表写成功。这里有个坑：写地址范围越界时，结束码会返回非0值，然后被基类的IOException挡住，看异常信息里的十六进制错误码再对症排查。
3.4 主程序调用：10行代码跑通首轮读写
把上面的类放进项目里，在Program.cs里写一个最小调用，接上真机或者仿真器就能看到效果：
using System; namespace PlcMonitor { class Program { static void Main(string[] args) { // 参数说明：IP、端口、PLC节点号、本机节点号 using (var plc = new FinsTcpClient("192.168.1.10", 9600, da1: 10, sa1: 0)) { plc.Connect(); ushort[] data = plc.ReadDm(100, 2); Console.WriteLine($"D100 = {data[0]}, D101 = {data[1]}"); plc.WriteDm(100, new ushort[] { 123 }); data = plc.ReadDm(100, 1); Console.WriteLine($"写入后 D100 = {data[0]}"); Console.ReadLine(); } } } }这段代码先把D100和D101读出来，再往D100写入123，最后重新读一次验证。如果你连的是模拟器，这一步不出意外就能看到数字变化。真机调不通的时候，优先检查前面三步：网线物理连接、PLC端口配置、节点号是否匹配。
4. 让通信程序扛得住现场：轮询、超时与自动重连
跑通单次读写只是开始。现场环境不是实验室，PLC断电重启、网线松脱、交换机死机都是常态。通信程序要能连续几个月挂在工控机上，必须在轮询策略、超时处理和重连机制上做足文章。
4.1 多台PLC轮询：一个连接跑到底，别给每台设备开一个线程
常见做法是在一个定时循环里挨个访问现场PLC，而不是给每台设备单独new一个线程去死循环读。原因很简单：PLC的通信口可能同时只处理有限数量的连接；上位机线程多了，反而会把自己电脑的资源耗尽。下面的代码展示了用一个后台任务顺序轮询两台PLC的骨架：
using System; using System.Collections.Generic; using System.Threading; using System.Threading.Tasks; class PlcPoller { private readonly List<FinsTcpClient> _plcs = new List<FinsTcpClient>(); public async Task RunAsync(CancellationToken token) { while (!token.IsCancellationRequested) { foreach (var plc in _plcs) { try { ushort[] data = plc.ReadDm(100, 10); Console.WriteLine($"读取成功，第1个值: {data[0]}"); } catch (Exception ex) { Console.WriteLine($"读取失败: {ex.Message}"); // 这里交给重连逻辑处理，不要吞掉异常 } } await Task.Delay(200, token); // 轮询间隔200ms，现场可调到500ms } } }轮询间隔需要根据工艺要求调整。200毫秒在快速检测场景够用，但如果你PLC里的数据是温度这类慢变化量，1秒一次更稳妥。间隔短不完全是坏事，但通信压力会成倍增加，PLC响应不过来时反而会丢帧。
4.2 断线自动恢复：先退避再重连，别死磕
通信异常最怕程序卡死在Connect里。Socket超时设了3秒，但断网时重连也可能持续报错。我习惯在重连逻辑里加入指数退避：第一次失败等1秒，第二次2秒，第三次4秒，最多等10秒。这样可以避免PLC还没恢复时，程序像个疯子一样每200毫秒撞一次门。
private int _failCount = 0; public bool TryReconnect(FinsTcpClient plc) { int delay = Math.Min(1000 * (1 << _failCount), 10000); _failCount++; Console.WriteLine($"等待 {delay}ms 后重连"); Thread.Sleep(delay); try { plc.Connect(); _failCount = 0; return true; } catch { return false; } }这里的_failCount要连续失败才递增，一旦重连成功就清零。还有个细节：FinsTcpClient对象在重连失败后不能直接复用，要把旧连接释放掉，重新new一个再Connect。TCP连接断开后，底层Socket状态不一定马上转为Closed，直接复用容易踩“连接未完全释放”的坑。
4.3 心跳检测：读PLC时钟比什么判断都可靠
判断PLC是否在线，发送自定义测试帧也行，但最省事的是读一个不可能不变的地址。常见做法是读PLC的年的数据，每年递增一次，说明链路活着。用FINS命令读DM区时，地址和数量不变，开销极小。心跳和业务数据读取可以在同一个轮询循环里完成，不需要额外再开线程。
心跳还有一个重要作用：防止上位机和PLC之间长时间没有数据通信，被交换机或PLC自身的空闲连接机制断开。在轮询间隔超过1秒的场景，专门每5秒读一次D0，能有效维持TCP连接活跃，避免现场“第一包正常，第二包开始超时”的诡异故障。
4.4 UI线程与数据刷新：跨线程更新控件要冷静
WinForm或WPF里直接在工作线程里更新TextBox会报跨线程异常。新手通常用Invoke一层层套，代码越来越乱。更稳妥的做法是让工作线程只负责产出数据，界面层用System.Timers.Timer定时从缓存变量里取最新值。下面的代码演示了最简单的数据缓存模式：
private volatile ushort[] _latestData = new ushort[10]; // 在轮询线程里写 _latestData = plc.ReadDm(100, 10); // 在UI定时器里读 private void Timer_Tick(object sender, EventArgs e) { label1.Text = _latestData[0].ToString(); }参数volatile保证读写线程之间的可见性。注意_latestData数组本身要保持引用不变，每次更新是替换整个数组，而不是在循环里改数组元素，否则其他线程可能读到写了一半的数据。
5. FINS通信现场避坑：5个半夜让你去查线的常见坑
通信程序代码本身往往没大问题，真正让人头疼的是现场环境和配置偏差。这里列出的5条都是我自己反复踩过的坑，按“现象、原因、解决”的方式记录，希望能帮你少走几个来回。
5.1 现象：TCP能连上，指令发出去却一直超时
现场最常见的故障就是上位机TcpClient.Connect成功，但SendFinsCommand读不到响应。原因通常是PLC侧根本没有启用FINS/TCP服务，或者端口不是9600。Socket连上只能说明IP通了，PLC的应用层并没有监听这个端口。解决步骤是进PLC的系统设置，找到内置以太网或通信单元选项，确认FINS/TCP服务为启用状态，端口号记下来，填到C#程序的port参数里。用工具查一下PLC端口有没有LISTENING状态，比反复改程序快得多。
5.2 现象：读到的数值和PLC监视画面不一致，经常乘以16或除以16
这种偏差十有八九是地址映射错了。FINS的地址是按字偏移的，不是按字节偏移。比如监控软件里看到D1000，程序里startAddress写500，那就把D500读回来了。尤其是D区地址较大的时候，十六进制换算一定要自己拿计算器按一遍。解决方法是先在PLC里给目标地址写一个固定值，比如十进制12345，上位机读到后确认二进制值对不对，再把地址偏移表逐条核对。
5.3 现象：响应报错 FINS错误码 0x11 0x01
0x1101是FINS里很经典的内存区错误码，意思是内存区不存在或访问越界。最常见的原因是DM区代码或起始地址超出了PLC型号的允许范围。比如CP1H的D区只有32768个字，你读D40000就会触发这个错。解决方法是查一下PLC的数据区范围，把读取范围限制在有效地址之内。另一个容易被忽略的原因是单次读取的字数超过上限，比如一次读200个字，不少PLC直接拒绝。
5.4 现象：程序运行几小时后突然卡死，之后再也不读取
通信程序最常见的心跳卡死，就是ReadTimeout没有设置或者设置得太长。现场网络偶尔抖动一次，Socket读取会一直等着，看起来就是整个程序“冻住”了。我在基类里把读写超时都设为3000毫秒，读不到数据就抛异常进入重连逻辑，程序就不会死。设置超时后要注意异常处理顺序：先释放旧连接，再重新建立连接，别在同一个Socket上无脑重试。
5.5 现象：上位机重启后，PLC通信要等几分钟才能恢复
PLC作为服务端，当上位机突然断电或软件崩溃时，TCP连接可能处于半开状态，PLC侧不知道自己已经失联。重新连接时，PLC还在等旧连接的超时释放。解决方法是把轮询和心跳做成程序启动后主动重连，并且在PLC侧把连接确认时间调短；如果都没有效果，可以在中断恢复时先手动触发一次PLC的网络复位。这个坑在很多升级改造项目中特别容易遇到，原因是老设备保留着很多历史连接。
注意：遇到FINS错误码时，先别急着改代码。用日志把“指令发出时间、原始请求帧、响应结束码”都记录下来，往往能直接看出是哪一类问题，省得反复试错。
6. 用仿真器做回归：把通信代码变成长期可靠的通信服务
看过现场排坑，还要有一个能长期维持质量的习惯：用仿真环境做回归验证。没有真机的时候，欧姆龙的CX-Simulator或Sysmac Studio自带的模拟功能能提供虚拟PLC，它支持FINS/TCP连接地址通常指向本机的仿真映射端口。你只需要把FinsTcpClient的IP指向本机仿真地址，节点号按要求改一下，就能把整个读写流程在办公室跑起来。
逻辑层关键在收发帧的日志记录。在SendFinsCommand里把请求帧和响应帧都转成十六进制字符串打印出来：
private void LogFrame(string tag, byte[] frame) { var sb = new StringBuilder(); foreach (var b in frame) sb.Append(b.ToString("X2")).Append(" "); Console.WriteLine($"{tag}: {sb}"); }调用位置放在发送结束后和读取结束后各打一次。别小看这个习惯：很多时候你以为程序逻辑写错了，把日志翻出来一看，其实是第二次发送时SID没有递增，或响应的字节序跟预期不符。一个可靠的通信服务，先要有可靠的观测能力，代码只是让它跑起来的手段。
自动化冒烟测试也是个值得投入的方向。用脚本连续执行100次“连接、读D100、写D100、断开”的操作，中途不允许出现卡死和异常退出。这个过程能逼出很多偶发问题，比如Socket释放不彻底、序号溢出在高频调用时可能被忽略，但跑满100轮就藏不住了。每次发版前跑一遍，长期下来你会发现自己对通信代码的信心明显不一样。
我现在的习惯是：办公室里放一台仿真PLC常开，任何改动先在仿真环境连续跑一个周末，确认没有异常后再上真机。通信程序出问题的时间成本太高，要么白天产线停线，要么半夜被人打电话叫醒，这两样我都不太想再体验了。希望帮到你。
本文还有配套的精品资源，点击获取
