网络控制：TCP / UDP 与设备指令
- 搞清 TCP 和 UDP 的核心区别，知道展厅控制场景各自用在哪
- 学会用网络调试助手（TCP Client 模式）连上设备、发指令、看应答
- 理解 HEX 与 ASCII 指令在网络协议中的用法，和串口时一样要选对模式
- 知道粘包/拆包是什么、为什么网络设备处理指令时要注意分隔符
- 拿到一张网络控制故障排查表：连不上/无响应/乱码/粘包怎么查
上一节讲串口，你可能已经发现一个问题：串口线最长也就几十米，展厅里投影挂在天花板、矩阵锁在机柜、灯光控制器装在配电间，距离这么散，不可能每台都拉根串口线回机房。
网络控制解决的就是这件事。展厅里的大量设备现在有网口了——网络继电器、网络矩阵、支持 PJLink 的投影、科星 IO 控制器——中控通过一根网线进交换机，就能指挥散在各处的设备。不用串口服务器中转，直接走 TCP 或 UDP，指令还是那一套 HEX/ASCII 字节，只是跑在网络上。
这一节先把 TCP/UDP 的区别和使用方式讲清，然后带你看一个实际例子，再把网络控制下特有的"粘包/拆包"问题说明白。
涉及设备接线与参数配置（R2）。协议参数、Modbus 帧格式以官方规范文档为准（见文末来源）；具体设备的指令格式以该设备手册为准，不同型号不通用。
TCP 和 UDP：先把这两个搞清楚
很多教程把 TCP/UDP 的区别描述得非常学术。从展厅控制的视角来看，你只需要记住一件事：
TCP 是"挂电话"模式，UDP 是"发短信"模式。
| 对比项 | TCP | UDP |
|---|---|---|
| 连接方式 | 需要先建立连接（三次握手） | 无连接，直接发包 |
| 可靠性 | 数据保证到达、保证顺序 | 不保证到达，不保证顺序 |
| 有无应答 | 每段数据有 ACK 确认 | 发出去不管有没有收到 |
| 延迟 | 稍高（握手+重传机制） | 更低（无握手） |
| 典型展厅用法 | 投影控制、继电器控制、矩阵控制 | 广播发现设备、时间同步 |
| 错误处理 | 操作系统层面自动重传 | 应用层自己处理 |
展厅里绝大多数设备的控制走 TCP。原因很直接：控制指令要的是"确认执行"——发出去"开灯"，灯确实亮了才算成功。TCP 的可靠交付机制帮你在网络丢包时自动重传，你不用自己写重试逻辑。
UDP 在展厅里主要出现在两种场合：设备广播发现（某些设备开机后会向局域网广播自己的 IP，走 UDP）和时间同步（NTP 协议走 UDP）。直接发控制指令用 UDP 的情况有，但不常见——除非设备手册明确说"控制走 UDP，固定端口 xxxx"，否则优先选 TCP。
科星网络继电器、有人串口服务器的控制接口都支持 TCP，常见端口范围以各型号手册为准。PJLink 走 TCP 端口 4352，这是开放标准写死的，不用查手册。Modbus TCP 走 TCP 端口 502，也是标准定义。
网络控制的设备怎么"发指令"
TCP 层帮你把字节可靠送达，但字节里的内容——指令格式——还是要看设备手册，和串口时一样：分 HEX 和 ASCII 两大类，一字节都不能错。
ASCII 指令（人可读的字符串）
PJLink 是最典型的例子。你在网络调试助手里以 TCP Client 连到投影的 IP:4352，然后发文本：
%1POWR 1
（注意结尾按 PJLink Class 1 规范应该加 \r，即 ASCII 码 0x0D）
投影收到后会回应：
%1POWR=OK
全是人可读的字符，理解成本低，调试方便。
HEX 指令（十六进制字节串）
Modbus TCP 是典型的 HEX 协议。你想控一个 Modbus TCP 设备（比如科星网络继电器）写一个线圈（开灯），要发的是一串字节，没有人可读性，但格式是严格规范的。
比如 Modbus TCP 功能码 05（写单线圈）的报文格式如下（以官方 Modbus Application Protocol 为准）：
事务标识符(2B) + 协议标识符(2B) + 长度(2B) + 单元标识符(1B) + 功能码(1B) + 线圈地址(2B) + 输出值(2B)
一个具体帧，把线圈地址 0x0000（第 1 个线圈）设为 ON（0xFF00）：
00 01 00 00 00 06 01 05 00 00 FF 00
│ │ │ │ │ │ │
│ │ │ │ │ │ └─ 输出值：FF 00 = ON（0000 = OFF）
│ │ │ │ │ └──────── 线圈地址：0x0000（第 1 个线圈）
│ │ │ │ └───────────── 功能码：05 = 写单线圈
│ │ │ └───────────────── 单元标识符（从站地址，通常 01）
│ │ └────────────────────── 后续字节数：6 字节
│ └───────────────────────────── 协议标识符：0x0000（固定，Modbus TCP）
└──────────────────────────────────── 事务标识符（递增，可用 01 开始）
上面的线圈地址 0x0000 是 Modbus 协议里"寄存器编号 1 对应地址 0x0000"的标准写法。但各家厂商实现时可能有"地址偏移"问题——比如科星某型号手册里写"线圈 1"，对应的 Modbus 地址到底是 0x0000 还是 0x0001，必须以你手上那台设备的手册地址表为准，不能照这里的例子硬套。这是 Modbus 实战里最常踩的坑之一。
Modbus TCP 和 Modbus RTU（走 RS485）的区别就是：RTU 有 CRC 校验字节，TCP 没有 CRC（TCP 层自己保可靠性），但 TCP 版本多了前面那 6 个字节的"MBAP 头"（事务标识符 + 协议标识符 + 长度字段 + 单元标识符）。理解了这个区别，你就能把 Modbus 的文档和设备对上。
网络控制特有的问题：粘包和拆包
串口通信时，字节是一个一个按顺序从线上走的，两个指令之间有自然间隔，很少有"两条指令混在一起"的问题。
TCP 是流式传输——它不知道"一条指令"在哪里结束、下一条在哪里开始。如果你快速连续发了两条 Modbus 指令，TCP 层可能把它们打包成一个数据帧到达对端（粘包），也可能因为网络分片把一条指令切成两段（拆包）。
对展厅控制来说，中控软件每次只发一条指令、等到应答再发下一条，这样自然规避了粘包问题。但如果你自己写脚本批量发指令，就需要注意：
处理粘包的常用方法（根据设备协议选）：
- 固定长度：如果指令长度固定（比如 Modbus TCP 的请求帧总是 12 字节），按长度截断就好。
- 结束符分割：如果是 ASCII 协议（如 PJLink），用
\r或\r\n分割每条指令。 - 长度字段：Modbus TCP 的 MBAP 头里有"后续字节数"字段，按这个值读完当前帧再处理。
- 一发一收：发一条、等响应、再发下一条，从应用层规避粘包。
对 SoftControl 这类中控软件，粘包处理在软件内部已经实现，你不需要自己处理。但如果你用网络调试助手手动调试，或者自己写脚本验证设备，要意识到收到的数据可能是多帧拼在一起的，不要以为收到的就一定是一个完整响应。实测时放慢节奏：发一条等应答，再发下一条。
实际例子：TCP 发指令控一台网络设备
拿科星网络继电器举例（通用思路适合所有 Modbus TCP 设备）。科星多款网络继电器支持 Modbus TCP 控制，详细参数以 corxnet.com 官方文档为准；下面是调试流程的通用步骤：
准备工具：网络调试助手（Windows 上常用"网络调试助手"，或 Hercules SETUP utility，都免费）。
第一步：确认设备 IP 和端口
打开设备的配置页面（通常通过浏览器访问设备 IP），确认：
- 设备 IP 地址（默认出厂 IP 以手册为准，常见如
192.168.1.200） - Modbus TCP 监听端口（标准 502，也有用其他端口的型号，以手册为准）
- 从站地址（Unit ID，通常 1，以手册为准）
第二步：网络调试助手建立 TCP 连接
打开网络调试助手：
- 选 TCP Client 模式
- 目标 IP：填设备 IP
- 目标端口：
502（或手册标注的端口） - 点"连接"
你应该看到：连接状态变为"已连接"，接收区出现连接成功提示（或空白，等第一次发数据后有应答才会出现内容）。
第三步：发 HEX 指令
切换到"HEX 发送"模式（不是文本模式），发以下字节串（写单线圈，线圈 1 置 ON）：
00 01 00 00 00 06 01 05 00 00 FF 00
你应该看到的应答（设备正常响应 Modbus FC05 的回应帧通常是相同的 6 个数据字节，带 MBAP 头）：
00 01 00 00 00 06 01 05 00 00 FF 00
（Modbus 写单线圈的成功应答是把请求原样回送）
同时，继电器第 1 路应该吸合——你能听到"咔嗒"声、看到继电器指示灯变化。
关灯（线圈 1 置 OFF）：
00 01 00 00 00 06 01 05 00 00 00 00
再次强调：以上地址 0x0000 是 Modbus 标准中线圈编号 1 的协议地址。科星具体型号的线圈地址偏移，以该型号官方地址表为准，实际操作前务必核对手册。
分隔符与结束符：ASCII 协议要注意的细节
对 ASCII 协议（如 PJLink），每条指令的结束符很关键。PJLink Class 1 规范定义每条指令以 CR（即 \r，十六进制 0D）结尾，少了这个结束符，设备不认为收到了完整指令，就不响应。
用网络调试助手发 ASCII 指令时：
- 如果工具支持"自动加回车"，勾上
- 如果不支持，切到 HEX 模式，把指令文本对应的 ASCII 码手动附上
0D结尾 - 或者用支持转义的工具，在文本末尾加
\r
不同 ASCII 协议的结束符不完全一样：有的用 \r，有的用 \r\n（0D 0A），有的用 \n，有的什么都不加（以帧长度定界）。查手册，确认结束符，这是 ASCII 协议调试的第一步。
故障排查：网络控制的常见问题
| 现象 | 最可能的原因 | 怎么查 / 怎么办 |
|---|---|---|
| TCP 连接失败（connection refused） | IP 或端口填错 / 设备没监听该端口 | ping 设备 IP 确认通；netstat 或设备配置页确认端口 |
| ping 通但 TCP 连不上 | 防火墙拦截 / 端口没开 | 检查设备端口配置；关闭 Windows 防火墙测试 |
| 连上了但发指令没应答 | 指令格式错误 / HEX-ASCII 模式选反 | 核对手册帧格式；确认发送模式 |
| Modbus 无应答 | 从站地址不匹配 / 端口非 502 | 确认设备 Unit ID 和你发的帧里单元标识符一致 |
| 收到 Modbus 异常响应（如 FC=0x85） | 功能码设备不支持 / 地址超范围 | 检查功能码是否设备支持；核线圈地址范围 |
| 设备偶发无响应，过一会又好 | 网络丢包 / 交换机问题 / 设备 TCP 连接超时关闭 | 检查交换机端口状态；给 TCP 连接加心跳保活 |
| PJLink 发了指令设备无响应 | 缺结束符 \r / 指令用了 HEX 模式 |
确认发送模式为 ASCII；末尾加 \r（0x0D） |
| 收到的应答看起来像两条粘在一起 | 粘包 | 按协议定义的帧长度或结束符逐帧解析，不能按"收到的就是一帧"处理 |
| IP 冲突导致时通时不通 | 两台设备用了同一个 IP | 检查网络里所有受控设备的 IP 配置，确保无重复 |
协议层级一览：你发的字节在哪一层
很多人调试时搞不清自己填的内容是哪一层，这里做个对应：
你在中控软件 / 调试工具里填的内容
│
▼
应用层（Modbus / PJLink / 私有协议）：指令帧的字节，你要对照手册填
│
▼
传输层（TCP / UDP）：帮你把字节可靠送到对端（TCP 自动重传）
│
▼
网络层（IP）：找到目标设备的路由路径
│
▼
数据链路层（以太网）：物理帧，网口和网线
你只需要管"应用层"：指令帧填对、端口填对、TCP/UDP 选对。传输层以下的事由操作系统和交换机负责。
和串口的对比：换了什么，没换什么
学完这一节，对比上一节的串口知识，你会发现：
没变的：
- 指令还是那套（HEX/ASCII，每个字节的含义一样）
- 协议逻辑没变（Modbus RTU 和 Modbus TCP 功能码、寄存器定义一样）
- 调试节奏没变（发指令、看应答、按现象查原因）
变了的：
- 物理介质从"RS232/485 线"变成"以太网线"
- 连接方式从"直连串口"变成"TCP Client 连 IP:Port"
- 多了 TCP 的连接状态（先建连才能发数据）
- 多了粘包/IP 冲突这类网络特有的问题
这意味着你在串口协议入门里学到的所有东西（参数对齐、HEX vs ASCII、分段排障），在这里全都还用得上，只是底层的物理通道换了。
学会之后你能做出什么——效果与应用场景
前面那些 TCP 连接、Modbus 帧、粘包，听着都是很"底层"的东西。但把它们串起来，你在展厅里能干的活其实很实在——就是让散在各处、够不到串口线的设备，全都听中控指挥。把常见需求拆开看，每一条都落在你这一节学的东西上：
| 想实现的效果 | 靠这一节的哪块知识做到 |
|---|---|
| 机柜/配电间里的设备也能远程控 | 走网口 TCP，不用再从机房拉几十米串口线到现场 |
| 一键开/关某路灯或某台设备 | 给网络继电器发 Modbus TCP 写单线圈帧（FC05），继电器"咔嗒"吸合 |
| 中控开投影、切电源 | 连投影 IP:4352 发 PJLink ASCII 指令（%1POWR 1），记得结尾带 \r |
| 一台中控管几十台散设备 | 每台设备一个 IP，中控挨个 TCP 连过去发指令，交换机做汇聚 |
| 自己写脚本批量验设备 | 懂粘包/拆包，知道"一发一收"或按帧长/结束符切，才不会把两帧当一帧 |
| 排查"连不上/没应答/乱码" | 照故障排查表，从 ping 通不通、端口对不对、HEX/ASCII 选反、结束符缺没缺一路查 |
说白了，网络控制让中控的"手"伸得更长——串口时代设备得围着机房转，网络时代设备散在哪都能收编。这就是展厅越做越大、设备越来越多之后，为什么控制几乎都往网口走。
这套技能用在哪些展厅场景：
- 大型综合馆（博物馆/科技馆）：设备跨楼层跨房间，投影在穹顶、继电器在配电间、矩阵在机柜——全靠网络把它们收进一套中控，讲解员一个平板全场指挥。
- 企业展厅/城市规划馆：网络继电器控灯光回路、电动窗帘、沙盘电源；PJLink 网口控投影开关机与信源，都不用现场布串口。
- 分布式弱电项目：设备天然分散，网络控制配合前面的 Modbus，就是弱电集成的日常——中控盒 + 交换机 + 一堆带网口的受控设备。
- 需要联网发现/对时的场合：设备广播发现、NTP 对时这类走 UDP 的活儿，知道 TCP/UDP 之分你才不会拿错传输方式去连。
同一套功底，换个场景照样能用：这一节练的"TCP Client 连 IP:Port、按手册发 HEX/ASCII 帧、看应答、按现象排障"，不是展厅专属。楼宇自控、工厂 Modbus TCP 采集、智能家居设备调试，底层都是这一套。你在展厅练出来的网络调试功夫，迁移过去基本不用重学，换的只是设备手册。
动手挑战
- 在你的本地网络里，找一台可以用 TCP 控制的设备（哪怕是有 Telnet 功能的网络设备），用网络调试助手建立 TCP 连接，发一条手册里的指令，看看能否得到应答。
- 用"固定发 4 条，快速连发"的方式，观察接收区是否出现帧粘连的情况，然后改成"一发一等"，对比差异。
本节学到的知识
- TCP = "挂电话"模式：先三次握手建连、数据保证到达且有序、每段有 ACK 确认、丢包自动重传；展厅绝大多数设备控制走 TCP，因为控制指令要的是"确认执行"。
- UDP = "发短信"模式：无连接直接发包、不保证到达/顺序、延迟更低；展厅里主要用于设备广播发现和时间同步（NTP），控制走 UDP 不常见，除非手册明写。
- PJLink 走 TCP 端口 4352、Modbus TCP 走 TCP 端口 502，都是标准写死的、不用查手册；其余设备端口以型号手册为准。
- 网络上发的指令内容还是那两套：ASCII（如 PJLink
%1POWR 1，人可读）和 HEX（如 Modbus TCP 字节串），选错模式设备不认。 - Modbus TCP 帧 = 6 字节 MBAP 头 + 功能码 + 数据；MBAP 头 = 事务标识符(2B)+协议标识符(2B,固定0x0000)+长度(2B)+单元标识符(1B)。
- Modbus TCP 没有 CRC（靠 TCP 层保可靠），Modbus RTU 有 CRC——这是 TCP 版和 RTU 版的核心区别；功能码/寄存器定义两者一样。
- 写单线圈用功能码 05（FC05），
FF 00= ON、00 00= OFF；成功应答是把请求帧原样回送。 - 线圈地址可能有偏移：手册写"线圈 1"对应 0x0000 还是 0x0001，必须以设备手册地址表为准，别照示例硬套——Modbus 实战最常踩的坑。
- TCP 是流式传输，会粘包/拆包：连发多帧可能被拼成一帧（粘包）或被切成两段（拆包）；四种处理法——固定长度截断、结束符分割、按 MBAP 长度字段读、一发一收（调试时最稳）。
- ASCII 协议靠结束符定界：PJLink Class 1 用
CR（\r/0x0D）结尾，缺了不响应；有的协议用\r\n(0D 0A)、\n或按帧长——查手册确认结束符。
小结 · 你现在掌握了什么
- 你清楚了 TCP（可靠、有连接、重传）和 UDP（无连接、低延迟）的区别，知道展厅控制为什么几乎都选 TCP。
- 你看懂了一条 Modbus TCP 帧的每个字节是什么意思，知道 MBAP 头是 TCP 版 Modbus 特有的、RTU 版没有。
- 你知道粘包是怎么发生的，以及为什么"一发一收"在调试时是最稳妥的策略。
- 你有了一张网络控制的故障排查表，连不上/无应答/粘包/IP 冲突都覆盖到了。
下一步：把串口和网络调试技能合并，去看设备控制与指令调试：串口助手 / 抓包 / 排乱码 / 无响应 / 地址冲突，这是协议章的"调试总成"，能看懂那张大故障排查表，展厅里 90% 的协议问题你都能自己搞定。