尧图网站建设 
前阵子一个做机房动环的朋友问我现场原来一直用RS485加Modbus RTU的温湿度传感器为什么新出的项目图纸里全换成了带TCP以太网接口的型号价格还贵一截。这个问题我琢磨了很久也踩过不少坑今天就专门聊聊TCP协议以太网温湿度传感器以及它为什么在工业项目里越来越常见。先说个结论这类传感器测的还是温度、湿度传感器本身并没有多神秘真正的分水岭在“数据怎么从现场传到系统里”。如果你搞过几个几十个点的环境监测项目应该能明显感受到通讯方式决定了整个项目的施工方式、调试方式、后期排障方式。这篇文章打算把这套东西从原理到实操掰开揉碎讲清楚适合做工业自动化集成、数据中心动环、洁净车间、仓库冷链、实验室监控的工程师看看。1. 温湿度传感器通讯方案的底层差异为什么不用RS485和4-20mA1.1 从DHT11到工业级网络传感器差的不是“准不准”很多刚入行的朋友一听到温湿度传感器脑子里跳出来的是Arduino套件里那种DHT11。DHT11确实便宜几块钱一颗数据手册里写着精度“±5%RH、±2℃”实际用过的都知道这玩意只能算“有信号”不能算“测量”。而且它走的是单总线协议只能由单片机直接读没法长距离接也没法组网实验课玩玩可以放到工业现场完全站不住脚。工业项目里用的网络温湿度传感器本体通常是一个带壁挂或管道安装外壳的探头里面是进口的数字温湿度芯片比如SHT30、SHT40这类加上一个带网络协议栈的处理器。注意现在很多低成本以太网传感器用的协议栈芯片是W5500这类硬件方案原理就是MCU通过SPI把数据丢给W5500由这块芯片自动完成TCP/IP报文封装MCU只需要解析业务帧就够了。这样做的好处是方案成熟、成本低、稳定不用自己啃协议栈底层的细节。所以网络传感器和DHT11的差距不在于“哪家测得更准”而在于它自带完整的网络通讯能力插一根网线就能接入现有的以太网络被上位机、组态软件、云平台直接访问。顺便说一句现在以太网技术本身已经发展到25G、40G车载以太网也在汽车行业大量上车甚至还有专门做FPGA三速以太网、PHY测试的玩家。但工业温湿度监测这种低频小数据量场景根本不需要跑满带宽我们需要的是以太网带来的组网能力和标准化传输机制这件事普通百兆交换机就完全够用。1.2 RS485轮询模式在大型系统中的瓶颈传统RS485方案在工业现场确实皮实两线差分信号抗干扰能力强一两百米距离轻轻松松。它的问题是半双工、主从轮询。什么意思RS485总线上挂的所有设备都是“哑巴”只能等主站点名主站问一句设备答一句谁抢话谁出错。当现场传感器数量少比如十几台以内轮询一遍的周期还能接受一旦点数到了三五十个轮询周期就非常难受。我算过一笔账假设每台设备响应需要50毫秒这是比较理想的Modbus RTU响应时间再加上主站等待时间、总线上半双工切换的间隔一台一台轮询50台设备一轮下来就是2.5秒以上。要是其中某台设备响应慢甚至超时整个周期还会被拉得更长。对于监控大屏上“每5秒刷新一次”的需求勉强能跑但要是系统里同时还有几百个点位、几十类不同协议设备调试起来真的会崩溃。RS485还有一个很现实的问题布线必须手拉手菊花链也就是从主机出来一根线串到设备1再从设备1串到设备2不能随便分叉。现场施工的时候设备分布往往不在一条直线上绕来绕去的线非常难看而且任何一个中间节点断线它后面所有设备全部失联。这种“串联”的物理结构天然没有以太网星型网络舒服。1.3 TCP和UDP为什么工业现场几乎只看TCP要么不联网一旦走IP网络就得在TCP和UDP之间做选择。UDP的优点是开销小、速度快发出去不管没有确认和重传机制。但这种“发出去不管”的脾气放在温湿度监控上是不行的。想象一下机房温度已经30℃了高温告警数据在网络上丢了一个包监控中心完全不知道这是不可接受的。TCP协议有三次握手、确认应答、超时重传、滑动窗口这些机制。我把TCP理解成快递签收寄出后必须有人签收没签收就重新送。对传感器来说报文从设备到上位机、从上位机到设备都能确认“对方收到了”数据可靠性有明确保证。代价是TCP协议栈开销比UDP大吞吐量有所下降但对温湿度这么小的数据量来说完全可以忽略。所以工业现场的传感器通讯几乎九成以上都在用TCP而不是UDP。这也是为什么标题里专门强调“TCP协议以太网温湿度传感器”根子上要的就是这份可靠。2. 工业项目选TCP以太网传感器的四个决定性理由2.1 布线灵活现场施工省一大截前面提到RS485要手拉手4-20mA模拟量更是“一个信号一对线”。一个4-20mA温湿度传感器如果同时输出温度和湿度两个信号要么用两线制变送器接两台采样设备要么用一个多通道采集模块反正线材和接线端子都不少。上了规模之后系统柜里的接线端子排密密麻麻查故障时拿万用表一根根对线能把人逼疯。以太网方案就简单了。传感器是RJ45接口直接插到交换机上整个网络是星型结构想在哪里加设备拉一根网线到最近的交换机端口即可。用工业交换机做汇聚一根光纤或者一根千兆主干线就能把几十台设备的数据带回中控室。现场施工的人最喜欢这种方案因为不用算总线的距离、不用画复杂的极性图也不会因为“这条总线最后一个设备的终端电阻忘了拨”导致整条链路通信异常。而且现在不少网络温湿度传感器支持PoE供电也就是一根网线同时传数据和供电传感器不需要再拉一根220V或24V电源线这对吊顶里、夹层里的安装场景来说省掉的施工成本非常可观。2.2 数据不占PLC资源直接对系统软件以前很多环境监控点位是挂在PLC的AI模块或者串口模块上的一个温度点占一个模拟量通道组态的时候还得在PLC里做工程量转换、滤波、越限判断。一旦点位多了PLC的程序越来越臃肿扫描周期被拉长而且扩展AI模块的成本并不低。TCP以太网传感器走的是另一条路它直接对上位机、组态软件、数据库、云平台对话完全绕开PLC。传感器的数据通过网络传递给监控软件软件自己完成解析、存储、报警需要对第三方系统联动时再由上位机决定是否下发给PLC执行。这样PLC只管现场逻辑控制环境监测自成一套独立系统两边互不干扰检修也不会影响生产逻辑。对系统集成商来说这套架构还有个大好处可交付性强。客户需要的不光是能在现场触摸屏上看几个数还要有数据报表、历史曲线、短信或者微信报警。这些功能以太网传感器直接对接软件平台就能实现比从PLC里一点一点抠数据再存数据库效率高太多了。2.3 多客户端并发调试、数采、上云可以同时做这是TCP方案一个很隐蔽但极其好用的优点。RS485是一主多从整个总线只能有一个主站调试电脑把总线占住之后HMI和监控平台都只能靠边站。而TCP协议天然支持多客户端连接同一个服务器端口的场景——只要传感器作为TCP Server端它就可以同时被多个Client连接访问。实际项目里我经常这么干一台传感器还在现场调试上位机软件连着一个连接、笔记本电脑开着Socket调试工具又连一个、HMI触摸屏也来读数据三个客户端同时连着互不影响随时可以“挤进去看一眼”当前的数据。这种并发访问能力对调试和排障的价值是实打实的。另外现在很多项目要做“边缘采集云上展示”传感器数据通过本地上位机采集后再转发到云平台或者园区物联网平台。如果传感器支持Modbus TCP中间还能加网关把Modbus TCP转成MQTT等协议上云。有以太网口意味着你有无数种后续玩法不会被物理总线限制死。2.4 有线网络比无线更稳温湿度也不怕干扰有人会问现在无线传感器那么多LoRa、NB-IoT、WiFi都有为什么还要拉网线。我的看法是看场景。温湿度传感器在车间、仓库、机房、实验室里用量很大很多点位就在头顶上、墙面、空调出风口附近这些地方布一根超五类网线难度并不大。有线以太网的稳定性和可靠性在工业环境里依然是最高的。无线方案主要的坑在于频段拥挤和穿透衰减。工厂里2.4GHz频段里蓝牙、WiFi、无线键鼠、微波炉都在挤信号干扰难以避免现场有很多金属设备、钢板隔断无线信号穿墙之后强度掉得很厉害数据总是时断时续巡检的人跑断腿也找不出原因。ZigBee、LoRa这类低速无线虽然功耗低、穿墙好一些但还是需要额外的网关设备把无线转成以太网系统多了一层维护量也就上来了。另外温湿度探头本身是个低频缓变信号我们真正需要的不是“无线”这种自由而是“稳定不丢数”。所以在相对固定、有网线条件的环境里我几乎都会优先考虑有线以太网方案。3. TCP通讯原理、报文解析与Wireshark验证3.1 先理解Server和Client模式再接线拿到一个TCP以太网温湿度传感器第一件事不是急着接线而是确认它工作在什么模式。市面上的传感器一般有两种工作方式第一种是TCP Server模式也就是传感器在网络上监听一个固定的端口比如8000、5000之类的。上位机、组态软件、调试工具作为TCP Client主动去连接它。这个模式最常用因为服务器端的IP和端口是固定的客户端随时可以发起连接调试方便多客户端并发也容易实现。第二种是TCP Client模式传感器主动向指定IP和端口发起连接。这种模式适合传感器主动上报数据比如定时往监控平台推送温度平台不需要去遍历所有设备。但要注意这种模式下如果平台还没启动传感器可能一直连接不上需要配置重连间隔。我建议采购之前一定问清楚传感器支不支持“同时作为TCP Server并且允许多个Client连接”有些便宜货只能支持一个客户端调试时自己电脑一连触摸屏就断了很被动。还有一点尽量选支持静态IP的传感器不要用DHCP自动获取IP。原因很简单现场交换机未必有DHCP服务器就算有断电重启后IP可能变了上位机找不到设备“续订失败”之类的坑我踩过不止一次。静态IP加上自己规划的地址表一劳永逸。3.2 报文解析从hex里把温度和湿度算出来传感器把温湿度数据发给上位机不是直接发“23.5℃”这个字符串而是按厂商协议拼成十六进制报文。不同厂家协议格式千差万别但套路都差不多帧头、地址、功能码、数据长度、数据区、校验位。举个例子某款传感器的查询命令长得像Modbus风格发送读取命令 01 03 00 00 00 02 C4 0B传感器返回响应帧 01 03 04 00 BE 02 21 5A 7B这帧怎么解析01是设备地址03是功能码04是后面数据区的字节数。数据区是四个字节00 BE和02 21。厂家手册会告诉你温度是两个字节的短整型高字节在前低字节在后原始值除以10就是摄氏度。于是温度值是0x00BE转换成十进制是190除以10就是19.0℃。湿度值是0x0221十进制是545除以10就是54.5%RH。千万别小看这一步很多新手在这里翻车。最容易错的是字节序。有的传感器是低字节在前有的高字节在前有的数据排列顺序是“温度在前湿度在后”有的反过来还有的是无符号整数有的用带符号整数表示负温度。不要想当然必须以手册为准。最稳妥的办法是拿一个已知温湿度的环境用Socket调试工具主动读一帧对照手册逐字节分析再写进程序里。比如0xFF38这种高位是1的数据如果按无符号算出来是65336实际可能是带符号的-200也就是-20.0℃这两种处理方式结果天差地别。3.3 Wireshark抓包确认通讯状态报文解析逻辑写好了设备还是“没反应”这时候别瞎猜直接上Wireshark抓包。抓包工具看网络通信就像万用表量电压一样是排障的基本功。Wireshark用法很简单。选择连接传感器的那块网卡抓包前在过滤栏输入类似这样的条件tcp.port 8000 ip.addr 192.168.10.50然后让上位机连接传感器发一次查询命令。回来看抓到的包正常情况下应该先看到三条握手包也就是SYN、SYN-ACK、ACK这代表TCP三次握手成功然后是应用数据包负载长度也就是我们发出去的查询命令接着传感器回一帧响应数据负载长度和返回帧完全一致。Wireshark里可以直接看到数据包里的十六进制字节内容。把“Data”字段展开就能看到传感器返回的一串hex我通常是直接复制出来和自己解析程序的输出结果对一遍。如果发现抓到的数据和理论值对得上程序却解析不对那问题一定出在代码的字节序或数据类型上如果抓包都看不到传感器的回包那就得回头查网络通不通、端口对不对、防火墙有没有拦。4. 与PLC、组态软件对接的几种典型玩法4.1 昆仑通态MCGS走TCP自由协议组态软件是工业项目里最常见的上位机形式其中昆仑通态的MCGS因为成本低、上手快在中小项目里用得非常多。它和TCP以太网传感器对接很多场景靠的不是标准的Modbus驱动而是走“TCP自由协议”。什么是自由协议就是组态软件不预设报文格式允许你用脚本自己组一个HEX字符串发出去再把收到的HEX字符串按字节解析成需要的数值。对传感器厂商来说这是一条很友好的路因为国产传感器常常用自定义的TCP报文未必严格按Modbus标准来。用MCGS对接TCP传感器我的经验是先在PC上用Socket调试助手把报文彻底调通。确认好“发什么命令、回什么数据、回包的哪个字节是温度、哪个字节是湿度”再去组态软件里写脚本。不要在组态里一点一点猜报文格式那样调试效率极低。脚本里做两件事建立连接、定时发送查询命令接收返回数据后把指定字节截出来做进制转换。转换后的工程值存到组态变量里就能显示在画面上、存进历史库了。4.2 威纶通HMI通过以太网接三菱FX5U再顺便读传感器威纶通MT系列触摸屏本身自带以太网口它和三菱FX5U PLC走以太网通讯是典型的自带功能在EasyBuilder Pro软件里选对PLC型号和驱动填上PLC的IP地址就行用的是三菱的MC协议。如果不清楚怎么配最简单的方法是先给PLC和HMI配同一个网段的IP然后在HMI的系统参数里新建三菱FX5U以太网设备填IP和端口号正常情况下连接状态会变成正常。有意思的是HMI除了能和PLC通讯它的宏指令里一般也支持Socket操作。也就是说我们可以把HMI当作一个TCP客户端同时去连接网络温湿度传感器读取数据后再写入HMI的LW内部寄存器显示在画面上。这样一台触摸屏就同时扮演了两个角色PLC的人机界面、环境监测的上位机。这种玩法很实用因为很多小型设备客户的预算有限不想单独上一台工控机和组态软件。动动HMI的宏指令就能给设备加上温湿度显示和报警功能交付效果比在PLC程序里读模拟量再送HMI显示要清爽得多。当然宏指令Socket编程对现场工程师来说有一定门槛但如果只是想读取数据思路其实很简单连接、发查询命令、延时等待、接收数据、解析字节。做好数据重连机制掉线自动重连。4.3 博图S7-1500用TSEND_C太慢、总是BUSY先搞清楚非阻塞再聊一个PLC和TCP通讯的高频问题。有些项目把网络温湿度传感器当成一个小服务器让S7-1500通过TSEND_C把采集到的数据主动发送到服务器端。不少人在博图里这样写过然后发现TSEND_C调用起来感觉很迟钝连续发数据的时候BUSY总是TRUE数据发不出去网上搜“TSEND_C发送数据太慢”能搜到一堆抱怨。问题的根子在于TSEND_C是非阻塞指令。意思是调用它只是“交出发送请求”真正的数据发送过程在后台执行可能跨多个PLC扫描周期。如果你在每个扫描周期里都把REQ输入置为TRUE或者用同一个背景DB连续触发多次发送任务那么上一次任务没有完成之前新任务根本无法启动BUSY就一直在TRUE给人一种“卡死”的错觉。正确做法是给REQ加一个上升沿脉冲触发发送完成后再复位。用结构化控制语言写出来大致是这样// 简化示意上升沿触发TSEND_C sendPulse : (startSend AND NOT prevStartSend); prevStartSend : startSend; IF sendPulse THEN TSEND_C_DB.REQ : TRUE; END_IF; IF TSEND_C_DB.DONE OR TSEND_C_DB.ERROR THEN TSEND_C_DB.REQ : FALSE; END_IF;关键就一句话同一个TSEND_C实例前一个发送作业没结束绝对不发起下一个。如果你有大量数据要连续发送正确做法是建立发送缓冲区一次只发一个数据包等DONE标志出现后再发下一包。新版本的S7-1500其实还有TSEND_C的“并发发送”更优雅的库但老项目里把REQ触发逻辑改正确问题就能解决大半。5. 部署实操IP规划、网络结构与问题排查5.1 给传感器分配IP的几条规则部署网络传感器的第一件事不是接网线而是做一张《现场设备IP地址规划表》。别嫌这步麻烦等设备上了五六十台再回头整理就会发现哪里都像有点问题但哪里都查不清楚。我常用的规划思路是传感器网段统一用一个私网段比如192.168.10.x子网掩码255.255.255.0网关指向现场的核心工业交换机或工业路由器给每一台传感器分配一个唯一的静态IP并且把标签打印出来贴在设备外壳上。标签内容包括IP地址、安装位置、物理点位编号。这个方法成本极低但排障的时候能省下大量时间。不建议给传感器开DHCP除非整网有严格管理的DHCP服务。工业现场很多交换机默认不开DHCP服务设备拿不到地址就一直用默认的厂商IP多台设备同一个IP冲突起来通讯就是一锅粥。有时候Windows更新之后电脑网卡的IP被重置成自动获取了调试工具就连不上设备了查一下网卡的IP配置就能发现原因。在虚拟机里跑上位机也一样VMware之类的虚拟机如果没设置桥接模式虚拟网卡跟物理网卡之间等于没通上位机自然找不到传感器。5.2 工业交换机选型和网络拓扑以太网传感器的性能上限很低一个点位每秒可能才几百个字节用百兆交换机绰绰有余。但工业场景不能只盯着带宽环境适应性更关键。商业交换机在车间里粉尘、温度、震动都可能引发端口闪断和死机工业交换机的好处是宽温、导轨安装、无风扇设计还存在断电重启快速恢复的能力有些还支持环网冗余协议比如ERPS、STP/RSTP。如果项目点位很多我习惯分层做现场用24口的工业以太网交换机做接入层传感器全部汇聚到接入交换机接入层向上用千兆光纤或者六类网线接到中心机房的核心交换机核心交换机再连接监控服务器、工程师站、数据中心动环监控平台。这样做的好处是某台接入交换机故障只影响它下面的一小块区域而且整个网络拓扑清晰排障范围能快速收缩。网络拓扑上还要注意VLAN划分。环境监测设备和管理办公网混在同一个二层网段里一旦办公网有人发广播风暴或者有病毒传播传感器通讯也可能被波及。条件允许的话把环境监测网单独划一个VLAN通过三层交换机或路由与办公网隔离传感器端口不做DHCP、不响应广播安全性会好很多。5.3 常见问题速查表这些是我在项目现场反复遇到的坑整理成一张速查表给兄弟们参考现象可能原因排查方法上位机软件连不上传感器IP不在同一网段、端口错误、网线没插好先ping传感器IP能通再检查端口不通查网线和IP能ping通但TCP连接失败传感器工作在TCP Client模式上位机没监听对应端口查看传感器配置改为Server模式或配置好平台监听端口数据连接OK但读到的值明显错误字节序不对、数据格式选错、数据区偏移算错用Wireshark抓包对照手册逐字节核对同一个命令发出去偶尔有回包偶尔没有上位机同时连接多个传感器导致Socket资源不够检查并发连接限制改用轮询方式逐个采集传感器每隔一段时间自己掉线交换机端口协商异常、网线衰减、PoE供电不稳定检查交换机日志更换网线/端口排除供电波动组态软件读到的温度和手持仪表相差很大传感器探头位置不好、存在热源干扰或校准偏移检查探头安装位置必要时做现场校准Windows系统更新后调试工具连不上设备网卡被重置或防火墙拦截了TCP端口检查网卡IP配置、在防火墙中放行对应端口和程序虚拟机里的上位机找不到设备虚拟网卡没有桥接、宿主机有多块物理网卡设置为桥接模式并指定正确的物理网卡关闭宿主机防火墙TSEND_C发送经常BUSY同一个FB实例的REQ触发太频繁上升沿触发DONE/ERROR后再发起下一包还有一个容易忽略的细节传感器的电源。很多以太网温湿度传感器是12V或24V直流供电有些还支持PoE。如果采用本地直流供电建议用带隔离的DC-DC电源避免现场大功率设备启停时把电源拉偏。数据跳变、偶发断线这类问题查到最后常常是供电质量问题而不是网络问题。这个习惯我保持了好多年帮我在项目现场少跑了很多冤枉路。6. 最后一些小经验做环境监测这些年我最大的体会是TCP以太网温湿度传感器真正解决的问题不是“度数准”而是“数据通”。只用一台仪表看现场温湿度用什么通讯方式都无所谓一旦系统超过几十个点、要上组态、要接云平台、要远程报警TCP方案的优势就会全面显现出来。另外还有个小技巧采购网络传感器的时候不要只看参数表上写着“以太网接口”一定要问清楚支持的是“标准Modbus TCP协议”还是“自定义TCP协议”。标准Modbus TCP意味着可以用组态软件现成的驱动直接对接开发量很小自定义TCP协议则需要写脚本解析对接成本就上去了。很多传感器明明硬件能力很强但因为协议不够“通用”导致现场集成非常吃力。这是我踩过坑以后才明白的写在这里给后面的人提个醒。 TCP以太网温湿度传感器：原理、优势与工程应用详解
前阵子一个做机房动环的朋友问我现场原来一直用RS485加Modbus RTU的温湿度传感器为什么新出的项目图纸里全换成了带TCP以太网接口的型号价格还贵一截。这个问题我琢磨了很久也踩过不少坑今天就专门聊聊TCP协议以太网温湿度传感器以及它为什么在工业项目里越来越常见。先说个结论这类传感器测的还是温度、湿度传感器本身并没有多神秘真正的分水岭在“数据怎么从现场传到系统里”。如果你搞过几个几十个点的环境监测项目应该能明显感受到通讯方式决定了整个项目的施工方式、调试方式、后期排障方式。这篇文章打算把这套东西从原理到实操掰开揉碎讲清楚适合做工业自动化集成、数据中心动环、洁净车间、仓库冷链、实验室监控的工程师看看。1. 温湿度传感器通讯方案的底层差异为什么不用RS485和4-20mA1.1 从DHT11到工业级网络传感器差的不是“准不准”很多刚入行的朋友一听到温湿度传感器脑子里跳出来的是Arduino套件里那种DHT11。DHT11确实便宜几块钱一颗数据手册里写着精度“±5%RH、±2℃”实际用过的都知道这玩意只能算“有信号”不能算“测量”。而且它走的是单总线协议只能由单片机直接读没法长距离接也没法组网实验课玩玩可以放到工业现场完全站不住脚。工业项目里用的网络温湿度传感器本体通常是一个带壁挂或管道安装外壳的探头里面是进口的数字温湿度芯片比如SHT30、SHT40这类加上一个带网络协议栈的处理器。注意现在很多低成本以太网传感器用的协议栈芯片是W5500这类硬件方案原理就是MCU通过SPI把数据丢给W5500由这块芯片自动完成TCP/IP报文封装MCU只需要解析业务帧就够了。这样做的好处是方案成熟、成本低、稳定不用自己啃协议栈底层的细节。所以网络传感器和DHT11的差距不在于“哪家测得更准”而在于它自带完整的网络通讯能力插一根网线就能接入现有的以太网络被上位机、组态软件、云平台直接访问。顺便说一句现在以太网技术本身已经发展到25G、40G车载以太网也在汽车行业大量上车甚至还有专门做FPGA三速以太网、PHY测试的玩家。但工业温湿度监测这种低频小数据量场景根本不需要跑满带宽我们需要的是以太网带来的组网能力和标准化传输机制这件事普通百兆交换机就完全够用。1.2 RS485轮询模式在大型系统中的瓶颈传统RS485方案在工业现场确实皮实两线差分信号抗干扰能力强一两百米距离轻轻松松。它的问题是半双工、主从轮询。什么意思RS485总线上挂的所有设备都是“哑巴”只能等主站点名主站问一句设备答一句谁抢话谁出错。当现场传感器数量少比如十几台以内轮询一遍的周期还能接受一旦点数到了三五十个轮询周期就非常难受。我算过一笔账假设每台设备响应需要50毫秒这是比较理想的Modbus RTU响应时间再加上主站等待时间、总线上半双工切换的间隔一台一台轮询50台设备一轮下来就是2.5秒以上。要是其中某台设备响应慢甚至超时整个周期还会被拉得更长。对于监控大屏上“每5秒刷新一次”的需求勉强能跑但要是系统里同时还有几百个点位、几十类不同协议设备调试起来真的会崩溃。RS485还有一个很现实的问题布线必须手拉手菊花链也就是从主机出来一根线串到设备1再从设备1串到设备2不能随便分叉。现场施工的时候设备分布往往不在一条直线上绕来绕去的线非常难看而且任何一个中间节点断线它后面所有设备全部失联。这种“串联”的物理结构天然没有以太网星型网络舒服。1.3 TCP和UDP为什么工业现场几乎只看TCP要么不联网一旦走IP网络就得在TCP和UDP之间做选择。UDP的优点是开销小、速度快发出去不管没有确认和重传机制。但这种“发出去不管”的脾气放在温湿度监控上是不行的。想象一下机房温度已经30℃了高温告警数据在网络上丢了一个包监控中心完全不知道这是不可接受的。TCP协议有三次握手、确认应答、超时重传、滑动窗口这些机制。我把TCP理解成快递签收寄出后必须有人签收没签收就重新送。对传感器来说报文从设备到上位机、从上位机到设备都能确认“对方收到了”数据可靠性有明确保证。代价是TCP协议栈开销比UDP大吞吐量有所下降但对温湿度这么小的数据量来说完全可以忽略。所以工业现场的传感器通讯几乎九成以上都在用TCP而不是UDP。这也是为什么标题里专门强调“TCP协议以太网温湿度传感器”根子上要的就是这份可靠。2. 工业项目选TCP以太网传感器的四个决定性理由2.1 布线灵活现场施工省一大截前面提到RS485要手拉手4-20mA模拟量更是“一个信号一对线”。一个4-20mA温湿度传感器如果同时输出温度和湿度两个信号要么用两线制变送器接两台采样设备要么用一个多通道采集模块反正线材和接线端子都不少。上了规模之后系统柜里的接线端子排密密麻麻查故障时拿万用表一根根对线能把人逼疯。以太网方案就简单了。传感器是RJ45接口直接插到交换机上整个网络是星型结构想在哪里加设备拉一根网线到最近的交换机端口即可。用工业交换机做汇聚一根光纤或者一根千兆主干线就能把几十台设备的数据带回中控室。现场施工的人最喜欢这种方案因为不用算总线的距离、不用画复杂的极性图也不会因为“这条总线最后一个设备的终端电阻忘了拨”导致整条链路通信异常。而且现在不少网络温湿度传感器支持PoE供电也就是一根网线同时传数据和供电传感器不需要再拉一根220V或24V电源线这对吊顶里、夹层里的安装场景来说省掉的施工成本非常可观。2.2 数据不占PLC资源直接对系统软件以前很多环境监控点位是挂在PLC的AI模块或者串口模块上的一个温度点占一个模拟量通道组态的时候还得在PLC里做工程量转换、滤波、越限判断。一旦点位多了PLC的程序越来越臃肿扫描周期被拉长而且扩展AI模块的成本并不低。TCP以太网传感器走的是另一条路它直接对上位机、组态软件、数据库、云平台对话完全绕开PLC。传感器的数据通过网络传递给监控软件软件自己完成解析、存储、报警需要对第三方系统联动时再由上位机决定是否下发给PLC执行。这样PLC只管现场逻辑控制环境监测自成一套独立系统两边互不干扰检修也不会影响生产逻辑。对系统集成商来说这套架构还有个大好处可交付性强。客户需要的不光是能在现场触摸屏上看几个数还要有数据报表、历史曲线、短信或者微信报警。这些功能以太网传感器直接对接软件平台就能实现比从PLC里一点一点抠数据再存数据库效率高太多了。2.3 多客户端并发调试、数采、上云可以同时做这是TCP方案一个很隐蔽但极其好用的优点。RS485是一主多从整个总线只能有一个主站调试电脑把总线占住之后HMI和监控平台都只能靠边站。而TCP协议天然支持多客户端连接同一个服务器端口的场景——只要传感器作为TCP Server端它就可以同时被多个Client连接访问。实际项目里我经常这么干一台传感器还在现场调试上位机软件连着一个连接、笔记本电脑开着Socket调试工具又连一个、HMI触摸屏也来读数据三个客户端同时连着互不影响随时可以“挤进去看一眼”当前的数据。这种并发访问能力对调试和排障的价值是实打实的。另外现在很多项目要做“边缘采集云上展示”传感器数据通过本地上位机采集后再转发到云平台或者园区物联网平台。如果传感器支持Modbus TCP中间还能加网关把Modbus TCP转成MQTT等协议上云。有以太网口意味着你有无数种后续玩法不会被物理总线限制死。2.4 有线网络比无线更稳温湿度也不怕干扰有人会问现在无线传感器那么多LoRa、NB-IoT、WiFi都有为什么还要拉网线。我的看法是看场景。温湿度传感器在车间、仓库、机房、实验室里用量很大很多点位就在头顶上、墙面、空调出风口附近这些地方布一根超五类网线难度并不大。有线以太网的稳定性和可靠性在工业环境里依然是最高的。无线方案主要的坑在于频段拥挤和穿透衰减。工厂里2.4GHz频段里蓝牙、WiFi、无线键鼠、微波炉都在挤信号干扰难以避免现场有很多金属设备、钢板隔断无线信号穿墙之后强度掉得很厉害数据总是时断时续巡检的人跑断腿也找不出原因。ZigBee、LoRa这类低速无线虽然功耗低、穿墙好一些但还是需要额外的网关设备把无线转成以太网系统多了一层维护量也就上来了。另外温湿度探头本身是个低频缓变信号我们真正需要的不是“无线”这种自由而是“稳定不丢数”。所以在相对固定、有网线条件的环境里我几乎都会优先考虑有线以太网方案。3. TCP通讯原理、报文解析与Wireshark验证3.1 先理解Server和Client模式再接线拿到一个TCP以太网温湿度传感器第一件事不是急着接线而是确认它工作在什么模式。市面上的传感器一般有两种工作方式第一种是TCP Server模式也就是传感器在网络上监听一个固定的端口比如8000、5000之类的。上位机、组态软件、调试工具作为TCP Client主动去连接它。这个模式最常用因为服务器端的IP和端口是固定的客户端随时可以发起连接调试方便多客户端并发也容易实现。第二种是TCP Client模式传感器主动向指定IP和端口发起连接。这种模式适合传感器主动上报数据比如定时往监控平台推送温度平台不需要去遍历所有设备。但要注意这种模式下如果平台还没启动传感器可能一直连接不上需要配置重连间隔。我建议采购之前一定问清楚传感器支不支持“同时作为TCP Server并且允许多个Client连接”有些便宜货只能支持一个客户端调试时自己电脑一连触摸屏就断了很被动。还有一点尽量选支持静态IP的传感器不要用DHCP自动获取IP。原因很简单现场交换机未必有DHCP服务器就算有断电重启后IP可能变了上位机找不到设备“续订失败”之类的坑我踩过不止一次。静态IP加上自己规划的地址表一劳永逸。3.2 报文解析从hex里把温度和湿度算出来传感器把温湿度数据发给上位机不是直接发“23.5℃”这个字符串而是按厂商协议拼成十六进制报文。不同厂家协议格式千差万别但套路都差不多帧头、地址、功能码、数据长度、数据区、校验位。举个例子某款传感器的查询命令长得像Modbus风格发送读取命令 01 03 00 00 00 02 C4 0B传感器返回响应帧 01 03 04 00 BE 02 21 5A 7B这帧怎么解析01是设备地址03是功能码04是后面数据区的字节数。数据区是四个字节00 BE和02 21。厂家手册会告诉你温度是两个字节的短整型高字节在前低字节在后原始值除以10就是摄氏度。于是温度值是0x00BE转换成十进制是190除以10就是19.0℃。湿度值是0x0221十进制是545除以10就是54.5%RH。千万别小看这一步很多新手在这里翻车。最容易错的是字节序。有的传感器是低字节在前有的高字节在前有的数据排列顺序是“温度在前湿度在后”有的反过来还有的是无符号整数有的用带符号整数表示负温度。不要想当然必须以手册为准。最稳妥的办法是拿一个已知温湿度的环境用Socket调试工具主动读一帧对照手册逐字节分析再写进程序里。比如0xFF38这种高位是1的数据如果按无符号算出来是65336实际可能是带符号的-200也就是-20.0℃这两种处理方式结果天差地别。3.3 Wireshark抓包确认通讯状态报文解析逻辑写好了设备还是“没反应”这时候别瞎猜直接上Wireshark抓包。抓包工具看网络通信就像万用表量电压一样是排障的基本功。Wireshark用法很简单。选择连接传感器的那块网卡抓包前在过滤栏输入类似这样的条件tcp.port 8000 ip.addr 192.168.10.50然后让上位机连接传感器发一次查询命令。回来看抓到的包正常情况下应该先看到三条握手包也就是SYN、SYN-ACK、ACK这代表TCP三次握手成功然后是应用数据包负载长度也就是我们发出去的查询命令接着传感器回一帧响应数据负载长度和返回帧完全一致。Wireshark里可以直接看到数据包里的十六进制字节内容。把“Data”字段展开就能看到传感器返回的一串hex我通常是直接复制出来和自己解析程序的输出结果对一遍。如果发现抓到的数据和理论值对得上程序却解析不对那问题一定出在代码的字节序或数据类型上如果抓包都看不到传感器的回包那就得回头查网络通不通、端口对不对、防火墙有没有拦。4. 与PLC、组态软件对接的几种典型玩法4.1 昆仑通态MCGS走TCP自由协议组态软件是工业项目里最常见的上位机形式其中昆仑通态的MCGS因为成本低、上手快在中小项目里用得非常多。它和TCP以太网传感器对接很多场景靠的不是标准的Modbus驱动而是走“TCP自由协议”。什么是自由协议就是组态软件不预设报文格式允许你用脚本自己组一个HEX字符串发出去再把收到的HEX字符串按字节解析成需要的数值。对传感器厂商来说这是一条很友好的路因为国产传感器常常用自定义的TCP报文未必严格按Modbus标准来。用MCGS对接TCP传感器我的经验是先在PC上用Socket调试助手把报文彻底调通。确认好“发什么命令、回什么数据、回包的哪个字节是温度、哪个字节是湿度”再去组态软件里写脚本。不要在组态里一点一点猜报文格式那样调试效率极低。脚本里做两件事建立连接、定时发送查询命令接收返回数据后把指定字节截出来做进制转换。转换后的工程值存到组态变量里就能显示在画面上、存进历史库了。4.2 威纶通HMI通过以太网接三菱FX5U再顺便读传感器威纶通MT系列触摸屏本身自带以太网口它和三菱FX5U PLC走以太网通讯是典型的自带功能在EasyBuilder Pro软件里选对PLC型号和驱动填上PLC的IP地址就行用的是三菱的MC协议。如果不清楚怎么配最简单的方法是先给PLC和HMI配同一个网段的IP然后在HMI的系统参数里新建三菱FX5U以太网设备填IP和端口号正常情况下连接状态会变成正常。有意思的是HMI除了能和PLC通讯它的宏指令里一般也支持Socket操作。也就是说我们可以把HMI当作一个TCP客户端同时去连接网络温湿度传感器读取数据后再写入HMI的LW内部寄存器显示在画面上。这样一台触摸屏就同时扮演了两个角色PLC的人机界面、环境监测的上位机。这种玩法很实用因为很多小型设备客户的预算有限不想单独上一台工控机和组态软件。动动HMI的宏指令就能给设备加上温湿度显示和报警功能交付效果比在PLC程序里读模拟量再送HMI显示要清爽得多。当然宏指令Socket编程对现场工程师来说有一定门槛但如果只是想读取数据思路其实很简单连接、发查询命令、延时等待、接收数据、解析字节。做好数据重连机制掉线自动重连。4.3 博图S7-1500用TSEND_C太慢、总是BUSY先搞清楚非阻塞再聊一个PLC和TCP通讯的高频问题。有些项目把网络温湿度传感器当成一个小服务器让S7-1500通过TSEND_C把采集到的数据主动发送到服务器端。不少人在博图里这样写过然后发现TSEND_C调用起来感觉很迟钝连续发数据的时候BUSY总是TRUE数据发不出去网上搜“TSEND_C发送数据太慢”能搜到一堆抱怨。问题的根子在于TSEND_C是非阻塞指令。意思是调用它只是“交出发送请求”真正的数据发送过程在后台执行可能跨多个PLC扫描周期。如果你在每个扫描周期里都把REQ输入置为TRUE或者用同一个背景DB连续触发多次发送任务那么上一次任务没有完成之前新任务根本无法启动BUSY就一直在TRUE给人一种“卡死”的错觉。正确做法是给REQ加一个上升沿脉冲触发发送完成后再复位。用结构化控制语言写出来大致是这样// 简化示意上升沿触发TSEND_C sendPulse : (startSend AND NOT prevStartSend); prevStartSend : startSend; IF sendPulse THEN TSEND_C_DB.REQ : TRUE; END_IF; IF TSEND_C_DB.DONE OR TSEND_C_DB.ERROR THEN TSEND_C_DB.REQ : FALSE; END_IF;关键就一句话同一个TSEND_C实例前一个发送作业没结束绝对不发起下一个。如果你有大量数据要连续发送正确做法是建立发送缓冲区一次只发一个数据包等DONE标志出现后再发下一包。新版本的S7-1500其实还有TSEND_C的“并发发送”更优雅的库但老项目里把REQ触发逻辑改正确问题就能解决大半。5. 部署实操IP规划、网络结构与问题排查5.1 给传感器分配IP的几条规则部署网络传感器的第一件事不是接网线而是做一张《现场设备IP地址规划表》。别嫌这步麻烦等设备上了五六十台再回头整理就会发现哪里都像有点问题但哪里都查不清楚。我常用的规划思路是传感器网段统一用一个私网段比如192.168.10.x子网掩码255.255.255.0网关指向现场的核心工业交换机或工业路由器给每一台传感器分配一个唯一的静态IP并且把标签打印出来贴在设备外壳上。标签内容包括IP地址、安装位置、物理点位编号。这个方法成本极低但排障的时候能省下大量时间。不建议给传感器开DHCP除非整网有严格管理的DHCP服务。工业现场很多交换机默认不开DHCP服务设备拿不到地址就一直用默认的厂商IP多台设备同一个IP冲突起来通讯就是一锅粥。有时候Windows更新之后电脑网卡的IP被重置成自动获取了调试工具就连不上设备了查一下网卡的IP配置就能发现原因。在虚拟机里跑上位机也一样VMware之类的虚拟机如果没设置桥接模式虚拟网卡跟物理网卡之间等于没通上位机自然找不到传感器。5.2 工业交换机选型和网络拓扑以太网传感器的性能上限很低一个点位每秒可能才几百个字节用百兆交换机绰绰有余。但工业场景不能只盯着带宽环境适应性更关键。商业交换机在车间里粉尘、温度、震动都可能引发端口闪断和死机工业交换机的好处是宽温、导轨安装、无风扇设计还存在断电重启快速恢复的能力有些还支持环网冗余协议比如ERPS、STP/RSTP。如果项目点位很多我习惯分层做现场用24口的工业以太网交换机做接入层传感器全部汇聚到接入交换机接入层向上用千兆光纤或者六类网线接到中心机房的核心交换机核心交换机再连接监控服务器、工程师站、数据中心动环监控平台。这样做的好处是某台接入交换机故障只影响它下面的一小块区域而且整个网络拓扑清晰排障范围能快速收缩。网络拓扑上还要注意VLAN划分。环境监测设备和管理办公网混在同一个二层网段里一旦办公网有人发广播风暴或者有病毒传播传感器通讯也可能被波及。条件允许的话把环境监测网单独划一个VLAN通过三层交换机或路由与办公网隔离传感器端口不做DHCP、不响应广播安全性会好很多。5.3 常见问题速查表这些是我在项目现场反复遇到的坑整理成一张速查表给兄弟们参考现象可能原因排查方法上位机软件连不上传感器IP不在同一网段、端口错误、网线没插好先ping传感器IP能通再检查端口不通查网线和IP能ping通但TCP连接失败传感器工作在TCP Client模式上位机没监听对应端口查看传感器配置改为Server模式或配置好平台监听端口数据连接OK但读到的值明显错误字节序不对、数据格式选错、数据区偏移算错用Wireshark抓包对照手册逐字节核对同一个命令发出去偶尔有回包偶尔没有上位机同时连接多个传感器导致Socket资源不够检查并发连接限制改用轮询方式逐个采集传感器每隔一段时间自己掉线交换机端口协商异常、网线衰减、PoE供电不稳定检查交换机日志更换网线/端口排除供电波动组态软件读到的温度和手持仪表相差很大传感器探头位置不好、存在热源干扰或校准偏移检查探头安装位置必要时做现场校准Windows系统更新后调试工具连不上设备网卡被重置或防火墙拦截了TCP端口检查网卡IP配置、在防火墙中放行对应端口和程序虚拟机里的上位机找不到设备虚拟网卡没有桥接、宿主机有多块物理网卡设置为桥接模式并指定正确的物理网卡关闭宿主机防火墙TSEND_C发送经常BUSY同一个FB实例的REQ触发太频繁上升沿触发DONE/ERROR后再发起下一包还有一个容易忽略的细节传感器的电源。很多以太网温湿度传感器是12V或24V直流供电有些还支持PoE。如果采用本地直流供电建议用带隔离的DC-DC电源避免现场大功率设备启停时把电源拉偏。数据跳变、偶发断线这类问题查到最后常常是供电质量问题而不是网络问题。这个习惯我保持了好多年帮我在项目现场少跑了很多冤枉路。6. 最后一些小经验做环境监测这些年我最大的体会是TCP以太网温湿度传感器真正解决的问题不是“度数准”而是“数据通”。只用一台仪表看现场温湿度用什么通讯方式都无所谓一旦系统超过几十个点、要上组态、要接云平台、要远程报警TCP方案的优势就会全面显现出来。另外还有个小技巧采购网络传感器的时候不要只看参数表上写着“以太网接口”一定要问清楚支持的是“标准Modbus TCP协议”还是“自定义TCP协议”。标准Modbus TCP意味着可以用组态软件现成的驱动直接对接开发量很小自定义TCP协议则需要写脚本解析对接成本就上去了。很多传感器明明硬件能力很强但因为协议不够“通用”导致现场集成非常吃力。这是我踩过坑以后才明白的写在这里给后面的人提个醒。