1. 先弄清欧姆龙的通信家族别一上来就写代码做C#上位机开发的人迟早会撞上“跟PLC通信”这道坎。我第一次接到欧姆龙的项目时也以为就是封装个Socket然后收发字节而已结果打开手册才发现事情没那么简单。欧姆龙的PLC至少有两条主流通信路线HostLink协议走串口和FINS协议走以太网。选错路线后面全是坑。先把这两条线捋清楚后面的代码才有意义。1.1 HostLink协议串口通信的老炮HostLink是欧姆龙很早提出的串口通信协议专走RS-232C/RS-422A。协议本身的定位很朴素——主站PC发送一条ASCII命令帧PLC返回一条ASCII响应帧一问一答没有任何花活。命令帧格式大致是这样结构指令头单元号命令码正文BCC异或校验结束符示例00RD00000010 FCS*CR其中RD是读命令读PLC从0x000010地址开始的1个字。后面紧跟着4字符的起始地址、4字符的数据长度。而FCS校验是用*之前所有字符逐个异或得到两个十六进制字符。响应帧则是从变成RR开头。比如读成功的响应RR00RD00000010 数据区 [FCS] *CR响应帧回带的数据往往是BCD编码解析时要小心——这是后话。如果你用C#写HostLink核心其实就三件事拼帧、算FCS、解析响应。// 计算FCS校验从后第一个字符到*前一个字符逐字符异或 static string CalculateFcs(string frameWithoutStar) { byte fcs 0; foreach (char c in frameWithoutStar) { fcs ^ (byte)c; } return fcs.ToString(X2); }拼帧时要注意地址、长度这些数字全部是ASCII字符串不是二进制字节。比如地址0x10帧里就是0010这四个字符。初学者最常犯的错就是把int直接转成像素导致PLC完全看不懂。1.2 FINS协议以太网通信的正规军FINS是欧姆龙另一套更现代的协议全称Factory Interface Network Service。它同样支持串口但现在主流是走UDP/TCP而FINS/TCP是工业现场最常用的一种。FINS帧结构就比HostLink“重”多了帧头FINS头部命令码参数区46 49 4E 53 00 00 00 0C 00 00 00 0080 00 02 00 00 00 00 1001 0182 00 10 00 00 01注意FINS的数据是二进制的不是ASCII字符串。这跟HostLink完全是两种思维。头部里包含了ICF、RSV、GCT、DNA、DA1、DA2、SNA、SA1、SA2、SID、命令码和参数区。新手看到这一排字节往往直接懵了。但好消息是欧姆龙提供了官方动态链接库FinsTcp.dll / FinsUdp.dll还带.NET封装。你要是图省事直接引用官方库也能做。但我的建议是能自己写就别依赖官方库。原因后面细讲。1.3 选型的现实逻辑串口还是以太网这个问题不是“哪个好”而是“你的产线上有什么”。老设备改造很多老产线的CP1A、CQM1H只有串口带HostLink协议你只能走串口。新项目CP1E、CP1L、CJ2、NJ/NX系列基本都带了以太网口FINS/TCP就是首选速度快、抗干扰强、还能多客户端同时连接。距离远、环境恶劣以太网用屏蔽双绞线走100米没问题串口RS-232只能15米左右RS-422可以到1200米。从开发便利度来说FINS/TCP明显更舒服——TCP天然支持长连接PLC侧只需要在内存里配好IP、端口号和节点号PC端就是Socket的常规操作。串口虽然原理简单但牵扯到波特率、数据位、停止位、校验位这些参数任何一个不匹配都等你半天。下面我把两条路都走一遍给你一套能直接抄的代码。2. 环境准备与通信链路自检写代码最忌讳的就是“代码觉得没问题现场却连不通”。等不及写逻辑先花15分钟把链路打通能帮你过滤掉90%的瞎折腾。2.1 硬件与驱动先确认电脑能找到PLC以我的经验最容易卡住的第一关不是代码是驱动和IP配置。USB串口线欧姆龙PLC自带的USB口通常用于编程软件不会映射成串口。你要买的是“USB转RS-232C”或者“USB转RS-422A”的转换线插上后确认电脑设备管理器里识别出COM口号。CP1A的串口DB9针脚定义和普通工控设备的定义可能不一致接线前务必看PLC手册里的针脚图。以太网口给PLC设置好固定IP保证电脑和PLC在同一网段。比如PLC设置192.168.1.10电脑网卡设192.168.1.20掩码255.255.255.0别设网关。这里提供一个串口通信的自检测试PLC侧先验证HostLink能通最直观的方法是用串口调试助手往COM口发一条HostLink命令帧看PLC能不能回数据。2.2 以太网通信前的连接测试如果走FINS/TCP先用ping确认网络可达ping 192.168.1.10 -t端口默认是9600FINS/TCP握手时PLC会先响应一个46 49 4E 53 00 00 00 0C 00 00 00 00的帧头这个帧头也叫FINS命令头确认对方身份用的。如果你用TCP调试工具连接能正常看到这个握手回复就说明网络层没问题。注意欧姆龙PLC的FINS/TCP服务在出厂时不一定默认开启。某些型号比如CP1E需要在Sysmac Studio里把“内置以太网端口”的FINS/TCP服务打开并设置好节点号、IP地址。2.3 串口通信前的参数确认HostLink默认参数通常是波特率9600数据位7位或8位停止位2位或1位偶校验。但这是“通常”具体以PLC的系统设定区为准。内部以CJ2M、CP1系列为例DIP开关可以切换波特率默认的设定未必是9600。我的习惯是先读PLC手册的“串行通信设定”章节确认DIP开关和系统设定区再按官方默认值试。如果怎么调都连不上检查一下是不是PLC侧把串口改成了“编程模式”或“无协议模式”HostLink只认“HostLink模式”。3. 用HostLink协议手写一套串口通信我倾向于把串口通信做成一个独立的类封装好“打开”“关闭”“读”“写”四个操作。这样不管是用在WinForm还是服务里都很顺手。3.1 命令帧格式从构造到解析先看一个完整的读命令样例读DM区0000地址1个字帧 00RD00000001FCS*CR说明00是单元号默认00RD是读命令0000是起始地址0001是长度此处我用来做示例真正长度要看PLC地址位数规则。FCS 把00RD00000001里所有字符异或后的两位十六进制ASCII注意地址的规则——HostLink的DM区地址编号是4位十六进制比如DM0000对地址转换时要直接去掉“DM”前缀填0000。如果你要读CIO区规则又不一样具体查阅手册。private string BuildReadFrame(int dmAddress, int wordCount) { string command 00RD dmAddress.ToString(X4) wordCount.ToString(X2); string fcs CalculateFcs(command.Substring(1)); // 从00开始算 return command fcs *\r\n; }发送后用SerialPort.ReadLine()读到以\r\n结尾的响应帧。比较响应头是RR还是RF前者代表正常后者代表异常异常码在后续章节会讲。3.2 响应帧解析不要把字符直接当成数值响应帧的格式是00RD 4位十六进制数据 FCS *CR如果读取成功中间会回带若干组4位的十六进制字符。但欧姆龙的寄存器里存的可能是BCD码也可能是二进制数据。这里最容易出问题——解析时必须先看PLC程序里用的是MOV指令还是BCD指令以及你用的是什么寻址模式。我实际踩过的坑从温控器上读回的温度值程序里存的是BCD解析时我却按二进制转了结果70℃读成了112。后来改了解析函数static double BcdToDouble(string bcdString) { int result 0; foreach (char c in bcdString) { int nibble c - 0; if (nibble 0 || nibble 9) throw new FormatException($非BCD数据: {bcdString}); result result * 10 nibble; } return result; }原则读到的原始字符串先别急着转数确认是“文字字符串”还是“数值数据”。比如PLC程序里用MOV #10 D100那D100里就是16位整数的二进制表示如果用BCD相关指令才需要按BCD解。3.3 写入操作小心写保护与地址范围写DM区的HostLink命令是WD格式类似00WD 0000 0001 数据 [FCS] *CR这里“数据”是4位十六进制表示的实际内容。如果写的是位bit用的是WB范围是CIO区中的某一位写通道时注意DM区按字读写CIO区有字也有位不能混用。现场最容易出现的异常码是1F命令格式错误和21地址范围错误多半是地址或长度写超出范围或者是DM区写入了只读区域。欧姆龙的DM区D0~D32767是可读写的但某些特殊继电器区是只读的写之前查一下手册里的“内存映射表”。3.4 串口通信实测中的常见幺蛾子写代码只是第一步现场问题往往出在你不注意的地方波特率乱改后忘恢复现场工程师通过编程软件改了PLC串口波特率后没恢复原设置导致PC通信全挂。解决写代码前先确认PLC当前通信设置用编程软件查看或强制复位系统区。USB转串口兼容性很多免驱USB转串口芯片假CH340、假FTDI会丢字节。我在现场遇到过“响应帧时有时无”的现象最后换了一根独立的USB转RS-422线才稳定。串口缓冲残留如果上次通信因异常中断PLC发送的响应帧可能滞留在缓冲区。每次打开串口后先DiscardInBuffer()清空缓冲避免把残留帧当成当前响应。sp.DiscardInBuffer(); sp.DiscardOutBuffer();4. FINS/TCP与FINS/UDP实战以太网通信的正确姿势FINS/TCP比起HostLink最大的进步在于帧头握手机制可靠的TCP连接。不用再手工算FCS也不用担心7位字符的编码问题一切以字节流为单位。4.1 三次握手FINS/TCP的地址绑定FINS/TCP通信的第一步是建立TCP连接然后发送握手命令。欧姆龙FINS/TCP的握手帧是固定格式46 49 4E 53 00 00 00 0C 00 00 00 00 00 00 00 00 00 00 00 00前4字节是FINS的ASCII码第13-16字节是“节点地址”可以填0表示由PLC自动分配后面还有8字节的数据长度和错误码字段。握手成功后PLC会给PC分配一个节点地址之后所有FINS命令帧都要带着这个节点号。public class FinsTcpClient { private TcpClient _tcp; private readonly string _ip; private readonly int _port; public FinsTcpClient(string plcIp, int port 9600) { _tcp new TcpClient(); _tcp.Connect(plcIp, port); Handshake(); } private void Handshake() { byte[] handshake { 0x46, 0x49, 0x4E, 0x53, // FINS 0x00, 0x00, 0x00, 0x0C, // 数据长度 0x00, 0x00, 0x00, 0x00, // 命令码 0x00, 0x00, 0x00, 0x00 // 错误码/节点号由模块回填 }; _stream.Write(handshake, 0, handshake.Length); _stream.Flush(); byte[] resp ReadExact(20); // 读20字节 // 解析响应提取节点号 _node resp[13]; } }注意TCP握手帧的字节序要求比较严格很多坑就出在“组包字节序”上。帧头和FINS命令头里的多字节字段用了大端Big-Endian编码C#里BitConverter默认是小端组包时要用IPAddress.HostToNetworkOrder或手动倒序。4.2 读取和写入内存区从帧组装到数据提取以读取DM0000开始的10个字为例FINS命令帧如下80 00 02 00 00 00 00 10 - FINS头部含命令码01 01 01 01 - CPU单元命令读取内存区 82 00 10 00 00 0A - 参数区DM区起始地址 00 10长度 00 0A看仔细了FINS的内存区代码区域代码字节序CIO区0x30字地址从0开始DM区0x82字地址从0开始WR区0x31——写代码时可以这样构建帧byte[] BuildReadDm(int startAddress, int wordCount) { var frame new Listbyte(); frame.AddRange(new byte[] { 0x46, 0x49, 0x4E, 0x53 }); frame.AddRange(new byte[] { 0x00, 0x00, 0x00, 0x0C }); frame.AddRange(new byte[] { 0x00, 0x00, 0x00, 0x00 }); frame.AddRange(new byte[] { 0x00, 0x00, 0x00, 0x00 }); frame.Add(0x80); frame.Add(0x00); frame.Add(0x02); frame.Add(0x00); frame.Add(0x00); frame.Add(0x00); frame.Add(0x00); frame.Add(0x10); frame.Add(0x01); frame.Add(0x01); frame.Add(0x82); frame.Add(0x00); frame.Add(0x10); // 起始地址 frame.Add(0x00); frame.Add(0x00); frame.Add(0x0A); // 长度 // 补齐FINS头命令码参数区的字节此处省略部分细节 return frame.ToArray(); }响应帧中错误码为0x00就是正常否则就是异常后面详表。数据按字2字节排列大端序。如果你读的是DM区存的实际数值解析时要把0x12 0x34并成一个0x1234再转short或ushort。ushort raw (ushort)((data[i] 8) | data[i 1]);4.3 FINS错误码遇到不要慌对着表查FINS返回的错误码响应帧中命令码后第2个字节常见几类错误码含义常见原因0x01命令长度错误帧长不符合规范0x02命令格式错误参数区长度/内容有误0x03地址范围错误起始地址长度超出范围0x04数据格式错误送入的数据类型不符0x1F命令保护异常写入被“程序保护”或密码锁定碰到0x03十有八九是地址换算错了——比如CJ2的DM区上限是D32767你读D32766长度为4个字就超界了。改小长度即可。经验FINS如果你想稳定复用一定要把错误码包裹进自定义异常里。项目后期排查问题时你能用一句话告诉客户“地址越界”还是“数据格式错误”远比丢一个TimeoutException专业得多。5. 工程化封装把通信层做成可以放心复用的大腿通信代码写出来不难难的是它能扛住产线7x24小时不间断跑。我从几个现场项目里总结出一套封装思路适用性很高。5.1 封装通信层为单例服务把通信核心逻辑与界面彻底分离。我一般定义三个类PlcConfig存放IP、端口、单元号、超时时间、重试次数。PlcCommunication封装HostLink和FINS两种实现暴露出ReadDm(int address, int count)和WriteDm(int address, int[] data)。PlcMonitor业务层比如每100ms读一次温度达到阈值则报警。界面里不要直接引用SerialPort或TcpClient全部通过接口调。这样后期如果PLC从CP1E换成NJ/NX代码改动量能控制在几小时以内而不是重写整个上位机。5.2 超时与重试策略工业通信的生死线工业场景下PLC响应慢了不是异常是常态。机床换刀、固件升级、甚至PLC忙于梯形图逻辑扫描都可能让响应延迟到几百毫秒。你要是设个50ms超时现场分分钟变“通信故障”。我建议的超时参数普通读写首次超时500ms重试2次每次间隔100ms。整体控制在1.5秒内既不影响产线节拍也更兼顾稳定性。public byte[] ExecuteWithRetry(byte[] request, int maxRetry 2) { for (int attempt 0; attempt maxRetry; attempt) { try { Write(request); return ReadResponse(); } catch (TimeoutException) { // 重试前主动清空缓冲 _stream.Flush(); Thread.Sleep(100 * attempt); } } throw new PlcTimeoutException(PLC连续两次超时); }5.3 异步与并发注意别把主线程堵死WinForm里直接在UI线程同步读PLC会卡界面。这倒不是不能用但客户可能会觉得软件“死了”而疯狂点鼠标反而给现场添乱。我现在的习惯是用async/await把读写全部异步化public async Taskbyte[] ReadAsync(byte[] request, CancellationToken token) { // 用SemaphoreSlim保证同一时刻只有一笔PLC请求在发送 await _lock.WaitAsync(token); try { await _stream.WriteAsync(request, 0, request.Length, token); return await ReadResponseAsync(token); } finally { _lock.Release(); } }重要上位机同时多个任务读PLC时一定要在通信层做互斥SemaphoreSlim。FINS/TCP虽然支持长连接但PLC处理单条命令是顺序的并发发命令会造成响应错乱的问题——虽然TCP流不会丢但响应和请求的顺序可能不是一一对应尤其是你复用了同一个连接。5.4 日志记录排查问题的最好线索我在通信层里放了两条日志Debug级记录每一条发出去的帧十六进制字符串和收到的帧。这个对定位“地址错、格式错、校验错”极其高效。Error级记录异常错误码、超时原因、重试次数。日志建议存成文件最小化滚动别打到数据库——数据库一旦锁表反而拖垮整个系统。6. 一些现场经验与细节最后这部分我专门挑几条真正让新手抓狂的经验按优先级写给你。6.1 欧姆龙PLC的地址范围确实跟三菱不一样三菱FX用D0-D7999欧姆龙CP1系列是D0-D32767但其中D32760-D32767被系统占用读写会返回错误。我做项目时经常默认“D区32767上限”结果现场一写就报地址异常。现在的习惯是写代码前先查型号内存表写地址时把系统区留出来。6.2 USB驱动与Sysmac Studio版本容易冲突欧姆龙的USB驱动OMRON USB Driver装在多台电脑上有时会冲突——尤其是你安装了CJ2的旧版驱动新装CP1E驱动时可能互相覆盖。症状是编程软件连不上PLC但驱动显示“正常”且设备管理器能看到COM口。解决方式装新版本Sysmac Studio或CX-Programmer会把配套USB驱动一并更新。如果设备管理器里出现黄色感叹号先卸载旧驱动再重装当前版本。6.3 “程序保护”和“写保护”的坑欧姆龙CJ2/NJ系列在“程序保护”状态下钥匙开关拨到RUN且写保护FINS写入命令会被拒。错误码是0x1F。调几小时代码不如拨一下钥匙开关。我遇到过一次死活写不进D区查遍手册才发现是CPU单元上写保护开关没有拨回去。回头想想这其实是个很消耗时间的低级错误。6.4 无协议模式与HostLink模式的冲突很多人拿欧姆龙PLC的串口既连HMI又连PC结果HMI把PLC串口设成了“无协议模式”上位机HostLink命令全部石沉大海。这里有一个判断技巧如果发00RR........命令后PLC连回帧都没有先别管代码用编程软件连接一下PLC看串口通信模式是不是HostLink。如果变成了“无协议”把它改回来就行。6.5 以太网通信时PLC节点号Node Number必须配好FINS/TCP的帧里DA2目标节点号和SA2源节点号都必须是有效的0-254之间的数。PLC侧如果没设置节点号或者节点号重复握手虽然成功但读写请求可能直接超时。我在现场遇到过两台PLC都设置了节点号10结果电脑连哪台都连不上——单独设置成不同节点号后立刻恢复了。这个细节如果你不接触多PLC项目几乎不可能一下预料到。7. 代码示例放不放我的看法不少文章到了这里习惯性贴一大堆完整代码。但坦白说通信类代码的价值在协议细节和现场参数完整源码贴出来反而容易让人产生“我只要复制就能跑”的错觉。建议你拿本文的思路去读欧姆龙官方手册CJ/CS/CP系列通信指令手册、FINS指令参考手册对着示例程序自己敲一遍效果最好。我在实际项目上最常用的一套组合是HostLink做串口调试时的快速验证FINS/TCP做主生产通信。前者适合在现场临时用串口调试助手排查问题后者适合上位机与PLC进入批量生产的高频读写阶段。两套代码同时维护一套PLC数据访问接口迁移成本极低。最后分享一个小技巧欧姆龙的官方手册写得非常完备但光看手册学不会抓重点。我建议你先把本文提到的命令帧用TCP调试工具手动发一遍成功了再写程序。这样你就能在代码出错时快速判断——到底是协议理解错了还是C#写错了。这段实践经验比任何教程都值钱。