简介面向需要与德国SICK RFU630 RFID读卡器联调的C#开发者这份代码工程将TCP客户端与工业RFID读取场景结合集中演示了异步IO、多线程调度和委托跨线程更新UI三个核心问题。压缩包内共有32个文件体积约60KB核心是10个C#源码文件配合解决方案文件与工程配置另有3个exe程序可直接运行验证resx/resources界面资源与pdb调试符号也一应俱全。已有1296人学习使用。工程详细展示如何使用TcpClient建立稳定连接如何在NetworkStream上通过async/await实现非阻塞读取以及怎样借助Task或Thread维护独立读卡线程同时通过委托和Control.BeginInvoke安全回传数据解决跨线程访问控件的常见异常。对于准备接入工业RFID设备、需要快速理解C#异步网络编程实战套路的开发者这份小巧但完整的示例覆盖了从IP端口配置、连接、发送指令到接收数据的完整链路具备很高的参考与移植价值尤其适合做二次开发时的最小可用原型。 前不久接了个产线MES对接的活儿一台德国SICK的RFID读卡器要求上位机用C#写一个TCP客户端把读卡器读到的标签数据异步取回来实时入库。项目本身不大但真做起来发现坑不少——协议帧怎么组、C#异步Socket怎么写、半包粘包怎么拆、断线怎么重连每一个点都能让人卡上半天。我想把这套SICK RFID读卡器读卡程序的完整实现思路写出来包括TCP客户端的骨架代码、通信协议解析、异步收发的关键细节以及现场调试时最容易翻车的几个地方。如果你正在做RFID、扫码枪、工业设备的上位机对接这篇文章应该能帮你少走不少弯路。1. 为什么用TCP客户端连SICK读卡器而不是串口或SDK1.1 工业读卡器的网口化趋势SICK的RFID读卡器在自动化产线上用得很多典型的如RFU系列基本都带了以太网接口支持TCP/IP通信。很多老工程师习惯性想到串口觉得简单、稳定但新设备、新产线里串口的比例越来越低。原因很现实串口传输距离有限波特率再高也就115200而且一台工控机要接多台读卡器时串口资源根本不够用。走以太网之后一根网线就能解决通信距离和组网问题通过交换机能同时接十几台设备数据量也大得多。另外SICK这类工业读卡器通常还支持多种工业协议比如PROFINET、EtherNet/IP、Modbus TCP但纯上位机做数据采集时最通用、最灵活的方式反而是直接开一个TCP Socket走读卡器原生的Host Protocol主机协议或者把读卡器配置成TCP Server模式让C#上位机作为TCP客户端去连。这种方式的优点是依赖最少不需要装任何SDK、不需要额外授权只要知道IP、端口和报文格式就能干活。1.2 动手前先确认三件事能省三天事写代码之前我强烈建议先确认三件事读卡器的IP地址和端口号。SICK读卡器一般可以在配置软件比如SOPAS里或网页配置界面里看。默认端口不一定相同常见的有2112、8090之类一定要按你手里这台设备的实际配置来不要凭经验猜。当前运行的协议模式。很多SICK读卡器出厂可能默认是PROFINET或Modbus TCP而不是纯TCP Host Protocol。如果你直接发ASCII命令过去设备可能只会回总线协议的报文通信根本对不上。需要先在配置软件里把通信接口切到TCP/IP Host模式。报文格式是ASCII还是十六进制。有的读卡器配置成文本模式时命令是可读字符串配置成二进制模式时就需要按字节组帧。这一点直接决定你后面所有代码怎么写。我把串口和TCP的差异整理成一张表方便你选型时做判断对比项串口TCP/IP传输距离一般十几米就衰减明显网线100米加交换机可扩展速率115200bps以内百兆/千兆远高于串口同时接入数一台工控机串口有限可接交换机多设备并发工程布线专用线缆抗干扰要求高标准网线方便维护上位机实现难度简单SerialPort即可需要处理Socket、拆包粘包适用场景老设备、点位少新建线、集中采集、多读卡器结论很简单如果读卡器有以太网口优先走TCP。虽然写起来比串口多了点技术门槛但后期扩展和维护舒服得多。2. 报文结构必须先吃透SICK读卡器的帧格式和校验方式2.1 一个典型的请求/响应帧长什么样SICK读卡器的Host Protocol在不同型号上可能有差异但大多逃不开一种结构起始符、设备地址、长度、命令、数据、校验、结束符。我以自己调试过的二进制帧形式为例通用结构如下字段字节数说明STX1起始符通常为0x02ADR1设备地址单机时一般0x00LEN1从命令字到数据末尾的总长度CMD1命令字比如读标签、读配置DATAN参数或标签数据LRC1校验字节ETX1结束符通常为0x03比如发送一条“读ID”命令命令字假设是0x20数据字段为0x00那么帧会是02 00 02 20 00 LRC 03。其中LEN0x02表示CMD DATA一共2个字节。总帧长就是5 LEN也就是7字节。不同设备可能有其他变体千万别把这个结构当铁律但理解思路后换到别的设备也快。提示开始写代码前一定先把设备手册里的帧结构拍下来对着逐字段核对。工业设备不像PC外设很多自定义协议靠猜会死得很惨。2.2 LRC校验的手工计算法很多SICK读卡器的二进制协议使用LRC纵向冗余校验作为帧校验。计算方式不复杂从ADR开始一直到DATA的最后一个字节把这些字节逐个异或再取反得到LRC字节。用C#写就是一小段static byte CalcLrc(ReadOnlySpanbyte data) { byte xor 0; foreach (var b in data) { xor ^ b; } return (byte)~xor; }以刚才的命令帧为例对00 02 20 00这四个字节做LRC0x00 XOR 0x02 0x020x02 XOR 0x20 0x220x22 XOR 0x00 0x22取反得 0xDD所以完整帧是02 00 02 20 00 DD 03。有些设备可能直接异或不去反有的甚至用累加和就算同样叫LRC细节也能差出十万八千里。所以加校验函数的时候最好用一个配置项区分“异或取反”还是“直接异或”现场切换方便。我吃过这个亏手册上写的是BCC校验我按惯用LRC去算整整折腾了两个小时才发现校验方式少了一步取反。2.3 先抓帧再写解析器很多同事拿到代码任务是直接开写TCP客户端我反而建议先做一步“不写代码”的动作用TCP调试助手或者干脆用C#写个最简单的Socket客户端手动连接读卡器发一条命令把读卡器返回的原始字节流完整看一遍。这个动作能帮你确认三件事设备响应是否正常、返回的帧里命令字段和长度字段的位置、以及标签数据藏在哪个字节区间。等原始数据抓清楚了你再动手写解析器成功率会高很多。我见过太多人上来直接写正式程序结果一边写一边猜协议写完全是Bug最后还搞不清是代码问题还是设备问题。3. C#异步TCP客户端骨架连接、发送、接收三层分离3.1 连接和断线重连的基本框架C#里做TCP客户端最直接的是TcpClient类。异步读取用async/await非常顺手关键是不要把所有逻辑堆在事件里而是分成连接管理、发送、接收循环三块各自独立。下面是一个简化的骨架代码public class SickRfidTcpClient : IDisposable { private TcpClient _tcpClient; private NetworkStream _stream; private CancellationTokenSource _connectCts; private readonly SemaphoreSlim _sendLock new SemaphoreSlim(1, 1); public event Actionbyte[] FrameReceived; public event Actionstring Disconnected; public async Task ConnectAsync(string ip, int port) { _connectCts?.Cancel(); _connectCts new CancellationTokenSource(); _tcpClient new TcpClient(); _tcpClient.ReceiveTimeout 3000; _tcpClient.SendTimeout 3000; await _tcpClient.ConnectAsync(ip, port); _stream _tcpClient.GetStream(); // 接收循环放后台跑不阻塞主流程 _ ReceiveLoopAsync(_stream, _connectCts.Token); } public bool IsConnected _tcpClient?.Connected ?? false; }这里要特别说明ReceiveTimeout只对同步读写有效异步ReadAsync并不会自动受它控制。所以真正的超时控制要么靠CancellationTokenSource.CancelAfter要么在接收循环自己做判断。如果后续要用异步发送建议发送方法里套一层带超时的等待否则命令丢失或设备停机时任务可能一直挂在那里。3.2 发送命令与等待应答的任务管道工业读卡器很多是“请求-响应”型上位机发一条命令读卡器回一条结果。如果每个命令都裸写WriteAsync再等接收代码会很散。我习惯用TaskCompletionSource做命令和响应的匹配发送时登记一个等待对象接收循环解到对应命令帧后把结果写回这个Task。private readonly ConcurrentDictionarybyte, TaskCompletionSourcebyte[] _pendingAwaits new(); public async Taskbyte[] SendCommandAsync(byte command, byte[] payload, CancellationToken ct default) { // 组帧、校验 var frame BuildFrame(command, payload); var tcs new TaskCompletionSourcebyte[](TaskCreationOptions.RunContinuationsAsynchronously); _pendingAwaits[command] tcs; await _sendLock.WaitAsync(ct); try { await _stream.WriteAsync(frame, ct); } finally { _sendLock.Release(); } using var timeoutCts CancellationTokenSource.CreateLinkedTokenSource(ct); timeoutCts.CancelAfter(3000); return await tcs.Task.WaitAsync(timeoutCts.Token); }有几处细节_sendLock用来保证同一时间只发送一条命令避免读卡器不支持并发命令时互相干扰。_pendingAwaits按命令字做匹配收到响应帧后从字典里取出TaskCompletionSource调用TrySetResult。超时触发后记得把TaskCompletionSource从字典移除否则会积累内存或导致后续响应匹配错乱。如果你的读卡器支持“主动上报”标签比如感应到标签后实时推送不需要每次请求那么接收分发的逻辑还要再拆一层一部分帧是“请求-响应”另一部分是“事件推送”两者要分别处理。3.3 基于NetworkStream的异步接收循环接收循环是整个程序的发动机核心就是一个不断从NetworkStream读数据的循环private async Task ReceiveLoopAsync(NetworkStream stream, CancellationToken ct) { var buffer new byte[4096]; var receiveBuffer new Listbyte(); try { while (!ct.IsCancellationRequested) { int count await stream.ReadAsync(buffer, ct); if (count 0) { break; // 连接关闭 } for (int i 0; i count; i) { receiveBuffer.Add(buffer[i]); } // 尝试从缓存中拆出完整帧见下一节 while (TryExtractFrame(receiveBuffer, out byte[] frame)) { FrameReceived?.Invoke(frame); } } } catch (OperationCanceledException) { } catch (Exception ex) { // 记录异常 } finally { // 触发断线事件供上层重连 Disconnected?.Invoke(); } }ReadAsync会挂起等待数据C#的async/await在这里基本没有额外线程阻塞很适合长时间运行的采集应用。要注意的是网络断开时不同情况下表现不一样正常关闭会返回0异常断开可能直接抛IOException所以catch里除了OperationCanceledException还要兜底记录异常然后触发重连逻辑。4. 拆包粘包处理和EPC标签数据的提取4.1 为什么必须处理半包和粘包TCP是字节流协议不像UDP那样一条消息一个包。底层可能一次收到半条命令也可能一次收到好几条完整命令连在一起。如果不管三七二十一直接按一次ReadAsync的结果去解析大概率会出错。所以必须在接收缓存里做帧边界识别。我们前面定了帧结构拆包逻辑就可以按“找STX - 读LEN - 判断总长是否足够 - 校验ETX”的顺序来。我给一个通用实现private bool TryExtractFrame(Listbyte buffer, out byte[] frame) { frame null; if (buffer.Count 0) return false; // 找到STX如果STX之前有脏数据全部丢弃 int stxIndex buffer.IndexOf(0x02); if (stxIndex 0) { buffer.Clear(); return false; } if (stxIndex 0) { buffer.RemoveRange(0, stxIndex); // 重新判断下一轮再取 if (buffer.Count 0) return false; } // 至少要能读到 LEN if (buffer.Count 3) return false; int len buffer[2]; int totalLen len 5; // STX ADR LEN CMDDATA LRC ETX if (buffer.Count totalLen) { // 半包继续等 return false; } // 检查ETX if (buffer[totalLen - 1] ! 0x03) { // 帧尾不对可能是噪声丢弃第一个字节再重试 buffer.RemoveAt(0); return false; } frame buffer.GetRange(0, totalLen).ToArray(); buffer.RemoveRange(0, totalLen); return true; }这段代码的核心思想就一句话凑够了再取取完就切没凑够就等。Listbyte虽然简单但数据量大时频繁增删有开销工业现场数据量一般不大足够用。如果追求极致性能可以改成MemoryStream或环形缓冲区但逻辑是一样的。4.2 校验和命令分发拆出完整帧后先做LRC校验再按命令字分发。如果校验失败这一帧要么是网络错误要么是设备协议里面还有隐藏字段最好记录下来而不是直接丢弃方便排查。private void DispatchFrame(byte[] frame) { byte adr frame[1]; byte len frame[2]; byte cmd frame[3]; // 校验LRC从ADR到数据末尾 byte expectedLrc frame[frame.Length - 2]; byte actualLrc CalcLrc(frame.AsSpan(1, frame.Length - 3)); if (expectedLrc ! actualLrc) { // 记录异常帧继续等下一帧 return; } if (_pendingAwaits.TryRemove(cmd, out var tcs)) { tcs.TrySetResult(frame); } else { // 可能是主动上报的标签数据帧 HandleTagReport(frame); } }需要注意_pendingAwaits.TryRemove(cmd, ...)这种按命令字匹配的方式前提是同一时间不会同时发两条相同命令。对于很多读卡器一次只发一条命令是够用的。如果你真遇到需要并发请求的场景就得改成递增序列号做匹配实现复杂度会高一个量级。4.3 EPC标签数据到底怎么抠出来当读到一条标签上报帧时EPC电子产品码通常以字节形式存在数据字段里。有些协议帧里会有一个长度字节说明EPC占多少字节有些则固定按某个偏移读取。以“第一个数据字节放EPC长度后面跟着EPC内容”的常见结构为例子private void HandleTagReport(byte[] frame) { if (frame.Length 6) return; int offset 4; // 从数据字段开始 int epcLength frame[offset]; offset; if (frame.Length offset epcLength) return; byte[] epcBytes frame.AsSpan().Slice(offset, epcLength).ToArray(); string epc Convert.ToHexString(epcBytes); TagDataReceived?.Invoke(epc); // 记录最近一次标签后续查询可以快速返回 _lastEpc epc; }Convert.ToHexString是.NET 5以后的用法输出就是大写十六进制字符串比如E280116060000204B7C4E624这样。如果你还在用.NET Framework可以用BitConverter.ToString(epcBytes).Replace(-, )替代。注意别把EPC数据长度和帧长度搞混。帧长度是整条报文的字节数EPC长度只是标签数据区里某段内容的长度。解析时先确认偏移量不然读出来的EPC永远是乱的。建议调试时先把返回帧用十六进制字符串整体打印出来人工对比着看确认EPC位置后再固化解析逻辑。5. 现场调通必备的三个坑和一种调试习惯5.1 坑一异步任务卡死命令超时没有兜底用TaskCompletionSource等响应最大的坑就是设备没回复时任务会永远挂住。尤其现场电磁干扰强偶尔一帧报文丢失很正常如果没有超时兜底几十秒后整个发送线程池都能被卡满。解决办法就是上面代码里已经写到的timeoutCts.CancelAfter(3000)并且给等待任务加上WaitAsync(timeoutCts.Token)。超时触发后记得把对应的TaskCompletionSource从字典里移除否则后面即使收到响应也没人消费它。5.2 坑二事件回调里直接操作UI控件直接抛异常C#上位机里接收循环跑在后台线程FrameReceived事件也是在后台线程触发的。如果你想在这个事件里更新WinForm或WPF的界面直接写label.Text epc大概率会崩因为UI控件只能在UI线程操作。简单处理方式是拿到控件的时候判断一下InvokeRequired或者在程序启动时捕获SynchronizationContextprivate readonly SynchronizationContext _syncContext; // 在UI线程构造函数里保存: // _syncContext SynchronizationContext.Current; private void OnTagDataReceived(string epc) { _syncContext.Post(_ label1.Text epc, null); }如果只是写数据库或日志就不需要切上下文保持后台线程执行即可别因为不必要的调度影响吞吐。5.3 坑三设备主动上报和命令应答混在一起导致响应错配有的SICK读卡器配置后读卡器检测到标签会主动往TCP连接里推数据不一定要上位机先发询问。这个“主动上报”帧里没有你的请求标记如果用请求/响应模型硬匹配就会解析错乱。我的做法是在DispatchFrame里先明确区分“应答帧”和“上报帧”。如果这个帧的命令字能在_pendingAwaits里找到对应等待就按应答处理找不到就按主动上报处理。这样既能支持一问一答也能支持设备实时推送两条通道各走各的。5.4 一种调试习惯原始字节流日志永远别省最后分享一个我个人坚持了很久的习惯上位机程序里一定要留一个“原始字节流日志”开关打开之后把TCP收发的所有字节以十六进制形式写入日志文件。平时可以关掉调试时打开排查问题会快很多。现场很多问题根本不是代码逻辑错而是设备固件版本不同、协议配置不对、或者某次网络丢包导致帧错位。有原始字节流你可以直接翻日志看到底发出去什么、收回来什么所有疑问用数据说话。如果没有这个日志就只能盲猜效率低到令人抓狂。写这套SICK RFIID读卡器C# TCP客户端时我自己的流程也慢慢固定成了一套先确认设备IP、端口、协议模式再用调试助手抓原始帧然后写C#的收发骨架接着处理拆包和校验最后补超时、重连和日志。这套思路不光适用SICK换到其他厂家的RFID读卡器、扫码枪、PLC网关基本也是同样的套路。把底子打好换设备只是改一改帧解析的事。本文还有配套的精品资源点击获取
C#异步TCP客户端对接SICK RFID读卡器：从组帧到拆包重连全解析
简介面向需要与德国SICK RFU630 RFID读卡器联调的C#开发者这份代码工程将TCP客户端与工业RFID读取场景结合集中演示了异步IO、多线程调度和委托跨线程更新UI三个核心问题。压缩包内共有32个文件体积约60KB核心是10个C#源码文件配合解决方案文件与工程配置另有3个exe程序可直接运行验证resx/resources界面资源与pdb调试符号也一应俱全。已有1296人学习使用。工程详细展示如何使用TcpClient建立稳定连接如何在NetworkStream上通过async/await实现非阻塞读取以及怎样借助Task或Thread维护独立读卡线程同时通过委托和Control.BeginInvoke安全回传数据解决跨线程访问控件的常见异常。对于准备接入工业RFID设备、需要快速理解C#异步网络编程实战套路的开发者这份小巧但完整的示例覆盖了从IP端口配置、连接、发送指令到接收数据的完整链路具备很高的参考与移植价值尤其适合做二次开发时的最小可用原型。 前不久接了个产线MES对接的活儿一台德国SICK的RFID读卡器要求上位机用C#写一个TCP客户端把读卡器读到的标签数据异步取回来实时入库。项目本身不大但真做起来发现坑不少——协议帧怎么组、C#异步Socket怎么写、半包粘包怎么拆、断线怎么重连每一个点都能让人卡上半天。我想把这套SICK RFID读卡器读卡程序的完整实现思路写出来包括TCP客户端的骨架代码、通信协议解析、异步收发的关键细节以及现场调试时最容易翻车的几个地方。如果你正在做RFID、扫码枪、工业设备的上位机对接这篇文章应该能帮你少走不少弯路。1. 为什么用TCP客户端连SICK读卡器而不是串口或SDK1.1 工业读卡器的网口化趋势SICK的RFID读卡器在自动化产线上用得很多典型的如RFU系列基本都带了以太网接口支持TCP/IP通信。很多老工程师习惯性想到串口觉得简单、稳定但新设备、新产线里串口的比例越来越低。原因很现实串口传输距离有限波特率再高也就115200而且一台工控机要接多台读卡器时串口资源根本不够用。走以太网之后一根网线就能解决通信距离和组网问题通过交换机能同时接十几台设备数据量也大得多。另外SICK这类工业读卡器通常还支持多种工业协议比如PROFINET、EtherNet/IP、Modbus TCP但纯上位机做数据采集时最通用、最灵活的方式反而是直接开一个TCP Socket走读卡器原生的Host Protocol主机协议或者把读卡器配置成TCP Server模式让C#上位机作为TCP客户端去连。这种方式的优点是依赖最少不需要装任何SDK、不需要额外授权只要知道IP、端口和报文格式就能干活。1.2 动手前先确认三件事能省三天事写代码之前我强烈建议先确认三件事读卡器的IP地址和端口号。SICK读卡器一般可以在配置软件比如SOPAS里或网页配置界面里看。默认端口不一定相同常见的有2112、8090之类一定要按你手里这台设备的实际配置来不要凭经验猜。当前运行的协议模式。很多SICK读卡器出厂可能默认是PROFINET或Modbus TCP而不是纯TCP Host Protocol。如果你直接发ASCII命令过去设备可能只会回总线协议的报文通信根本对不上。需要先在配置软件里把通信接口切到TCP/IP Host模式。报文格式是ASCII还是十六进制。有的读卡器配置成文本模式时命令是可读字符串配置成二进制模式时就需要按字节组帧。这一点直接决定你后面所有代码怎么写。我把串口和TCP的差异整理成一张表方便你选型时做判断对比项串口TCP/IP传输距离一般十几米就衰减明显网线100米加交换机可扩展速率115200bps以内百兆/千兆远高于串口同时接入数一台工控机串口有限可接交换机多设备并发工程布线专用线缆抗干扰要求高标准网线方便维护上位机实现难度简单SerialPort即可需要处理Socket、拆包粘包适用场景老设备、点位少新建线、集中采集、多读卡器结论很简单如果读卡器有以太网口优先走TCP。虽然写起来比串口多了点技术门槛但后期扩展和维护舒服得多。2. 报文结构必须先吃透SICK读卡器的帧格式和校验方式2.1 一个典型的请求/响应帧长什么样SICK读卡器的Host Protocol在不同型号上可能有差异但大多逃不开一种结构起始符、设备地址、长度、命令、数据、校验、结束符。我以自己调试过的二进制帧形式为例通用结构如下字段字节数说明STX1起始符通常为0x02ADR1设备地址单机时一般0x00LEN1从命令字到数据末尾的总长度CMD1命令字比如读标签、读配置DATAN参数或标签数据LRC1校验字节ETX1结束符通常为0x03比如发送一条“读ID”命令命令字假设是0x20数据字段为0x00那么帧会是02 00 02 20 00 LRC 03。其中LEN0x02表示CMD DATA一共2个字节。总帧长就是5 LEN也就是7字节。不同设备可能有其他变体千万别把这个结构当铁律但理解思路后换到别的设备也快。提示开始写代码前一定先把设备手册里的帧结构拍下来对着逐字段核对。工业设备不像PC外设很多自定义协议靠猜会死得很惨。2.2 LRC校验的手工计算法很多SICK读卡器的二进制协议使用LRC纵向冗余校验作为帧校验。计算方式不复杂从ADR开始一直到DATA的最后一个字节把这些字节逐个异或再取反得到LRC字节。用C#写就是一小段static byte CalcLrc(ReadOnlySpanbyte data) { byte xor 0; foreach (var b in data) { xor ^ b; } return (byte)~xor; }以刚才的命令帧为例对00 02 20 00这四个字节做LRC0x00 XOR 0x02 0x020x02 XOR 0x20 0x220x22 XOR 0x00 0x22取反得 0xDD所以完整帧是02 00 02 20 00 DD 03。有些设备可能直接异或不去反有的甚至用累加和就算同样叫LRC细节也能差出十万八千里。所以加校验函数的时候最好用一个配置项区分“异或取反”还是“直接异或”现场切换方便。我吃过这个亏手册上写的是BCC校验我按惯用LRC去算整整折腾了两个小时才发现校验方式少了一步取反。2.3 先抓帧再写解析器很多同事拿到代码任务是直接开写TCP客户端我反而建议先做一步“不写代码”的动作用TCP调试助手或者干脆用C#写个最简单的Socket客户端手动连接读卡器发一条命令把读卡器返回的原始字节流完整看一遍。这个动作能帮你确认三件事设备响应是否正常、返回的帧里命令字段和长度字段的位置、以及标签数据藏在哪个字节区间。等原始数据抓清楚了你再动手写解析器成功率会高很多。我见过太多人上来直接写正式程序结果一边写一边猜协议写完全是Bug最后还搞不清是代码问题还是设备问题。3. C#异步TCP客户端骨架连接、发送、接收三层分离3.1 连接和断线重连的基本框架C#里做TCP客户端最直接的是TcpClient类。异步读取用async/await非常顺手关键是不要把所有逻辑堆在事件里而是分成连接管理、发送、接收循环三块各自独立。下面是一个简化的骨架代码public class SickRfidTcpClient : IDisposable { private TcpClient _tcpClient; private NetworkStream _stream; private CancellationTokenSource _connectCts; private readonly SemaphoreSlim _sendLock new SemaphoreSlim(1, 1); public event Actionbyte[] FrameReceived; public event Actionstring Disconnected; public async Task ConnectAsync(string ip, int port) { _connectCts?.Cancel(); _connectCts new CancellationTokenSource(); _tcpClient new TcpClient(); _tcpClient.ReceiveTimeout 3000; _tcpClient.SendTimeout 3000; await _tcpClient.ConnectAsync(ip, port); _stream _tcpClient.GetStream(); // 接收循环放后台跑不阻塞主流程 _ ReceiveLoopAsync(_stream, _connectCts.Token); } public bool IsConnected _tcpClient?.Connected ?? false; }这里要特别说明ReceiveTimeout只对同步读写有效异步ReadAsync并不会自动受它控制。所以真正的超时控制要么靠CancellationTokenSource.CancelAfter要么在接收循环自己做判断。如果后续要用异步发送建议发送方法里套一层带超时的等待否则命令丢失或设备停机时任务可能一直挂在那里。3.2 发送命令与等待应答的任务管道工业读卡器很多是“请求-响应”型上位机发一条命令读卡器回一条结果。如果每个命令都裸写WriteAsync再等接收代码会很散。我习惯用TaskCompletionSource做命令和响应的匹配发送时登记一个等待对象接收循环解到对应命令帧后把结果写回这个Task。private readonly ConcurrentDictionarybyte, TaskCompletionSourcebyte[] _pendingAwaits new(); public async Taskbyte[] SendCommandAsync(byte command, byte[] payload, CancellationToken ct default) { // 组帧、校验 var frame BuildFrame(command, payload); var tcs new TaskCompletionSourcebyte[](TaskCreationOptions.RunContinuationsAsynchronously); _pendingAwaits[command] tcs; await _sendLock.WaitAsync(ct); try { await _stream.WriteAsync(frame, ct); } finally { _sendLock.Release(); } using var timeoutCts CancellationTokenSource.CreateLinkedTokenSource(ct); timeoutCts.CancelAfter(3000); return await tcs.Task.WaitAsync(timeoutCts.Token); }有几处细节_sendLock用来保证同一时间只发送一条命令避免读卡器不支持并发命令时互相干扰。_pendingAwaits按命令字做匹配收到响应帧后从字典里取出TaskCompletionSource调用TrySetResult。超时触发后记得把TaskCompletionSource从字典移除否则会积累内存或导致后续响应匹配错乱。如果你的读卡器支持“主动上报”标签比如感应到标签后实时推送不需要每次请求那么接收分发的逻辑还要再拆一层一部分帧是“请求-响应”另一部分是“事件推送”两者要分别处理。3.3 基于NetworkStream的异步接收循环接收循环是整个程序的发动机核心就是一个不断从NetworkStream读数据的循环private async Task ReceiveLoopAsync(NetworkStream stream, CancellationToken ct) { var buffer new byte[4096]; var receiveBuffer new Listbyte(); try { while (!ct.IsCancellationRequested) { int count await stream.ReadAsync(buffer, ct); if (count 0) { break; // 连接关闭 } for (int i 0; i count; i) { receiveBuffer.Add(buffer[i]); } // 尝试从缓存中拆出完整帧见下一节 while (TryExtractFrame(receiveBuffer, out byte[] frame)) { FrameReceived?.Invoke(frame); } } } catch (OperationCanceledException) { } catch (Exception ex) { // 记录异常 } finally { // 触发断线事件供上层重连 Disconnected?.Invoke(); } }ReadAsync会挂起等待数据C#的async/await在这里基本没有额外线程阻塞很适合长时间运行的采集应用。要注意的是网络断开时不同情况下表现不一样正常关闭会返回0异常断开可能直接抛IOException所以catch里除了OperationCanceledException还要兜底记录异常然后触发重连逻辑。4. 拆包粘包处理和EPC标签数据的提取4.1 为什么必须处理半包和粘包TCP是字节流协议不像UDP那样一条消息一个包。底层可能一次收到半条命令也可能一次收到好几条完整命令连在一起。如果不管三七二十一直接按一次ReadAsync的结果去解析大概率会出错。所以必须在接收缓存里做帧边界识别。我们前面定了帧结构拆包逻辑就可以按“找STX - 读LEN - 判断总长是否足够 - 校验ETX”的顺序来。我给一个通用实现private bool TryExtractFrame(Listbyte buffer, out byte[] frame) { frame null; if (buffer.Count 0) return false; // 找到STX如果STX之前有脏数据全部丢弃 int stxIndex buffer.IndexOf(0x02); if (stxIndex 0) { buffer.Clear(); return false; } if (stxIndex 0) { buffer.RemoveRange(0, stxIndex); // 重新判断下一轮再取 if (buffer.Count 0) return false; } // 至少要能读到 LEN if (buffer.Count 3) return false; int len buffer[2]; int totalLen len 5; // STX ADR LEN CMDDATA LRC ETX if (buffer.Count totalLen) { // 半包继续等 return false; } // 检查ETX if (buffer[totalLen - 1] ! 0x03) { // 帧尾不对可能是噪声丢弃第一个字节再重试 buffer.RemoveAt(0); return false; } frame buffer.GetRange(0, totalLen).ToArray(); buffer.RemoveRange(0, totalLen); return true; }这段代码的核心思想就一句话凑够了再取取完就切没凑够就等。Listbyte虽然简单但数据量大时频繁增删有开销工业现场数据量一般不大足够用。如果追求极致性能可以改成MemoryStream或环形缓冲区但逻辑是一样的。4.2 校验和命令分发拆出完整帧后先做LRC校验再按命令字分发。如果校验失败这一帧要么是网络错误要么是设备协议里面还有隐藏字段最好记录下来而不是直接丢弃方便排查。private void DispatchFrame(byte[] frame) { byte adr frame[1]; byte len frame[2]; byte cmd frame[3]; // 校验LRC从ADR到数据末尾 byte expectedLrc frame[frame.Length - 2]; byte actualLrc CalcLrc(frame.AsSpan(1, frame.Length - 3)); if (expectedLrc ! actualLrc) { // 记录异常帧继续等下一帧 return; } if (_pendingAwaits.TryRemove(cmd, out var tcs)) { tcs.TrySetResult(frame); } else { // 可能是主动上报的标签数据帧 HandleTagReport(frame); } }需要注意_pendingAwaits.TryRemove(cmd, ...)这种按命令字匹配的方式前提是同一时间不会同时发两条相同命令。对于很多读卡器一次只发一条命令是够用的。如果你真遇到需要并发请求的场景就得改成递增序列号做匹配实现复杂度会高一个量级。4.3 EPC标签数据到底怎么抠出来当读到一条标签上报帧时EPC电子产品码通常以字节形式存在数据字段里。有些协议帧里会有一个长度字节说明EPC占多少字节有些则固定按某个偏移读取。以“第一个数据字节放EPC长度后面跟着EPC内容”的常见结构为例子private void HandleTagReport(byte[] frame) { if (frame.Length 6) return; int offset 4; // 从数据字段开始 int epcLength frame[offset]; offset; if (frame.Length offset epcLength) return; byte[] epcBytes frame.AsSpan().Slice(offset, epcLength).ToArray(); string epc Convert.ToHexString(epcBytes); TagDataReceived?.Invoke(epc); // 记录最近一次标签后续查询可以快速返回 _lastEpc epc; }Convert.ToHexString是.NET 5以后的用法输出就是大写十六进制字符串比如E280116060000204B7C4E624这样。如果你还在用.NET Framework可以用BitConverter.ToString(epcBytes).Replace(-, )替代。注意别把EPC数据长度和帧长度搞混。帧长度是整条报文的字节数EPC长度只是标签数据区里某段内容的长度。解析时先确认偏移量不然读出来的EPC永远是乱的。建议调试时先把返回帧用十六进制字符串整体打印出来人工对比着看确认EPC位置后再固化解析逻辑。5. 现场调通必备的三个坑和一种调试习惯5.1 坑一异步任务卡死命令超时没有兜底用TaskCompletionSource等响应最大的坑就是设备没回复时任务会永远挂住。尤其现场电磁干扰强偶尔一帧报文丢失很正常如果没有超时兜底几十秒后整个发送线程池都能被卡满。解决办法就是上面代码里已经写到的timeoutCts.CancelAfter(3000)并且给等待任务加上WaitAsync(timeoutCts.Token)。超时触发后记得把对应的TaskCompletionSource从字典里移除否则后面即使收到响应也没人消费它。5.2 坑二事件回调里直接操作UI控件直接抛异常C#上位机里接收循环跑在后台线程FrameReceived事件也是在后台线程触发的。如果你想在这个事件里更新WinForm或WPF的界面直接写label.Text epc大概率会崩因为UI控件只能在UI线程操作。简单处理方式是拿到控件的时候判断一下InvokeRequired或者在程序启动时捕获SynchronizationContextprivate readonly SynchronizationContext _syncContext; // 在UI线程构造函数里保存: // _syncContext SynchronizationContext.Current; private void OnTagDataReceived(string epc) { _syncContext.Post(_ label1.Text epc, null); }如果只是写数据库或日志就不需要切上下文保持后台线程执行即可别因为不必要的调度影响吞吐。5.3 坑三设备主动上报和命令应答混在一起导致响应错配有的SICK读卡器配置后读卡器检测到标签会主动往TCP连接里推数据不一定要上位机先发询问。这个“主动上报”帧里没有你的请求标记如果用请求/响应模型硬匹配就会解析错乱。我的做法是在DispatchFrame里先明确区分“应答帧”和“上报帧”。如果这个帧的命令字能在_pendingAwaits里找到对应等待就按应答处理找不到就按主动上报处理。这样既能支持一问一答也能支持设备实时推送两条通道各走各的。5.4 一种调试习惯原始字节流日志永远别省最后分享一个我个人坚持了很久的习惯上位机程序里一定要留一个“原始字节流日志”开关打开之后把TCP收发的所有字节以十六进制形式写入日志文件。平时可以关掉调试时打开排查问题会快很多。现场很多问题根本不是代码逻辑错而是设备固件版本不同、协议配置不对、或者某次网络丢包导致帧错位。有原始字节流你可以直接翻日志看到底发出去什么、收回来什么所有疑问用数据说话。如果没有这个日志就只能盲猜效率低到令人抓狂。写这套SICK RFIID读卡器C# TCP客户端时我自己的流程也慢慢固定成了一套先确认设备IP、端口、协议模式再用调试助手抓原始帧然后写C#的收发骨架接着处理拆包和校验最后补超时、重连和日志。这套思路不光适用SICK换到其他厂家的RFID读卡器、扫码枪、PLC网关基本也是同样的套路。把底子打好换设备只是改一改帧解析的事。本文还有配套的精品资源点击获取
