很多人问我上位机开发最难的是啥。我说界面不对那玩意儿就是个壳子。数据库也不对SQL写熟了就那么几条。最难的是通信就这一块能卡死你大半的项目时间。我刚入行的时候天真得很觉得通信不就是打开串口发几个字节过去那边回了几个字节我收一下就完事儿了嘛。后来才明白通信这个坑有多深每往下走一层就多一堆你想都想不到的破事儿。第一层坑你以为你配对了参数实际上根本没通这是新人遇到的第一个拦路虎也是被坑得最惨的一关。我头一回接真实的设备串口调试助手打开COM口波特率9600、数据位8、停止位1、无校验照着设备手册配的。发了一条读取命令出去等了半天接收框里啥都没有。我开始调参数波特率从9600换到19200再换到4800不行。校验位换奇校验、偶校验、Mark、Space全试了一遍还是没动静。折腾了两个多小时一脑门子汗最后发现设备那头根本没上电。这是最蠢的一种但后来我发现很多人第一步都栽在这种蠢事儿上。通信没通你第一反应是调参数但真正的原因可能是设备没通电、线没接上、TX和RX接反了、USB转串口的驱动没装对、电脑分配的COM口号跟设备实际的不一致、甚至是你打开串口的时候别的软件已经占用了这个口。我的经验是接了设备之后第一件事不是写代码是拿个现成的串口调试助手先发一条指令试试能收到东西了再去调代码。调试助手里能通你的代码不通那是你代码的问题。调试助手里都通不了你改代码改到天亮也没用。这第一层坑难就难在你根本不知道问题出在你这边还是设备那边只能一个一个排查。新手卡在这一步卡个一两天太正常了。第二层坑参数对了线也对了收到的全是乱码等你能收到数据了你以为胜利在望结果收上来的东西根本不是你想的那个样子。一个典型的场景你发了一条03命令去读寄存器设备回了十来个字节你拿着说明书一对报文头对了、地址对了、功能码也对了但是数据部分的值怎么算都不对。这是编码和字节序的问题。有一次我读一个温湿度传感器的数据说明书上写温度值占两个字节高位在前单位为0.1摄氏度。我收到了两个字节0x01和0x2C按照高位在前拼起来就是0x012C换算成十进制就是300再乘以0.1就是30.0度。结果实际环境温度我拿温度计一测明明只有25度。怎么回事我把两个字节反过来0x2C01换算出来是11265更不对了。后来我把收到的原始数据打印出来才发现这设备回的数据根本不是两个字节代表一个数而是一个字节代表整数部分、一个字节代表小数部分。0x01代表整数10x2C是44组合起来是1.44度也不对。最后翻了设备厂家更早版本的说明书找到一行小字本设备通讯数据采用自定义格式第一个字节为整数部分第二个字节为小数部分乘以100后的值。所以0x01和0x2C算出来是1.44度。换成这个公式跟实际温度对上了。这种破事儿你找谁说理去。明明是标准Modbus协议厂家在数据格式上自己加了个魔改。还有就是字节序的大小端问题。有些设备是Big-Endian高字节在前低字节在后你按大端拼出来是对的。换了台设备它是Little-Endian你按大端拼出来的数值不知道跑哪儿去了。我的处理办法是数据格式全都做成可配置的不写死在代码里。用户自己选高字节在前还是低字节在前选有符号还是无符号选整数还是浮点选原始值直接显示还是乘以系数再加偏移。虽然配置界面做得复杂了点但至少不会因为换了设备就得改代码重新编译。第三层坑数据能收了但包拆不对你调通了单条指令的收发觉得差不多了开始做连续采集。这时候第三个坑来了。串口通信是流式的就是你发一条指令设备回一堆字节这堆字节是连续从线上流过来的。你收到的数据可能是一次性来一整包也可能拆成了两三段分着来。我有个项目采集八台仪表的温度数据每台仪表每秒回一帧每帧13个字节总共每秒104个字节。看起来不多吧但是八台设备挂在同一条485总线上轮询读取数据你挤我我挤你地回来收数据缓冲区里永远是乱糟糟的一堆。我的做法是把收到的东西全部存到一个缓冲区里然后从缓冲区里面找帧头帧尾找到了就截取出来解析剩下的留着跟下次收到的拼在一起继续找。这个过程说起来简单写起来全是细节。万一数据帧里面恰好有个字节跟帧头一样怎么办万一设备返回了异常帧长度不对怎么办万一设备没回完整帧就超时了怎么办有一种情况我处理了很久才想明白收到数据后要立刻启动一个超时定时器超时时间内如果还没收完一帧就认为这次通信失败了。因为有些老设备反应慢你发完命令它要几百毫秒才开始回数据你要是傻等程序就卡在那里了。还有一种更恶心的设备回的数据中间夹杂了干扰字节导致CRC校验怎么算都不对。这种我通常的做法是再发一次命令重新读如果连续三次CRC都不对就判定这条数据无效记录下来然后跳过。第四层坑拆包解决了但程序卡了前面都搞定了程序终于能稳定收数据了界面也能正常刷新了。你喝口茶歇会儿过了半小时回来一看程序死了界面卡住不动了。这是多线程的问题。串口接收事件是在子线程里触发的你在这个事件里直接更新UI控件的Text属性就会抛出跨线程操作无效的异常。很多新人的解决办法是加上Control.CheckForIllegalCrossThreadCalls false把这行代码一关了之。我也这么干过然后程序就时不时莫名其妙地崩掉。UI线程和通信线程抢着改同一个控件的属性数据竞争界面要么显示不对要么直接卡死。正确的做法是用Invoke。子线程要更新UI的时候用this.Invoke把一个委托丢给UI线程去执行保证UI的修改永远在主线程里完成。我的写法是这样的private void UpdateDisplay(string value) { if (this.InvokeRequired) { this.Invoke(new Actionstring(UpdateDisplay), value); return; } this.textBox1.Text value; }这套写法我用了好多年没出过问题。后来换成BeginInvoke异步更新UI更流畅一些但原理是一样的。比跨线程更新UI更隐蔽的是多线程共享数据的问题。通信线程不停地往一个List里面添加数据UI线程每隔一秒把这个List拿出来显示两个线程同时在读写同一个集合不加锁的话程序迟早要崩。最简单的就是加锁lock(obj)包住读写操作。数据量大的时候用ConcurrentQueue或者BlockingCollection生产者消费者模式天然线程安全。第五层坑程序稳定了但延迟下不去有些项目要求响应速度快。我之前那个精密测量的项目要求两百毫秒内从设备拿到数据并显示出来超了就判定为通信故障。C#是托管语言有GC。你不停地在通信线程里new对象、new数组GC就会频繁触发。GC触发的时候所有托管线程都要暂停通信线程一暂停你这边的超时定时器还在走一下子就超时了。我之前有一版程序连续跑一个小时之后通信延迟从50毫秒慢慢涨到200多毫秒然后时不时超时报错。查了半天就是GC闹的。最后把所有通信线程里的临时对象全干掉了。收发缓冲区提前分配好一次new完循环使用。收到的数据用指针操作能不用new就不用new。日志改用异步批量写入减少对象分配。折腾完了再跑延迟稳定在了30毫秒以内连续跑了一天没出过问题。第六层坑你这边都搞定了现场给你出幺蛾子前面五层你都过了到了现场还有第六层等着你。最常见的干扰。工厂车间里变频器、大电机到处都是这些东西一开485线上全是干扰脉冲你的程序收到的数据时不时就多几个字节或者少几个字节。你代码写得再稳原始数据就是错的你能怎么办实际项目里我加了三个措施来应对第一CRC校验不过的数据直接扔掉绝不用错误数据去更新界面。第二连续三次通信失败就触发报警让操作工知道通信有问题而不是默默用错误数据顶着。第三所有成功收到的数据在日志里存一份原始报文出问题了可以翻出来跟设备厂家对质。有一次出了个特邪门的事设备显示温度和上位机显示温度在某个特定时刻总是差两度其他时候都正常。排查了一整天最后发现那天下午两点到三点之间旁边有台大焊机在干活一开机就产生强电磁干扰正好把温度数据的某个位给干扰了。这事你代码怎么处理没办法只能让甲方把那台焊机挪远点或者把485线换成带屏蔽的。还有一个坑是设备关机重启之后不回数据了。有些设备上电之后要几十秒才能准备好通信你这边程序一启动就连它肯定超时。后来我在程序里加了重试机制连不上就等三秒再试试十次还连不上才报错。这个重试逻辑看着简单写起来要考虑的东西不少重试间隔不能太短也不能太长重试次数不能太多也不能太少每次重试状态怎么记录界面怎么提示用户。说几句心里话上位机通信这东西从入门到能干活可能三个月就够了。但从能干活到什么样的通信问题来了我都不慌至少得三年。因为那无数种你永远想不到的意外情况必须靠时间堆出来。纯软件的工程师觉得通信就是调库一个NuGet包装进去三行代码就搞定了。那是因为他的应用场景简单标准的HTTP请求发出去标准的JSON回来中间的网络环境是可控的。上位机不一样你不知道线那头接的是个什么玩意儿说明书可能印错了参数可能配反了设备可能在工作的时候突然断电重启了车间环境可能今天和明天完全不一样。你要处理的事情远远超出了发一个请求收一个响应这个简单的模型。我现在看一个项目半天时间就能把通信层的框架搭出来剩下的时间全在填那些万一怎么怎么样的坑。超时了怎么办、断线了怎么办、数据格式不对怎么办、设备无响应怎么办、缓冲区溢出了怎么办、线程冲突了怎么办、GC暂停了怎么办。这些问题你提前想到了代码里处理了现场出问题了你一翻日志就知道怎么回事。你没提前想到现场就要蹲在那儿一个个调运气好半天解决运气不好三天都不一定能定位到原因。所以回到最初那个问题上位机通信究竟难在哪里难就难在它不再是一个纯粹的软件问题它下面还压着一整层你控制不了的物理世界。而你的程序必须在这个你控制不了的世界里稳定可靠地活着。