半个月前调一台设备时碰到一个很有代表性的需求一台三菱FX3U PLC通过RS485总线同时管理两台台达温控器。不仅要读回两个加热区的当前温度还要能在触摸屏上改设定值、监控报警甚至远程触发自整定。这套玩法就是典型的Modbus RTU主从通信FX3U当主站两台台达温控器分设两个从站地址PLC按步骤轮流跟它们交换数据。搞过温控的人都知道温控器单独控温没问题可一旦要把温度往上送、要在屏幕上改SV、要做超温联锁没有通信就是在跟面板较劲。这篇文章就把我踩过的坑、配通的经验和调试思路完整写出来适合小设备改造、初学PLC通信的人参考。1. 一拖二到底在解决什么问题1.1 温控器自己活得好好的为什么非要PLC来拖台达温控器本身就是闭环控制器热电偶输入、PID运算、加热输出全部自己完成还带自整定。看起来在回路内部什么都不缺。但它的短板也很明显所有数据都停留在面板上想改设定温度必须有人走到柜子前按按键。两条加热回路就是两台独立温控器操作员每隔半小时去抄一次PV值还要手工比对有没有超温这种做法既落后又容易出错。FX3U插进来不是抢温控器的PID饭碗。温控器继续负责闭环控温PLC只做两件事把面板上的数据搬进PLC内部再把上位机设定值写进温控器。加热控制逻辑还是温控器自己做温度输入、输出回路一切照旧。这种分工在工业现场是最稳的因为温控器在PID调节和自整定方面的成熟度远不是PLC里自己写一段PID能比的。1.2 只有两台温控器上DCS就太浪费了以前遇到这类需求很多人第一反应是上成套的温控采集方案几十条回路的设备这样干合理。但现场往往只有两台温控器最多再加一台备机为这两三台设备单独上系统成本高、柜内空间也紧张。FX3U加一块485扩展板成本低得可以忽略接线也简单。“一拖二”的本质就是让PLC用一套串口资源去管理多台温控器靠从站地址区分设备。PLC和温控器之间是典型的主从关系PLC主动问温控器被动答。两台温控器不会同时收到请求谁应答、谁沉默完全由PLC的轮询逻辑决定。理解了这一层后面写程序就有方向了。1.3 一拖二和一拖N的区别只在于轮询表长短很多初学者担心“一拖二”是不是有特殊指令其实没有。通信机制跟一拖四、一拖八完全一样就是把多台从站设备挂到同一条RS485总线上PLC按顺序一个个问。站号是1就应答1号站号是2就应答2号。唯一的区别是设备多了以后PLC要处理的步骤多了轮询周期变长数据区要重新规划。所以这篇东西写的是“一拖二”但思路可以直接扩展。我把这个点放在最前面是为了让大家别把标题理解成某种特殊功能它就是一个标准的Modbus主从应用。2. 从接线到握手RS485链路和Modbus从站参数2.1 FX3U要加一个485口别拿编程口硬怼三菱FX3U本体带的是编程口一般走RS422不是标准RS485主站口。想挂两台台达温控器硬件上先加一块通信扩展板。最常用的就是FX3U-485-BD插在PLC机身的BD槽位上不占输入输出点安装也简单拧两颗螺丝的事。这块板子适合大多数一拖二场景通信距离几十米以内现场没有特别强的变频器干扰。如果距离拉到一百米以上或者柜里变频器、直流驱动器一大堆稳妥做法是加带隔离的通信模块或者中间加485隔离中继器。我用过隔离型方案确实能少很多莫名其妙的数据错乱。接线要特别留意端子的定义。FX3U-485-BD上面有发送和接收两组端子三菱习惯标SDA、SDB和RDA、RDB跟台达温控器上常见的A、B-不是一一对应就能乱接。我之前按颜色接了一回结果数据完全不通后来对着两边端子图重新核对才解决。接法很简单PLC侧SDA接温控器的ASDB接B-两边的地线端子尽量共地。别小看这一步十次通信故障里至少有三次是A/B接反。2.2 站号、波特率、数据格式一次全配齐物理线接好只是第一步真正让两边“握手”的是通信参数。台达温控器的面板菜单里通常能找到通信站号、波特率、数据位、停止位、校验位这些参数。一拖二时站号分配很关键1号温控器设12号温控器设2绝对不能重复也不能设成0因为0在很多Modbus设备里是广播地址从站不回应答。波特率和数据格式两边必须完全一致。我习惯用9600、8位数据、偶校验、1位停止位也就是常说的8E1。这个组合兼容性最好调试工具也好配。如果你的项目要求刷新快一点可以上19200但前提是两台温控器都支持并且线路抗干扰能力够。还有一点特别容易忽略有些台达温控器的通信参数修改后要断电重新上电才生效。很多人在面板上改了站号没断电就直接通信结果怎么都不通以为参数没保存。顺手断电重开一次问题往往就消失了。我强烈建议动手接PLC之前先用电脑加一个USB转485模块配上Modbus调试工具把每一台温控器单独读一遍。这样做有几个好处能确认站号和通信格式没设错能确认寄存器地址查对了还能顺手验证一下线序。等每台温控器单独都能通再往FX3U上接这时候如果出问题就可以很确定问题出在PLC侧排查范围直接砍半。2.3 接线顺序和终端电阻看着不起眼其实很关键RS485布线推荐“手拉手”的菊花链结构也就是PLC先到1号温控器再从1号到2号温控器不要从PLC分出两条线各接一台。星形接法在长距离、高波特率时容易出信号反射一拖二虽然设备少但养成好习惯没坏处。线材用双绞屏蔽线屏蔽层要单端接地避免形成地环路。终端电阻不是随便加的只有总线的物理两端才需要。一拖二这个规模距离不远时可以先把终端电阻放一放但最好预留位置方便以后扩展。真出现数据不稳定再给线路两端并上120欧电阻试试往往有奇效。这里还要再提醒一句很多Modbus通信问题不是程序问题而是物理层问题。先确认线序、屏蔽层、共地再怀疑PLC寄存器配置。3. FX3U侧的通信配置D8400参数与ADPRW指令3.1 为什么我直接选ADPRW而不是自己拼帧FX3U实现Modbus通信有两条路一条是用RS指令自己组报文、自己算CRC校验、自己解析应答另一条是用ADPRW指令让PLC内部自动完成Modbus RTU的请求和应答处理。我一开始也试着用RS指令写过一版轮询功能倒是能实现但代码量很大CRC算法占了不少程序步调试的时候盯着十六进制帧看得眼睛疼。后来换成ADPRW整个人都轻松了。它把Modbus帧的拼装和CRC计算封装在指令内部编程时只需要告诉PLC跟哪个从站说话、用哪个功能码、读哪个寄存器、数据存到哪里。对于一拖二这种固定模式的应用这个指令就是为它准备的。3.2 M8411和D8400先把通信底子打好ADPRW不是拿来就能用使用前要做两件事。第一件把特殊继电器M8411置ON让FX3U进入Modbus主站模式第二件往特殊数据寄存器D8400里写入通信格式告诉PLC用什么样的串口参数去跟温控器打交道。我这里给一个开机初始化的示意写法实际值以你手头PLC的版本手册为准LD M8002 SET M8411 MOV H0C87 D8400这段逻辑的意思是PLC上电瞬间启动Modbus主站功能并把通信格式设为9600、8E1。这个H0C87是我在多个项目里用过的组合不同的固件版本可能会有细微差异第一次调试时最好对照编程手册的D8400 Bit定义表核对一遍。还有一个细节M8411要在第一次执行ADPRW之前就已经置ON。很多项目写梯形图时随手把M8411放在轮询逻辑后面结果第一次通信就超时查半天才发现是使能位没及时生效。3.3 ADPRW指令怎么读从站号、功能码、起始地址ADPRW的格式并不复杂大致是ADPRW S1 S2 S3 DS1是从站地址S2是功能码S3是寄存器起始地址D是本地数据寄存器首地址。S3这里的地址是Modbus协议地址按实际手册给出的十六进制或十进制值填不是人眼看到的“40001”这种编号。这个地址换算很容易踩坑后面专门讲。常用功能码就三个H03读保持寄存器H06写单个保持寄存器H10写多个保持寄存器。台达温控器大多数参数都在保持寄存器区域所以最常用的就是H03和H06。读报警状态、读PID参数这类操作也基本在这几个功能码里绕。我举个例子读1号温控器的PV值假设协议地址是0x0000数据存到D110ADPRW K1 H3 K0 D110执行完成后读取的数据存放在D110和D111里。这里牵扯到字节序问题不同温控器返回的数据高低字节排列不一样有的需要在高位寄存器左移后合并有的要直接交换高低字节。我在实际项目里就遇到过读回的温度显示成几千一百多后来交换一次字节就正常了。所以读到怪数值先别怀疑寄存器地址先想想是不是字节序反了。4. 台达温控器的寄存器读写与一拖二轮询逻辑4.1 先把协议地址表捧在手里不同型号差异很大台达温控器有多个系列寄存器地址不保证统一。我以自己调试过的一台为例把常用的几项列出来目的是展示查找思路不是让你照抄。用到具体型号时一定要从对应型号的协议手册里确认一次。功能描述Modbus协议地址读写属性备注PV当前温度0x0000只读可能带小数位需按分辨率换算SV设定温度0x0001读写写入后温控器立即采用报警上限值0x0002读写超限时温控器内部报警报警下限值0x0003读写超限时温控器内部报警自整定触发0x0020读写示例地址具体查手册寄存器地址这个东西看起来只是几个数字但坑很深。Modbus调试工具里显示的“40001”通常对应协议地址0x0000工具显示40002对应0x0001。换算关系如果搞反在ADPRW指令里写S3时很容易把寄存器号多写了1读回来的数据完全对不上。我每次新接一种温控器都会先用调试工具读一遍再往PLC里写死。4.2 轮询器设计别让两条ADPRW打架FX3U只有一套串口资源同一时刻只能执行一条ADPRW所以一拖二必须做轮询。我习惯用一个轮询步号寄存器做状态机每一步只发一条指令收到完成标志后步号加1再发下一条。以最简单的需求为例读1号PV、读2号PV、写1号SV、写2号SV、读1号报警、读2号报警这六步就是轮询表的基本内容。写SV的动作不可能每时每刻都发正常的做法是只在触摸屏上数值被修改时才触发一次写操作平时轮询只读。轮询逻辑要特别注意完成标志的清理。ADPRW执行完成后PLC会置位M8029。如果在下一步指令发出前没有对这个标志做脉冲处理可能造成新指令还没执行就被误判为完成轮询顺序就乱了。我调试时遇到过两次轮询乱跳最后都是在这里被坑的。4.3 写SV的坑锁定、量程和温度单位写设定值这个动作看起来最简单实际上最容易被阴。台达温控器面板上常有参数锁功能锁住以后通过Modbus写SV会被拒绝PLC读不到正常的应答。我被这个问题折腾过折腾完才意识到温控器默认开启了面板锁定远程写入自然失败。还有一个问题是量程。温控器的SV不是随便写什么都能接受超出上下限会直接返回异常码。PLC程序里最好做好限幅比如目标温度只能写进0到400之间的整数越界就提示操作员检查输入而不是让通信返回一堆错误码。温度单位也要留意。有的温控器设成华氏有的设成摄氏同样的数值显示出来天差地别。如果PLC程序里固定按摄氏度处理而温控器面板被改成了华氏读回来的PV换算后会有很大的偏差。我后来学乖了在轮询启动时先读一次温控器的单位参数再决定后续要不要额外换算。5. 完整程序骨架与触摸屏联调5.1 一个可参考的梯形图骨架下面是一个简化版的程序骨架作用是演示轮询状态机的结构不建议直接复制到项目里因为D区分配和步号逻辑要按实际程序布防。// 上电初始化 LD M8002 SET M8411 MOV H0C87 D8400 MOV K0 D0 // 轮询步号初始化为0 // 轮询完成触发下一拍用定时器加完成标志控制 LD M8029 OR M8140 // 超时标志示意具体看手册 INCP D0 // 步号加1 // 步号0读1号温控器PV LD D0 CMP K0 ADPRW K1 H3 K0 D100 // 步号1读2号温控器PV LD D0 CMP K1 ADPRW K2 H3 K0 D105这个小骨架的好处是逻辑好懂每一步干一件事排查时能一步步看。步数少的时候非常推荐。如果以后扩展到八台设备每台都要读PV、SV、报警那还是换成查表式的写法更省程序步不过思路完全一样。别忘了给轮询设置兜底逻辑。如果某条指令超时了不能让轮询卡死在原地而是记录一次错误次数强制跳到下一步。否则两台温控器中有一台临时没响应整个系统的数据都会停更。5.2 触摸屏只跟PLC说话别让它直接读温控器很多人在触摸屏和PLC之外还想让触摸屏再开一个串口直接读温控器觉得这样似乎更直接。但这样会让总线上出现两个主站一个PLC一个触摸屏两个主站同时发请求Modbus主从模型下这属于打架场面通信时好时坏是必然的。我的做法很死板但很稳定PLC是唯一的主站温控器的PV、SV、报警全部刷到PLC的D区触摸屏只跟PLC用三菱协议通信画面上显示D区数据操作员改设定值时也先写回PLC的缓冲区再由PLC判断时机执行ADPRW写操作。整个链路只有一个主站逻辑清晰出问题也好查。5.3 数据有效性通信失败时别让旧温度骗了人温度数据从温控器读回PLC后如果一路正常PV值会不断刷新。但一旦通信超时旧值还留在D区里如果程序不处理画面看起来温度还是正常的实际上已经好几分钟没更新了。我给每个温度值配一个数据有效位通信成功时有效位置ON失败时置OFF。触摸屏上显示温度时先判断有效位无效就显示两个减号而不是显示旧值。报警联动也是同样的逻辑只有新鲜的数据才能参与判断和联锁否则等于拿过期的温度做超温停机这是要出事的。6. 调不通的现场还原三个典型故障6.1 场景一1号温控器有数据2号完全没反应现场最常见的故障就是一台正常一台完全不通。我调过的一次就是这样1号温控器温度刷新得好好的2号始终报超时。我当时没急着改PLC程序而是先用USB转485模块只接2号温控器用调试工具直接读它的PV。结果工具也读不到问题基本锁定在温控器侧。一查面板参数发现2号温控器的站号显示为0。站号0在Modbus里是广播地址正常从站不会应答。把它改成2断电重新上电再回到PLC这边操作一切正常。这个案例说明通信调试时先分开测比对着PLC程序猜效率高得多。6.2 场景二数据读出来了但数值跳来跳去或者全是大数这个坑我在前面提过字节序但还有一个很常见的来源校验位设置不一致。有一次系统刚接线时基本能通信但一小时里总出现几次乱码而且不稳定。我查来查去发现PLC的D8400里设的是偶校验而台达温控器面板上被人改成了无校验。MODBUS帧的校验信息对不上接收方就会丢弃应答表现出来就是偶发超时和跳变。数值离谱还有一种情况温控器带一位小数比如实际是123.4摄氏度寄存器里存的值可能是1234。如果PLC程序直接当作1234显示操作员一看就知道不对。这是分辨率换算问题不是通信问题。解决方法是查温控器的小数点设置在PLC程序里做一次除以10的处理。6.3 场景三一拖二跑几小时后某一步轮询卡死这种故障最隐蔽因为重启PLC就好但跑一段时间又犯。我遇到过的情况是某次通信超时后完成标志没有正常清理轮询步号停在原地后面的指令全被堵住。现场表现就是触摸屏温度好几分钟不刷新温度看起来像冻结了一样。排查时我盯着轮询步号看发现它卡在5不是往前走。后来在轮询逻辑里加了一个强制跳步的兜底每条ADPRW无论成功失败都会在几十毫秒内结算超时也一样计步绝不阻塞后续轮询。加了这一步后这个故障再也没出现过。这种问题很像窗口排队办理业务窗口一直等前面那个磨蹭的人后面的人就全部堵死。实际工程里不能等该超时就超时该跳步就跳步保存错误记录就行。最后再分享一点实用习惯我调试温控器通信项目时都会做一套很笨但很管用的准备工作三个人们最不容易记清的东西打印成表贴在柜门上。一张是站号分配表一张是波特率与校验参数表一张是寄存器地址表。设备少的时候还能靠脑袋记设备一多、项目一多任何一个人改过参数都可能让之前的配置全部作废。还有每次新接一种温控器型号哪怕看再多的文档我都要先用USB转485和调试工具实际读一遍确认能读到PV、能改动SV再让PLC接管。这一步看着多花了半小时实际上省掉的是现场跟人工错误较劲的半天。通信这种东西顺序对了线路对了参数对了剩下的就是水到渠成的事。