博途S7-1500作Modbus TCP客户端连接从站仿真器完整实战

1. 这个仿真实验到底在做什么

最近在做一个设备改造项目的前期验证，核心就是用博途（TIA Portal）里的 S7-1500 作为 Modbus TCP/IP Client，去连接远端一个 Modbus Slave 仿真软件。很多人听到“仿真”就觉得简单，凑个 IP 就能跑通，其实这套实验里最容易踩坑的点不在程序，而在网络栈、地址语义和状态码判断。这篇内容就是我完整跑一遍的记录，从选软件到组态、下载、联调、排错全写出来，代码和数据块结构也直接给可复现的版本，给后面需要做同类验证的人做个参考。

为什么值得写这篇文章？因为实际现场调试时，Modbus TCP 从站往往是第三方仪表、变频器或 RTU 网关，你不一定有实物设备，也不一定方便反复断电重启。在办公电脑上用 PLC 仿真器加 Modbus 从站工具，把通信逻辑、功能码、寄存器映射、轮询节奏全部验证过，再带着这套逻辑去现场，能省下至少半天到一天时间。适合谁看？刚接触 S7-1500 与 Modbus TCP 的电气工程师、做上位机联调的自动化开发人员，以及需要在无硬件条件下做教学演示的人。下面的实验我以“20260216”这个日期版本做了存档，方便后续追溯。

先说清楚实验里两个角色的关系。博途里的 S7-1500 是主动方，配置成 Modbus TCP/IP Client，负责发起 TCP 连接并发送 Modbus 请求；对端是运行在 PC 上的 Modbus Slave 仿真软件，扮演服务器角色，监听 502 端口等待连接，收到请求后返回寄存器或线圈数据。整个过程全部在本机完成，不需要真实 PLC，也不需要现场仪表。

2. 整体网络拓扑与软件选型

2.1 逻辑拓扑与数据流向

先想清楚数据怎么走，后面组态才不会乱。整个过程可以描述成下面这种结构：

code复制PC 主机
├── TIA Portal + S7-1500 项目（软件环境）
├── S7-PLCSIM（运行 S7-1500 仿真对象，绑定 PLCSIM 虚拟以太网适配器）
└── Modbus Slave 仿真软件（监听 TCP 502 端口）

数据链路：
S7-1500 虚拟 IP（如 192.168.0.1） -> TCP 连接 -> 127.0.0.1:502 -> Modbus Slave

在这条链路里，S7-1500 主动向从站工具的 502 端口发起 TCP 连接。连接建立后，PLC 通过 MB_CLIENT 功能块发出 Modbus 请求帧，比如读保持寄存器、写单个线圈；从站工具收到请求后组织响应帧返回。PLC 的 DONE 信号代表这一次读写交互完成，STATUS 给出结果，数据落在你指定的数据区里。

这里有一个非常关键的认知：虽然 PLC 和从站工具都跑在同一台 PC 上，但它们之间的通信并不是“内存直接交换”，而是完整走了一遍 TCP/IP 协议栈。因此，IP 地址是否能被路由到、端口是否能监听、防火墙是否放行，都会直接影响实验成败。

2.2 软件选型与版本搭配

这个实验的软件组合比较固定，我给出一个经过验证的组合，以及备选方案：

版本搭配是最容易忽略的事。博途和 PLCSIM 版本必须一致，比如博途 V17 配 PLCSIM V17，混用高版本工程和低版本仿真器会出现下载不兼容的问题。从站仿真软件尽量选择支持“TCP 监听”和“从站 ID”配置的工具，ModRSsim2 这类免费小工具足够用，界面简陋但功能完整。

2.3 为什么选 1500 而不是其他 PLC 方案

有人会问，为什么要用 S7-1500 做这个实验？用 S7-1200 行不行？答案是行，但 1500 有一些优势。S7-1500 的开放式通信指令集更完整，MB_CLIENT 和 MB_SERVER 都是标准化功能块，资源占用和连接管理更清晰；在纯仿真环境下，1500 的 PLCSIM 对 TCP/IP 协议栈的支持比旧型号稳定得多。S7-1200 也能做同样的事，但遇到复杂连接参数调整时，1500 的调试体验显然更好。

另外，如果你现场计划用 1500 做上位机或网关的角色，那这个仿真实验几乎就是现场工况的预演。提前把所有 Modbus 地址规划好，验证一遍读、写、频率、异常处理，比现场再翻手册高效得多。

3. 环境搭建与关键参数准备

3.1 安装并确认 PLCSIM 虚拟以太网适配器

我一直强调，S7-PLCSIM 第一次做这种 TCP 通信实验前，一定要先确认虚拟网卡是否存在。安装 PLCSIM 时，除了主程序，还有一个“PLCSIM 虚拟以太网适配器”组件，它会在系统里创建一个名为“Siemens PLCSIM Virtual Ethernet Adapter”的虚拟网卡。在 Windows 的网络连接里能看到才算装好，看不到就说明组件缺失或没启用。

这个适配器的作用相当于给仿真 PLC 提供了一个“看得见的网口”。没有它，S7-1500 仿真对象虽然能运行，但它发出的 TCP 数据包根本没有出口。实验前先打开命令提示符，用 ipconfig 检查是否存在该虚拟网卡，再确认它的 IP 是否为自动获取或与 PLC 同网段。

我的习惯是让虚拟网卡保持默认设置，然后在博途里给 PLC 分配一个固定 IP，比如 192.168.0.1。为什么给这个地址？因为虚拟适配器本身处在一个虚拟局域网里，PLC 的 IP 只要在这个网段内就能被本机协议栈正确识别。如果你发现虚拟网卡是 192.168.0.x，那 PLC 设成 192.168.0.1 最自然；如果虚拟网卡是其他网段，直接把 PLC 的 IP 和掩码改到同一网段即可。

3.2 在博途工程中分配 S7-1500 的 IP 地址

打开博途，新建一个 S7-1500 项目后，在“设备和网络”里进入 CPU 属性，设置 IP 地址和子网掩码。我这里用的是 CPU 1511-1 PN，以太网地址设为 192.168.0.1，子网掩码 255.255.255.0。设置完成后，编译整个站点，确认没有 IP 冲突或接口分配错误。

特别提醒一点，S7-1500 的 PN 接口默认开启，不需要额外激活 S7 通信，因为 MB_CLIENT 属于开放式通信，不依赖 S7 连接。但是在组态“连接资源”时要留够空间，如果项目里已经建了大量 S7 连接，Modbus TCP 连接可能会因为连接资源耗尽而建立失败。入门实验不需要管这些，但要有这个意识。

3.3 Modbus Slave 从站仿真工具的参数配置

从站工具的功能是模拟一个 Modbus TCP 服务器。以 ModRSsim2 为例，启动后首先要做的是进入 TCP 监听模式，端口设置为 502。为什么偏偏是 502？因为这是 Modbus TCP 的标准端口号，博途端默认也是连这个端口。如果你本机 502 被占用，可以在从站工具里改成其他端口，但相应地要在博途连接参数里改成同一端口。

接下来配置从站 ID 和寄存器区。我实验中规划了 10 个保持寄存器，即 40001 到 40010，分别填入 100、200、300 这样的测试值，方便观察读取结果。另外规划了 8 个线圈，即 00001 到 00008，作为写入试验的对象。注意，不同工具对地址显示方式不一样，有的显示“0 到 9”，有的显示“40001 到 40010”，本质上都是同一个保持寄存器区，关键在于地址语义要前后统一。

我强烈建议把从站工具的监听地址设置为 0.0.0.0 或 127.0.0.1。0.0.0.0 表示监听所有网卡接口，避免因虚拟网卡和回环地址的路由问题导致收不到连接；127.0.0.1 表示只监听本机回环地址，两者都可以。实际测试中，PLC 侧 remoteAddress 设置为 127.0.0.1 时，从站监听 0.0.0.0 最稳。

4. 博途侧组态：MB_CLIENT 的完整用法

4.1 连接参数数据结构详解

MB_CLIENT 功能块本身并不直接包含 IP 和端口信息，它通过一个名为 CONNECT 的指针参数引用一个数据结构，这个结构里保存了访问点、连接 ID、通信类型、远程地址、远程端口等全部信息。很多人第一次用就觉得奇怪，为什么要绕一层？因为这样设计能让同一个功能块复用不同连接配置，程序里只需要切换指针指向不同连接数据块即可。

在博途里新建一个全局数据块，命名为“ModbusTCP_Conn”，内容如下：

code复制DATA_BLOCK "ModbusTCP_Conn"
VERSION : 0.1
STRUCT
    interfaceId : CONNECT_REFERENCE := 64;
    id : CONN_OUC := 1;
    connectionType : BYTE := B#16#11;
    activeEstablished : BOOL := TRUE;
    remoteAddress : STRING[15] := '127.0.0.1';
    remotePort : INT := 502;
    localPort : INT := 0;
END_STRUCT
BEGIN
END_DATA_BLOCK

逐个解释各参数的含义。interfaceId 是硬件接口标识，64 对应 S7-1500 的 PROFINET 接口，这是一个约定值，不是随意取的。id 是连接 ID，在同一 PLC 里要唯一，如果后面还想建第二条 Modbus 连接，第二个数据块的 id 就改成 2。connectionType 是通信类型，B#16#11 表示 TCP 协议，Modbus TCP 的底层就是 TCP，所以这里固定是这个值。

activeEstablished 为 TRUE 时，PLC 作为主动方发起连接，这正是 Client 模式；如果为 FALSE，MB_CLIENT 就变成被动等待，那就不再是客户端的行为了。remoteAddress 是目标从站的 IP 地址，因为我们做本机仿真，填 127.0.0.1 最省心，如果你把从站工具运行在别的电脑上，这里就要填那台电脑的真实 IP。remotePort 填 502，localPort 填 0 表示由系统自动分配本地端口，不用手动指定。

4.2 MB_CLIENT 引脚语义与地址映射关系

调用 MB_CLIENT 时，需要关注的引脚有 REQ、DISCONNECT、CONNECT、MB_MODE、MB_DATA_ADDR、MB_DATA_LEN、MB_DATA_PTR，以及输出 DONE、BUSY、ERROR、STATUS。REQ 是请求触发信号，既可以长期置 TRUE 保持连接持续轮询，也可以用上升沿做一次单次读写。DISCONNECT 平时置 FALSE，需要通过程序断开连接时再置 TRUE。

MB_MODE 决定本次操作是读还是写，0 表示读，1 表示写。MB_DATA_ADDR 是 Modbus 侧的起始地址，MB_DATA_LEN 是数据长度，MB_DATA_PTR 指向 PLC 侧存放数据的内存区域。

这里必须重点讲地址映射，因为这是整个实验里最容易翻车的地方。MB_CLIENT 根据 MB_DATA_ADDR 所在的区间自动选择功能码，规则如下：

也就是说，你想读保持寄存器，就把 MB_DATA_ADDR 填 40001，这就是博途侧的 1 号保持寄存器。要注意，标准 Modbus 协议里，协议编号 0 对应的是 PLC 侧 40001，1 对应 40002。如果你在从站工具上看到的是“保持寄存器 0 开始”，那它和博途 40001 是同一个目标。

MB_DATA_PTR 的指向类型也得说清楚。读保持寄存器时，数据区通常用 ARRAY[0..9] OF WORD；读写线圈时，用 ARRAY[0..9] OF BYTE 或者 BOOL 数组都行，但位操作在 PLC 侧要注意位序。我的建议是：寄存器一律用 WORD/WORD 数组，线圈一律用 BYTE 数组，然后通过 AT 覆盖方式或位逻辑去取，避免混用导致的数据错位。

4.3 在 OB1 里编写读写轮询逻辑

我用一个简化版的 SCL 片段来演示在博途里的调用方式，这个逻辑放在 OB1 里，通过一个定时触发位来发起请求：

code复制// 数据块 MODBUS_DATA
// ReadBuf: ARRAY[0..9] OF WORD
// WriteBuf: ARRAY[0..9] OF WORD

IF #reqTrig AND NOT #reqTrigPrev THEN
    #mode := 0;                 // 0=读，1=写
    #dataAddr := 40001;         // 从站保持寄存器起始地址
    #dataLen := 10;             // 读取 10 个字
    #reqTrigPrev := #reqTrig;

    "MB_CLIENT_DB"(
        REQ := TRUE,
        DISCONNECT := FALSE,
        CONNECT := "ModbusTCP_Conn",
        MB_MODE := #mode,
        MB_DATA_ADDR := #dataAddr,
        MB_DATA_LEN := #dataLen,
        MB_DATA_PTR := "MODBUS_DATA".ReadBuf[0],
        DONE => #done,
        BUSY => #busy,
        ERROR => #error,
        STATUS => #status
    );
END_IF;

注意，MB_DATA_PTR 填的是数组首元素地址，博途会自动把这个 ANY 指针指向整个数组区域。MB_CLIENT 不是每次调用都发一帧，而是靠 REQ 信号的边沿触发。如果你用周期脉冲作为 REQ，每个上升沿会发起一次完整事务；如果你保持 REQ 一直为 TRUE，连接会保持建立，块会在内部循环处理请求，DONE 会在每轮完成后短暂置位。

我个人的建议是，从简单开始，第一次实验先用“手动置位 REQ”的方式。在博途监控表里直接把 REQ 关联的变量置 TRUE，观察 DONE 和 STATUS，确认通了之后再改成周期轮询或自动状态机。这样定位问题会更快。

4.4 下载到 PLCSIM 并启动仿真的完整操作

下载前先把工程编译一遍，确保没有语法错误。启动 PLCSIM，会自动弹出一个仿真器窗口。下载方式跟在真实 PLC 上一样，在博途里点击下载到设备，目标选择 PLCSIM，下载后把 CPU 切换到 RUN 模式。这时你打开 PLCSIM 的虚拟以太网适配器状态，应该能看到 192.168.0.1 这个虚拟 IP 已经激活。

从站软件此时应该已经处于监听状态。如果顺序反了也不影响，先启动 PLC 再启动从站，或者先从站后 PLC，TCP 客户端发起连接的时间点可以比服务器晚，只要在请求发出前监听就位即可。

我实验时习惯先在监控表里加上 MB_CLIENT 的 STATUS、DONE、ERROR，以及 ReadBuf[0] 到 ReadBuf[9]。把这些变量全部拖进监控表，运行后一次看清全部状态。

5. 联调过程实录：从连接建立到数据变化

5.1 第一次触发 REQ 时观察到的状态变化

当我第一次把 REQ 置 TRUE 后，瞬间看到 DONE 变为 TRUE，STATUS 为 16#0000，ERROR 为 FALSE，ReadBuf 里立刻出现了从站工具预置的 100、200、300 这些值。这时立刻到从站工具里看连接列表，能看到一个来自 127.0.0.1 的 TCP 连接已经建立，连接计数从 0 变 1。这一步跑通，意味着 TCP 握手、Modbus 请求、响应解析三者全部正常。

如果这一帧没有通，不要急着查程序。先看从站工具是不是真的在监听，用 netstat -ano | findstr 502 确认监听状态；再检查 PLCSIM 虚拟网卡是否激活。80% 的首次连接失败都出在这两层。

5.2 从站侧数据变化与地址偏移验证

读保持寄存器跑通后，我在从站工具里手动把 40003 的值从 300 改成 8888，博途监控表里的 ReadBuf[2] 立刻变成 8888，基本没延迟。这就验证了地址对应关系：博途 40001 对应从站工具的 40001（或协议地址 0），40003 对应 ReadBuf[2]。如果发现数值错位一位，就去检查从站工具里的地址是否从 1 开始还是从 0 开始，常见的是地址定义习惯不一致导致偏移。

5.3 写操作联调与报文验证

读通了就测试写。把 MB_MODE 改成 1，MB_DATA_ADDR 设成 40001，MB_DATA_LEN 设成 5，MB_DATA_PTR 指向 WriteBuf。预先在 WriteBuf 里填好 10、20、30、40、50，触发 REQ 后，从站工具上对应寄存器立刻变成这些值。写操作用的是 0x10 功能码，也就是写多个保持寄存器。

如果从站工具支持报文日志，此时打开日志能看到完整的请求和响应帧，请求帧里的 Transaction Identifier 和 Protocol Identifier 会按标准排列。我一般会做一次非 10 的倍数长度的写入，比如写 9 个字，确认长度字段和地址连续性没有问题。

5.4 仿真环境下的几个特殊现象

仿真环境有个特点，你从监控表里观察数据刷新时，感觉不到真实的通信延迟，因为都在本机协议栈里跑，时延在毫秒级。但如果你的从站工具设置了应答延迟模拟，比如强制加 500ms 延迟，PLC 侧会观察到 BUSY 状态持续时间明显变长。这可以帮你理解 MB_CLIENT 的状态机行为：一个请求从发出到完成，BUSY 会一直为 TRUE，直到收到响应或超时。

另外注意，仿真环境下 PLC 的时钟是虚拟的，跟真实 PLC 的时钟精度不完全一样。如果实验里用到时间戳记录，不要把它当作精确现场时序来对待。

6. 常见问题与排查技巧

6.1 STATUS 错误码速查表

MODBUS TCP 通信失败的典型状态码，这里我整理成表，方便对照：

这些状态码要结合上下文看。比如 8102，如果从站工具本身没收到任何连接，先把问题定位到网络层；如果连接建立了但收到 8102，那就要检查功能码和地址是否匹配。一个简单的原则：先看连接层，再看协议层，最后看数据层。

6.2 从站工具收不到连接请求时的排查步骤

如果 PLC 侧报 8101，但从站工具完全没反应，按这个顺序排查。

第一，确认从站工具是否真正监听在 502 端口。命令行执行 netstat -ano | findstr 502，如果能看到 LISTENING，说明监听正常；如果什么也没有，说明工具没启动监听模式，或者被防火墙拦截。

第二，检查 PLCSIM 虚拟以太网适配器是否启用。打开 Windows 网络适配器列表，找到虚拟适配器，确认它处于启用状态。如果适配器是禁用状态，PLC 的 TCP 数据包根本没有出口。

第三，把从站工具的监听地址改成 0.0.0.0。有些工具默认只监听 127.0.0.1 或第一块物理网卡，而 PLCSIM 虚拟网卡不一定属于同一接口，监听所有接口可以避开这个坑。

第四，临时关闭 Windows 防火墙，或者专门放行 502 端口的入站连接。完成实验后再把防火墙规则收回来，不要一直关着。

6.3 连接参数配置中的隐性错误

我在实验中遇到过一个非常隐蔽的问题：connectionType 被写成了 B#16#12，也就是 ISO-on-TCP，这是 S7 通信的传输层，不是 Modbus 需要的 TCP。MB_CLIENT 对 connectionType 的取值很敏感，写错后 PLC 依然能“建立连接”，但请求帧完全不会被从站工具识别。所以这个字段必须保持 B#16#11。

还有一个高频错误是 remoteAddress 里写了带空格的字符串，比如 ' 127.0.0.1'。博途不会自动去首尾空格，直接用字符串比较，结果就连不上。检查时看变量的显示值，确认没有多余字符。id 重复也是常见问题，如果项目里已经有一个 TCP 连接用了 id=1，第二个连接必须改成其他值。

6.4 地址偏移与长度不匹配导致的假报错

我以前带过一个同事做实验，PLC 一直报 8002，我让他把从站工具的寄存器区删掉重配，果然就好了。问题出在从站工具只建了 10 个保持寄存器，PLC 却一次要读 11 个，地址越界后从站直接返回异常响应。Modbus 协议规定非法地址必须返回异常帧，这就是 8002 的来源。解决办法很简单，把 MB_DATA_LEN 改成从站实际配置的长度以内，或者从站工具多建一些寄存器区。

地址偏移也一样，很多从站工具在显示保持寄存器时从 0 开始，而 PLC 侧从 40001 开始，两者对应关系要换算清楚。比如从站工具显示地址 5，实际对应的是协议保持寄存器映射到 PLC 侧的 40006。如果写程序时把 40005 当成从站工具的地址 5，读取到的就是另一个寄存器的值。建议在实验记录表里明确标注“博途地址”和“从站工具地址”两列，防止混用。

6.5 REQ 信号的控制策略与自动重连

MB_CLIENT 的 REQ 信号有两种常见玩法。一是长期置 TRUE，让连接一直保持，适合需要高频轮询的场景；二是用周期脉冲触发，每次上升沿执行一次请求，适合低频读取或写操作。

如果使用周期脉冲，你会注意到每轮完成后 DONE 会短暂置位，紧接着 BUSY 变 FALSE，然后进入下一轮。如果中途从站工具重启了，连接会断开，PLC 侧需要重新发起连接。这时候最简单的处理方式是让 REQ 保持一个固定频率的脉冲，MB_CLIENT 内部会在下次触发时重新建立连接，不需要你写额外重连逻辑。但如果使用长期 TRUE 的方案，从站重启后 REQ 还是 TRUE，连接恢复机制会相对慢一些。我习惯先用低频脉冲做联调，确认没问题后再根据实际需求决定是否改成长期保持。

6.6 从站工具被系统权限拦住的坑

端口 502 属于低于 1024 的端口，在 Windows 上监听这样的端口通常需要管理员权限。如果你启动从站工具时没右键“以管理员身份运行”，很可能出现工具显示正在运行但端口没有实际监听。判断方法很简单，看 netstat 输出里有没有 502，或者用 telnet 127.0.0.1 502 试一下，连不通就去检查权限。

7. 实操经验和最后几句提醒

这套实验我前后跑过几次，起初也栽过跟头，几个经验比较值得拿出来说。

第一，本机仿真时，PLC 的 remoteAddress 直接用 127.0.0.1 是最稳的方案。我试过在 PLCSIM 虚拟网卡和物理网卡之间折腾 IP 路由，最后发现绕回环地址反而最简单，因为仿真 PLC 和从站工具本来就在同一台机器的协议栈上。

第二，调试顺序比什么都重要。先手动触发一次 REQ，确认 STATUS、DONE、ERROR，再去看数据内容。很多人在数据对不上时还在改程序，其实是前面的地址映射就已经偏了。从站工具上的地址 0 和 PLC 侧的 40001 是同一个对象，这一点想清楚，能省掉一大半调试时间。

第三，实验记录要保留版本。像这个实验我命名为“20260216”就是把日期作为版本号，记录当时的软件版本、IP 规划、寄存器映射表、状态码出现的情况。后面做类似项目，直接翻这份记录对照，不用重新踩坑。

如果后续你想扩展方向，这套实验还可以继续演变成双机仿真：两台 S7-1500 仿真对象，一个作 MB_CLIENT，一个作 MB_SERVER，跑通之后你已经具备完整的 Modbus TCP 主从联调能力。再往上走，可以接入真实仪表，用同样的程序做现场验证。无论怎么扩展，先把本机仿真这一环吃透，后面就顺了。