这三家 PLC 是什么，用在哪些设备上
汇川、信捷、台达是国内非标自动化设备上用得最多的中小型 PLC 品牌。 常见的场合是组装线、检测台、贴合机、点胶机、绕线机、包装机、 锂电与光伏的辅助工站、以及各类专机的主控。 配套的伺服与变频器往往也是同一品牌， 有时候数采需求不只是读 PLC，还要读驱动器的电流、转矩、报警字。
从数采角度看，这三家的共同特点是对 Modbus 支持得比较到位——
RS485 口能配成 Modbus RTU 从站，带以太网口的机型多数能做 Modbus TCP 从站。
这意味着不需要买私有协议栈、不需要装原厂中间件，
协议层面的工作量很小。
敏洽 SCADA 数采软件
在这类现场最常用的是 modbus_rtu_over_tcp 驱动
（485 经串口服务器转以太网后按 RTU 报文访问），
遇到私有的上位机专用协议或者特殊帧格式时用
python_custom（Python 自定义协议引擎，子进程隔离，带调试器面板）补齐。
实际会遇到的几个坑
1. 软元件地址与 Modbus 寄存器地址的映射各家不同
这是最高频的错误来源。PLC 程序里写的是 D100、M20 这样的软元件，
Modbus 请求里发的是寄存器地址，两者之间有一张品牌与系列特定的映射表。
各家的规则不一样：偏移量不同、位软元件（M/Y）打包成字的方式不同、
有的品牌把不同区域映射到不连续的地址段。
必须查对应型号的通信手册，不要拿另一个型号的经验去套。
映射错的后果是读到的是别的地址的值，
而且返回的往往是看起来合理的数字，不会报错——非常难发现。
2. 地址差 1：协议地址还是 PLC 地址
Modbus 的传统文档习惯把保持寄存器写成 40001 起， 而报文里实际发的偏移量是从 0 起。 不同厂家的手册在这一点上写法不统一， 有的直接给报文用的地址，有的给 4xxxx 形式。 表现是读出来的所有数据都整体错开一个位置， 如果点表里相邻地址的数据类型相同，很容易被当成正常数据用下去。 验证方法很简单：找一个已知会变化的点（比如产量计数）， 让设备动一下，看变的是不是你以为的那个地址。
3. 32 位数与浮点数的字序
32 位整数和浮点数占两个寄存器，谁在前面各家习惯不同， 甚至同一品牌不同系列也会变。 症状是数值看起来数量级完全不对，或者小数点位置离谱。 排查方法是让设备产生一个已知的值（比如把计数器置到 1000）， 然后把两种字序都算一遍看哪个对得上。 点表里应该明确标注每个 32 位数据项的字序， 不要留给采集侧猜。同理还有有符号与无符号的区别， 温度这类可能为负的量如果按无符号解析，零下就变成六万多。
4. 缩放系数与枚举含义没有跟着点表给
PLC 里常把带小数的量放大整数倍存成整数（25.6℃ 存成 256）， 也常用一个状态字的不同数值代表不同状态（0 待机、1 运行、2 报警…）。 这些约定只存在于设备厂工程师的脑子里和 PLC 程序注释里。 点表如果只有地址和数据类型，采集侧取到的数字是没法解释的。 要求点表必须包含缩放系数（或换算公式）、单位、 以及状态字/报警字每一位或每个取值的含义。 报警字尤其重要——按位定义的报警字如果没有位含义说明， 报警看板就没法做。
5. 485 口被 HMI 占用，或者一条线上挂了太多东西
国产 PLC 的 485 口经常已经接了触摸屏、变频器、伺服或温控表。 再加一路采集有两个问题： 一是 PLC 作从站时可能只支持单主站，采集程序和 HMI 同时发请求会互相干扰； 二是总线上节点多、轮询周期长，采集频率上不去。 稳妥的做法是向设备厂要一个独立的通信口 （加通信扩展模块，或用带以太网的机型）， 或者由 PLC 把需要外发的数据集中整理到一段连续的寄存器区， 采集侧一次批量读完，把请求次数压到最低。
6. 数据是「瞬时值」还是「已锁存的结果」
采集侧按周期轮询，PLC 里的值是随时在变的。 如果要的是件级结果（这一件的测量值、这一件的判定）， 直接轮询瞬时寄存器一定会漏件或者读到中间态。 正确做法是让 PLC 在每件完成时把结果锁存到固定寄存器， 并同时把一个序号或握手位加一， 采集侧监视这个序号变化再去读结果区，读完回写确认。 这套握手机制必须在接口文档里定清楚，属于设备厂 PLC 程序要配合改的部分—— 不能等软件开发到一半才提。
接入方式与硬件条件
| 项目 | 要求与说明 |
|---|---|
| 首选接法 | PLC 带以太网口且支持 Modbus TCP 从站：网线直接接入，最简单 |
| 次选接法 | RS485 配成 Modbus RTU 从站，经串口服务器转以太网，驱动用 modbus_rtu_over_tcp |
| 特殊协议 | 只开放上位机专用协议或自定义帧格式时，用 python_custom 自定义协议引擎实现 |
| 通信口 | 建议向设备厂要独立通信口，避免与 HMI、伺服、温控表共用同一条 485 |
| 485 布线 | 手拉手、屏蔽双绞线、两端 120Ω 终端电阻、屏蔽层单端接地、与动力线分槽 |
| 寄存器规划 | 要求 PLC 把外发数据集中到连续寄存器区，便于一次批量读取 |
| 件级结果 | 需 PLC 侧做锁存 + 序号/握手位，采集侧按序号变化触发读取并回写确认 |
| 点表 | 名称、软元件地址、Modbus 地址、数据类型、字序、缩放系数、单位、枚举与位含义、更新频率 |
硬件上需要客户或设备厂准备的是：通信口（可能要加扩展模块）、串口服务器（485 方案）、 以及交换机端口与 IP 规划。串口服务器型号敏洽可以给建议， PLC 程序侧的寄存器规划与握手逻辑由设备厂的电控工程师实现。 这部分分工要在项目启动时就说清楚， 因为它涉及设备厂改 PLC 程序的工作量。
相关交付情况
国产 PLC 现场的经验是：协议本身几乎不花时间， 绝大部分沟通量在点表与握手机制上。 所以敏洽的做法是项目一开始先出一份点表模板给设备厂填， 模板里把字序、缩放系数、枚举含义这些容易漏的列都预置好， 填完再评估软件工作量。 点表定稿之后接口就固定了，两边可以并行开发—— 设备厂改 PLC 程序，软件侧按点表做解析与看板， 现场联调只核对数值和握手时序。
接口先定后开发的具体切分方式见 上位机软件外包怎么切分， 更多交付情况见 案例中心。
常见问题
有具体设备清单或工件样品，可以直接给判断
提供设备型号、PLC 品牌与需要采集的数据项，或提供被检工件照片与精度要求，敏洽可先给出可行性判断与硬件前置条件，再谈软件工作量与报价。