图注：这篇把串口和以太网放到同一条链路上讲，从电气层一直排到业务层
现场最耗时间的一类故障，不是设备坏了，而是线明明是通的、程序却连不上。万用表量着有电压，Ping 也通，可数据就是不对；或者串口偶尔蹦出几个乱码，重启一次又好了，过两天再犯。
这类问题有个共同点：能通的层面都查过了，出问题的层面还没查到。通信是一条从业务一路往下压到电平、再一路往上解开的链路，任何一层掉链子，表现出来的现象都差不多——”连不上”或”数据不对”。所以真正省时间的做法不是加校验、换线、改超时，而是先把问题定在哪一层。
接下来按串口侧、以太网侧、协议设计三块往下走，中间插一节专门讲位移传感器在现场是怎么挂上去的。
一、通信到底在传什么
先建立一个整体印象：一条命令从你按下按钮，到对方真的动作，中间要过五道关。
一条命令要过五道关
图注：应用数据、协议封装、控制器编码、线缆电信号、接收端解析，五道关任何一道出问题都会表现为”不通”
按图上的顺序说：应用层先产生业务数据（比如”启动电机、转速 1500 rpm”），协议层把它按约定封装成帧（帧头、长度、数据、CRC、帧尾），控制器把帧编成 0 和 1 的电平序列，线缆把电平送出去，接收端再一层层还原回去。
反过来看，这也是排查的方向。你看到的现象在”业务”这一层——命令没执行、数值不对；但根因可能落在其中任意一层。反过来也一样，物理层看着波形很漂亮，业务层照样可能因为协议理解错而失败。
出问题先定性：是信号、帧、网络，还是业务
在现场养成一个习惯：拿到故障先问一句”问题发生在信号、帧、网络，还是业务”。这句话能省掉大半天。信号层的问题表现为波形不对、电平不对、噪声大；帧层的问题表现为校验错、长度不对、丢字节；网络层的问题表现为超时、连不上、地址不通；业务层的问题表现为帧收对了但数值解释错了、寄存器地址错了。
四类问题的排查工具和修改动作完全不同。把它们混在一起查，就会出现”来回换线、来回改超时，最后还是不通”的局面。
二、串口这一层：UART、RS-232 和 RS-485 不是一回事
很多人把这三个词当同义词用，实际上它们说的是三件不同的事。这也是现场接线最容易出错的地方。
三个名字，管的是三件事
图注：UART 管字符与比特的排列，收发器管电平怎么变，RS-485 管总线怎么接
UART 是一种数字收发机制，管的是”字节怎么变成串行比特、比特怎么排列”，它不规定线上是什么电压。收发器管的是电平转换与驱动，把 UART 的 TTL 电平换成 RS-232 的正负电压，或者换成 RS-485 的差分电压。RS-232 和 RS-485 是两种电气规范，管的是总线怎么接、能拉多长、能挂几个节点。
所以现场有个反复出现的坑：3.3V/5V 的 TTL 串口直连 RS-232 或 RS-485 的线，是不可直接互接的。直连轻则不通信，重则把收发器打坏。调试口一般用 UART 加 USB 转串口芯片；工业仪表走的是 UART 加一颗 RS-485 收发器。
一个字节是怎么从线上发出去的
图注：8N1 一帧是 10 位，不是 8 位——这就是”9600 波特不等于 9600 字节每秒”的原因
这是被误解得最多的一条。8N1 的含义是 1 个起始位、8 个数据位、0 个校验位、1 个停止位，一帧总共 10 位。所以 9600 bit/s 的实际有效字节率是 9600 ÷ 10 = 960 字节每秒，而不是 9600。
这个数字直接决定超时该设多少。发 100 个字节，光在线路上就要 100 × 10 ÷ 9600 ≈ 104 毫秒。如果报文走完 104 毫秒，程序里却把超时设成 50 毫秒，那不管你代码写得多快，这条报文一定”失败”。很多”偶尔超时”的故障，根子就在这里。
接收端也有讲究。异步串口没有独立的时钟线，双方各自按本地时钟采样，所以接收端要先检测起始沿，等约 1.5 个位时间之后采首个数据位，此后每隔一个位时间采一位。波特率稍有偏差、线路稍长，采样点就会往边上漂，比特一多就采错。
串口乱码，先别急着换波特率
图注：乱码有五类根因，波特率只是其中一支
乱码的根因分五类：参数不一致（波特率、数据位、校验、停止位）、电平接错（TTL、RS-232、RS-485 混接）、时钟漂移导致采样点偏移、接收溢出（中断或 DMA 处理不及时、缓冲区太小）、干扰与接地（电机、变频器、长线、地电位差）。
其中”接收溢出”最容易被忽略。它的表现很典型：字节看着都对，但隔一段时间丢一批，而且丢的时候恰好是程序在忙别的。这种情况改波特率没用，要看中断优先级、DMA 配置和缓冲区深度。
图上给的排查顺序是从低到高：先看误码标志（帧错误、奇偶错误、溢出、CRC 错），再核协议一致性，之后查电平与布线，再看波形与溢出，最末才动代码和缓存。这个顺序的价值在于——先看硬件错误标志，再改协议；先定位是哪一层，再换线重启。反过来做，就是不断重复劳动。
还有一个具体案例值得记住：发送端用 8N1、接收端配成 8E1，字节能看到，但每次校验都失败，PE 标志位持续置位。参数”就差一位”，现象却是”数据不对”，很容易被误判成干扰问题。
三、RS-485 能扛住现场，靠的不只是差分
RS-485 在现场的口碑很好，但它也经常被”接第三台设备就丢帧”这类问题打脸。原因不在芯片，多半在接法。
差分只是起点
图注：接收器只看两根线的差值，所以共模干扰能一起减掉；但拓扑、终端、偏置、接地一个都不能少
差分传输的原理简单：接收器只关心 (VA − VB)，两根线上同时出现的干扰会一起被减掉。这是 RS-485 抗干扰的底子。
但只有差分是不够的。拓扑必须是手拉手的一条总线，两端各放一个 120Ω 终端电阻；星形接法或者一根长长的分支，会让阻抗不连续、产生反射，表现为时有时无的丢帧。总线空闲时还要有偏置，给两根线一个确定的电平，否则接收器可能把噪声当成起始位。
还有一条现场必须记住的：A、B 的命名不同厂家可能相反。有的标 A/B，有的标 D+/D−，有的干脆反过来。判据以手册上的 D+/D− 定义为准，不要只认丝印。接反了的现象是”完全不通”或者”偶尔通”，很容易被当成参数问题查半天。
接地同样要注意。RS-485 收发器有共模电压范围限制（常见是 −7V 到 +12V），超出这个范围就可能损坏或误码。两地之间有地电位差、线又拉得很长的时候，仅靠屏蔽和接地是不够的，需要考虑隔离型收发器。
半双工：最后一个字节为什么会丢
图注：TXE 和 TC 是两件事，用错标志位就会在最后一个字节发完之前拉低 DE
这是半双工 RS-485 最经典的一个坑，而且它只在”最后一个字节”上出错，特别难查。
发送链路上有两级缓冲：数据寄存器（TDR）和移位寄存器（TSR）。TXE 标志只表示”数据寄存器空了”，意思是 CPU 可以往里塞下一个字节了；TC 标志才表示”移位寄存器也空了”，也就是最后一个停止位已经真的发出去了。
程序如果一看到 TXE 就立刻拉低 DE、释放总线，那最后一个字节的后半段——通常在停止位附近——就被截断了。接收端收到的数据体是对的，CRC 却是错的；重发几次，偶尔又能过。数值上很好理解：115200 波特率、8N1 时，一个字节只有约 86.8 微秒，方向切换早 50 微秒，末字节就必然残缺。
所以判据只有一条：判断”发送完成”要看 TC，不能看 TXE；判断”缓冲区可写”才看 TXE。把这一句记住，能省掉很多”偶发 CRC 错”的排查。
四、字节流没有边界，这是串口和 TCP 最像的地方
串口和 TCP 表面上差得很远，但在这一点上完全一样：它们都只保证字节流，不保证消息边界。很多人写程序时默认”发一次就是收一次”，后面所有怪现象都是从这一条假设来的。
四种成帧方式
图注：同一个字节序列，接收端可能一次读到完整一帧，也可能分两次读到，两种都对
四种成帧方式各有取舍。固定长度最简单，但灵活性差、改协议就崩；长度字段最通用，帧头里带一个长度，接收端先读头再按长度读数据体；结束符最直观，适合文本协议，但二进制数据里出现同样的字节就麻烦了；间隔时间靠静默时长分帧，Modbus RTU 用的就是这一种——帧尾靠 3.5 个字符时间的静默来判定。
接收端的写法应该是状态机：找帧头、读固定头、校验长度不超过上限、收满数据体、校验 CRC、交付业务；任何一步失败就滑动重同步，从下一个字节重新找帧头。而不是”读一次就当一帧”。
CRC、序号、ACK、重试各管一段
图注：五层各司其职，加一层替代不了另一层
这一层阶梯的顺序值得背下来：CRC 发现内容损坏；序号识别重复、丢失与乱序；ACK 确认对方已接收或已处理；超时重试在没收到响应时补请求；幂等与事务记录保证重复请求不会重复执行。
为什么不能只加一个校验码？看图上那个”打开断路器”的例子就明白了：主站发事务号 102 打开断路器，从站执行成功，响应在链路里丢了。主站超时后重发，从站如果只认命令不认事务号，就会再执行一次。断路器被开了两次，可能现场看不出来，但语义已经错了。
还有一层区分要拎清：TCP 的 ACK 只说明字节到达了传输层，不代表业务处理了。要确认”这件事到底做没做”，得有应用层的 ACK，返回的是已处理、成功还是失败。
五、以太网这一层：网线只是物理入口
以太网侧的问题，比串口侧更容易被”经验”带偏。网口灯亮了、Ping 通了，很多人就觉得网络没问题，其实这才走到一半。
以太网不等于 TCP/IP
图注：以太网管的是物理链路和帧，TCP/IP 管的是寻址与传输，两者不是一回事
报文出去的时候是一层层封装的：应用数据变成 TCP 或 UDP 段，段外面套 IP 包，包外面套以太网帧，帧最后变成线路上的电信号。进来的时候方向相反，一层层解开。
关键在于”证据阶梯”：网口灯亮只证明物理链路建立了；ARP 正常只证明同网段邻居能解析；Ping 通只证明 IP 路径可达；TCP 握手成功才说明端口上真的有服务；应用响应正确才是业务成功。每一层只证明自己的事，不能替上一层背书。
MAC、IP、端口分别解决什么
图注：MAC 找网卡、IP 找主机、端口找程序，三层地址各管一段
拿楼房来类比很直观：MAC 相当于楼门卡，只在同一栋楼（同网段）里有效；IP 相当于城市地址，可以跨区；端口相当于房间号，进了大楼之后要靠它找到具体哪一间。同一台设备上可以同时开很多个服务，就是因为它们的端口不一样。
所以现场遇到”两台设备 IP 冲突”和”同一台设备上服务端口冲突”，是两件不同的事，排查手段也不同。
Ping 通了程序连不上，差在哪
图注：ICMP 可达和 TCP 可连接是两件事，Ping 通只说明走到了第三级
顺序是网口状态、IP 地址、邻居 ARP、可达性、路由、端口、监听、策略、握手、应用。Ping 在第四步，后面还有六步。
TCP 连接失败分三种典型表现：SYN 发出去没有回应，最后超时——问题在路由、防火墙或服务没起；收到 RST 立刻被拒——端口上确实没有监听，或者被策略明确拒绝；握手完成了马上被断开——说明网络是通的，问题在应用层或者协议不匹配。
把”Ping 通了”当成”网络没问题”，会把后面六步全部跳过，最后变成在自己代码里反复找 bug。先确认端口，再查应用；不要拿 Ping 当业务验收。
TCP 和 UDP 怎么选
图注：不是谁更快的问题，而是可靠性该放在哪一层的问题
TCP 面向连接、有序字节流、有序号确认和重传、有流量与拥塞控制，适合参数配置、文件传输、远端管理这类必须可靠的场景；它不保留消息边界，应用层照样要自己分帧。UDP 无连接、保留报文边界、不保证到达与顺序，但开销小、没有重传带来的延迟，适合高频状态广播、实时视频这类”旧数据丢了反而更好”的场景。
判断路径可以简单一点：能不能容忍丢包？要求不要求低延时？需不需要广播或组播？是不是必须确认业务执行？四个问题走下来，多数场景就定了。
有一个结论要单独记：关键命令不要指望协议层替你保证业务。跳闸、停机这类动作，需要在应用层加 ACK、加事务号、做幂等，而不是选一个”可靠协议”就完事。
粘包拆包不是故障
图注：错的是把一次 send 当成对方的一次 recv，TCP 从来不承诺这件事
“粘包”这个词本身有点误导。发 ABC 再发 12345，对方收到 ABC12345、或者先收到 ABC 再收到 12345、或者分成三段收到，三种都合法。原因既有发送缓冲和接收缓冲，也有 MSS 分段、接收窗口和调度时机。
正确做法是长度前缀协议，按字节流循环解析：读满固定头、解析长度、检查不超过上限、读满数据体、校验、交付、保留剩余字节继续下一轮。长度一定要校验上限——不然一个错误的长度字段就能让程序一直等数据或者申请超大内存。
六、协议怎么写：从字段设计到超时核算
前面讲的是”怎么查”，这一节讲”怎么设计得不容易出问题”。自定义协议的坑，多数在字段设计和超时设置上。
一个自定义协议该有哪些字段
图注：字段不是越多越好，每个字段要解决一个明确的问题
八个要素：魔数用来识别帧头并在失步后恢复；版本用来支持协议升级与向后兼容；消息类型区分命令、响应、事件、心跳；标志位放应答、错误、分片这类状态；序列号用来匹配请求与响应、定位丢包；长度字段确定边界；业务内容放具体数据；CRC 做端到端错检。
除此之外还要约定字节序、变长编码方式（文本用 UTF-8）、地址与时间戳的长度与精度、版本协商规则。协议的目的不是写得漂亮，而是让不同团队、不同 CPU、不同版本的设备都能理解同一段字节。
为什么不能直接发一个 C 结构体
图注：内存布局是编译器的事，协议格式是双方约定的事，两者不能混为一谈
把结构体直接按内存字节发出去，看着省事，实际埋了三个雷。一是对齐填充：编译器为了访问效率会在字段之间插入空隙，同一个结构体换个平台大小就变了。二是字节序：小端机器发出去的多字节整数，到大端机器上读出来就是另一个数。三是类型宽度：int 可能是 16 位也可能是 32 位，float 的精度和表示也不一定一样。
正确做法是显式序列化：把每个字段按协议规定的宽度、字节序逐个写进缓冲区，长度和 CRC 也是算出来再填。举个具体例子，温度 25.3℃ 按 0.1℃ 量化成 253，写成 16 位大端就是 0x00 0xFD，接收端再乘回 0.1 得到 25.3。
Modbus RTU 和 Modbus TCP 差在哪
图注：功能码和寄存器地址完全一样，差的是外层封装和分帧方式
这两个容易混，其实差别全在外层。RTU 跑在 RS-485 串行总线上，帧是”站号 + 功能码 + 数据 + CRC”，帧尾靠 3.5 个字符时间的静默来分；TCP 跑在以太网上，帧前面多了一个 7 字节的 MBAP 头（事务标识、协议标识、长度、单元标识），不再带 RTU 的 CRC，分帧靠长度字段。
拿读保持寄存器举例（起始地址 0x0000、数量 2）：RTU 请求是 8 个字节，01 03 00 00 00 02 C4 0B；TCP 请求是 12 个字节，00 01 00 00 00 06 01 03 00 00 00 02。同一件事，字节数都不一样，所以”把 RTU 报文直接塞进 TCP”一定会出错。
网关的作用就在这里：收到 TCP 请求后剥掉 MBAP，补上站号和 CRC 再发到 485 总线；响应回来反向处理，并用事务号匹配回原来的请求。
超时要算，不能拍脑袋
图注：总时延不是线路时间，而是六个环节加起来的和
总时延由六部分组成：请求发送、总线传输、从站处理、响应发送、调度抖动、安全裕量。通信协议里只有”字符时间”是确定的，其余都要估。
拿一个常见的 Modbus RTU 例子算一遍（9600 波特率，请求 8 字节、响应约 37 字节，从站处理 20 毫秒）：请求发送 8 × 10 ÷ 9600 ≈ 8.33 毫秒，总线传输约 5 毫秒，从站处理 20 毫秒，响应发送 37 × 10 ÷ 9600 ≈ 38.54 毫秒，调度抖动 15 毫秒，安全裕量 10 毫秒，加起来约 86.87 毫秒。所以超时设 120 到 150 毫秒是合理的，设 50 毫秒必然偶尔失败。
TCP 侧要分三段设：连接超时（3 到 5 秒）、写超时（3 到 10 秒）、读超时（10 到 30 秒）。三个阶段卡的资源不一样，用同一个数不合适。超时要大于可证明的最坏响应时间，而不是凭感觉设一个整数。
心跳不是发个 0x00
图注：TCP 重连成功不等于双方状态一致，恢复的重点是重新同步
心跳的作用是判断设备是否在线、运行是否正常，不是周期性发一个没有语义的字节。真正有用的心跳是”一次能验证协议和业务的读取”——比如周期性读一个固定寄存器，读到了才叫在线。
重连要有退避策略，比如 1 秒、2 秒、4 秒、8 秒、16 秒，并且每次加一点抖动（上下浮动 20% 左右），避免大量客户端同时重试把服务打垮。
恢复顺序比连接本身更重要：先做身份与版本校验，再同步时间，之后读设备的真实状态，对账未完成的事务，清理过期命令，最后才恢复控制。有一步的差别是很大的——如果连接一恢复就把断线前的命令全部重发，而设备断电重启后状态已经变了，就可能执行出完全不同的动作。
千兆以太网，为什么控制命令还是慢
图注：带宽解决吞吐，实时性关心的是最坏时延与抖动
带宽和实时性是两件事。端到端时延是串行化、传播、排队、处理、重传五项之和。把百兆换成千兆，只是把一帧 1500 字节的串行化时间从约 120 微秒压到约 12 微秒，省下来的一百多微秒，如果系统的任务调度本身就有几毫秒的抖动，那等于没省。
更值得看的是分布而不是平均值。控制类业务要看 P99 甚至最坏值——平均 1 毫秒、偶尔 40 毫秒的系统，比平均 3 毫秒、最坏 5 毫秒的系统危险得多。常见的隐藏瓶颈有交换队列、操作系统调度、内存回收、日志写入、TCP 重传。
七、位移传感器在现场是怎么通信的
前面讲的都是通用规律，落到位移传感器上，有几件具体的事需要单独说清楚。位移传感器是产线的”尺子”，它的数据出问题，往往不是传感器坏了，而是通信链路上某一环没配对。
四种常见接口，各自的适用面
现在现场常见的位移传感器接口有四类，各自的适用面差别很大。
- 模拟量（4-20mA 或 0-10V）：最传统，一根线进 PLC 模拟量模块。4-20mA 用电流环传信号，抗干扰比电压型好得多，断线时电流掉到 0 还能报故障。缺点是分辨率有限、需要标定、一条线只能传一个值，量程改了要重新标定。
- SSI 同步串行：位移传感器里很常见。主站给时钟脉冲，传感器回绝对位置数据，断电再来不用回零。线数偏多（时钟差分、数据差分加电源），一般用在几十米以内的机床、液压伺服场合。
- RS-485 加 Modbus RTU：多站、成本低、普通双绞线就能拉。一条总线挂多台，PLC 轮询读取。适合点位多、布线长、对刷新周期要求不算苛刻的产线。
- CANopen 等现场总线：工程机械、风电这类本来就有 CAN 网络的场合用得比较多，抗干扰好、带优先级仲裁。
选哪种，跟前面第六节讲的选型六问是同一套逻辑：传多远、多少节点、每帧多大、多久更新一次、要不要逐个确认、最坏时延能接受多少。答案不同，接口就不同。
图注：选接口先回答六个问题，而不是先看哪个更”高级”
多台传感器挂在一条 RS-485 总线上
这是位移传感器上量最多的用法，也是最容易接出问题的地方。几条现场经验：
- 手拉手，不要星形。从 PLC 出发一路串下去，每台传感器挂在总线上，不要从中间某个点分出一根长分支。分支一长，反射一来，表现就是”某几台偶尔读不到”。
- 终端电阻只在两端。一条总线两个 120Ω，分别放在物理两端。中间几台不要各加一个——多接会并联降阻抗，反而更容易出问题。
- A、B 以 D+/D− 为准。不同品牌的丝印可能相反，接反了直接不通。初次调试时先只挂一台，通了再往上加。
- 屏蔽层单端接地。屏蔽层通常只在 PLC 侧接一次地，两头都接会形成地环流，反而把干扰引进来。
- 站号不能重，轮询要有间隔。同一总线上出现重复站号，会表现为”两台读数一样”或者”随机某台不响应”。
- 距离长、干扰大就降波特率。9600 比 115200 稳得多，代价是刷新变慢。位移数据的刷新周期能接受的话，优先选低波特率。
- 和动力线分开走。传感器线缆不要和变频器输出线、伺服动力线同槽，平行距离尽量拉开，交叉时垂直过。
具体的接线端子定义、两线三线四线六线怎么分，可以参考站内这篇：位移传感器怎么接线？先分清两线、三线、四线、六线，再对着线色定义接。线缆本身怎么选，尤其是双绞和屏蔽的部分，双绞线为什么能抗干扰这篇讲得更细。
读位移值的超时、心跳与断线判断
把第六节的算法套到位移传感器上，就很好算了。一条典型的 Modbus RTU 读取（请求 8 字节、响应 37 字节），在 9600 波特率下光线路时间就接近 47 毫秒，再加上传感器内部处理、PLC 扫描周期和调度抖动，总时延落在 90 到 150 毫秒是正常的。
所以两个常见的错误设置要避开：超时设成 50 毫秒以下，必然”偶尔失败”；轮询周期设得比响应时间还短，总线上会不停堆积请求，读到的数值会越来越滞后。
心跳建议用”周期性读一个固定寄存器”来做，而不是发一个没有业务含义的字节。这样一次心跳同时验证了三件事：通信在线、协议正确、设备可响应。判断”设备掉线”的判据也要多看几个：连续几次超时、CRC 错误计数上涨、数值长时间不变化。
断线恢复的时候有一个坑：不要一恢复连接就把断线前攒下的命令全部重发。传感器断电重启后位置可能已经变了，这时候应该先重新读一次实际位置，确认现场状态，再决定要不要继续执行原动作。
读数跳变：先分通信和干扰
位移传感器最常见的现场投诉就是”数值在跳”。判断起来其实有规律，看跳的形态就能分开。
- 数值整段跳、跳完停住，同时通信超时计数在涨：这是通信问题，不是传感器。查总线、终端电阻和轮询周期。
- 数值小幅高频抖动，幅度和频率都不规律：多半是干扰、接地或电源问题。查屏蔽层接法、与动力线的距离、以及供电是否和变频器共用。
- 只在电机或变频器启动的瞬间跳：典型的共模干扰或地电位差。考虑隔离收发器，或者把传感器供电单独走一路。
- 数值按固定步长跳，且跳变点和机械位置对得上：这更可能是机械间隙、联轴器松动或者安装同轴度的问题，跟电信号无关。
一个实用判据：先看 PLC 侧的通信错误计数（CRC 错、超时次数），再看数值本身。错误计数不动而数值在跳，问题在传感器或机械；错误计数在涨，问题在通信链路。这一条能把排查范围立刻缩小一半。
八、现场排障的顺序：从物理层往上查
前面把原理铺完了，这一节是操作顺序。
串口不通，按这六层查
图注：从电气信号向上排，不要一上来就改协议
六层的顺序是：接口类型（接对了吗）、线缆拓扑（端子、屏蔽、接地的接法对吗）、电气波形（干净吗、幅值对吗、差分对吗）、UART 参数（波特率和帧格式一致吗）、协议（字节对得上吗、帧格式对吗）、业务解析（寄存器地址和数值解释对吗）。
工具也要配对：万用表量电压、通断和线序；示波器看波形、幅值、时序和噪声；带协议解码的逻辑分析仪看字节流；USB 转串口工具做收发和回显测试。手上只有万用表的时候，能落到实处的是前两层，硬查第三到第六层只会浪费时间。
以太网不通，按这八步查
图注：Ping 只走到网络层，业务成功必须逐层举证
顺序是电缆与网口、VLAN 与子网、IP 与网关、ARP 与路由、端口与服务、策略与 ACL、抓包与会话、应用与业务回应。
抓包看不明白的时候，按八个要素扫一遍：有没有包、ARP 有没有解析、IP 对不对、TCP 三次握手成不成、端口对不对、序号连不连续、有没有重传、有没有 RST 或零窗口。八个要素对着看，多数”网络时通时不通”的问题都能定位。
十个常见误区
图注：这十条都是在现场被反复验证过的错觉，每一句错话都能带偏一整条排查思路
把图上这十条过一遍：UART 不等于 RS-485；9600 波特不等于 9600 字节每秒；终端电阻不是越多越稳；一次 read 不等于一整帧；TCP 可靠不代表业务不需要 ACK；Ping 通不代表服务正常；UDP 不一定比 TCP 快；CRC 解决不了重复和乱序；断线后不要盲目重发全部旧命令；反复通信失败不要先改协议参数。
这十条有一个共同的错误来源：把不同层的问题混成一句话。记住分层之后，很多争论其实不用争——问题本来就在不同层。
九、写在最后
图注：一套可靠的通信系统，是从”能通”走到”可证明、可恢复、可演进”
把整篇收一下。一套可靠的通信系统要具备七件事：一条完整的链路；数据层保证一帧可解析（边界明确、长度、类型、CRC）；事务层知道这件事到底做没做（请求 ID、执行一次、ACK）；连接层断了也能安全回来（心跳、退避、恢复顺序）；可观测性（日志、时间戳、报文长度、事务号、错误计数）；安全（身份、权限、防重放、限速）；以及上线前做过破坏性测试（断电重启、热插拔、极端时延、断线、边界长度、丢包与乱序）。
如果只记一段话，记这个：UART 管字符与比特，RS-485 管差分电气；串口和 TCP 都只保证字节流，不保证边界；CRC 只查损坏，不保证业务；分片、丢失、乱序、超时要应用层自己处理；超时要按时延核算；关键业务必须有事务号与幂等；排障从物理层往上查证据链。
通信这块内容看着零碎，其实只有一个主线：每一层只证明自己的事。把这条线抓住，现场一大半”玄学问题”都会变成有顺序可查的普通问题。
相关产品：拉绳位移传感器 ｜ 磁致伸缩位移传感器 ｜ 本安防爆位移传感器
相关阅读：位移传感器怎么接线？先分清两线、三线、四线、六线，再对着线色定义接 ｜ 双绞线为什么能抗干扰？差分、绞距、阻抗与屏蔽四个环节 ｜ 压铸机用什么位移传感器？合模行程、顶出位置与压射位移三个测量点
选型、安装调试、输出通信、故障排查、防爆认证这几类现场问题，站里另有一页 位移传感器常见问题解答，按主题分开整理，遇到拿不准的可以对着翻。
