企业官网建设流程全解析

前阵子给一家药厂的洁净车间做环境监测改造，业主提了一个很明确的要求：“温湿度传感器全部走以太网，直接用TCP协议，不要再用RS485手拉手那种了。”不用说，这代表了现在工业项目里一种很主流的选型趋势。TCP协议以太网温湿度传感器，说白了就是把传统的温湿度变送器加了一颗以太网协议栈芯片，让现场探头采集到的温度和湿度数据，能以TCP/IP协议包的形式接入局域网，上位机、PLC、SCADA系统直接用网线就能读取。这篇文章我就结合自己实际调试过的项目，把这类传感器的原理、选型逻辑、调试手法和常见坑一次讲清楚，尤其侧重聊一个问题：为什么工业项目现在越来越愿意用它。

先说结论，工业项目更倾向以太网温湿度传感器，不是因为RS485老掉牙了，而是因为布线成本、节点数量、故障排查和系统集成的便利性，在几十甚至上百个测点的场景下，以太网方案明显更划算。后面我会把原理、细节、抓包调试和S7-1500通信指令的坑逐个展开，做自控、楼宇、数据中心、洁净车间、冷库这类项目的朋友，应该都能用得上。

1. 先拆开看：TCP协议以太网温湿度传感器到底是什么

1.1 它不是一个探头，而是一个小型的网络终端

很多人一听到温湿度传感器，脑子里先想到的是DHT11那种蓝色模块，三条引脚，一条电源一条地一条数据线，拿杜邦线往STM32开发板上一插，程序里写个单总线时序就能读到温度。DHT11这类传感器确实便宜，几块钱一个，做做电子设计、智能家居原型足够，但它距离工业现场用的TCP以太网温湿度传感器，差了整整一个维度。

工业用的TCP协议以太网温湿度传感器，内部结构大概是这样的：前端是一个高精度探头，常见的是数字式SHT30/SHT31或者PT100加湿敏元件，信号经过调理电路、MCU做滤波和线性化补偿，最后由一颗以太网控制器和物理层收发器把数据打包成TCP/IP报文，通过RJ45网口发出去。有的传感器甚至内部跑了一个精简的嵌入式系统，支持DHCP、静态IP、Modbus TCP从站，还带网页配置界面。

所以它本质上是一台“能测温湿度的网络小终端”，不只是一个探头。这也就意味着，它可以直接挂在工业交换机上，和PLC、上位机、HMI处于同一个局域网内，IP地址就是它的身份标识，寄存器地址就是它的数据接口。

1.2 “TCP协议”在传感器语境里通常是指Modbus TCP

实际项目里说的“TCP协议”，通常不是让你用Socket从零写一个私有协议去收数据，而是指应用层跑在TCP之上的Modbus TCP协议，或者某些厂家基于TCP封装的私有协议。

Modbus TCP是从Modbus RTU延伸过来的，保留了寄存器、线圈、功能码这些概念，但把串口传输换成了以太网TCP/IP。默认端口502，报文格式也很直接：事务处理标识符、协议标识符、长度、单元标识符、功能码、寄存器地址、数据。上位机或者PLC只要按这个格式发一条读保持寄存器的请求，传感器就会回一条包含温度值、湿度值的报文。

这里有个很容易误解的点：为什么很多传感器说明书上写“支持TCP/IP”，同时又写“支持Modbus TCP协议”？因为TCP/IP是下面的传输层和网络层，Modbus TCP是上面的应用层。传感器只是把温度湿度数据放到了TCP的应用载荷里，而数据怎么组织、怎么解析，要靠Modbus TCP这套规矩来统一。所以选购时不要只盯着“TCP”，要确认它支持哪种应用协议，最好能直接兼容你现在用的上位机组态软件或者PLC指令库。

1.3 与RS485 Modbus RTU传感器方案的核心差异

这里我把两种方案的关键参数做一个对比，方便你快速理解差异：

从这个表能看出来，RS485在长距离、简单总线和强干扰场合仍有价值，尤其是单点对单点，或者一条线上挂十几个测点的中小项目，RS485的成本优势还很明显。但一旦你的测点数量上去了，或者现场需要多区域独立布线，RS485的轮询等待和接线复杂度就会拖后腿，这时TCP以太网传感器的优势就体现出来了。

2. 工业项目为什么更愿意用以太网方案

2.1 布线与组网成本在几十个测点时反超

很多人都觉得RS485布线便宜，其实要看规模。RS485是一条总线串到底，听起来省线，但每个节点都要破线接入，A、B两根线不能接反，屏蔽层要单端接地，终端电阻要匹配，施工队稍微马虎一点，通信就会时断时续。我在一个冷链仓库项目里见过最典型的例子：一条RS485总线挂了三十几个温湿度传感器，走线穿了三层楼，结果最远端那几只传感器经常无响应。排查了一下午，最后发现是中间有个接线端子松了，半接触状态导致整个总线反射严重。

换成TCP以太网传感器，施工逻辑就变了。每个传感器单独一根网线到弱电井的交换机，接线做水晶头或者模块端，逻辑上和布网线一样，施工队很熟练，不用理解A/B线、屏蔽地这些概念。对于大型项目，一台24口工业交换机就能带二十多台传感器，如果距离远就加光纤收发器，组网思路和办公网络完全一致，维护团队上手成本低很多。

规模越大，以太网方案的综合布线成本越有优势。有人统计过临界点大概在十五到二十个测点，超过这个数量，RS485省下来的线缆钱会被施工人工和时间成本吃掉。

2.2 节点数量和轮询效率不在一个量级

Modbus RTU是半双工轮询机制，主站发一帧问询，从站回一帧响应，同一个时刻总线上只能有一个设备说话。波特率9600的情况下，一帧典型报文大约10到14个字节，再加上帧间隔，单次问答大约要10到15毫秒。假设一条RS485总线上挂了50台传感器，每台轮询一次，理想情况下也要0.5到0.75秒；如果某些从站响应慢，或者总线质量差导致重试，整个轮询周期轻松超过两秒。

你可能觉得两秒也不算慢，温湿度本来就是慢变量，但工业项目往往不希望所有传感器轮流排队占着通信链路，因为这条链路可能同时还要传输其他设备的报警状态、开关量信号。更头疼的是，如果有一个从站掉线，主站要等超时，整个轮询周期会被严重拉长，后面的传感器全部跟着遭殃。

TCP以太网传感器走的是交换机网络，从站不再共享同一条物理链路。每台传感器独立网线和交换机端口，即使有几十台，通过上位机多线程或者PLC并行连接也能做到毫秒级并发读取。即便用轮询方式写程序，单次TCP请求的响应通常也在几毫秒以内，和总线式相比，整体吞吐效率高出一个数量级。

2.3 故障排查可以用抓包工具直接定位

这是我最看重的一点。项目调试末期最怕什么？怕通信时好时坏，怕现场反馈“那台传感器偶尔没数据”。RS485遇到这种问题，基本手段就是万用表量静态电压、示波器看波形、然后怀疑线路干扰、怀疑接地、怀疑终端电阻，整个排查过程非常依赖经验。

以太网传感器就舒服多了。在电脑上用Wireshark抓包，过滤条件一行输进去，比如：

tcp.port == 502 && ip.addr == 192.168.1.50

马上就能看到主站和传感器之间的完整TCP交互，有没有三次握手、有没有重传、Modbus请求和响应是否匹配、响应时间是多少。这些信息清清楚楚。

有一次现场报障，说车间里一台传感器上位机读数经常卡住不动，我远程让现场工程师把笔记本接到故障传感器同一个交换机上，抓了三十秒的包，一眼就看到TCP连接建立之后频繁出现Dup ACK和Retransmission，判断是网线质量太差或者水晶头接触不良。换了一根成品网线立马恢复正常。这种问题放到RS485现场，多半要耗掉半天。

2.4 距离和中继方式的灵活性

很多人拘泥于“网线最长100米”这个限制，觉得RS485能传1200米，以太网扛不住，这是一个很常见的误会。RS485的1200米是在低波特率、良好屏蔽和正确接地的前提下才能达到的理想值，而且现场如果变频器多、电缆桥架密集，实际能跑多远心里真的没底。

以太网到100米就上交换机，而交换机的位置可以灵活放置。工业项目里最常见的做法是每个区域放一台工业交换机，区域间用光纤汇聚到中控室，光纤传几公里毫不费力。药厂、电子厂房、物流仓库这种大面积场景，经常是分区域交换机加光纤主干，这时候温湿度传感器以太网接口的优势就体现得很充分：它天然就是为这种树形/星形网络设计的。

3. 为什么工业数据采集偏偏选TCP而不是UDP

3.1 温湿度数据不允许“悄悄丢失”

如果你做过网络编程，会知道TCP和UDP最根本的区别：TCP是面向连接的可靠传输，UDP是无连接不可靠传输。UDP的包头开销小、延迟低，适合音视频流、游戏实时同步这类可以忍受少量丢失的场景；但温湿度采集恰恰不能忍受无感丢包。

你可以想一个场景：一套环境监控系统，要求每30秒记录一次温度，假如用了UDP，某个瞬间网络拥塞或者交换机队列溢出，一个数据包被静默丢弃，监控软件并不知道，这一帧数据就永久缺失了。万一丢的正好是某段时间的温度峰值，后面对车间环境追溯、批次放行分析都会留下一个洞。

TCP不一样，它通过三次握手建立连接，给每个包编序号，接收方收到数据要回ACK，超时没收到就重传。对温湿度这种小数据量应用，TCP的可靠传输特性明显更有价值。

3.2 数据量太小，TCP的“开销”根本不算事

有人会说TCP握手、确认、重传这些机制太啰嗦，会增加延迟和带宽开销。对于传大文件的场景，这个批评有道理，因为TCP慢启动和拥塞控制会限制吞吐。但请算一笔账：一条温湿度数据报文，Modbus TCP请求大约是12个字节，响应大约是16个字节，就算加上TCP首部和IP首部，整个包也不超过60字节。

假设一台传感器每秒采集一次数据，一天下来也就几十兆字节，对于百兆以太网来说连九牛一毛都算不上。网络带宽对这类应用来说极其充裕，TCP那点握手延迟和确认开销，在毫秒级甚至微秒级面前完全可以忽略。

我们真正要关心的是数据的完整性和有序性。TCP自带序号机制，数据先发后到也能按顺序重组，对监控软件非常友好。UDP如果数据乱序，上层应用还得自己处理，纯属给自己找麻烦。

3.3 说句公道话：UDP在工业现场也并非一无是处

做技术不能二极管，UDP在工业现场确实有它的用武之地。比如时间同步用PTP或者NTP，底层走的是UDP；SNMP协议上报设备告警也用UDP；一些高速运动控制或视觉系统为了追求极低延迟，也会用UDP加应用层重传来减少握手开销。

但对于温湿度传感器这种低频、小包、重要数据，TCP是最稳妥、最省心的选择。这也是大多数传感器厂家默认支持Modbus TCP而不是Modbus UDP的原因。你在选型时看到某些传感器宣称“支持UDP上报”，要谨慎评估，问清楚应用层有没有补包机制，否则项目后期会被丢包问题折磨到崩溃。

4. 从方案选型到现场调试：一次药厂项目的完整记录

4.1 硬件选型与网络规划

我以最近做的那个药厂项目为例，把整体架构捋一遍。需求是三层楼，每层16个洁净车间，每个车间1个温湿度测点，总共48个点，数据要同时进WinCC上位机和一套S7-1500 PLC，用于环境报警联动。

硬件选型如下：

• 温湿度传感器：工业级Modbus TCP接口，壁挂式，配SHT30探头，精度温度±0.3℃，湿度±2%RH，供电采用POE或者24V DC双选型。
• 网络设备：每层一台8口工业PoE交换机，支持宽温和冗余电源，交换机间用网线级联到一层机柜，机柜端用一台24口千兆核心交换机汇聚。
• PLC：S7-1500带PN口，直接接入核心交换机。
• 上位机：一台工控机，WinCC 7.5，安装网卡驱动后配置静态IP。

网络规划上，我给传感器、PLC、上位机划了同一个网段，手动分配静态IP，这样做的好处是后续抓包、写轮询脚本时不用到处猜地址。IP规划如下表：

一个很实用的习惯是给传感器IP地址和物理安装位置建立表格，贴在中控室机柜门内侧，不然三年后换人维护，谁也不知道192.168.1.133到底在哪个房间。

4.2 用博途S7-1500通过TCP读取传感器的过程

PLC读取以太网温湿度传感器，主要用西门子开放式通信指令TCON、TSEND_C、TRCV_C。TCON负责建立TCP连接，TSEND_C发送请求，TRCV_C接收响应。

很多人在这一步踩坑，觉得“用TSEND_C发送数据太慢，总是busy”，其实这多半不是指令本身慢，而是调用方式不对。TSEND_C属于异步指令，它一旦触发，只要连接没有被关闭，指令会保持忙碌状态直到发送完成。如果你在OB1里每个扫描周期都无条件调用TSEND_C，又不判断上次发送是否已完成，指令永远不会正确工作，表现出来就是“发一次之后再也发不了下一条”。

正确做法是做一个发送状态机：

第一步：TCON建立连接，等待DONE位置位。 第二步：发送请求帧，等待TSEND_C的DONE或ERROR标志。 第三步：调用TRCV_C接收响应，接收完成后再允许触发下一次发送。

常见周期设置为1秒读取一次。你可能会问，TSEND_C这么麻烦，能不能用Modbus TCP库指令？如果TIA Portal装了Modbus TCP库，当然可以直接用Modbus_Client指令，封装更友好。但如果设备不支持标准Modbus映射，只想用TSEND_C/TRCV_C裸收发的场合，上面这套状态机是必须掌握的。

4.3 Wireshark抓包验证数据通信

PLC程序写好后，不要急着标定传感器，先抓包看看底层通信质量。我在项目调试时就养成了一个习惯：任何新设备接入网络，第一件事就是用Wireshark抓一次包，确认底子干净再谈业务逻辑。

抓包要点如下：

• 把笔记本接在和传感器同一台交换机上，镜像口或者直接用交换机监控口。
• 打开Wireshark，设置过滤器tcp.port == 502 || ip.addr == 192.168.1.101。
• 查看TCP三次握手：SYN，SYN+ACK，ACK，说明连接能正常建立。
• 查看Modbus TCP请求和响应：关注功能码03（读保持寄存器）对应的响应是否在几十毫秒内返回。
• 检查有没有大量TCP重传、零窗口、RST连接复位，这些都在提示链路质量或设备资源异常。

有一次我在这类项目里遇到传感器响应概率性超时，上位机读到的数据偶尔是0，抓包后发现传感器在TCP握手阶段频繁发送RST包，说明设备端的连接资源没有被正常释放。最后查明是因为上位机轮询周期太短，传感器还没来得及处理完上一个连接请求又被新请求打断，调整轮询间隔从200毫秒改成500毫秒后彻底解决。

4.4 上位机轮询脚本的简易实现

如果你的系统没有用组态软件，而是自己写采集程序，Python加ModbusTCP库是个很轻巧的方案。示例片段如下：

from pymodbus.client import ModbusTcpClient client = ModbusTcpClient('192.168.1.101', port=502, timeout=1) if not client.connect(): print("连接失败") else: # 读取从地址0开始的2个保持寄存器，分别是温度、湿度 rr = client.read_holding_registers(address=0, count=2, slave=1) if not rr.isError(): temp = rr.registers[0] / 10.0 humi = rr.registers[1] / 10.0 print(f"温度={temp}℃ 湿度={humi}%RH") client.close()

注意不同厂家传感器的寄存器地址和缩放系数可能不同，务必以官方手册为准。有的传感器温度寄存器值直接就是实际的十倍，有的是一百倍，有的还分整数位和小数位两个寄存器，搞错一个系数，数据看着正常，实际完全是错的。

5. 常见问题与排查技巧实录

5.1 TSEND_C发送太慢、总是busy的处理思路

前面说了，TSEND_C busy的根源大多是调用方式问题。我再补充几个排查点：

• 确认TCON连接是否已经建立，只有连接成功后才能发送。
• 检查TSEND_C的REQ信号是否只在需要发送的上升沿出现，不要在循环扫描里一直置1。
• 发送数据长度是否与数据块DB的可用字节数一致，不一致会导致指令报错。
• 连接号CONNECT参数是否唯一，多个连接使用同一个连接号也会导致行为异常。

如果排查完还是偶尔busy，可以在程序里加一个“发送忙等待”逻辑：上一个发送完成后置一个标志位，下个周期再启动下一次发送，严禁一个循环周期内多个TSEND_C叠加触发。

5.2 网线没问题，为什么就是ping不通

以太网传感器最常见的故障是“Ping不通”。按这个顺序排查：

• 确认笔记本和传感器是不是同一网段，子网掩码是否正确，Windows的“以太网没有有效IP配置”十有八九是DHCP没分配到地址，重新设置静态IP即可。
• 确认交换机的端口是否被划到隔离VLAN里，工业交换机很多默认端口是隔离的，需要进Web管理关掉端口隔离。
• 确认传感器供电是否正常，某些PoE交换机没有开启PoE供电，网线通了但设备没有上电。
• 确认传感器本体有没有启动完成，有些设备上电后要等二十多秒才能响应ping请求。

我见过最奇葩的一次，是现场工人把网线插到了旁边一台没用过的旧交换机上，而那台交换机根本没有接上主干网，传感器和上位机物理上隔着一堵墙。所以排查网络问题要结合物理拓扑走一遍，不要只盯着IP和协议。

5.3 读数跳动明显，是传感器质量问题吗

很多时候读数不准、反复跳动，不一定是传感器坏了，先检查探头安装位置和环境因素。探头如果靠近空调出风口、门口、设备散热口，数据自然会波动得很厉害。工业场景里，壁挂式传感器要离地1.4米左右，不要阳光直射，不要贴在冷桥或者外墙内侧安装。

另外，传感器内部一般有采集滤波逻辑，低通采样平均可以抑制瞬时波动。如果你发现传感器每帧数据跳变超过0.5℃或者2%RH，可以先读取传感器原始值和滤波值寄存器，确认是不是MCU内部滤波没生效。再不行就用冰水混合物或者恒温槽做一次现场比对，验证标定。

注意DHT11这类裸传感器的精度只有±2℃，湿度±5%RH，而且出厂一致性较差。如果现场标定时发现偏差太大，大概率不是网络问题，而是传感器本身的精度等级就不满足项目需求。

5.4 工控系统里的Windows网络疑难杂症

工控机用的Windows经常“升级后网络就坏了”。有几次我在现场排查，传感器、交换机、配置全都没问题，就是工控机网卡驱动被Windows更新悄悄覆盖了，导致TCP连接异常。处理办法很简单：进入设备管理器，回滚网卡驱动程序，或者直接关闭Windows自动更新。

虚拟机安装系统时也经常遇到“没有连接以太网”的提示，比如在VMware里装OpenEuler，安装时网卡选的是NAT，后来宿主机的网络环境变了，虚拟机自然就上不了网。在虚拟网络编辑器里重新选桥接模式，然后手动配置静态IP，通常能解决。

5.5 串口老用户想平滑过渡，能用转换网关吗

很多现有项目还有不少RS485接口的老传感器，不想一次性全部报废，又想让它们接入以太网，最经济的方案是加一台Modbus RTU转Modbus TCP网关。网关本身是Modbus TCP服务端，通过RS485总线轮询下挂的RTU从站，再把数据映射到网关内部的寄存器空间，上位机只要用Modbus TCP读网关即可。

这种方案的优点是过渡平滑，但有个性能瓶颈：网关轮询RS485从站的速度再快，也快不过原生以太网传感器。如果网关下面的RTU从站超过三四十个，读取周期会明显变长。我的建议是，老设备少可以用网关兜底，新项目或者大规模扩容，直接上TCP以太网传感器才是长期省心的选择。

最后说点个人体会

做了这几年工业通信项目，我最大的感受是，选通信方案不能只看参数表，要看整个生命周期。TCP以太网温湿度传感器之所以在工业项目里越来越常用，表面上是因为它传输可靠、组网灵活、排查方便，本质上是因为它把传感器从一个孤立的“测量节点”变成了网络中真正可管理的“智能终端”。你可以在中控室看到它的IP、它的在线状态、它的报文，甚至远程配置它的IP地址，这对一个几十上百个测点的运维体系来说，价值远远超过省下来的那几米网线。

最后提一个非常具体的建议：不管项目大小，新装以太网温湿度传感器时，一定要把IP地址、测点编号、物理位置、校准日期四类信息登记成册，最好贴在机柜门上。我见过太多项目，设备倒是用上了，三年后维护的人看着一排传感器IP完全不知道哪个是哪个，只能一台台拔线确认。这种最基本的文档习惯，比任何高端调试工具都管用。