4. 通信协议详解
通信协议，说白了就是设备之间交流的“语言”。在产线实时检测系统里，相机、PLC、机器人、上位机，它们能不能顺畅地“对话”，全靠协议搭桥。我见过不少项目，硬件选型都没问题，最后栽在通信上——要么丢包，要么延迟高，要么干脆连不上。
这一章，咱们就把几种最常用的协议掰开揉碎讲清楚。你搞懂了这些，现场调试至少能少走一半弯路。
4.1 TCP/IP与UDP基础：可靠 vs 实时
先聊最底层的。TCP/IP和UDP，是互联网世界的“地基”。几乎所有工业以太网协议，最终都跑在这俩上面。
4.1.1 TCP/IP：可靠，但慢
TCP/IP的核心机制是“三次握手”和“确认重传”。
- 三次握手：建立连接前，双方先“打招呼”——你发SYN，我回SYN+ACK，你再回ACK。确认链路通了，才开始传数据。
- 确认重传：每发一个包，接收方必须回ACK。如果发方没收到ACK，就认为丢了，重新发一次。
这种机制保证了数据100%到达，且顺序不乱。但代价是延迟高、带宽利用率低。
适用场景：配置文件下发、日志上传、数据库写入——这些场景丢一个字节都不行。
4.1.2 UDP：快，但“尽力而为”
UDP就简单多了。它不建立连接，发出去就不管了。接收方收到就收到，没收到也不重发。
- 无连接：直接发，省去握手时间。
- 无确认：不保证到达，不保证顺序。
为什么工业现场还用UDP？因为实时性。你想想看，一个运动控制周期只有1ms，如果等TCP确认重传，黄花菜都凉了。丢一个包，下一帧数据马上就到，旧数据重传反而干扰。
我的经验：在视觉检测项目中，图像流传输我通常用UDP。偶尔丢一帧，大不了下一帧补上。但控制指令（比如触发拍照）必须用TCP，丢一条指令可能造成漏检。
4.1.3 对比一览
| 特性 | TCP/IP | UDP |
|---|---|---|
| 连接方式 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 100%可靠，有重传 | 尽力而为，无重传 |
| 延迟 | 较高（握手+确认） | 低（无握手） |
| 带宽利用率 | 较低（头部大+ACK开销） | 高（头部小） |
| 典型工业应用 | Modbus TCP、OPC UA | EtherCAT、Profinet RT |
4.2 Modbus TCP协议：老将出马
Modbus TCP，就是把经典的Modbus RTU协议搬到TCP/IP网络上。它简单、开放、几乎所有设备都支持。
4.2.1 协议结构
Modbus TCP的报文结构很清晰：
| MBAP Header (7字节) | 功能码 (1字节) | 数据 (N字节) |- MBAP Header：包含事务标识符、协议标识符、长度、单元标识符。说白了就是“谁发的、发给谁、多长”。
- 功能码：告诉设备要干什么。比如0x03读保持寄存器，0x06写单个寄存器。
- 数据：具体参数，比如起始地址、寄存器数量、写入值。
4.2.2 实际应用：读一个寄存器
假设你要从PLC的地址0x100读一个16位数据：
请求报文（上位机→PLC）：
事务ID: 0x0001
协议ID: 0x0000
长度: 0x0006
单元ID: 0x01
功能码: 0x03
起始地址: 0x0100
寄存器数量: 0x0001
响应报文（PLC→上位机）：
事务ID: 0x0001
协议ID: 0x0000
长度: 0x0005
单元ID: 0x01
功能码: 0x03
字节数: 0x02
数据: 0x1234我曾经踩过的坑：Modbus TCP的“单元ID”在点对点连接时通常填0xFF或0x01。但如果你通过网关连接多个串口设备，这个ID必须对应串口设备的地址。有一次我忘了改，结果所有设备都返回数据，上位机直接崩溃。
4.2.3 调试技巧
- 用Modbus Poll/Simulator：这两个工具是调试神器。先模拟主站发请求，看从站回什么。能快速定位是协议问题还是设备问题。
- 抓包分析：Wireshark过滤
modbus.tcp，直接看报文。我习惯先抓一次正常通信的包，保存为模板。出问题时对比，一眼就能看出哪里不对。 - 注意字节序：Modbus默认大端（高字节在前）。但有些设备（尤其是国产的）用小端。不匹配时读出来的数据完全不对。
4.3 Profinet与EtherCAT对比：实时性的两条路
Profinet和EtherCAT，是当前工业以太网实时通信的两大主流。它们都基于以太网物理层，但实现实时性的方式完全不同。
4.3.1 Profinet：IT与OT的融合
Profinet由西门子主导，分三个层级：
- Profinet RT（实时）：基于UDP，循环时间1-10ms。适合大多数工厂自动化场景。
- Profinet IRT（等时实时）：通过硬件同步和预留时间槽，循环时间可达31.25μs。适合运动控制。
- Profinet NRT（非实时）：走标准TCP/IP，用于配置和诊断。
Profinet的核心理念是“一个网络，多种服务”。你可以在同一根网线上同时跑实时控制数据和IT数据（比如HTTP、SNMP）。
适用场景：西门子生态、需要与IT系统深度集成的产线、对拓扑灵活性要求高的场合。
4.3.2 EtherCAT：极致的“飞读飞写”
EtherCAT由倍福（Beckhoff）开发，采用“集总帧”技术。主站发一个报文，经过每个从站时，从站在报文经过的瞬间读取或写入数据，然后报文继续往下传。最后一个从站把报文返回给主站。
- 延迟极低：一个周期内，所有从站的数据都处理完了。典型循环时间100μs以下。
- 抖动极小：硬件处理，不依赖软件堆栈。
- 拓扑灵活：支持线型、星型、树型，甚至环形冗余。
我的个人习惯：做高速视觉检测（比如每分钟检测600个产品），我首选EtherCAT。相机触发、光源控制、数据采集，全部走EtherCAT，延迟稳定在几十微秒。如果用Profinet RT，抖动可能达到几百微秒，检测位置就不准了。
4.3.3 核心差异对比
| 对比项 | Profinet | EtherCAT |
|---|---|---|
| 通信机制 | 时间槽+硬件同步（IRT） | 集总帧（飞读飞写） |
| 最小循环时间 | 31.25μs（IRT） | 12.5μs（理论） |
| 抖动 | <1μs（IRT） | <0.1μs |
| 最大从站数 | 约256 | 65535（理论） |
| IT集成 | 原生支持（NRT通道） | 需额外网关 |
| 主导厂商 | 西门子 | 倍福、欧姆龙、松下 |
| 典型应用 | 汽车焊装、物流仓储 | 电子装配、高速分拣 |
4.3.4 怎么选？
- 如果你用西门子PLC：别纠结，直接上Profinet。生态兼容性最好，调试工具（TIA Portal）集成度最高。
- 如果你做高速运动控制或视觉检测：EtherCAT是更优解。延迟和抖动都优于Profinet IRT，而且从站成本更低。
- 如果你需要混合IT/OT：Profinet更合适。一根网线同时传控制数据和诊断信息，省去额外布线。
避坑指南：我曾经在一个项目里混用了Profinet和EtherCAT设备，想通过一个交换机互联。结果Profinet的IRT时间槽被EtherCAT的集总帧打乱，整个网络崩溃。后来老老实实加了网关隔离。记住：实时协议不能直接混用，必须通过网关或耦合器桥接。
4.4 知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当作调试时的“地图”。