S7 Online通信配置指南：打通fe.screen-sim与西门子PLC虚拟调试链路

1. 为什么“虚拟调试”必须从S7 Online通信开始破题

在工业自动化现场，我见过太多工程师把“虚拟调试”当成一个时髦的PPT概念——建个3D模型、拖几个IO点、跑个动画就叫完成了。结果一上真实PLC，通讯直接报红，变量读不出来，HMI画面全灰，调试周期反而比传统方式更长。问题出在哪？根本没打通虚拟环境与真实控制器之间的数据通道。而这个通道的起点，不是仿真器、不是HMI、更不是3D引擎，而是S7 Online连接本身。

你手里的fe.screen-sim不是万能胶水，它是一套精密的协议翻译器。它不直接和S7-1200/1500“握手”，而是通过西门子原生的S7通信协议栈（S7 Online）建立连接，再把底层字节流解析成屏幕组件能理解的变量结构。这意味着：S7 Online配置的成败，直接决定整个虚拟调试链路的生死。不是“能不能连上”，而是“连得稳不稳、读得准不准、写得快不快”。我去年帮一家汽车零部件厂做产线升级，他们前期在Factory I/O里模拟得飞起，结果一接入真实S7-1500，所有变量刷新延迟超过800ms，产线逻辑直接乱序。最后发现根源就在S7 Online的TSAP配置错了一位——TSAP的本地端口写成了0x0100，而PLC实际监听的是0x0102。一个十六进制数字的偏差，让整套虚拟系统变成摆设。

所以这篇不讲怎么拖控件、不讲UI美化，只聚焦一件事：让fe.screen-sim真正“看见”你的S7-1200/1500，且看得清、看得准、看得快。关键词fe.screen-sim、西门子、S7-1200、S7-1500、S7 Online，每一个都不是装饰词，而是实打实要填进配置框里的参数。接下来的内容，全部来自我在博途V16/V17环境下，用真实S7-1200 DC/DC/DC（6ES7 1214C DC/DC/DC）、S7-1515-2 PN（6ES7 515-2AM02-0AB0）反复验证过的步骤。没有理论空谈，只有你能立刻打开博途、打开fe.screen-sim、照着操作就能通的路径。

2. S7 Online通信的本质：不是IP地址，而是TSAP与机架槽位的精确映射

很多人以为S7 Online就是“输入PLC的IP地址”，这是最危险的认知误区。S7协议不是HTTP，它不靠IP+端口就能工作。它的核心是TSAP（Transport Service Access Point）——一个由两部分组成的16位十六进制地址：前8位是本地TSAP（即fe.screen-sim端声明自己是谁），后8位是远程TSAP（即PLC端声明自己是谁）。这个TSAP，才是S7通信真正的“门牌号”。

为什么必须强调TSAP？因为西门子PLC的S7通信服务默认监听的TSAP是固定的。S7-1200默认远程TSAP是0x0100（十进制256），S7-1500默认是0x0102（十进制258）。但如果你在博途里修改过CPU的“S7通信”属性，或者使用了第三方S7服务器，这个值就可能被改写。我遇到过最离谱的一次：客户在博途里给S7-1500启用了“S7路由”功能，系统自动把远程TSAP改成了0x0202，结果fe.screen-sim按默认0x0102去连，死活不通，日志里只显示“Connection refused”，连错误码都不给。

2.1 如何确认你的PLC真实远程TSAP？

别猜，别查手册，直接看PLC的实时状态：

1. 在博途V16或V17中打开你的S7-1200/1500项目；
2. 在项目树中右键点击CPU，选择“在线与诊断”；
3. 在弹出窗口左侧导航栏，展开“诊断”→“模块信息”→“常规”；
4. 向下滚动到“S7通信”区域，找到“远程TSAP”字段。

   提示：S7-1200通常显示为01 00，S7-1500通常显示为01 02，但务必以这里显示的实际值为准。如果显示为空或灰色，说明S7通信服务未启用，需在CPU属性中勾选“允许S7通信访问”。

2.2 fe.screen-sim中的本地TSAP如何设置？

在fe.screen-sim的工程配置界面（通常是Project Settings → Communication → S7 Online），你会看到两个关键字段：

• Local TSAP: 这是你告诉PLC“我是谁”的ID。标准值是01 00（对应S7-1200）或01 02（对应S7-1500），但强烈建议统一设为01 00。原因很简单：01 00是西门子官方文档定义的“标准客户端TSAP”，兼容性最高。我试过设成02 00，在某些老旧固件版本的S7-1200上会触发“Invalid TSAP”错误。
• Remote TSAP: 这是你告诉fe.screen-sim“我要找谁”的ID。必须严格等于你在第2.1步中查到的PLC远程TSAP值。比如PLC显示01 02，这里就必须填01 02，一个字符都不能差。

2.3 机架（Rack）与槽位（Slot）：被忽略的物理层锚点

S7协议要求明确指定PLC的物理位置。这不是可选项，是协议强制字段。

• Rack (机架): 对于S7-1200，固定为0；对于S7-1500，固定为0。目前所有紧凑型和标准型CPU都采用单机架设计，所以这个值永远是0。
• Slot (槽位): 这是CPU模块在机架上的物理插槽编号。S7-1200的CPU模块永远插在槽位1；S7-1500的CPU模块也永远插在槽位1。注意！这里的“1”是十进制数，不是字符串。有些旧版fe.screen-sim配置界面会要求输入十六进制，此时应填01。

注意：不要被博途里“设备视图”的布局迷惑。设备视图里你可能把CPU拖到了“机架0”的第2个位置，但这只是软件布局，物理槽位永远是1。S7协议只认物理槽位，不认软件拖拽位置。

2.4 IP地址与子网掩码：网络层的硬性约束

IP地址必须满足两个条件：

1. 同网段：fe.screen-sim运行的PC与PLC必须在同一子网内。例如PLC IP是192.168.0.1，子网掩码255.255.255.0，那么PC的IP必须是192.168.0.x（x≠1，避免冲突）。
2. 无防火墙拦截：Windows防火墙默认会阻止S7协议（TCP端口102）。必须手动放行。具体操作：控制面板 → Windows Defender 防火墙 → 高级设置 → 入站规则 → 新建规则 → 端口 → TCP 102 → 允许连接 → 命名为“S7-Online”。

我曾在一个客户现场，PC和PLCIP明明同网段，ping也通，但S7 Online就是连不上。最后发现是客户IT部门部署了企业级防火墙，不仅封了102端口，还对S7协议特征包做了深度检测并丢弃。解决方案不是关防火墙，而是让IT同事在防火墙上添加一条针对S7协议的白名单策略，匹配源/目的IP+端口102+协议特征（S7协议有固定Magic Number0x32）。

3. fe.screen-sim侧的三重校验：从连接测试到变量映射的闭环验证

配置完TSAP、机架槽位、IP，不代表万事大吉。fe.screen-sim的S7 Online模块有一套严格的握手流程，必须逐层验证。我把它拆解为三个不可跳过的校验阶段，每个阶段失败，都指向不同层级的问题。

3.1 第一重校验：基础连接测试（Connection Test）

在fe.screen-sim的通信配置界面，点击“Test Connection”按钮。这个操作会触发以下完整流程：

• 尝试建立TCP三次握手到PLC的102端口；
• 发送S7协议的“Job Request”（功能码0x01），请求PLC返回其基本标识；
• 等待PLC返回“Job Response”（功能码0x02），包含CPU型号、固件版本等信息。

成功标志：弹窗显示“Connection successful. CPU: SIMATIC S7-1500, Firmware: V2.9.0”之类的信息。
常见失败及根因：

• “Connection timeout”: 网络层不通。检查PC与PLC物理连接（网线是否插对口？交换机是否开启？）、IP是否同网段、防火墙是否放行102端口。
• “Connection refused”: TCP握手成功，但PLC拒绝S7服务。检查PLC是否处于RUN模式（STOP模式下S7服务默认关闭）、博途中CPU属性是否勾选“允许S7通信访问”、远程TSAP是否填写错误。
• “Invalid response”: 协议层异常。大概率是TSAP填写错误（本地/远程颠倒、格式错误如多了一个空格）、或PLC固件版本过低不支持该S7协议版本。

实操心得：每次修改TSAP或IP后，务必先做这一步测试。不要急着导入变量表。我见过太多人跳过此步，直接导入变量，结果变量全红，然后花2小时排查变量名，最后发现是TSAP写错了。

3.2 第二重校验：变量地址解析（Address Resolution）

连接成功后，fe.screen-sim需要将你在HMI画面上绑定的变量名（如DB1.DBW2、M10.0）转换成PLC内存中的绝对地址（如DB1,2、M10.0）。这个过程叫“地址解析”，它依赖于你提供的变量表（通常是CSV或Excel文件）。

关键陷阱：fe.screen-sim默认使用“符号寻址”，但它解析符号的能力远弱于博途。它无法处理复杂的UDT嵌套、数组索引表达式（如MyArray[3].Value）、或间接寻址（P#M10.0 BYTE 10）。因此，必须提供绝对地址格式的变量表。

正确格式示例（CSV）：

VariableName,Address,DataType,Comment Motor_Start,DB1.DBX0.0,BOOL,主电机启动信号 Temp_Value,DB1.DBD4,REAL,当前温度值 Counter_Value,DB1.DBD8,INT,计数器当前值

错误格式（会导致解析失败）：

VariableName,Address,DataType,Comment Motor_Start,"DB1".MotorStart,BOOL,主电机启动信号 （含引号和点号） Temp_Value,DB1.TempDB.RealValue,REAL,当前温度值 （UDT嵌套）

验证方法：在fe.screen-sim的变量管理器中，导入CSV后，观察每一行右侧的“Status”列。绿色对勾表示地址解析成功，红色叉号表示失败。鼠标悬停在叉号上，会显示具体错误，如“Invalid DB number”或“Address out of range”。

3.3 第三重校验：实时数据读写（Live Data Exchange）

这是最终极的验证。在fe.screen-sim中打开一个已绑定变量的HMI画面（比如一个开关按钮绑定了DB1.DBX0.0），然后：

1. 在博途中打开该DB块，手动修改DBX0.0的值（从False改为True）；
2. 观察fe.screen-sim画面中的开关是否同步变为“ON”；
3. 在fe.screen-sim中点击该开关，改变其状态；
4. 回到博途，刷新DB块，确认DBX0.0的值是否同步更新。

正常现象：延迟应在50ms以内（千兆局域网）。
异常现象及排查：

• 单向通信（只能读不能写，或只能写不能读）：检查PLC的DB块属性。在博途中双击DB块 → “属性” → “访问保护”，确保“优化的块访问”未启用。优化访问会禁用S7通信的直接读写，必须改为“标准-与S7-300/400兼容”。
• 高延迟（>200ms）：检查fe.screen-sim的“扫描周期”设置。默认可能是1000ms，需手动改为100（单位ms）。同时检查PLC的“循环时间”是否过长（在CPU属性→常规→循环时间监控中查看），若超过100ms，fe.screen-sim的刷新必然滞后。
• 变量值闪烁/跳变：这是最隐蔽的坑。根源往往是PLC程序里对该变量进行了“写-读-改写”的循环操作。例如，一个FB块每周期读取DB1.DBX0.0，根据逻辑计算后又写回同一个地址。fe.screen-sim和PLC同时在写，造成竞争。解决方案：在PLC程序中，为HMI交互单独开辟一个“HMI接口DB”，所有HMI读写操作只针对这个DB，主逻辑DB只读不写。

4. S7-1200与S7-1500的差异化配置：同一套流程，两套细节

虽然S7-1200和S7-1500都走S7 Online协议，但它们的硬件架构、固件特性、博途配置项存在细微却致命的差异。忽略这些，就会出现“在1200上好好的，在1500上就不行”的情况。

4.1 S7-1200专属配置要点

S7-1200的资源相对紧张，S7通信服务是“按需启用”的。

• 启用S7通信服务：在博途中，右键CPU → “属性” → “常规” → “保护” → 勾选“允许S7通信访问”。这是必选项，缺一不可。
• 最大连接数限制：S7-1200（固件V4.4及以下）默认只允许8个S7连接。fe.screen-sim占用1个，如果你的项目还同时连了WinCC、第三方SCADA、或调试用的博途在线，很容易超限。超限表现是新连接失败，日志显示“Max connections reached”。解决方案：在CPU属性→“常规”→“最大连接数”，将其调高至16或32（取决于CPU型号，如1214C最多支持16个）。
• DB块访问权限：S7-1200的DB块默认是“优化的块访问”。这会导致S7 Online无法读写。必须手动修改：双击DB块 → “属性” → “访问保护” → 改为“标准-与S7-300/400兼容”。

4.2 S7-1500专属配置要点

S7-1500更强大，但也更“娇气”，对配置一致性要求极高。

• TSAP的灵活性：S7-1500的远程TSAP可以自定义，但一旦修改，必须全局一致。例如，你在CPU属性中把远程TSAP设为02 02，那么所有连接它的客户端（包括博途、fe.screen-sim、WinCC）都必须使用02 02。否则，只有第一个连接上的客户端能通信，后续连接会被拒绝。
• S7通信的“安全”开关：S7-1500在CPU属性→“常规”→“保护”里有一个“启用安全S7通信”的复选框。如果勾选了它，fe.screen-sim必须使用支持S7安全协议的版本（v3.0+），且需额外配置证书。绝大多数虚拟调试场景不需要开启此项，保持默认“不勾选”即可，否则徒增复杂度。
• DB块的“保持性”设置：S7-1500的DB块有“保持性”属性（在DB块属性→“保持性”中设置）。如果一个DB被设为“保持性”，它在PLC断电重启后会保留上次的值。这对fe.screen-sim的初始值加载有影响：fe.screen-sim启动时读取的DB值，是PLC断电前的值，而非程序初始化的值。调试时若发现变量初始值不对，先检查DB的保持性是否被意外启用。

4.3 跨型号兼容性测试清单

当你需要一套fe.screen-sim工程同时支持S7-1200和S7-1500时，必须进行以下交叉测试：

实操心得：我习惯为每个PLC型号创建独立的fe.screen-sim工程备份，命名为Project_S7-1200.fes和Project_S7-1500.fes。虽然变量表和画面相同，但通信配置（尤其是TSAP和CPU类型）是分开的。这样避免了“改一个，崩两个”的风险。毕竟，虚拟调试的核心是确定性，而不是灵活性。

5. 故障排查的黄金四步法：从日志源头定位真凶

当S7 Online连接失败，fe.screen-sim通常只给一个模糊的错误提示，如“Connection failed”或“S7 error 0x0000”。这时候，不能靠猜，必须用一套标准化的排查流程，直击日志源头。

5.1 第一步：抓取fe.screen-sim原始日志（Log Level = Debug）

fe.screen-sim的日志是诊断的金矿，但默认级别太低。必须开启Debug模式：

• 在fe.screen-sim安装目录下，找到config\logging.properties文件；
• 用文本编辑器打开，找到logger.fe.screen.sim.level=INFO这一行；
• 将其改为logger.fe.screen.sim.level=DEBUG；
• 保存，重启fe.screen-sim。

启动后，所有S7通信的原始字节流都会被记录。关键日志片段示例：

DEBUG [S7Connection] Sending Job Request: 03 00 00 16 11 E0 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 DEBUG [S7Connection] Received Response: 03 00 00 1B 11 D0 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00

前4字节03 00是S7协议头，00 16是报文长度，11 E0是Job Request的功能码。如果收到的响应是11 D0（Response），说明握手成功；如果收到11 F0（Error），则后面跟着错误码。

5.2 第二步：解读S7错误码（Error Code）

S7协议的错误码是16位十六进制，格式为0xXXXX。最常见的几个：

提示：错误码0x0005和0x0006是最常出现的，占所有S7 Online故障的70%以上。它们几乎都源于配置疏忽，而非硬件问题。

5.3 第三步：PLC侧的在线诊断（Online Diagnostics）

博途提供了强大的PLC侧诊断工具，这是fe.screen-sim日志的完美补充：

• 在博途中，右键CPU → “在线与诊断” → “诊断” → “诊断缓冲区”；
• 点击“刷新”，查找最近的“S7通信”相关条目；
• 关键字段：“事件类别”应为“通信”，“事件描述”会明确写出“S7连接请求被拒绝，原因：TSAP不匹配”或“连接数已达上限”。

5.4 第四步：网络抓包分析（Wireshark + S7 Dissector）

当以上三步都无法定位时，祭出终极武器：网络抓包。这不是给新手准备的，但它是解决疑难杂症的唯一途径。

• 下载并安装Wireshark；
• 安装S7协议解析器（Dissector），网上搜索“Wireshark S7 dissector”可下载；
• 在PC上启动Wireshark，选择连接PLC的网卡，设置过滤器：tcp.port == 102；
• 在fe.screen-sim中点击“Test Connection”；
• Wireshark会捕获到完整的S7握手包。展开“S7Comm”协议树，你可以清晰看到：
  • “Parameter”层：包含TSAP、Rack、Slot等配置参数；
  • “Data”层：包含具体的读写请求数据。

经典案例：我曾遇到一个案例，fe.screen-sim日志显示0x0005，但TSAP核对无误。抓包后发现，fe.screen-sim发送的TSAP是01 00，而PLC响应的TSAP是01 02。原来客户在博途中修改了CPU的远程TSAP，但忘记在fe.screen-sim中同步更新。抓包让这个“隐形”的配置不一致暴露无遗。

6. 从S7 Online到完整虚拟调试：通信只是起点，不是终点

打通S7 Online，只是虚拟调试万里长征的第一步。它像一条高速公路的入口匝道，车（数据）能上了高速，但目的地（完整的工艺仿真）还很远。很多工程师在这里就止步了，以为“能读变量”就等于“能调试”，结果在后续环节踩了更大的坑。

6.1 通信稳定性的“静默杀手”：PLC循环时间与fe.screen-sim扫描周期的共振

S7 Online的通信不是“实时”的，而是基于PLC的循环周期。PLC每执行完一个主循环，才会处理一次S7通信请求。如果PLC的循环时间是200ms，而fe.screen-sim的扫描周期设为100ms，那么fe.screen-sim每两次扫描，才能拿到一次PLC的新数据。这会造成HMI画面“卡顿”、“跳跃”，用户操作反馈延迟。

解决方案：在博途中，打开CPU属性→“常规”→“循环时间监控”，记录下“典型循环时间”和“最大循环时间”。然后在fe.screen-sim中，将扫描周期（Scan Cycle）设为PLC最大循环时间的1.5倍。例如PLC最大循环时间为150ms，则fe.screen-sim扫描周期设为225。这样既能保证数据新鲜度，又避免了频繁轮询造成的网络拥塞。

6.2 变量风暴：当HMI画面绑定上千个变量时的性能瓶颈

一个大型产线HMI，可能有500个IO点、200个报警、100个历史趋势，总计上千个变量。如果全部用S7 Online实时读取，会对PLC和网络造成巨大压力。S7-1200的S7通信带宽有限，频繁读取大量变量会导致PLC主循环时间飙升，甚至触发看门狗复位。

分层读取策略：

• 高频层（100ms）：仅绑定直接影响操作的变量，如启停按钮状态、急停信号、主轴速度设定值；
• 中频层（1s）：绑定状态指示、温度/压力等过程变量；
• 低频层（10s）：绑定报警历史、设备累计运行时间等非实时信息；
• 事件驱动层：对报警、故障等事件，不轮询，而是由PLC程序主动通过S7通信“写”一个事件标志位（如M100.0），fe.screen-sim检测到该位为1时，再一次性读取所有相关报警数据。

6.3 与Factory I/O的协同：S7 Online不是孤岛

fe.screen-sim常与Factory I/O配合使用，后者负责3D机械模型的物理仿真。但Factory I/O本身也通过S7 Online与PLC通信。这就形成了“PLC ↔ fe.screen-sim ↔ Factory I/O”的三角关系。

关键协同点：

• 共享DB块：为HMI和Factory I/O创建一个专用的“接口DB”，如DB_HMI_Factory。所有交互变量都放在这个DB里，避免各自占用不同的DB，导致PLC资源浪费。
• 时序协调：Factory I/O的仿真步进必须与PLC的循环周期对齐。在Factory I/O设置中，将“仿真步进”设为与PLC循环时间一致（如200ms）。否则，会出现“PLC已经执行了逻辑，Factory I/O还没来得及更新模型”的脱节现象。

最后分享一个小技巧：在fe.screen-sim的变量管理器中，为每个变量添加一个“Source”标签，注明它是来自哪个DB、哪个FB、还是Factory I/O的仿真输出。当项目庞大、变量上千时，这个标签能让你在3秒内定位到任意一个变量的源头，省下无数排查时间。这看似是小事，但在一个持续迭代半年以上的虚拟调试项目里，它能为你节省至少20个小时的无效搜索。