企业官网建设流程全解析

1. 项目概述

1.1 为什么写这套通讯程序

做自动化项目这些年，温控器和PLC之间的通讯始终是个绕不开的经典场景。尤其是拿到台达EH3和台达温控器这套组合时，基本上就告别了复杂的硬件接线——用Modbus RTU协议，两根线就能把所有温度数据读上来、把设定值写下去。

这套程序的核心价值在于：省掉了温控器面板的重复设定操作，让温度控制参数可以统一从触摸屏上修改和管理。比如现场有几十台温控器，如果每台都需要人工走到设备前按键调整温度，那运维成本会非常难看。而通过PLC作为Modbus主站轮询读取各温控器数据，再交由触摸屏集中显示与设定，整个操作效率能提升一个量级。

这个项目适合谁参考？一类是刚接触台达PLC通讯功能的新手工程师，另一类是在做设备改造、想把手动控温设备升级为集中监控系统的老手。无论是哪一种，只要把通讯建立的逻辑理清楚，后面换其他品牌的温控器也只是改改地址映射表而已。

1.2 通讯方案选型：Modbus RTU还是别的

台达EH3系列PLC支持多种通讯方式，比如内置的串口通讯、以太网Modbus TCP等。但在温控器这个场景下，Modbus RTU几乎是唯一需要认真考虑的选择，原因是这样的：

绝大多数工业温控器（无论是台达DT系列还是其他品牌）标配的通讯接口都是RS-485串口，协议上最通用的就是Modbus RTU。Modbus TCP当然更快，但很多温控器低配版本根本不给网口。而RS-485的差分信号传输方式，在工业现场抗干扰能力足够，传输距离也能到几百米，对大多数控温设备来说完全够用。

台达EH3本身自带一个COM口（COM1或COM2，具体看型号），支持RS-232或RS-485通讯。其中COM2支持RS-485，正好用来挂温控器总线。如果温控器数量多或者现场距离远，也可以外插通讯板卡扩展COM3。

这里有一个容易被忽视的细节：台达EH3的通讯口同时承担程序下载和在线监控功能。如果同一个口既接编程线又接温控器总线，调试时就得来回插拔。所以我在项目中把编程口和通讯功能分开使用——编程用USB口，通讯用RS-485口。

提示：如果你的EH3机型是早期的ES2/ES3系列，部分型号只有一个标准RS-232通讯口，需要搭配扩展板才能上RS-485，选型时一定确认清楚端口定义。

2. 硬件接线与通讯参数规划

2.1 真正的接线没有玄学，但必须注意极性

RS-485接线算是整个项目中最基础但最容易翻车的环节。EH3的COM2通讯口，一般定义如下（具体端子号以随机手册为准）：

这里我要强调一个很多人忽略的问题：通讯地的连接。近距离（几十米内）不接地线可能也能跑，但现场一有变频器启动或者继电器吸合，通讯就容易莫名掉线。把GND接上之后，数据稳定性会有明显提升。

然后是终端电阻的问题。Modbus RTU的RS-485总线两端各需要接一个120Ω左右终端电阻，用来匹配特性阻抗，减少信号反射。但这个事情要视规模而定：

• 如果就一台EH3带一两台温控器，短线直连，不接终端电阻基本上也正常。
• 如果总线上挂了十台以上温控器，或者通讯距离超过100米，两端加终端电阻是必需的。

接终端电阻不是随便买两个电阻焊上去就完事，很多台达温控器本身自带跳线或拨码开关来启用终端电阻，用之前先翻一下硬件手册。我踩过这个坑，一开始没注意温控器内置终端电阻开关，结果总线阻抗不匹配，通讯时好时坏。

2.2 温控器站号与波特率的规划原则

在写任何一行程序之前，必须先把温控器的地址（站号）规划好。Modbus RTU协议中，每个从站有一个唯一地址，范围是1到247。PLC作为主站，通过地址来区分和访问不同的温控器。

站号设置有两个原则：

原则一：按物理位置顺序编号。比如一号烘箱温控器设1，二号设2，三号设3。这样现场维护人员根据编号就能轻松定位问题设备，排查故障时不用拿设备表来回对照。

原则二：预留扩展区间。不要从1开始排满了才加新设备。比如目前有8台温控器，可以占1到8号，但规划时可以把连续编号段在10到19之间，给后续增加加热区段留出余量。

波特率的选择相对固定，温控器Modbus RTU一般支持9600或19200。我看过太多项目死磕高波特率，结果现场一开变频器就丢数据。坦白讲，温控器通讯的数据量并不大——一台上传一两个温度值、下载一个设定值，也就是几十个字节。9600波特率完全够用，抗干扰性反而更好。我自己做这类项目，默认就是9600、8、N、1（数据位8位、无校验、停止位1位），所有温控器统一配置。

2.3 通讯参数表参考

在给温控器设置参数时，建议做一份表格作为项目交付文档的一部分：

这里有一个很多新手看不懂的点：温控器侧的“通讯超时”参数是什么意思？它的作用是当温控器作为从站时，如果超过设定时间没有收到主站报文，就自动结束当前通讯处理。这个值设太短，偶发的一帧延迟可能会导致从站罢工；设太长又拖慢了异常恢复。500ms是一个比较稳妥的中间值，配合PLC侧200ms左右的重试间隔，整体通讯恢复时间比较理想。

3. 通讯协议的数据地址映射

3.1 温控器寄存器地址解释

Modbus RTU协议本质上就是读写寄存器，但温控器手册里的寄存器地址和PLC侧看到的Modbus地址不是一一对应的。这里面有一个地址偏移的坑，几乎每个做通讯的工程师都踩过。

台达DT系列温控器（以DTE为例）的一些常用寄存器如下（部分型号有差异，以具体手册为准）：

这里的关键规则是：Modbus协议中的寄存器编号是从1开始计数的，而温控器手册给出的地址通常是以0开头的十六进制地址。两者相差1。

比如手册上写的1000H，转成十进制是4096。但组态软件或PLC发送报文时，要访问的地址是4097而不是4096。这个偏移关系用公式表达就是：

实际Modbus地址 = 手册地址（十进制转换值） + 1

如果在这里搞错了，读写回来的数据完全对不上，而且很难排查——因为通讯本身是正常的，指令也执行了，但读回来的数就是乱码或者恒定不动。我在项目中专门写了一个地址映射表注释在程序里，就是为了防止后续维护人员踩这个坑。

3.2 PLC内部软元件的规划

数据地址理清楚了，接下来需要在PLC里规划对应的软元件（寄存器），用来存储从温控器读回来的数据以及待下发的设定值。

我给这套程序做了如下的软元件规划：

这些软元件的规划看似简单，实则有几个经验点：

第一，数据区分配要留空隙。比如D0-D7存温度，D10-D17存设定值，中间隔了D8和D9。这样一来，后续要扩展数据（比如温度上限、下限），不用大改程序，直接在空隙里插入就行。PLC程序最怕的就是后续加需求时牵一发动全身。

第二，每个站配两个标志位。通讯成功标志和失败标志，别只用一个标志位表示两个状态。这样触摸屏上可以同时显示“通讯中”和“通讯失败”两种状态，方便操作人员判断现场问题；如果只有一个标志，程序逻辑和画面显示都会受限。

第三，数据的缩放与偏移。温控器的温度一般有小数位，比如显示25.5度。但Modbus寄存器返回的是整数（255）。PLC侧需要根据温控器的“温度分辨率”（常见0.1度或0.01度）做一次换算。这个换算建议在PLC程序中使用专门的子程序处理，而不是在触摸屏上做，因为触摸屏的数值精度处理不像PLC那么灵活，而且PLC处理完之后触摸屏只管显示，逻辑更清晰。

3.3 触摸屏变量映射的对应关系

项目标题里提到了触摸屏，这也是整个方案中不可缺少的一环。触摸屏（比如台达DOP系列）作为上位机，通过以太网或串口与EH3 PLC通讯，读取PLC内部的D区数据和M标志位，显示在画面上。

触摸屏变量和PLC软元件对应关系规划如下：

这里有一个联动逻辑要在触摸屏中处理：操作人员在画面上修改了SV_1的数值后，数值先写入PLC的D10缓存区，然后由PLC程序判断D10数值发生变化后，自动通过Modbus指令写入到温控器的设定值寄存器中。

这种“触摸屏写入缓存区 + PLC自动检测下发”的方式，比触摸屏直接通过宏指令写温控器地址要稳妥得多。因为如果触摸屏直接发起Modbus报文和温控器通讯，一旦通讯失败，触摸屏画面没有直观的PLC侧诊断信息，故障定位会很困难。而通过PLC中转，所有通讯过程都可以通过PLC程序监控，出问题时直接检查M0到M7的通讯标志，一目了然。

4. 台达EH3的Modbus指令说明

4.1 MODRW指令语法与各参数含义

台达EH3系列PLC实现Modbus RTU通讯，核心指令就一条：MODRW。这条指令是台达独有的一条多功能读写指令，通过不同的参数组合实现读取和写入操作。

MODRW指令的格式如下：

MODRW S1 S2 S3 S4 S5

各参数的详细含义：

• S1：通讯端口的设定。K2表示使用COM2（RS-485），K3表示使用COM3。这个参数其实是一个扩展寄存器编号，用来告诉PLC使用哪一个串口做通讯。
• S2：从站地址（站号）。K1代表访问1号温控器，K2代表2号温控器，以此类推。
• S3：控制代码/功能码设定。具体含义取决于你要执行的操作。K3表示读取保持寄存器（对应Modbus功能码03），K6表示写入单个寄存器（对应功能码06）。
• S4：从站的寄存器地址（注意地址偏移规则，前面已经详细讲过了）。
• S5：数据长度或数据来源区。当S3为K3（读取）时，S5得到的是读取数据存放的PLC起始软元件；当S3为K6（写入）时，S5是待写入数据的来源起始软元件。

下面给出两个实际调用的例子。

读取1号温控器的当前温度（寄存器地址4097），存到D0：

LD M0 ; 通讯空闲标志 MODRW K2 K1 K3 K4097 D0

这条程序的含义是：使用COM2口，访问站号1的温控器，执行读操作，读取地址4097的寄存器数据，存到PLC的D0中。

写入设定值到1号温控器（寄存器地址4098），假设D10存放的是要下发的设定值：

LD M20 ; 手动触发一次写入 MODRW K2 K1 K6 K4098 D10

写入单个寄存器时，S4指定了要写入的从站地址，S5是PLC内存中存放数据的起始寄存器。

4.2 通讯流程的整体架构

实际项目中，不可能只用一条MODRW指令就能稳定完成几十台温控器的通讯。核心问题在于：Modbus RTU是半双工通讯，同一时刻只能有一帧数据在总线上传输。如果PLC程序每个扫描周期都同时发起多个站的读写请求，总线就会出现冲突，导致通讯错乱。

因此，通讯流程必须设计为轮询调度模式。我在这套程序中的基本思路是：

1. 每个扫描周期，只向一个温控器发送一条指令（读或写）。
2. 指令发送完成后，等待温控器应答。使用PLC的M1129（通讯超时标志）或M1140（通讯发送标志）进行流程控制。
3. 收到应答或超时后，再切换到下一个温控器，循环往复。

用梯形图描述这个流程就是典型的“步进式状态机”。这种结构虽然看似简单，但这个思路是整个通讯程序稳定运行的核心保障。

更具体地说，通讯流程设计包含两个轮询模式：

• 常规数据轮询：依次读取1号、2号、3号……温控器的当前温度，每个扫描周期处理一个站。全部轮询一次后，再从头开始。
• 写入操作触发：写入操作不能占满轮询周期。建议只有在PLC检测到触摸屏上的设定值发生变化（比如D10与上一次值不同）时才触发写入指令，写入完成后等一轮再恢复正常轮询。

这两种模式并行，但是在一个状态机中统一调度，避免读写指令在同一个时间片发生碰撞。

4.3 通讯流程程序的伪代码逻辑

为了更清楚地说明轮询状态机的实现，我用结构化文本伪代码展示核心逻辑（台达EH3也支持ST语言，但实际项目用梯形图居多，此处以逻辑说明为主）：

// 伪代码：通讯调度状态机 CASE state OF 0: // 空闲，开始第一站 send_read(1, PV_ADDR); state := 1; 1: // 等待应答 IF comm_done THEN store_data(1, read_buffer); comm_ok[1] := TRUE; state := 10; // 切换到第二站 ELSIF timeout THEN comm_fail[1] := TRUE; state := 10; END_IF; 10: // 第二站 send_read(2, PV_ADDR); state := 11; ...

实际上不必机械地写CASE，梯形图中可以用SET/RST指令实现步进。这样一个流程结构，无论挂几台温控器，都能保证通讯稳定且有节奏。编写这一整套流程时一定要加上详细的注释，尤其是每一条MODRW指令对应的物理意义（哪个温控器、读取什么数据），这一点和标题里“程序有注释”的诉求完全匹配。

5. 程序实现与关键段注释

5.1 初始化段的设计要领

程序开头需要做初始化动作，包括通讯口波特率设置、协议设置、通讯超时时间等。台达EH3的串口通讯参数可以通过特殊寄存器设定：

以COM2为例，初始化设定程序如下：

LD M1002 ; 初始化脉冲标志（PLC上电第一扫描周期为ON） MOV K87 D1320 ; 设定COM2为9600,8,N,1 MOV K100 D1329 ; 通讯超时1秒 SET M1132 ; 启动COM2通讯

注意：D1120和D1320的设定值不是直接写入波特率数值，而是按照特定编码格式，将波特率和数据格式打包成一个16位数值。常见配置的对应关系如下：

实际操作中，可以在台达编程软件WPLSoft或ISPSoft中直接调用“COM2设定”功能块，软件会自动生成对应的配置程序，比自己手动写MOV稳妥，也不容易把编码搞错。

5.2 数据采集轮询程序示范

下面是核心的轮询采集程序段示例。需要说明的是，梯形图程序在文本中不易呈现，我用结构化表达进行描述，逻辑完全一致，方便阅读与移植。

程序段A：1号温控器温度采集

当前状态 RUN_STEP = 0 触发条件：[RUN_STEP=0] 执行动作： 向站号1发送读请求，读取寄存器4097，数据保存到D0 RUN_STEP=1 状态 RUN_STEP = 1 触发条件：[RUN_STEP=1 且 D0接收完成标志=ON] 执行动作： 写入通讯成功标志M0=ON 记录当前值D0 RUN_STEP=2 状态 RUN_STEP = 1（超时路径） 触发条件：[RUN_STEP=1 且 M1129=ON] 执行动作： 写入通讯失败标志M0=OFF，M10=ON RUN_STEP=2

程序段B：2号温控器温度采集

逻辑与1号几乎一致，唯一区别在于MODRW指令中S2参数改为K2，读取寄存器地址仍为4097，数据存到D1。RUN_STEP从2到4轮转。

如此循环，直到第8号温控器采集完毕后，RUN_STEP回跳到0，开始下一轮循环。

这种顺序轮询的方式在数量少（10台以内）时完全没有问题，整个周期也就几百毫秒。如果温控器数量达到几十上百台，就要考虑分组轮询或改用Modbus TCP的方式了。

5.3 设定值写入与确认机制

写设定值这块需要多一道确认机制，防止误写和重复写。

程序逻辑设计如下：

1. 触摸屏上操作人员修改设定值，先写入PLC的D10缓存区。
2. PLC程序比较当前缓存值与上一次成功下发的值（保存在D50）。如果相等，说明设定值没变化，不触发写操作。
3. 如果不相等，置位“写入请求标志”M20，并把待下发值暂存到D52。
4. MODRW写入完成或超时后，复位M20，更新D50为最新已下发值。

这样做的好处是：即使操作人员在触摸屏上连续改多次设定值，PLC也只会按顺序一条一条地发指令，不会出现一帧一帧地连发覆盖的情况。否则，网络一旦拥堵，后发的指令可能先到达，温控器的设定值最终稳定在错误的数值上。

写入操作完成后的确认环节同样重要。从站温控器执行写操作后，会返回一帧应答报文。这帧报文的含义是“写入请求已收到并处理”，代表写入已经成功。如果既没有应答也没有超时，那就是通讯失败了，这时要在程序中置位M10（通讯失败标志），并在触摸屏上闪烁报警，提醒现场人员检查线缆或温控器状态。

5.4 程序注释的写作规范

既然项目标题里特意提到“程序有注释”，这说明原作者在交付时非常看重程序的可维护性。我在程序注释方面有一些具体的做法：

第一，每个网络（Network）都需要注释，不要只注释关键段。很多情况下，维护人员看程序时并不是从头到尾读的，而是通过注释关键词搜索定位问题。如果你的注释只写了“读取温度”这种四个字的描述，后面排查故障时根本找不到具体是哪个程序段。

我的一般做法是类似这样：

网络注释：1号温控器当前温度读取（Modbus地址4097，对应DTE手册1000H，偏差值+1，存D0）

这样写的好处是，即使完全不了解项目背景的人拿到程序，也能从这个注释中知道这行代码读取的是哪个设备、哪个参数、为什么地址是这个。

第二，PLC程序的内部软元件表一定要放到程序开头注释中。就好比一本书的目录，让维护人员先看到D0到D100都被规划成了什么用途。没有这张表，程序读起来就像没有路标的迷宫。

第三，写清楚信号流向。触摸屏上的某个数值是通过什么方式进来的，从哪里下发到温控器，最终写到哪里，这条链路要在注释中体现出来。特别是牵涉到数值转换（比如整数到实际温度的缩放）时，转换公式必须写进注释，否则后续维护时根本不敢去改这个参数。

6. 触摸屏画面的数据绑定

6.1 触摸屏与PLC的变量对接

台达触摸屏常用的组态软件是DOPSoft。在新建项目时，首先要添加PLC的通讯驱动，选择台达EH3系列，通讯方式根据实际硬件选择以太网或串口。

变量绑定这一步，很多人直接使用地址映射的方式，直接在触摸屏组态软件中将数值输入元件关联到D10。这种做法简单直接，但需要注意几点：

触摸屏组态的数值显示元件，建议将格式设置为“整数”或“带小数”，根据PLC侧处理后的实际含义来定义。如果PLC内部已经将温度值做了浮点换算（比如直接转为浮点25.5），那触摸屏的元件也要设置为浮点数格式，显示位数设为1位小数。

如果PLC侧没有做换算，触摸屏侧就必须自己做计算。在DOPSoft中可以通过数值运算宏实现。但我个人建议还是在PLC侧做换算，这个经验前面已经提过——PLC处理完之后，触摸屏只负责显示，画面组态更简单，逻辑也更集中。

6.2 画面报警与状态指示的联动

触摸屏画面上，每个温控器对应一组元素：当前温度显示框、设定温度输入框、通讯状态指示灯、报警指示块。其中通讯状态指示灯的颜色可以通过变量值变化来切换。

我一般这样定义：

在触摸屏的“指示灯”组件属性中，可以设置三种以上的状态切换。关键是要把PLC侧M0和M10的逻辑关系定义清楚：任意时刻只能有一个为ON，绝对不能同时为ON。这就要求PLC程序中在M0置ON时同时将M10复位，反之亦然，避免出现“既正常又异常”的并列状态。

很多工程师在触摸屏上直接把M0和M10独立绑定两个灯，看似也能显示，但一旦程序逻辑有问题导致两个标志都为ON，画面上就是绿灯红灯同时亮，操作人看了会一头雾水。还是应该用一个字或一个标志位做状态字，然后触摸屏根据状态字的值切换显示，逻辑最干净。

如果温控器数量多，一副画面上放几十个温控器显示框会比较拥挤，建议使用画面翻页功能，每页显示8台或12台。台达触摸屏借助宏指令或画面切换按钮，按页切换非常流畅。如果涉及权限管理，可以在触摸屏中设定用户等级，只有管理员权限才能修改设定温度，操作工只允许查看。

7. 调试过程与常见问题实录

7.1 初次通讯失败的排查流程

这套系统第一次上电测试时，我就遇到过通讯完全不通的情况。故障现象：触摸屏上所有温控器通讯状态显示“红色异常”，温度显示区全部为“----”或0。

排查步骤，我建议按以下顺序进行：

第一步：检查串口连接与端口配置。用万用表量一下RS-485的A/B线是否有电压（通讯时总线会有2V到6V左右的差分电压）。如果没有电压，大概率是通讯线接错或PLC的COM口没有配置为通讯模式。

第二步：检查PLC侧通讯参数和温控器侧参数是否完全匹配。波特率、数据位、校验位、停止位，这几项必须完全一致。最常见的低级错误是，温控器设置的是8, E, 1（偶校验），而PLC侧配置的是8, N, 1（无校验），两边波特率都是9600，看似差不多，但Modbus协议中校验位的匹配是严格要求的，差一位都不行。

第三步：用MODRW指令单发一条测试指令，配合WPLSoft的在线监视功能看数据变化。在PLC程序里临时加一条对站号1、地址4097的读指令，触发条件可以暂时设为常ON。如果D0里出现了有效温度数值，说明通讯链路已经通了，问题多半出在后面的轮询调度逻辑上。

第四步：检查温控器是否处于“允许通讯”状态。部分温控器有一个“通讯写允许”或“通讯读允许”的开关参数，默认值是关闭的。必须有意识地在温控器面板上把这个参数设置为开启，否则即使总线通着，温控器也不会响应请求。

7.2 偶发性通讯中断与恢复

项目运行中最常被诟病的问题就是“通讯不定时掉线”。这类问题一般分三种情况：

第一种：地址冲突。两台温控器的站号设成了同一个。Modbus物理层对这种冲突并不会主动报警，而是两台设备同时尝试应答时，总线电平和数据帧就会互相干扰，主站收到的数据帧校验失败，现象就是那个站偶尔能通，偶尔完全没响应。用万用表或串口调试工具抓一下总线上是否有两个设备同时拉低电平，就能判断出来。

第二种：电磁干扰。温控器的RS-485线与变频器输出线在同一个线槽里并行走线。变频器启动时PWM脉冲信号会通过分布电容耦合到通讯线，干扰RS-485差分信号。处理方法是：通讯线缆选用屏蔽双绞线，屏蔽层单端接地，并且与动力线保持至少20cm间距；如果空间实在不足，就套金属软管做屏蔽。

第三种：握手时序问题。PLC发送完一帧后，立即开始计时等待应答。如果温控器处理速度稍慢（尤其在执行写入指令后需要回读确认），可能会导致超时。这时候适当调长PLC侧的通讯超时时间（D1129/D1329），从1秒调到2秒试试，同时把PLC的“通讯重试次数”设置为2次或3次，这样单次超时不会立刻报失败，整体可靠性会好不少。

7.3 通讯地址偏移问题的实测记录

在调试过程中，我还遇到过一次特别典型的地址偏移问题。当时读取温控器当前温度，使用手册上标注的地址4096，结果返回的数据恒定是0，反复检查硬件连接、功能码都没发现问题。后来查阅资料后验证，台达温控器手册的地址是从0开始的（Protocol Address = 1000H即4096），而Modbus协议标准中数据地址从1开始，必须使用4097才能正确访问。

这也是我在前面反复强调的“地址+1”的经验来源。这个问题用示波器或串口监视器抓包时其实已经能看出来端倪——发送出去的报文地址是4096，但温控器手册中的数据结构起始编号是0，温控器内部把0号寄存器作为起始地址了，等于访问到了“错误的起始地址”，自然读不出数据。

建议项目程序里做一张专门的“地址映射表”注释，把温控器手册地址和PLC实际发送地址的对应关系整理清楚，后续维护人员想扩展新功能时，照表修改即可，不会再犯同类错误。

7.4 通讯数据的校验与安全

最后补充一个不是所有人都能想到的问题：通讯数据的安全校验。

Modbus RTU本身有CRC校验，能保证传输过程中的数据不出错。但这还不够，因为如果从站温控器本身出现问题（比如传感器短路导致PV值跳到高限），PLC会忠实地把错误的温度值读到内存里，触摸屏上照样显示，系统也不会报警。如果这个温度参与PID控制或超温保护逻辑，后果可能很严重。

所以我在程序中增加了数据合理性判断：

LD D0 CMP K2000 ; 温度上限判断（比如200.0度） 如果D0 > 2000，则置位“温度异常”标志，并在触摸屏上显示红色报警 如果D0 = 0 且连续读取3次都为0，则提示“传感器断线”

这种“通讯通了但数据不合理”的场景，恰恰是现场最容易忽视的漏洞。通讯程序只负责通道畅通，而数据本身的正确性需要应用逻辑来把关。作为项目的设计者，必须有意识地加这道保险。

8. 程序模块化设计带来的后期便利

8.1 宏定义与子程序的复用设计

当项目中有8台甚至更多台温控器时，如果每台都写一遍轮询梯形图，程序会变得又长又乱。这时候就体现出了子程序的价值。

台达EH3支持子程序调用（CALL和RET指令）。我的经验是，把“温控器数据读写”做成一个带参数的子程序，然后用循环变量作为参数重复调用。当然，台达的梯形图子程序传递参数不如高级语言方便，实际操作时可以采用如下两种方式之一：

方式一：使用不同的数据寄存器做中转参数。调用子程序前，先将要访问的站号写入D200，将寄存器地址写入D201，将数据存储区起始地址写入D202，然后CALL子程序。子程序内部读取D200-D202完成通讯。

方式二：如果需要更高的执行效率，可以在梯形图中直接生成8段相同的轮询逻辑，虽然程序长一些，但每段之间互不干扰，调试时也可以单独禁止某段运行。台达EH3的程序容量足够大，这种方式在小项目中也完全可行。

我个人的建议是：项目在10台温控器以内，直接用展开式梯形图；超过10台再考虑子程序化。展开式的可读性在数量少时反而更好——每个站一段，注释清楚，维护人员逐个排查非常直观。

8.2 扩展性考虑：如何应对新加温控器

这类项目交付后再加设备的情况非常常见。工厂产能提升，新增一台烘箱、一台烤箱，都要再加一台温控器。

如果程序一开始就考虑了扩展性，那么加设备的操作流程非常固定：

1. 新温控器设置好站号，确认与现有站号不冲突。
2. 触摸屏组态软件中新增变量并绑定到PLC新的D区（比如D8就是预留位）。
3. PLC程序中复制一段现有温控器轮询逻辑，修改站号、数据存储区、标志位，地址映射表新增一条记录。
4. 下载程序，重新上电测试。

整个过程能控制在半小时内完成，而且不影响现有设备的正常运行。如果当初没有预留D区空间，没有采用统一的轮询状态机结构，新增设备就得大改程序，风险要高得多。

8.3 关于程序注释的再思考

最后再聊一下程序注释。作为技术人员，交付物不只是设备能运行，更重要的是让后来人能维护。程序里每一条MODRW指令我都写了“谁在用、读什么、存哪里、为什么是这个地址”这样的完整注释。这样写也许看上去啰嗦，但维护过别人无注释程序的人，都应该能理解这种做法的价值。

有一次我到现场去改程序，打开之前同事调的程序，内容全是类似下面的状态：

LD M100 MODRW K2 K5 K3 K4097 D4

没有网络注释、没有软元件表、没有任何地址说明。现场温度不对，修改时完全靠猜，猜错一次还得重新来。经历过这种痛苦，我在自己做项目时就格外看重注释的完整度。

这也是我对这套通讯程序“程序有注释”这个标签的回应：注释不是写给别人看的装饰，而是一个工程项目的定海神针——它确保六个月后你回来改程序时，还能像六个月前一样清楚每一行代码在做什么。

9. 实操心得与常见注意事项汇总

9.1 调试必备工具清单

做通讯类项目，建议手头备齐这几样工具，能省不少排查时间：

串口调试助手查看报文是关键能力。正常读取一帧的格式大致如下：

发送报文（PLC→温控器）：

01 03 10 01 00 01 CRC_LO CRC_HI

• 01：从站地址
• 03：功能码（读保持寄存器）
• 10 01：寄存器地址（16进制1001，即十进制4097）
• 00 01：读取1个寄存器
• CRC_LO CRC_HI：CRC校验低字节、高字节

应答报文（温控器→PLC）：

01 03 02 00 FF CRC1 CRC2

• 02：返回2个字节数据
• 00 FF：寄存器值，即255，对应25.5度

如果看到发送正常但没有应答，问题基本可以锁定在从站侧（温控器地址、通讯参数或硬件接线）。如果应答内容完全不对，优先怀疑地址偏移问题而非物理层故障。

9.2 与变频器共存现场的通讯抗干扰技巧

工业现场，温控器和变频器常常安装在同一台设备上，这是最考验通讯可靠性的场景。我整理了以下几个实用技巧供参考：

第一，通讯线和动力线分开布线，不能走在同一个线槽中。如果空间不允许必须交叉，保持交叉角度为90度。

第二，RS-485屏蔽层的接地方式，建议采用“单端接地”。在PLC端将屏蔽层接到通讯端口的地线端子（或接地排），温控器端屏蔽层悬空或通过电容接地。这个做法能减少地环路引入的干扰。

第三，PLC的通讯口需要做隔离时，可以考虑加装485隔离器。台达部分高端机型通讯口自带隔离，但低端型号没有。如果现场变频器功率较大，加隔离器是明智的投资，一般价格为几百元，相对于频繁掉线带来的停机损失，非常划算。

9.3 程序下载后通讯不恢复的怪现象

调试过程中还遇到过一种现象：程序修改后通过USB线下载到PLC，程序正确执行了，逻辑也正常，但Modbus通讯怎么也建立不起来，PLC的通讯指示灯显示没有数据收发。

重复排查后发现，是下载程序时USB隔离器被电脑的电源适配器干扰，导致通讯口电平异常，PLC的通讯硬件进入了某种保护状态。重新断电上电后恢复正常。

这个问题的处理建议是：下载完程序后，务必对PLC做一次完全的断电重启，而不是仅仅软复位。特别是修改过通讯口参数或通讯流程的情况下，硬件状态需要重新初始化。这一点经常被忽略，但遇到通讯莫名失效时往往就是这一步断电重启的问题。

9.4 触摸屏和PLC同时修改设定值时的竞态处理

当触摸屏上操作人员频繁修改设定值时，PLC侧通过D10缓存读取数据。如果操作人员在同一秒钟内连续改了多次，PLC侧的检测到D10变化触发写入时，温控器可能还在处理上一次写入请求，就出现了“写写重叠”的情况。

针对这个问题，我通常在PLC中增加“写入忙”逻辑。当一条写入指令执行中，将M21置为ON；此时即使D10再次发生变化，也不会触发新的写入指令。只有等到上一条指令完成后（成功或超时），才将M21复位，允许下一次写入。这样，即便操作人员手速再快，温控器侧的写入请求始终是串行化的，不会互相打断。

实测下来，这个机制还能防止一种误操作：操作人员把设定值改成100度，马上又改成120度，再改成110度，最终PLC只会按顺序依次写入三条指令而不会丢弃，最终结果一定是110度。这只是通讯层面的保证，工艺层面的温度变化还需要系统其他保护逻辑来完成。

9.5 通讯状态标志在触摸屏上的优化显示

触摸屏上通讯状态的实时显示，对现场操作非常直观。但需要注意“通讯中”和“通讯成功”两个状态的区别。采用状态字方式，两字节可以表示32位，每一位代表一个温控器的状态，触摸屏上可以做多状态显示。

更为细致的做法是：对每台温控器的通讯异常做累积计数，比如连续3次通讯失败才判定为“断线”，单次失败先标记为“通讯中”。这个思路能过滤掉偶发的瞬时干扰，避免报警画面频繁闪烁，操作人员长时间盯着看也不容易疲劳。

10. 项目的扩展空间

10.1 从纯采集到集中控制

目前的程序架构已经实现了温度采集和设定值下发两大功能。在这个基础上，还能扩展出更多的控制逻辑：

• 超温报警联动：当某温控器温度超过设定上限时，PLC直接切断对应加热回路。这是将通过Modbus读到的温度值用于实际保护控制的第一步。
• 升温曲线管理：把升温时间和目标温度做成配方表，PLC按配方中的时间节点，自动逐段修改温控器的设定值，实现简单的温度曲线控制，而不再依赖外部上位机。
• 数据记录与报表：将D0-D7区温度值定时采集到PLC数据寄存器，再通过触摸屏的数据采样功能生成历史曲线，为工艺分析和客户验收提供依据。

这些扩展都只需要在现有通讯框架上增加附加逻辑，不必改动通讯轮询本身，这就是前期结构设计带来的收益。

10.2 与上位机组态软件的对接

如果项目后期还需要上位机（比如组态王、WinCC）远程监控，EH3 PLC的以太网口可以直接承载Modbus TCP通讯，上位机作为客户端访问PLC内部D区数据。这种架构下，温控器的原始通讯完全由PLC负责，上位机只需要和PLC谈数据，不需要关心温控器的通讯细节。

这个对接思路的价值在于分层清晰，又不干扰底层的Modbus RTU轮询。底层通讯已经经过了验证，上位机接入后不会引入新的通讯风险，扩张起来也容易。

10.3 关于调试和交付的建议

最后整理几条项目调试和交付层面的经验建议，都是实际项目中踩过坑之后摸索出来的：

一、通讯程序的开发一定要先做最小验证再做整体设计。先让PLC和一台温控器通过最简单的MODRW指令通讯成功，再扩展到多台轮询，能节省大量排查时间。

二、交付文档中一定要包含地址映射表、软元件规划表、通讯参数表这三张表。这三张表对整个系统后续的维护至关重要，现场问题定位速度能快十倍。

三、程序注释不是给别人看的，是给三个月后的自己看的。哪怕项目再急，也要把关键逻辑注释补全。省下的时间，迟早会以几倍的方式花回去。

这套台达EH3与温控器Modbus RTU通讯程序，核心技术点并不多，但每一个细节都值得认真对待——从地址偏移到轮询时序，从通讯失败恢复到数据合理性校验，无不是现场经验的沉淀。只要把架构和逻辑理清楚，这套方案完全可以作为模板，快速复制到不同规模和不同配置的控温项目中。我自己在实际使用中最大的体会是，通讯程序并不难写，难的是把它写得稳定、可维护、可扩展。希望这套程序的经验总结，能让你在项目中少走一些弯路。