简介：三菱FX5U系列PLC与温湿度变送器实现MODBUS RTU通信的编程示例文档，面向工业自动化现场工程师与PLC编程初学者，重点解决FX5U作为主站通过485串口读取温湿度变送器数据的问题。资源为单个docx格式文档，压缩包共1个文件，大小约1018KB，内容图文并茂，便于直接对照操作。文档从温湿度变送器A+、B-通信线连接方式讲起，完整覆盖GX Works3中485串口通信参数配置、波特率与校验方式匹配、主站站号设置等关键步骤；随后介绍FX5U编程指令手册中MBR/MBW等MODBUS指令的用法，并在程序中设定对应寄存器地址，将读取到的温度和湿度分别存入D0、D1寄存器。调试部分给出仿真测试与实际下载验证的思路，可帮助使用者理清通信链路和数据转换逻辑。已有1030人学习下载，适合需要快速上手FX5U与温湿度变送器MODBUS RTU通信的开发、调试与维护人员参考。 做自动化这些年，温湿度采集还真是一个绕不开的活儿。仓库环境监控、机房动环、冷库冷链、洁净车间，甚至养殖大棚，十有八九都要把温度和湿度送回PLC。最省事的做法是直接上模拟量变送器，4-20mA一路信号一根线，简单是简单，可连个三五台就要拉一捆线，而且模拟量在长距离传输时容易受干扰。另一条路就是今天要聊的：用MODBUS RTU通信，一根两芯屏蔽双绞线把所有变送器串起来，PLC当主站挨个问，设备少花钱、线缆少一半、抗干扰还更好。三菱FX5U系列PLC是目前中小型项目里很常见的机型，本体自带RS-485口，不需要额外加通信模块，跟温湿度变送器做MODBUS RTU主从通信非常顺手。这篇就基于我最近做的一个实际案例，把从硬件接线、参数配置到梯形图编程和现场排错的完整过程都过一遍，给正在搞类似项目的朋友一个能直接照抄的参考。
1. 这套方案到底解决什么问题
1.1 温湿度采集场景与方案选型
先说你什么时候会遇到这个需求。我最近接的一个项目是给某工厂的恒温恒湿仓库做环境监控，四个库房、每个库房两台变送器，一共八台，要求温湿度数据实时进PLC，再配合风机和除湿机做联动控制。如果我按老思路每个变送器都走一路4-20mA模拟量，那光信号线就要拉八根，而且模拟量信号进了PLC还得挨个配置通道、做量程换算，后面还想加设备就得重新放线。用MODBUS RTU方案就完全不一样，八台变送器全部并联在同一对RS-485总线上，PLC作为主站按顺序跟每个从站通信，想加设备只要在总线上再接一台、改一下轮询表就行。
这个方案的性价比优势在设备稍微一多的时候就会体现得非常明显。我特意做了个对比：模拟量方案单台变送器一般比RS-485的贵一些，再加上线缆和施工成本，五六台以上基本就是MODBUS RTU完胜了。在信号传输距离上RS-485也有优势，1200米以内的常规距离完全够用。至于抗干扰，差分信号比单端模拟量可靠得多，这在车间里一堆变频器、伺服驱动器同时工作的环境下体现得尤其明显。
| 对比项 | 4-20mA模拟量方案 | MODBUS RTU方案 |
|---|---|---|
| 单台变送器成本 | 较高 | 较低 |
| 线缆数量 | 每台一路信号线 | 一根总线串所有 |
| 传输距离 | 一般百米内可靠 | 最长约1200米 |
| 抗干扰能力 | 一般，长线易漂移 | 差分信号，抗干扰强 |
| 扩展新设备 | 需重新放线 | 总线上并接即可 |
| 数据内容 | 只能传一个物理量 | 可读温度、湿度、露点等 |
1.2 三句话讲清MODBUS RTU协议
很多朋友一听MODBUS就头大，其实它特别简单。你可以把它理解成写信：主站是发信人，每个从站有一个唯一的地址，相当于收件人地址；报文里的功能码相当于“我要干什么”，比如功能码03就是“把你这边的寄存器内容读几份给我”；后面跟着数据部分，比如从哪个寄存器开始、读多少个，最后还有两位CRC校验，相当于信件封口的火漆，防止内容被篡改。从站收到信后会回一封信，如果正常就返回数据，如果指令有误就返回一个异常码。
MODBUS里最常见的对象是寄存器。保持寄存器（对应功能码03、06、16）可读可写，输入寄存器（对应功能码04）只能读。温湿度变送器基本都用保持寄存器存测量值，所以我们读取时用功能码03就够了。报文格式是固定的：从站地址（1字节）＋功能码（1字节）＋数据区＋CRC校验（2字节，低字节在前）。在FX5U上用专用指令做MODBUS主站时，报文和CRC都是PLC自动生成的，你只要告诉它“去几号站、从哪个寄存器、读几个字、读回来放哪”，剩下的事情它全包了。
2. 硬件准备与现场接线
2.1 设备清单
整套方案用到的硬件并不复杂，我按实际项目列了一份清单：
| 设备 | 型号/规格 | 数量 |
|---|---|---|
| PLC | 三菱FX5U-32MT/ES（带内置RS-485口） | 1 |
| 温湿度变送器 | RS-485输出，MODBUS RTU协议，默认地址1 | 8 |
| 电源 | DC 24V开关电源，视变送器功耗选择2A以上 | 1 |
| 通信线 | 两芯双绞屏蔽线（RVSP 2×0.5以上） | 按现场 |
| 终端电阻 | 120Ω | 2 |
选择FX5U的一个重要原因就是它机身自带RS-485端口，GX Works3里会识别为一个串行通信通道。如果手上是FX5U的某些低配型号，或者485口被其他设备占用了，也可以挂一块FX5-485ADP扩展板，用法大同小异。通信线我习惯用RVSP双绞屏蔽线，双绞本身能抑制共模干扰，屏蔽层又能挡住空间辐射干扰，在靠近变频器的线槽里走线时稳定很多。
2.2 FX5U内置485口怎么接
FX5U自带的RS-485端口通常是一个小端子排，丝印上有SDA、SDB、RDA、RDB、SG这几个端子。和两线制温湿度变送器对接时，要用2线接法：把RDA和SDA短接，RDB和SDB短接，然后变送器的A+（有的标D+）接SDA/RDA，变送器的B-（有的标D-）接SDB/RDB，SG是信号地，建议和变送器的GND接在一起，但要注意确认变送器GND和PLC的SG是否允许共地，拿不准时先不接。
接线的顺序和颜色习惯最好全项目统一，我在现场就吃过亏。一开始总线的A、B线没做颜色规范，接了两台以后再去接第三台，另外一个人顺手把颜色接反了，结果那台变送器死活不通，查了半小时。后来我定了个死规矩：所有通信线A相（正极）一律用红色、B相（负极）一律用黑色，并且每台变送器柜内留好端子标识，严格按图纸核对一遍再接。规范一旦定下来，后面维护的人也不会踩雷。
2.3 接线里的坑
第一个坑是A/B接反。RS-485总线看起来简单，就两根线，但很多新手的第一个故障就出在这。接反的典型现象是：单台设备连电脑调试时正常，一旦并上第二台就全部乱套，或者干脆全部超时。解决办法很简单，把任一端的两根线对调一下再测试。
第二个坑是屏蔽层接地。通信电缆的屏蔽层我建议只在PLC这一端单端接地，另一端悬空。如果在两端都接地，反而会因为地电位差在屏蔽层上形成环流，干扰更大。至于变送器那一端，柜内如果没有可靠接地条件，宁可空着也不要乱接。
第三个坑是终端电阻。总线两端各接一个120Ω终端电阻，但前提是总线上设备确实比较多、距离比较长（一般超过50米或挂了5台以上）。小项目几十米内两根线直连，不接终端电阻通常也能正常工作，接上去反而可能让从站信号幅值降低。这个是工程经验，最好根据现场实测波形或者看通信稳定性来决定，不是绝对必须。
3. 摸清变送器底细：寄存器表与报文验证
3.1 读懂说明书寄存器表
拿到一台温湿度变送器，第一件事不是写程序，而是把说明书里的MODBUS寄存器表找出来。我手头这台变送器默认从站地址是1，波特率9600，数据位8位、停止位1位、无校验（也就是8N1），这些参数在背后有一个拨码开关或者通过配置软件可以改。寄存器表大概是这样的：
| MODBUS地址 | 协议地址（十六进制） | 内容 | 数据类型 | 说明 |
|---|---|---|---|---|
| 40001 | 0x0000 | 温度 | INT16 | 实际值=原始值/10，单位℃ |
| 40002 | 0x0001 | 湿度 | INT16 | 实际值=原始值/10，单位%RH |
| 40003 | 0x0002 | 露点 | INT16 | 部分型号才有 |
这里最容易懵的是地址换算。变送器说明书上写的“40001”是MODBUS数据区地址，而协议里真正传输的是“协议地址”，也就是40001对应的0x0000。你在PLC指令里填的寄存器地址是后者，不是前者。很多人在这一步搞混，把40001直接填进去，结果读回来的数据不知道是什么地址上的。记住一个口诀：PLC指令里填的地址 = MODBUS地址 - 40001，也就是40001写0x0000，40002写0x0001。
3.2 用串口助手手动读一次
在写PLC程序之前，我非常建议先用电脑上的串口调试助手把报文跑通。把变送器通过USB转RS-485接到电脑上，选好COM口，波特率9600，8N1，然后手动发送一行十六进制报文：
01 03 00 00 00 02 C4 0B
拆开看：01是从站地址，03是读保持寄存器功能码，00 00是从40001开始的协议地址，00 02是读两个寄存器，C4 0B是CRC16校验。正常情况下变送器会回复一帧，例如：
01 03 04 01 2C 01 F4 xx xx
01是地址，03是功能码，04表示后面有4个字节数据，01 2C是十六进制表示的300，换算回十进制就是300，再除以10等于30.0，也就是温度30.0℃；01 F4换算成500，除以10等于50.0，即湿度50.0%RH；最后两个字节是CRC。这一步能走通，说明变送器本身没问题，CRC算法没问题，通信链路没问题，后面PLC程序调不通时就可以放心往PLC一侧排查。
3.3 为什么强烈建议先验证
这个“先手动验证”的习惯帮我省过很多时间。有一次到现场，我把电脑接上总线，发送读报文后变送器完全没有回复。我第一反应是地址写错了，检查配置软件发现地址已经改成3，而我报文里发的是01。把报文改成03开头后，数据立刻正常返回。如果在现场一开始就直接写PLC程序，这个问题会混在PLC配置、线缆、程序一大堆变量里，排查起来至少要翻倍时间。
手动验证的另一个好处是能快速确认变送器的数据格式。有些变送器温度是放大10倍，有些是放大100倍，有些湿度直接给整数百分比。你在串口助手上看到原始报文，再结合说明书算一遍，就彻底搞清楚该在PLC里怎么处理小数点了。这个环节省下来的时间，绝对比你花掉的时间多得多。
4. GX Works3参数配置与编程实现
4.1 485口参数配置
打开GX Works3新建工程，选择FX5U对应的CPU型号。工程建好后，左侧导航窗口里找到【参数】→【FX5U CPU】→【模块参数】，往下能找到485串口对应的设置项。最关键的几个地方：通信协议那一栏要选择“无协议通信”，别看这里名字叫无协议，三菱的IVRD、IVWR这些MODBUS专用指令恰恰就是在这个模式下工作的，选成“MODBUS RTU主站”反而走的是另一种参数化轮询方式，不能混用；通信格式要和变送器完全一致，我这里设成波特率9600、数据位8、停止位1、无校验。
设置完以后一定记得把参数写入PLC并复位上电，串口参数一般是上电时才生效。我遇到过不止一个朋友，在软件里改完参数后直接切到在线监视就开始写程序，结果通信一直异常，最后才发现PLC还在用默认的旧参数运行。改完串口参数，尤其要注意先“重置”或断电重启一次，这个动作看着不起眼，却能省很多冤枉排查时间。
4.2 用IVRD指令读温湿度
参数配好之后，程序设计就清晰了。我用IVRD指令作为主站读取的核心。IVRD的基本调用方式大致是：源端参数指定从站号和从站寄存器起始地址，目标端参数指定本机存储区起始地址和读取点数。比如要读1号从站的温度（协议地址0x0000）和湿度（0x0001）两个寄存器，存到本机D0开始的两个字里，就是“IVRD K1 H0 D0 K2”这样一条命令的语义，K1代表1号从站，H0代表协议地址0x0000，D0是本机存放区起始，K2是连续读2个字。
在实际梯形图里，我是用一个轮询定时器来做读取触发的。每5秒置位一次通信请求标志M0，M0接通时执行IVRD。执行完成标志（类似M8029这类指令结束标志）导通后，先把D0、D1的数据复制到保持用的寄存器里，再复位M0，等待下一轮触发。这样做的好处是程序不会一直在发报文，给总线上其他潜在从站留出时间，也降低了总线冲突的风险。如果你在同一根总线上还要接触摸屏或者上位机，更要注意错开访问时间。
4.3 数据处理：放大倍数与负数
数据读回来不代表就能直接用。前面说了，变送器返回的温度原始值是放大10倍后的整数，必须除以10才是真正的温度值。实际编程时我会专门开两个寄存器存换算后的数据，比如D10存放温度实际值，D11存放湿度实际值，供HMI显示和联动控制用。换算用标准的二进制除法指令（DIV）就能搞定，除以K10，商和余数分别存下来。
还有一个特别容易被忽略的问题是零下温度的负数。温度变送器在零下时返回的是有符号数的补码形式，比如-12.3℃对应的原始值应是-123，十六进制显示为FF85。如果你在PLC里把这个数据当无符号整数处理，得到的会是65413，除以10后变成6541.3，完全不是那么回事。三菱FX5U的数据寄存器默认按有符号数理解，但涉及十六进制格式转换时还是要格外小心，建议程序里加一个判断：如果原始值大于等于某个上限（比如大于等于32768），就按负数处理，转换为负值后再除以10。在冰冻库、北方冬季室外这种场景下，这个细节能少挨很多骂。
4.4 多台变送器轮询写法
一台变送器读通之后，多台变送器的本质就是一个轮询逻辑。我的做法比较简单直接：用一个计数器记录当前轮询到第几号从站，每轮通信完成后计数器加1，地址按轮询表依次指向1、2、3……，轮完一遍自动回1。每台变送器之间加一个200毫秒左右的延时，给从站足够的响应时间，也避免地址切换太快导致上一帧还没处理完就发下一帧。
轮询流程里我还会加上超时和错误计数的处理。用定时器做超时判断，如果一条指令发出后在规定时间内没有收到完成信号，就认为该从站通信异常，错误计数器加1，然后继续轮询下一台。连续错误次数超过一定值（比如10次）时，把该从站的故障标志位置ON，送到HMI上报警，提示现场人员去检查这台变送器。这种设计在只有一两台设备时看不出价值，等总线挂了二三十个从站，一个站掉线不应该影响其他站正常采集，这个机制就是必须的了。
5. 常见问题与排查实录
5.1 读不到数据先查这四件事
如果程序写完一运行，通信就一直超时，我建议按下面这个顺序排查，这也是我最常用的排查路径。第一件事是查参数是否一致：PLC的波特率、数据位、停止位、校验方式是否跟变送器完全一致，9和9600看着差不多，在总线上就是鸡同鸭讲。第二件事是查站号：变送器拨码开关或者配置软件设的地址，跟程序里IVRD指定的从站号是否一致，尤其是已经改过配置的旧设备，最容易被配置文件里的旧地址骗到。第三件事是查接线：A、B是否接反，变送器是否真的供电正常，通信线有没有断。第四件事是查“最近一次成功”的经验：把这台变送器单独拆下来接到USB转485上，用串口助手手动发一遍读帧，如果手动能通、PLC不行，问题就在PLC侧配置或程序；如果手动都不通，问题就在变送器或线缆。
实际项目里还有一种很容易被忽略的情况：变送器的RS-485通信芯片供电异常。有一些低成本变送器的485收发器电源和传感器电源是分开的，如果只给传感器供了电，没给通信隔离部分供上电，指示灯看着正常，但根本不会响应总线上的请求。这类问题用串口助手一测就暴露了，接上电脑手动发送读帧，没有回复，基本就能锁定在变送器本身。
5.2 数据跳变和偶发通信失败
如果程序能通信，但数据偶尔跳一下，或者时不时读超时一次，这种问题多数不在协议，而在物理层。最常见的元凶是总线长度太长没有终端电阻，或者通信线跟动力电缆走在同一个线槽里，变频器一启动数据就开始乱跳。解决办法是通信线尽量远离动力线，至少保持20厘米以上的距离，无法避免交叉时要垂直交叉通过；总线两端按实际效果考虑加120Ω终端电阻。
还有一种偶发失败的原因和程序触发方式有关。如果我把读取指令放在一个永远接通的常开触点后面，PLC每个扫描周期都会尝试发一帧，就很容易出现请求还没响应完又发一帧的情况，导致通信不稳定。正确做法是用定时器产生一个合理的通信节拍，一帧完成后再发下一帧，特别是多从站轮询场景，这个节拍必须留够裕量。
5.3 排查速查表
| 故障现象 | 可能原因 | 处理建议 |
|---|---|---|
| 完全读不到数据 | 站号错误、A/B接反、参数不一致 | 串口助手手动验证，逐项核对 |
| 第一帧成功后续超时 | 指令触发频繁、从站响应慢 | 增加轮询间隔，确认完成后再发下一帧 |
| 数据乱跳 | 干扰、屏蔽层接地不当 | 远离动力线，屏蔽层单端接地，加终端电阻 |
| 数据为0或明显偏大 | 寄存器地址填错、负数补码未处理 | 确认40001对应0x0000，检查负数转换逻辑 |
| 只有部分从站能通 | 从站地址重复、某台从站掉线 | 逐台单独验证，修复或替换故障从站 |
| CRC错误 | 总线干扰、波特率设置不一致 | 降低波特率，检查线缆质量和接法 |
6. 最后几点实操体会
做完这个项目我最大的感受是，MODBUS RTU通信本身并不难，难的是把物理链路和参数这些基础准备工作做扎实。我在现场见过太多人拿着程序翻来覆去改，最后发现只是A/B两根线接反了。所以不要嫌麻烦，接线、参数核对、串口助手手动验证这三步，每一台新设备都要走一遍，通一次以后记录在项目文档里，后面维护会轻松很多。
另外，数据读回PLC只是第一步，真正让项目有价值的是后面这些数据怎么用。我在这个项目里把温湿度数据接了HMI做实时曲线，还在PLC里写了一个简单的判断逻辑：温度超过设定上限时联动开启排风机，湿度超过上限时联动开启除湿机，等到恢复正常范围再自动停机。这些联动控制完全可以在同样的通信基础上扩展出来，不需要再加任何硬件，这也是当初选MODBUS RTU方案而不是模拟量方案带来的红利之一。
最后分享一个小技巧：调试阶段在总线上挂一个USB转RS-485的“监听器”，用串口助手开着十六进制显示看总线上的报文，既能确认PLC发出的请求帧对不对，也能看到从站返回的数据有没有异常。这就相当于给通信系统装了一个摄像头，现场大部分疑难杂症都能从这个信息里找到突破口。
本文还有配套的精品资源，点击获取
