简介这份范例代码聚焦 C# 上位机与昆仑通态 MCGS 之间的 TCP 通信面向需要完成工控数据采集、设备联调或上位机界面开发的初、中级工程师与学习者重点解决在 VS2013 环境下建立连接并读取 MCGS 数据的实现问题。压缩包共 36 个文件约 92KB包含 9 个 cs 源码、sln 解决方案、resx 窗体资源、config 配置及 txt 说明等既有可直接打开的 Windows Forms 工程也保留了看板人机例程的工程配置线索便于对照理解通信流程与界面组织。目前已有 2507 人学习读者可从中获取 TCP 连接、数据读取、窗体调用和工程调试的参考写法适合作为课程设计、项目原型或二次开发的起点。1. 车间屏幕上那个不动的小数点某条产线的中控室里组态屏上的温度、压力、转速跳得正欢旁边上位机里同一批点位却一直停在 0.0。排查了大半天问题不在采集而在 C# 与 MCGS 之间的那条 TCP 通信通道上帧头对上了、长度字段猜错了、字节序反了数据就永远是零。这种对接几乎是自控项目的固定工序——组态端负责现场画面和 I/O 采集C# 上位机负责报表、追溯、算法和数据库两边靠 TCP 通信搬数据。这份范例代码要解决的就是这件事设备窗口怎么配、Socket 怎么收、粘包怎么切、CRC 怎么校验、下发指令怎么组帧一整套跑通。它适合刚接手组态对接的上位机开发者也适合要把产线数据接进管理系统的现场工程师。2. 通信链路怎么定角色、端口与一帧数据的格式动手写代码之前先把链路的「身份关系」定下来。这一步定错了后面所有调试都是在给玄学交学费一会儿能通一会儿不通重启一次又好了。C# 与 MCGS 通信最常见的两种拓扑是「上位机做服务端」和「组态端做服务端」选哪一种直接影响断线重连、端口占用和现场排障的难度。定完角色再定帧格式帧格式定完再谈参数顺序不能反。2.1 谁当服务端两种拓扑的取舍上位机做服务端也就是 C# 用TcpListener监听一个固定端口组态端在设备窗口里配成客户端主动连上来。这是我一般优先选的方案原因很实际组态软件的重连逻辑基本是内置的断线之后按配置的间隔自动重连不需要在组态脚本里写循环判断而上位机侧只需要维护一张会话表谁连上来就登记谁。缺点是上位机所在机器的 IP 要相对固定现场如果是 DHCP 环境得让网络管理员做地址保留否则组态端配置的目标 IP 一变连接就全断了。反过来组态端做服务端、C# 主动去连好处是组态端通常就是那台常年不关机的工控机地址更稳坏处是重连逻辑全压到 C# 这边你得自己写一个带退避的重连定时器还得处理「连接成功但对方没准备好」这种半开状态。现场血泪经验是如果产线有十几台设备都要连同一个组态端C# 侧的重连风暴很容易把组态端的连接数顶满那就得加连接间隔的随机抖动。下面这张表是我在项目里做技术选型时常用的判断依据可以直接对照自己的场景。判断维度上位机做服务端组态端做服务端重连逻辑归属组态端内置配置即可C# 自行实现需要退避策略地址稳定性要求上位机 IP 需固定组态端 IP 需固定多设备接入天然支持多客户端需要组态端侧支持多连接排障难度上位机抓包即可看到全部流量需要在组态端侧做镜像或日志适合场景一台上位机对接一到多台组态端一台组态端对接多台上位机选定之后就不要中途换我见过一个项目前期按组态端做服务端写了两个月后期因为要接第二台上位机被迫整体改拓扑改造成本比预想高得多。2.2 报文结构设计帧头、长度、命令字与 CRC16TCP 是字节流没有消息边界。这一点是所有粘包问题的根源也是新手最容易翻车的地方写测试的时候一次发一条什么问题都没有现场组态端按 200ms 周期连着发几百毫秒之后上位机解析就全乱了。解决办法只有一个——自己定义帧边界让接收端能靠字节内容判断「这一帧从哪开始、到哪结束」。我用的帧结构是固定头 变长载荷 尾部校验字段排布如下。偏移长度字节字段说明02帧头固定0xAA 0x55用于在脏数据流中重新同步21版本号当前为0x01为后续协议升级留位31命令字0x01上报采集值、0x02下发设定值、0x03心跳42载荷长度小端序只算载荷不含头尾6N载荷业务数据按命令字解释6N2CRC16对「帧头到载荷末尾」做 Modbus CRC16小端序帧头用两个字节而不是一个是为了降低误判概率。单字节0xAA在浮点数据里出现的概率太高一旦载荷中恰好出现0xAA接收端就可能把它当成新帧的开头切出一堆垃圾。用0xAA 0x55这对组合误判率会低一个量级即便如此解析循环里仍然要保留「帧头对不上就逐字节前移」的兜底逻辑这一点在后面的代码里会体现。长度字段用两字节小端是因为它足够覆盖常见载荷最大 65535 字节而且 C# 侧BinaryPrimitives.ReadUInt16LittleEndian读起来最省事。校验用 Modbus CRC16 而不是简单累加和主要是考虑现场干扰累加和对付单比特翻转还行遇到连续两个字节同时出错就完全失效CRC16 的检错能力在电磁环境差的车间里明显更稳。2.3 端口与连接参数几个必须提前定的数值端口不要用 1024 以下的那些需要管理员权限现场部署时容易卡在权限上也不要用组态软件自己占用的端口段。我一般选 20000 以上的端口号比如 28001 这种不容易撞车。定完之后要在上位机防火墙里放行入站这一步漏掉现象就是「代码没问题、组态端一直显示连接失败」排查起来非常费时间。连接参数上NoDelay true基本是必开的。TCP 默认开启 Nagle 算法会把小包攒一攒再发对于 8 字节、12 字节这种小帧来说延迟可能被拖到几十毫秒现场表现就是「数据看起来慢半拍」。关掉之后每帧立刻发出代价是包数量变多在局域网里完全可以接受。心跳间隔我一般设 3 秒超时判定设 10 秒也就是连续三次心跳没有回应就判定连接失效。间隔太短会白白增加流量太长则断线感知迟钝操作员那边看到的是「数据卡住了但界面没报错」比直接报错更麻烦。心跳帧的载荷可以带一个自增序号接收端靠序号跳变判断对端是否假死——有些设备 TCP 连接还在但业务线程已经卡住只靠 socket 层是看不出来的。3. C# 服务端核心实现监听、会话与粘包处理链路和帧格式定完接下来落到代码。这一部分我按「接入 → 收字节 → 切帧 → 校验 → 解释业务」的顺序拆四个代码块分别对应四个职责中间不给省略号确保拿去能直接编译。目标框架用 .NET 6 及以上如果你在 .NET Framework 4.x 上做BinaryPrimitives和ReadSingleBigEndian需要换成BitConverter加手动反转我会在对应位置标注。3.1 TcpListener 异步接入与会话表服务端骨架只做三件事绑定端口开始监听、接受连接、把每条连接丢到独立的任务里跑读循环。最容易犯的错是在Accept循环里直接await业务处理那样第二条连接就进不来了。// 上位机侧 TCP 服务端骨架只负责接入与登记业务处理交给会话自己 public sealed class TcpHost { private readonly TcpListener _listener; private readonly ConcurrentDictionarystring, DeviceSession _sessions new(); private readonly ILoggerTcpHost _logger; public TcpHost(IPAddress bindIp, int port, ILoggerTcpHost logger) { _listener new TcpListener(bindIp, port); _logger logger; } public async Task RunAsync(CancellationToken ct) { // 绑定并开始监听端口被占用会在这里抛 SocketException日志里要打出来 _listener.Start(); _logger.LogInformation(监听已启动端口 {Port}, ((IPEndPoint)_listener.LocalEndpoint).Port); while (!ct.IsCancellationRequested) { TcpClient client; try { client await _listener.AcceptTcpClientAsync(ct); } catch (OperationCanceledException) { break; // 正常停机不是错误 } client.NoDelay true; // 关 Nagle避免小帧被攒着发 var session new DeviceSession(client, _logger); _sessions[session.Key] session; // Key 用远端 IP:Port 拼出来 _logger.LogInformation(组态端接入 {Key}, session.Key); // 每条连接一个读循环这里必须 fire-and-forget否则会阻塞后续 Accept _ Task.Run(async () { try { await session.PumpAsync(ct); } finally { _sessions.TryRemove(session.Key, out _); session.Dispose(); _logger.LogInformation(组态端断开 {Key}, session.Key); } }, ct); } _listener.Stop(); } }这段代码里几个参数的意义值得单独说清楚。bindIp用IPAddress.Any表示监听本机所有网卡工控机有多张网卡一个连办公网、一个连设备网时最好显式绑定设备网那张网卡的地址避免把服务暴露到不该暴露的网络里。NoDelay前面提过设成true之后帧延迟会明显下降。会话表用ConcurrentDictionary而不是普通Dictionary是因为读循环在多个线程里并发增删普通字典会直接抛集合被修改的异常。Key建议用远端 IP 加端口同一台组态端重连时端口通常不同能自然区分新旧连接。3.2 粘包拆包攒够一帧再解析拆包的核心思路是维护一个可变的接收缓冲区和一个已写入长度每次ReadAsync之后追加然后循环尝试从缓冲区头部切出完整帧。切不出来就返回等下一次读切出来了就消费掉把剩余字节往前挪。public sealed class DeviceSession : IDisposable { private readonly TcpClient _client; private readonly NetworkStream _stream; private readonly byte[] _buffer new byte[8192]; // 环形以外的简单方案线性缓冲 搬移 private int _count; // 缓冲区里现有的有效字节数 private readonly ILogger _logger; public DeviceSession(TcpClient client, ILogger logger) { _client client; _stream client.GetStream(); _logger logger; Key client.Client.RemoteEndPoint?.ToString() ?? Guid.NewGuid().ToString(N); } public string Key { get; } public async Task PumpAsync(CancellationToken ct) { var read new byte[4096]; while (!ct.IsCancellationRequested) { int n await _stream.ReadAsync(read, ct); if (n 0) break; // 对端正常关闭退出循环 if (_count n _buffer.Length) // 防御单帧超过缓冲上限直接丢弃重来 { _logger.LogWarning({Key} 缓冲区溢出丢弃 {Count} 字节, Key, _count); _count 0; } Buffer.BlockCopy(read, 0, _buffer, _count, n); _count n; ParseFrames(); // 每读一次就尝试切帧不要等读满 } } }缓冲区给 8KB是经验值按 200ms 一帧、每帧 16 字节算一秒才 80 字节8KB 足够兜住网络抖动带来的突发。真实项目里如果载荷很大比如带条码字符串按最大帧长度乘 4 来定缓冲区更稳。n 0在 TCP 里代表对端优雅关闭这是唯一可以干净退出的信号而IOException和SocketException代表异常断开需要在更外层捕获两条路径都要能清理会话表。ParseFrames是这套逻辑的心脏写法如下。private void ParseFrames() { while (true) { if (_count 6) return; // 连帧头 长度都不够等下一批 if (_buffer[0] ! 0xAA || _buffer[1] ! 0x55) { // 帧头错位逐字节找下一个候选起点避免一个脏字节卡死整个缓冲区 int idx FindNextHeader(); if (idx 0) { _count 0; return; } Buffer.BlockCopy(_buffer, idx, _buffer, 0, _count - idx); _count - idx; continue; } int payloadLen _buffer[4] | (_buffer[5] 8); // 小端两字节 int total 6 payloadLen 2; // 头 6 载荷 CRC 2 if (payloadLen 4096) { _count 0; return; } // 长度明显异常判定为脏数据 if (_count total) return; // 半包等下一次 Read 补齐 var span new ReadOnlySpanbyte(_buffer, 0, total); ushort crcCalc Crc16.Compute(span.Slice(0, total - 2)); ushort crcIn (ushort)(_buffer[total - 2] | (_buffer[total - 1] 8)); if (crcCalc crcIn) { var payload new ReadOnlySpanbyte(_buffer, 6, payloadLen); HandleFrame(_buffer[2], _buffer[3], payload); // 版本、命令字、载荷 } else { _logger.LogWarning({Key} CRC 校验失败丢弃一帧 {Len} 字节, Key, total); } // 消费掉这一帧剩余字节整体前移 Buffer.BlockCopy(_buffer, total, _buffer, 0, _count - total); _count - total; } } private int FindNextHeader() { for (int i 1; i _count - 1; i) if (_buffer[i] 0xAA _buffer[i 1] 0x55) return i; return -1; }这里有三个细节容易出问题。第一_count 6的判断必须在读长度字段之前否则会读到上一帧残留的字节。第二payloadLen 4096这个上限很关键如果没有它一个被干扰成0xFFFF的长度字段会让程序一直等一个永远凑不齐的「大帧」整个连接就此僵死现场表现是「连上了但一条数据都没有」。第三CRC 失败时不要整段清空缓冲区只丢这一帧就行因为后面的字节可能已经是下一帧的开头了。3.3 CRC16 校验与载荷解析CRC16 用 Modbus 那套多项式实现短、检错能力够用而且和大多数仪表的校验方式一致将来要接第三方设备也省事。public static class Crc16 { // Modbus CRC16初值 0xFFFF多项式 0xA001反向表示 public static ushort Compute(ReadOnlySpanbyte data) { ushort crc 0xFFFF; foreach (byte b in data) { crc ^ b; for (int i 0; i 8; i) { if ((crc 0x0001) ! 0) { crc 1; crc ^ 0xA001; } else crc 1; } } return crc; } }载荷解释部分按命令字分发。上报帧的载荷我定成「4 字节序号 4 字节浮点值」序号自增用于丢帧检测浮点值走大端——很多组态软件在拼字节时默认按高字节在前如果你是两端都用 C# 写用小端更省事但和组态端对接时务必先在设备调试窗口里看清楚实际字节顺序。private void HandleFrame(byte version, byte cmd, ReadOnlySpanbyte payload) { switch (cmd) { case 0x01: // 组态端上报采集值 if (payload.Length 8) return; uint seq BinaryPrimitives.ReadUInt32LittleEndian(payload.Slice(0, 4)); float value BinaryPrimitives.ReadSingleBigEndian(payload.Slice(4, 4)); // .NET Framework 4.x 没有 ReadSingleBigEndian等价写法 // var b payload.Slice(4, 4).ToArray(); Array.Reverse(b); value BitConverter.ToSingle(b, 0); if (_lastSeq ! 0 seq ! _lastSeq 1) _logger.LogWarning({Key} 丢帧上次 {Last}本次 {Now}, Key, _lastSeq, seq); _lastSeq seq; OnSample?.Invoke(this, new SampleEventArgs(seq, value)); break; case 0x03: // 心跳回一帧同样的命令字表示存活 _lastHeartbeat DateTime.UtcNow; Send(BuildHeartbeat()); break; default: _logger.LogDebug({Key} 未知命令字 {Cmd}, Key, cmd); break; } }下发设定值的时候要自己组帧逻辑和解析严格对称帧头、长度、CRC 一个都不能省。这里把组帧抽成静态方法方便单元测试直接调用不用起真实连接。public static byte[] BuildSetValue(uint seq, float value) { var payload new byte[8]; BinaryPrimitives.WriteUInt32LittleEndian(payload, seq); BinaryPrimitives.WriteSingleBigEndian(payload.AsSpan(4), value); var frame new byte[6 payload.Length 2]; frame[0] 0xAA; frame[1] 0x55; frame[2] 0x01; // 版本 frame[3] 0x02; // 命令字下发设定值 BinaryPrimitives.WriteUInt16LittleEndian(frame.AsSpan(4), (ushort)payload.Length); payload.CopyTo(frame, 6); ushort crc Crc16.Compute(frame.AsSpan(0, 6 payload.Length)); BinaryPrimitives.WriteUInt16LittleEndian(frame.AsSpan(6 payload.Length), crc); return frame; }写完之后先别急着连组态端用localhost起一个回环测试服务端自己发一帧给自己验证组帧和拆帧能对上。这一步能挡掉八成的低级错误——比如长度字段少算了 CRC 的两个字节、CRC 计算范围包含了校验位本身这类问题在现场排查会非常痛苦因为两端各自看日志都「看起来正常」。4. MCGS 侧配置与数据映射让组态端把数据吐出来上位机代码跑通只是半场另一半在组态端。组态软件的通信配置基本都在「设备窗口」里做流程是加一个通信父设备TCP 类型设置目标 IP 和端口再挂一个通用设备作为子设备然后在子设备里逐条建通道、绑数据对象。这一套配下来界面上的操作点不少但真正决定成败的是三个地方连接参数、收发触发时机、数据类型对齐。4.1 设备窗口与通道配置的关键项父设备里要填的就是上位机的 IP 和监听端口还有「通信超时」和「重连间隔」。通信超时我一般设成 1000ms 到 3000ms设太小组态端会频繁判定超时并重连日志里全是反复连断重连间隔设 3000ms 左右比上位机的心跳超时10 秒短就行保证上位机还没判死组态端已经在尝试恢复了。子设备里逐条建通道时通道的「数据类型」要和上位机的解析方式严格对应。常见做法是数值量用 4 字节浮点开关量用位按字节读写再取位累计量用 4 字节无符号整型。这里最容易出问题的是浮点——组态端内部对浮点的字节序处理不同版本、不同设备驱动可能不一样不要凭经验猜直接在设备调试窗口里看原始报文的十六进制再和上位机解析出来的值比对。需要提醒的是设备调试窗口是这套方案里最该善用的工具。它会显示收发字节数、最近一次收发的原始报文还能手动触发一次读或写。上位机那边加一句把收到的原始字节按十六进制打到日志里两边一对字节序问题基本无所遁形。4.2 收发触发时机周期上报还是变化上报组态端的通信采集通常有两种驱动方式按固定周期轮询或者数据变化时主动上报。轮询的好处是节奏稳定、丢一帧不影响后续坏处是数据不变时也在发流量白费变化上报省流量但一旦某一帧丢了上位机就可能长时间停在旧值上而且操作员完全看不出来。我一般用「周期上报 变化立即补发」的组合在运行策略里建一个循环策略定时器设 200ms脚本里判断待发数据有没有变化变了就立刻发一帧没变就每 5 个周期1 秒发一次保底帧。这样既保证实时性又能让上位机通过「超过 3 秒没收到帧」判断链路异常。脚本里触发一次主动收发通常是通过设备命令函数去做比如!SetDevice(设备名, 命令码, 参数)这种形式命令码具体取值以设备帮助文档里的定义为准不同驱动不一样不要照抄别人项目里的数字。这一点我吃过亏从一个老项目里复制了命令码结果新项目的驱动版本不一样脚本执行了但什么也没发出去日志里干干净净查了一整天才发现是命令码语义变了。4.3 数据类型对齐浮点、整型与位数据映射这一层本质是把组态端的「数据对象」翻译成字节。数值型对象在组态端通常以双精度存储发给上位机时要按约定的 4 字节单精度打包转换时注意精度损失——比如累计流量到了千万级单精度的有效位就不够了这种量应该改成 4 字节整型传输单位取升或者 0.1 升别用浮点。开关量按位打包时一个字节八位位的顺序要和上位机约定清楚是从低位往高位排还是反过来。这种约定写在协议文档里别只留在某个人的脑子里否则半年后加一个新点位谁也不敢动那个字节。字符型数据比如当前工单号要注意编码。组态端和中文字符串交互时常见的是 GBK而上位机 .NET 默认Encoding.UTF8直接转就是乱码。约定用 GBK 的话上位机要显式Encoding.GetEncoding(GBK)并且在 .NET Core 及以上版本还需要注册CodePagesEncodingProvider否则运行时直接抛异常说找不到编码。5. 常见问题排查连接、字节序与假在线这套方案在现场会遇到的问题类型其实很集中。下面五条是我自己踩过或者帮别人定位过的按「现象 → 原因 → 解决」写遇到了可以逐条对照。5.1 组态端一直显示连接失败上位机日志没有任何接入记录现象是组态端通信状态一直是「未连接」上位机侧日志干净得像没启动。原因通常不在代码而在网络层上位机防火墙没放行入站端口或者服务绑定了127.0.0.1只有本机能连或者两台机器不在同一个网段网关配置不对。解决顺序是先在本机用telnet 127.0.0.1 端口验证服务本身活着再从组态端那台机器telnet 上位机IP 端口。第一步通、第二步不通问题一定在网络或防火墙别去翻代码。绑定地址改成设备网那张网卡的 IP防火墙加一条入站规则放行该端口基本就能解决。5.2 连接正常但收到的数据全是零或者乱码现象是ReadAsync能读到字节长度也对但解析出来的浮点值完全不符合物理量。原因大概率是字节序反了或者长度字段的单位理解错了有的协议长度算的是「字」而不是「字节」。解决方法是把收到的原始字节按十六进制打到日志里对照组态端设备调试窗口里同一时刻的报文一个字节一个字节比。浮点值的验证可以用一个已知量让组态端发 1.0对应的 IEEE754 是3F 80 00 00如果收到的是00 00 80 3F那就是端序问题把ReadSingleBigEndian换成小端即可。5.3 心跳一直在数据却长时间不更新现象是上位机每 3 秒能收到心跳帧会话表里连接状态正常但业务数据停在几分钟前的值。原因是组态端那边的采集线程卡住了或者脚本里的发送条件写错导致只有心跳在被周期触发业务帧根本没发出去。TCP 连接本身是好的所以从 socket 层面完全看不出异常。解决办法是给业务数据也加超时判定除了心跳记录每个点位最后一次更新的时间戳超过阈值就在界面上标黄并写一条告警日志。这一点比修 bug 本身更重要——「数据卡住但界面没提示」比直接断线危险得多操作员会拿旧数据做判断。5.4 数据偶尔跳变出一个离谱的极值现象是温度、压力这些量平时都正常隔一段时间冒出一个明显不可能的极值比如 20℃ 突然变成 3.4e38。原因是半包处理有漏洞某一帧只收到一半就被当成完整帧解析了或者长度字段被干扰解析起点整体错位。解决办法是确认_count total的等待逻辑真的生效别在读到数据后无条件解析同时在业务层加量程过滤超出物理量程的值直接丢弃并计数别让它进数据库。量程过滤这层兜底我建议不管协议多可靠都要加。5.5 跑一段时间后连接数越来越多最后新连接进不来现象是运行几小时后上位机会话表里的条目只增不减组态端重连时新连接被拒绝。原因是异常断开那条路径没有清理会话IOException抛出后任务直接结束finally块里的TryRemove没执行到或者Key生成方式导致新旧连接被当成两条。解决办法是把清理动作统一放到finally里异常捕获只负责记日志Key用远端端点生成保证同一物理连接重连后能覆盖旧条目。另外加一个定期扫描把最后心跳时间超过阈值的会话主动关闭作为兜底。6. 二次开发改造把协议层抽出来用测试和压测兜住这套范例代码拿来就能跑但要落到真实项目我建议先做三件事成本不高收益很明显。第一件是把协议层从网络层里剥出来单独建一个类库只放帧结构定义、Build*组帧方法、ParseFrames拆帧逻辑和Crc16。网络层只负责收发字节不碰任何业务字段。这样做完之后加一个新命令字只需要在协议库里加一个case和一个组帧方法不用动服务端骨架。我在一个项目里就是这么改的后面接第二种设备时只花了半天如果还揉在一起估计要一周。改造点具体做法收益协议层独立抽成Protocol类库只依赖System.Buffers.Binary可单测、可复用、加命令字不动网络代码命令字扩展用enum定义命令字配一个Dictionarybyte, IHandler消除 switch 膨胀处理逻辑可插拔会话生命周期统一在finally清理加超时扫描长跑不掉连接数组帧方法静态纯函数输入参数输出byte[]单元测试直接断言字节第二件是给拆帧逻辑写单元测试这是我最推荐的投入。测试用例不用多四五个就够完整一帧能解析、两帧粘在一起能拆成两条、半包不解析、CRC 错帧被丢弃、帧头前有脏字节能重新同步。写法上把ParseFrames改成接受ReadOnlySpanbyte并返回解析出的帧列表纯函数化之后测试非常好写不用起 socket。[Fact] public void 半包不解析_补齐后解析出一条() { var frame Protocol.BuildSetValue(1, 25.5f); var codec new FrameCodec(); var first codec.Feed(frame.AsSpan(0, 5)); // 只喂 5 字节连长度字段都不完整 Assert.Empty(first); var second codec.Feed(frame.AsSpan(5)); // 补齐剩余字节 Assert.Single(second); Assert.Equal(0x02, second[0].Command); }第三件是压测。写一个控制台模拟客户端起 50 到 100 条连接每条按 200ms 发一帧跑半小时观察上位机的内存、线程数和会话表是否稳定。这一步能提前暴露缓冲区溢出、会话泄漏、日志把磁盘写满这类问题。模拟器里记得故意发一些脏字节和错 CRC 的帧真实的车间环境比测试环境脏得多。从那以后我每次做组态对接都强制走一遍「先定帧格式写进文档、再写协议库和单测、最后接网络层和压测」这三步哪怕工期再紧也不跳。因为跳过之后省下的那两个小时通常会在现场用两个晚上还回来。希望帮到你。本文还有配套的精品资源点击获取
