1. 从一台“能上云”的PLC说起TM1200到底解决了什么问题第一次拿到 Tenlink TM1200 的时候我脑子里冒出来的第一个念头其实很朴素这不就是一台支持 CODESYS 的控制器嘛市面上同类产品一抓一大把。但真正把它接上传感器、跑通 MQTT、把数据推到云端看板之后我才意识到这台设备的价值不在“PLC”这三个字上而在“上云”这两个字上——它把传统 PLC 那套封闭的、本地化的控制逻辑和现在工业物联网最需要的协议对接、数据上报、远程运维能力揉到了一块板子上。说白了TM1200 是一台基于 CODESYS 编程环境、原生支持 MQTT 等物联网协议的工业控制器。它能做的事情分两层底层还是老老实实做 PLC 该干的活——采集传感器信号、跑 PID、控制电机顺启逆停、驱动六轴机械臂的伺服上层则通过网口把运行状态数据打包用 MQTT 协议发布到服务器让远端的人能看到设备在干什么、温度有没有飘、某个寄存器是不是越界了。这篇文章适合谁看如果你是做非标自动化项目的工程师手上有一堆分散的设备要集中监控如果你是刚接触 CODESYS 想找个能落地的硬件练手如果你是做毕业设计需要把 PLC 和云平台打通——TM1200 这类产品手册里的东西值得你花时间啃一遍。我下面会从整体设计思路、核心细节、实操流程、踩坑排查几个角度把这份产品手册背后的东西拆开讲尽量让你看完就能上手。2. 整体设计与选型思路为什么是 CODESYS MQTT 这套组合2.1 为什么 TM1200 选择 CODESYS 而不是自家封闭 IDE传统 PLC 厂商大多有自己的编程软件三菱有 GX Works西门子有博途台达有自己的 ISPSoft。这套模式的好处是生态闭环、稳定性可控坏处是学习成本高、跨品牌迁移难。TM1200 直接用了 CODESYS这是一个很聪明的选择。CODESYS 本质上是一个遵循 IEC 61131-3 标准的软 PLC 运行时支持梯形图LD、功能块图FBD、结构化文本ST、顺序功能图SFC等多种编程语言。你之前在汇川 PLC 上写的 CODESYS 程序理论上稍作调整就能跑到 TM1200 上你在 CODESYS 里学的六轴运动控制、SoftMotion 库也能直接复用。这就意味着工程师的学习成本被大幅摊薄了——不用再为每个品牌的私有 IDE 重新学一遍。从产品手册的角度看TM1200 把 CODESYS 作为核心编程环境等于把自己接入了整个 CODESYS 生态。CODESYS 商店里有大量现成的库Modbus RTU/TCP 主从站库、OPC UA 服务端库、MQTT 客户端库、PID 控制库、运动控制库。你要读一台西门子 S7-200 SMART 的数据用 Modbus 库你要和 ABB 变频器通讯还是 Modbus你要把数据以 OPC UA 形式暴露给上位机直接调库。这些在传统 PLC 上可能要额外买通讯模块、额外授权才能做的事在 CODESYS 里往往就是添加一个库、配置几个参数的事。注意CODESYS 的版本差异很大TM1200 手册里通常会指定适配的 CODESYS 版本号比如 3.5 SP17 或 SP19。版本不匹配会导致库加载失败、编译报错甚至下载后设备不启动。拿到设备第一件事就是确认固件版本和 CODESYS 版本的对应关系。2.2 MQTT 为什么成了工业上云的首选协议工业现场的数据上报早年用的是 Modbus TCP 轮询、OPC DA、甚至自己写 Socket 发 JSON。这些方案不是不能用而是在“多设备、弱网络、需要双向通信”的场景下越来越吃力。MQTT 恰好补上了这些短板。MQTT 是基于发布/订阅模型的轻量级消息协议跑在 TCP 之上默认端口 1883加密是 8883。它的核心概念就三个Broker服务器、Publisher发布者、Subscriber订阅者。TM1200 作为 Publisher把设备状态发布到某个 Topic云端的看板、数据库、报警服务作为 Subscriber订阅这个 Topic 拿数据。反过来云端也可以往另一个 Topic 发布指令TM1200 订阅后执行——这就是远程控制。它比 Modbus 轮询强在哪我列几个实际项目里感受最深的点带宽占用极低MQTT 的最小报文头只有 2 个字节而 Modbus TCP 每次读写都要带一堆功能码和地址。现场几十台设备同时上报MQTT 的流量优势非常明显。支持断线重连和 QoS 等级QoS 0 是“发出去不管”QoS 1 是“至少送达一次”QoS 2 是“恰好送达一次”。对于温度、电流这种周期性数据QoS 0 够用对于报警事件QoS 1 更稳妥。天然支持一对多一个 Topic 可以被多个订阅者同时消费云端做数据存储、做实时看板、做报警推送互不干扰。遗嘱消息Last Will设备掉线时Broker 可以自动发布一条“遗嘱”消息告诉云端“这台设备失联了”。这个功能在设备状态监控里非常实用。TM1200 把 MQTT 客户端做进了固件或 CODESYS 库意味着你不需要额外加一个采集网关也不需要在外挂一个 Linux 盒子跑脚本。控制器本身就是采集器这是它和“PLC 采集网关”方案最大的区别。2.3 硬件接口与典型拓扑虽然不同批次的 TM1200 接口配置可能有差异但典型的上云 PLC 一般会包含这几类接口接口类型典型数量主要用途以太网口1-2 个CODESYS 下载、MQTT 上云、Modbus TCP、OPC UARS4851-2 路Modbus RTU 接传感器、电表、变频器RS2320-1 路老设备通讯、调试串口数字量输入 DI8-16 点按钮、限位、接近开关数字量输出 DO8-16 点继电器、指示灯、接触器模拟量输入 AI2-8 路温度、压力、液位变送器模拟量输出 AO0-4 路变频器频率给定、比例阀典型拓扑是这样的TM1200 通过 RS485 用 Modbus RTU 轮询现场的电表、温湿度传感器、变频器通过以太网口用 Modbus TCP 或 OPC UA 读取数控机床、机械臂的状态自身跑 PID 控制冷库温度或水处理加药所有数据在 CODESYS 程序里整理成结构体再通过 MQTT 发布到云端 Broker。云端可以是自己搭的 EMQX、Mosquitto也可以是阿里云、腾讯云、华为云的物联网平台。提示如果现场电磁干扰严重RS485 一定要用屏蔽双绞线屏蔽层单端接地。我见过太多因为屏蔽层两端接地形成地环流导致 Modbus 通讯随机丢包的案例。3. 核心细节解析CODESYS 工程配置与 MQTT 通讯要点3.1 CODESYS 新建工程与设备描述文件导入拿到 TM1200 后第一步不是急着写程序而是把设备描述文件Device Description装进 CODESYS。这个文件通常是一个 XML 或 Package里面定义了 TM1200 的 CPU 型号、IO 模块、通讯接口等硬件信息。没有它CODESYS 的设备树里根本找不到这台设备。操作路径大致是打开 CODESYS → 工具 → 设备仓库 → 安装设备描述文件 → 选择厂商提供的包 → 重启 CODESYS。然后在新建工程时设备选择界面就能看到 Tenlink TM1200 的条目。选好 CPU 型号后CODESYS 会自动生成一个设备树包含以太网口、串口、本地 IO 等节点。这里有个细节很多人会忽略设备描述文件里已经预设了各接口的默认参数比如以太网口的 IP 获取方式、串口的波特率。如果你现场的网络规划跟默认值不一样要在设备树的对应节点里改。改完之后记得“写入到设备”否则只改了工程里的配置实际设备还是老参数。3.2 网口 MAC 地址与 IP 配置的坑CODESYS 设备的网口 MAC 地址通常印在设备侧面标签上也可以在 CODESYS 的“设备”属性里看到。MAC 地址在下载程序时会被用到——CODESYS 通过扫描网络找到目标设备靠的就是 MAC 和 IP。实际项目里最常见的坑是 IP 冲突。TM1200 出厂默认 IP 可能是 192.168.1.10 之类的地址如果你现场路由器也是这个网段或者另一台设备占用了这个 IP下载就会失败。我的习惯是先不接现场网络用一根网线直连电脑把电脑 IP 改成和 TM1200 同网段进 CODESYS 扫描设备改好 IP 再接入现场交换机。另一个坑是双网口设备的网段划分。有些 TM1200 型号有两个网口一个用于编程和上云一个用于接现场设备。如果两个网口配到同一网段路由会乱MQTT 可能连不上。正确做法是编程/上云口走办公网段比如 192.168.1.x现场设备口走设备网段比如 192.168.10.x两者通过控制器内部路由隔离。3.3 MQTT 客户端库的添加与参数配置CODESYS 里用 MQTT通常有两种方式一是厂商提供的专用 MQTT 库二是 CODESYS 商店里的通用 MQTT 库比如 IIoT 库里的 MQTT Client。TM1200 的产品手册一般会推荐前者因为厂商库对自家硬件做了适配稳定性和性能更有保障。添加库的步骤在 CODESYS 的“库管理器”里点“添加库”→ 选择厂商提供的 .library 文件 → 确认版本 → 编译。编译通过后你就能在程序中调用 MQTT 的功能块了。MQTT 客户端的核心配置参数有这么几个Broker 地址和端口比如tcp://192.168.1.100:1883。如果 Broker 在公网要确认端口是否开放、是否需要 TLS。Client ID每个 MQTT 客户端的唯一标识。同一 Broker 下 Client ID 不能重复否则后连接的会把先连接的踢掉。我一般用“设备型号序列号”来拼保证唯一。用户名和密码如果 Broker 开了认证这里要填。很多现场问题其实是密码错了或者认证没开。Keep Alive 时间心跳间隔默认 60 秒。如果现场网络不稳定可以适当调大但太大会导致掉线检测变慢。Clean Session是否清除会话。如果设为 falseBroker 会保留订阅关系和未送达消息设为 true 则每次连接都是全新会话。对于周期性上报数据的场景一般设 true 就行。遗嘱消息配置一个 Topic 和 Payload设备异常掉线时 Broker 会自动发布。在 CODESYS 程序里MQTT 客户端的调用通常是这样的逻辑初始化 → 连接 Broker → 订阅控制 Topic → 周期性发布数据 Topic → 处理接收到的消息 → 异常时重连。功能块一般会提供Connect、Publish、Subscribe、Disconnect这些方法以及Connected、Error这些状态输出。注意MQTT 的 Topic 命名要有规划。我见过有人把所有数据都发到data这一个 Topic 下结果云端订阅者拿到一堆混杂的 JSON解析起来非常痛苦。建议按“厂区/产线/设备/数据类型”分层比如factory1/line2/tm1200_01/temperature。3.4 数据采集侧Modbus 与 OPC UA 的配合TM1200 上云的前提是先把数据采上来。现场设备五花八门通讯协议也各不相同。产品手册里通常会强调两种主要方式ModbusRTU/TCP和 OPC UA。Modbus 是最普遍的。电表、温湿度变送器、变频器、老式仪表大多支持 Modbus RTU走 RS485或 Modbus TCP走网口。在 CODESYS 里Modbus 主站库可以配置轮询周期、从站地址、寄存器地址、数据类型。这里的关键是寄存器地址映射——不同厂商的 Modbus 地址定义不一样有的从 0 开始有的从 1 开始有的用十进制有的用十六进制。手册里一般会给出常见设备的地址表但现场调试时还是要用 Modbus Poll 之类的工具先确认一遍。OPC UA 则更多用于数控机床、高端变频器、机械臂这类设备。它比 Modbus 复杂但信息模型更丰富能直接读到“主轴转速”“进给倍率”这种语义化的数据而不是一堆裸寄存器。TM1200 如果支持 OPC UA 客户端就可以直接订阅这些设备的数据节点。如果只支持 OPC UA 服务端那就是把 TM1200 自己的数据暴露给上位机。实际项目里我通常的做法是能用 Modbus 就用 Modbus简单可靠设备原生支持 OPC UA 且数据点很多时才用 OPC UA。因为 OPC UA 的配置复杂度、证书管理、网络开销都比 Modbus 高不少。3.5 运动控制与 SoftMotion 的取舍热词里出现了“CODESYS 六轴”“SoftMotion”“控制 6 轴机器人”说明很多人关心 TM1200 能不能做运动控制。CODESYS 的 SoftMotion 是一个软运动控制库可以在普通 CPU 上实现插补、凸轮、电子齿轮等功能。但要注意SoftMotion 对 CPU 性能和实时性要求很高不是所有上云 PLC 都能跑六轴插补。TM1200 如果定位是“上云 PLC”它的强项可能在数据采集和通讯而不是高精度多轴联动。产品手册里一般会明确说明支持几轴、支持哪些运动控制功能PTP、直线插补、圆弧插补等。如果你的项目是六轴机械臂的高精度轨迹控制建议先确认 TM1200 的 CPU 型号和 SoftMotion 授权情况必要时用专用的运动控制器。如果只是简单的多轴点位控制比如十字路口红绿灯那种定时顺序控制或者简单的伺服定位TM1200 完全能胜任。SoftMotion Light 是简化版适合对插补要求不高的场景资源占用也更低。4. 实操过程从零搭建一个 TM1200 上云 Demo4.1 硬件准备与接线检查先列一下我搭 Demo 用的东西TM1200 一台、24V 开关电源一个、网线两根、RS485 温湿度传感器一个、USB 转 RS485 模块一个调试用、安装了 CODESYS 的电脑一台。接线顺序先接电源确认 24V 极性正确TM1200 的电源端子一般有明确标注。然后接 RS485传感器的 A 接 TM1200 的 AB 接 B屏蔽层接 FG。最后接网线一根从 TM1200 的编程口到电脑一根从另一个网口到路由器如果 Broker 在局域网。上电后观察指示灯PWR 常亮表示供电正常RUN 闪烁表示程序在跑ERR 如果常亮或快闪说明有故障。第一次上电如果 ERR 亮先别慌很多时候是没下载程序或者 IO 模块没识别。4.2 CODESYS 工程创建与硬件组态打开 CODESYS新建标准工程设备选 Tenlink TM1200 对应型号编程语言选 ST结构化文本或 LD梯形图都行。我习惯用 ST 写逻辑因为处理字符串、JSON、数组更方便。在设备树里配置以太网口 IP192.168.1.50子网掩码 255.255.255.0RS485 串口波特率 9600数据位 8停止位 1无校验跟传感器一致添加 Modbus 主站设备配置从站地址和寄存器映射添加 MQTT 客户端实例填入 Broker 地址、端口、Client ID配置完先编译确认没有报错。然后点“登录到设备”CODESYS 会扫描网络找到 TM1200下载程序。下载完成后设备会自动重启并运行。4.3 Modbus 读取传感器数据假设温湿度传感器的温度寄存器是 40001保持寄存器地址 0湿度是 40002地址 1数据类型是 16 位整数实际值要除以 10。在 CODESYS 里Modbus 主站功能块会返回一个寄存器数组你从数组里取对应下标做缩放。// 伪代码示例 ModbusMaster( Execute : TRUE, SlaveAddress : 1, FunctionCode : 3, // 读保持寄存器 StartAddress : 0, Quantity : 2, Data : RegisterBuffer ); Temperature : INT_TO_REAL(RegisterBuffer[0]) / 10.0; Humidity : INT_TO_REAL(RegisterBuffer[1]) / 10.0;这里要注意字节序。Modbus 寄存器是 16 位的但有些设备的高低位是反的。如果读出来的值明显不对比如温度 25.3 读成 532就要做高低字节交换。CODESYS 里可以用SWAP函数或者位操作来处理。4.4 MQTT 发布数据到 Broker数据采到之后下一步是打包成 JSON 并通过 MQTT 发布。CODESYS 里处理 JSON 可以用现成的 JSON 库也可以手动拼字符串。手动拼虽然土但可控性强适合简单场景。// 拼 JSON 字符串 JsonStr : CONCAT({device:TM1200_01,temp:, REAL_TO_STRING(Temperature)); JsonStr : CONCAT(JsonStr, ,humi:, REAL_TO_STRING(Humidity)); JsonStr : CONCAT(JsonStr, ,ts:, ULINT_TO_STRING(Timestamp), }); // MQTT 发布 MQTTClient.Publish( Topic : factory1/line2/tm1200_01/status, Payload : JsonStr, QoS : 0, Retain : FALSE );发布周期我一般设 5 秒一次。太快了流量大、Broker 压力大太慢了实时性差。如果是报警事件用单独的 Topic 和 QoS 1确保不丢。4.5 云端验证与看板搭建Broker 我用的是 Mosquitto装在局域网的一台 Linux 机器上。启动命令很简单mosquitto -c /etc/mosquitto/mosquitto.conf -v-v是打印详细日志调试阶段很有用。然后在电脑上用 MQTT Explorer 连接 Broker订阅factory1/#就能看到 TM1200 发上来的数据。MQTT Explorer 是个图形化客户端比命令行直观得多推荐新手先用它验证。数据通了之后可以接 Node-RED 做看板或者写入 InfluxDB Grafana 做趋势图。如果要用云平台阿里云、腾讯云、华为云都有物联网平台支持 MQTT 接入配置好三元组ProductKey、DeviceName、DeviceSecret就能连。提示云端 Broker 如果开了 TLSTM1200 这边要配置证书。证书过期是常见的“昨天还好好的今天连不上”的原因之一。建议在日历上标记证书到期时间提前更换。4.6 远程控制回路的实现上云不只是为了看数据还要能控。远程控制的逻辑是云端往factory1/line2/tm1200_01/cmd这个 Topic 发布指令TM1200 订阅后解析并执行。// 订阅回调里解析指令 IF ReceivedTopic factory1/line2/tm1200_01/cmd THEN // 解析 JSON比如 {do1: true} IF Find(ReceivedPayload, do1:true) 0 THEN DO1 : TRUE; ELSIF Find(ReceivedPayload, do1:false) 0 THEN DO1 : FALSE; END_IF; END_IF这里的安全设计很重要。远程控制必须有权限校验和超时保护。我的做法是指令里带一个时间戳和校验码TM1200 检查时间戳在有效期内才执行同时设一个“远程控制使能”开关现场人员可以随时切断远程控制。否则云端误发一条指令现场设备突然动作可能出安全事故。5. 常见问题与排查技巧实录5.1 CODESYS 编译与下载类问题现象可能原因排查方法编译报错“找不到设备描述”设备描述文件未安装或版本不匹配重新安装厂商提供的设备包确认 CODESYS 版本下载失败“无法扫描到设备”IP 不同网段、防火墙拦截、网线问题直连电脑改同网段关闭防火墙换网线下载后设备不运行程序有运行时错误、看门狗超时看 ERR 灯用 CODESYS 在线查看日志数组越界报错循环变量超出数组长度检查 FOR 循环边界CODESYS 对数组越界很敏感数组越界是 CODESYS 新手最容易踩的坑。比如定义ARRAY[0..9] OF INT你循环到 10 就崩了。ST 语言里FOR i : 0 TO 10 DO会访问下标 10直接触发异常。建议所有数组访问前都加边界判断或者用FOR i : 0 TO 9 DO这种明确的范围。5.2 MQTT 连接与通讯类问题MQTT 连不上按这个顺序查网络通不通在 TM1200 所在的网络里 ping 一下 Broker 地址。如果 ping 不通先解决网络问题。端口开没开用telnet BrokerIP 1883测试端口。如果 telnet 不通可能是 Broker 没启动、防火墙拦截、或者端口不是 1883。Client ID 冲突如果两台设备用了同一个 Client ID会互相踢下线。检查每台设备的 Client ID 是否唯一。认证失败用户名密码错了或者 Broker 要求认证但设备没配。看 Broker 日志最直接。Topic 权限有些 Broker 配置了 ACL限制哪些 Client 能发布/订阅哪些 Topic。如果发布成功但订阅者收不到查 ACL。QoS 和 Retain 配置QoS 2 在某些 Broker 上性能很差非必要不用。Retain 消息如果设了 TRUE新订阅者会立刻收到最后一条有时候会造成误解。5.3 数据采集类问题Modbus 读不到数据常见原因从站地址错有的设备地址是 1有的是 2手册上写的和实际可能不一致。寄存器地址偏移PLC 手册上的 40001 对应 Modbus 协议里的地址 0但有些设备是从 1 开始。差一位就全错。数据类型不匹配温度可能是 16 位整数、32 位浮点、或者 BCD 码。类型不对读出来就是乱码。波特率/校验位不一致RS485 两端参数必须完全一致9600-8-N-1 和 9600-8-E-1 是通不了的。接线 A/B 反了RS485 的 A 和 B 接反现象是时通时不通或者完全不通。交换一下试试。终端电阻长距离 RS485 总线两端要接 120 欧终端电阻不接会导致信号反射、通讯不稳定。5.4 上云稳定性类问题设备跑几天就掉线或者数据时有时无我遇到过这几种情况网络抖动现场交换机质量差、网线过长、电磁干扰。换工业级交换机网线用屏蔽超五类。Keep Alive 太短网络稍有延迟就判定掉线。适当调大 Keep Alive同时开启自动重连。Broker 负载过高大量设备同时上报Broker 处理不过来。升级 Broker 配置或者做集群。设备内存泄漏CODESYS 程序里动态分配内存没释放跑久了内存耗尽。尽量避免动态内存用静态数组。看门狗复位程序某段逻辑耗时过长触发看门狗。优化代码把耗时操作拆分。5.5 独家避坑技巧技巧一先本地后云端。不要一上来就调 MQTT先用 CODESYS 的在线监控确认 Modbus 数据读对了再用 MQTT Explorer 确认 Broker 能收到数据最后才接云平台。分层排查问题定位快得多。技巧二给每个数据点加时间戳。云端收到数据后如果不知道是什么时候采集的做趋势分析会很麻烦。JSON 里带一个毫秒级时间戳成本很低价值很高。技巧三保留一个调试 Topic。除了业务数据 Topic再开一个debugTopic把程序内部的中间变量、错误码发上去。现场出问题时不用连电脑就能看到设备内部状态。技巧四MQTT 密码不要硬编码在程序里。如果程序被反编译密码就泄露了。可以放在设备的加密存储区或者用证书认证。技巧五定期备份 CODESYS 工程和 Broker 配置。我见过太多因为电脑坏了、服务器重装工程文件丢失只能重新写的情况。Git 也好网盘也好一定要有备份。6. 从单台设备到批量部署TM1200 的扩展思路单台 TM1200 跑通上云只是第一步实际项目里往往是几十台甚至上百台设备要接入。这时候要考虑的东西就多了。设备命名和 Topic 规划要有统一规则。我一般用{厂区}/{产线}/{设备类型}_{编号}/{数据类型}这种层级。比如sz/factory1/line2/tm1200_001/temperature。这样云端订阅可以用通配符sz/factory1///temperature一次性拿到所有设备的温度。固件和程序版本管理也很重要。批量部署时如果每台设备的程序版本不一样排查问题会疯掉。建议给每台设备的程序里加一个版本号变量随数据一起上报。云端一看版本号就知道哪些设备需要升级。OTA 远程升级是上云 PLC 的高级功能。CODESYS 支持通过 PLC 的 Web 服务器或者自定义协议做程序更新。但 OTA 有风险升级失败可能导致设备变砖。我的建议是OTA 功能要有回滚机制升级前备份当前程序升级后校验运行状态异常时自动回滚。数据存储和清理是云端的事但和 PLC 的发布策略有关。如果 PLC 每秒发一次数据云端存一年就是 3000 多万条记录。合理的做法是PLC 端做数据变化上报死区压缩云端做分级存储近期全量、远期降采样。安全加固不能忽视。MQTT 用 TLS 加密Broker 开认证和 ACL设备端禁用不必要的端口和服务程序里不要留后门。工业现场的安全事件越来越多上云设备是重点目标。7. 我个人在实际操作中的几点体会TM1200 这类上云 PLC 的出现确实把工业设备接入物联网的门槛降低了不少。以前做一个“PLC 数据上云”的项目要 PLC 工程师、网关工程师、后端工程师配合现在一个懂 CODESYS 和 MQTT 的工程师就能搞定大半。但工具越方便越容易让人忽略底层原理。我见过有人 MQTT 连不上就换 Broker换了三个还是连不上最后发现是网线水晶头没压好。也见过有人 Modbus 读不到数据就怀疑 PLC 坏了其实是传感器的 A/B 线接反了。上云的前提是本地控制稳定本地控制的前提是接线和参数正确这个顺序不能乱。另外CODESYS 生态虽然强大但版本碎片化是个现实问题。不同厂商的 CODESYS 运行时版本不同库的兼容性也不同。我的习惯是每个项目锁定一套 CODESYS 版本和库版本写进项目文档不轻易升级。升级带来的新功能往往抵不上兼容性问题带来的麻烦。最后说一个很小的点TM1200 的网口 MAC 地址建议在设备标签之外再在程序里读出来随数据上报。这样云端能建立“设备序列号-MAC-IP”的对应关系设备换 IP 或者换网段时排查起来方便很多。这个功能实现起来就几行代码但省下的时间可能是几个小时。