企业官网建设流程全解析

我拿到这本西门子AF框架手册的第十三章时，前后翻了不下十遍。这一章不像前面章节那样讲硬件组态或者基础逻辑，而是把整条自动化线的“神经脉络”——通信与驱动控制——集中摊开来讲。无论是S7-1500做为主站，还是S7-200 SMART通过RS485挂变频器，又或者是MCGS触摸屏跨网段访问1500，AF框架给出的都不是“单点能通就行”的野路子，而是一套能复制到下一个项目、再下一个项目的标准套路。这篇文章我就以第十三章为主线，把自己实际照着做、踩坑、改参数的过程全部记录下来，希望能帮到正在啃框架、或者正在现场被通信问题折磨的人。

1. 第十三章的内容定位：通信控制才是框架的骨架

1.1 AF框架的章节脉络与这一章的位置

AF框架（Automation Framework）往大了说是西门子面向TIA Portal的一套标准化工程模板，往小了说就是一套“别人已经替你踩过坑”的项目结构。前面章节通常涉及硬件配置、变量表规范、基础FB封装，到了第十三章，主题会明显转向系统级联调，也就是PLC与变频器、HMI、机器人、上级SCADA之间的数据交换，以及围绕这些交换建立的驱动控制逻辑。

我在实际项目中体会最深的一点是：很多工程师单点调试没问题，一旦把PLC、变频器、触摸屏、机器人全部串起来，问题就冒出来了。第十三章恰恰就是解决这个“串起来”的过程，包括如何规划通信数据块、如何用一个统一的FB去管理多台变频器的启停和频率给定，以及如何在不同网段之间建立可靠的访问路径。

这一章的受众很明确：已经能做基本TIA Portal编程、但还没形成标准化通信思维的工程师。如果你刚接触西门子，建议先把变量表和基本FC/FB搞清楚再来啃这一章，否则里面的DB结构和间接寻址会让你晕。

1.2 为什么说这只是“翻译”，不是“照抄”

标题里的“翻译”两个字，我觉得得两说。一方面是把英文原版手册翻译成中文，方便团队内部分享和培训；另一方面，真正有价值的翻译是把框架的“思想”翻译成你所在现场能落地的东西。比如手册里用S7-1500加ET200SP做演示，但你现场全是S7-200 SMART加森兰SB200变频器，那数据映射、通信指令都不能照搬，得“翻译”成西门子S7协议或MODBUS RTU的写法。

第十三章很聪明的一点是：它没有替你做选型，而是给了你一套“选型后的组织方式”。也就是说，无论你用1500的PN口走PROFINET，还是用200 SMART配485口走MODBUS，框架层面的DB结构、FB接口、HMI画面结构都是通用的，变的只有底层的通信指令。这个“隔离变化”的思路，是整章最值钱的干货。

2. 深入解析第十三章的核心设计思路

2.1 从“通讯指令”到“通信框架”的思维转变

很多人在做PLC与变频器通信时，脑子里只有一件事情：把指令发出去，把数据收回来。所以程序里会出现好几处单独的MOV、CRC校验、自由口收发代码，每个地方风格都不一样，出问题只能一个个看。第十三章强调的是建立一个围绕通信的“框架层”，包含以下固定成员：

• 通信参数配置块：存放站号、波特率、数据位、停止位、校验方式
• 数据映射区：把变频器的运行频率、电流、状态字、故障码统一映射到结构体
• 通信管理FB：负责轮询、超时处理、错误计数和状态上报
• 操作接口：独立于具体通信协议，HMI只跟这个接口打交道

以森兰SB200变频器和S7-200 SMART走MODBUS RTU为例，传统做法是在主程序中直接写一段发送和接收。放进AF框架后，程序段变为“点名要频率->框架自动打包请求->等待响应->更新状态字->通知主逻辑”。这样一来，上层逻辑永远不知道底层是MODBUS还是PROFINET，下次换变频器品牌，只需要替换通信驱动FB，上层纹丝不动。

2.2 报文格式、数据块规划与编址规范

第十三章对数据块规划有一套明确约定。它建议为每台驱动设备单独建一个背景DB，DB里复用一种标准结构。我实际参照过的结构大致长这样：

TYPE "Type_DriveTelegram" VERSION : 0.1 STRUCT DriveState : Word; // 状态字：0x04F2等 DriveSpeed : Real; // 实际转速 DriveCurrent : Real; // 实际电流 DriveFaultCode : Word; // 故障代码 SetpointSpeed : Real; // 设定转速 CtrlCommand : Word; // 控制字：启停、复位 ErrorCount : Int; // 通信错误累计 END_STRUCT END_TYPE

为什么单独建“类型”而不直接用单个变量？因为当你有6台变频器时，你可以把这些结构体放到一个数组里（Drives : Array[1..6] of "Type_DriveTelegram"），再用一个循环FB去轮询管理，程序量不会随着设备数量线性膨胀。这就是框架的意义：用结构化定义换取维护效率。

编址规范方面，第十三章花了不小篇幅讲“符号名优先”和“禁止散点编址”。这一点我强烈共鸣。实际项目中如果直接给变频器地址写%MW100，到了后期加一台设备，整个地址表都要挪，而用符号寻址后在DB里加一行、插入一个数组元素即可，TIA Portal会自动重算地址。

2.3 协议选型背后的权衡逻辑

这一章关于协议选型的内容不算多，但几句话都很关键。我用实际项目经验展开说一下：

• S7-1500与S7-1200之间走PN通信，最推荐是直接建立S7连接，用PUT/GET或基于TSEND_C/TRCV_C的数据传输。优点是实时性好、诊断方便，适合PLC到PLC的数据交换。
• S7-200 SMART加森兰SB200这类通用变频器，几乎都是走MODBUS RTU。优点是通用性强、几乎任何变频器都支持，缺点是速率和距离有限，轮询周期长，站点多了需要合理分配刷新时间。
• 与KUKA机器人交互时，如果机器人侧支持PROFINET，建议直接用IO设备方式，PLC侧不需要任何通信指令，只做IO映射。如果机器人侧只支持以太网TCP，那就用TSEND_C/TRCV_C组态。

我的建议是：不要追求“一协议吃遍天下”，结合你现场已有的设备接口、响应时间要求、工程调试成本来做决定。第十三章给的价值不是告诉你选哪个，而是告诉你选完以后如何用同一种框架容纳不同的协议，把协议差异局部化。

3. 实操演练：从零配置一套标准通信与驱动控制

3.1 搭建测试环境的硬件组态与网络规划

我这边搭建测试环境用的是一台S7-1500（CPU 1511C-1 PN）、一台S7-200 SMART（SR20）、一台森兰SB200变频器、一台MCGS触摸屏（通过以太网跨网段访问S7-1500），外加一台KUKA机器人仿真器（用于验证TCP通信）。网络规划如果没有提前做，后面会乱成一锅粥，建议按我这个思路：

• 自动化网段：192.168.10.x，里面放S7-1500、ET200SP、KUKA
• 现场设备网段：192.168.20.x，放S7-200 SMART和现场IO
• HMI网段：192.168.30.x，MCGS触摸屏

S7-1500上装了两块网卡或者用CPU自带双口，就能同时连通三个网段。你用MCGS触摸屏跨网段访问1500时，需要在1500侧设置路由，同时MCGS的驱动要写成访问网关设备的IP，而不是直接访问10网段的PLC IP。如果MCGS没有路由选项，最简单的方式是用一个带静态路由功能的交换机，或者通过S7-1500的PN接口做中转。

3.2 编写通信管理FB：以S7-200 SMART和森兰SB200为例

核心是轮询驱动的思想。我用S7-200 SMART连接3台森兰SB200变频器，采用RS485接口走MODBUS RTU。具体参数如下：

注意地址通常是16位寄存器地址，在MODBUS报文里用的是0x0001这一类，但实际功能码加偏移后地址会变成40001，别搞混。我用MB_MASTER指令块按站号依次轮询。

FUNCTION_BLOCK FB_DriveModbusPoll VAR_INPUT Execute : Bool; // 轮询启动 PollInterval : Time; // 轮询间隔 RequestID : Int; // 当前请求索引 END_VAR VAR_IN_OUT Drive : "Type_DriveTelegram"; CommState : Word; END_VAR

轮询逻辑在SCL里并不复杂，核心是每次轮询一台设备，发完控制字请求后等响应，然后再请求状态字、频率、电流。每台设备四个请求组成一个周期。轮询间隔建议设置为100毫秒，如果现场RS485总线设备多，间隔要适当加大，否则总线冲突和从站响应超时会让你怀疑人生。

IF Execute AND NOT Busy THEN CASE RequestID OF 0: // 发送控制字与设定频率 MB_MASTER_Req := TRUE; MB_MASTER_Addr := 16#0001; // 把化好的数据写入保持寄存器 1: // 读取状态字 MB_MASTER_Req := TRUE; MB_MASTER_Addr := 16#0001; 2: // 读取实际频率 MB_MASTER_Req := TRUE; MB_MASTER_Addr := 16#0002; 3: // 读取电流和故障代码 MB_MASTER_Req := TRUE; MB_MASTER_Addr := 16#0003; END_CASE; END_IF;

这段代码的意义在于：将原本在主程序里反复出现的通信指令收敛到一个FB内部，HMI和过程逻辑只需要设置Drive.SetpointSpeed和Drive.CtrlCommand，剩下的交还给框架。

3.3 驱动控制库的建立与复用

通信FB解决“数据怎么回来”，驱动控制库解决“数据怎么用”。第十三章建议把驱动控制逻辑抽成两个层次：

• 驱动接口层：负责与通信层交互，比如把设定转速换算成变频器频率对应的数字量，或者把读回来的原始寄存器值换算成工程单位。
• 驱动功能层：负责实现工艺逻辑，比如加速斜坡、减速斜坡、点动、急停、故障复位。

以森兰SB200为例，它的频率设定范围是0到50Hz，寄存器里存的是百分比数值0到10000，对应千分之一的百分比。把工程频率转成寄存器值时，用RegisterValue := SetpointFrequency * 10000 / 50.0。但如果你不通过框架换算，直接在HMI里输入百分比，操作人员容易错，后期换变频器更麻烦。

驱动功能层我一般用SCL写。

IF (Drive.CtrlCommand AND 1) = 1 THEN // 启动：先给使能，再给运行 Drive.SetpointSpeed := SetpointHz; ELSIF (Drive.CtrlCommand AND 2) = 2 THEN // 停止：斜坡停 Drive.SetpointSpeed := 0.0; END_IF;

这个层次分离带来的好处是：如果某天老板说换ABB变频器，你只需要改底层驱动接口层和通信FB，驱动功能层和HMI画面完全不用动。真正经历过全厂换变频器的朋友，一定会理解这种幸福。

3.4 HMI联动与跨网段通讯配置实操

MCGS触摸屏跟S7-1500跨网段通讯这个需求，我在现场踩了比较久。问题根源在于MCGS通常位于单独网段，而S7-1500在自动化网段，两边通过三层交换机连接。MCGS本身不带路由功能，直接填1500的IP地址是连不上的。解决办法有几种：

1. 给MCGS所在网段设置静态路由，下一跳指向S7-1500的网关地址；
2. 在S7-1500侧设置允许多协议访问，同时开放PUT/GET通信权限；
3. 把MCGS的IP地址设置到与S7-1500同一网段，如都放在192.168.10.x，跨网段就不再存在，但这种方式限制较多。

实际经验是：能通过交换机静态路由解决就尽量用路由，不做ARP代理。调试时用MCGS的“通讯测试”窗口直接发送读取请求，看返回的错误码。如果返回超时，先ping通网关，再ping通S7-1500，最后检查PLC侧是否启用了“允许来自远程对象的PUT/GET通信访问”。

在S7-1500侧，我一般这样配置：

• CPU属性 -> 防护与安全 -> 连接机制 -> 勾选“允许来自远程对象的PUT/GET通信访问”
• 如果使用TIA Portal V15及以上，还需确认“仅支持安全通信”未被强制勾选，否则MCGS这种第三方驱动可能无法建立连接。

3.5 与KUKA机器人交互的配置过程

这一节我单独列出来，因为机器人通信和变频器通信的套路不太一样。KUKA机器人通常支持PROFINET或者EtherNet/IP，用PROFINET时，PLC侧不需要写任何通信指令，关键是IO映射。你在TIA Portal里组态一个PROFINET IO设备，然后在KUKA侧配置好设备名称和IP，PLC侧就能把机器人的状态字、位置、节拍信号映射到输入字和输出字里。

实际操作中要注意设备名称必须完全一致，PROFINET对设备名称的大小写和符号很敏感。我曾经因为KUKA侧设备名填成了“kuka_robot_1”，而PLC侧填的是“KUKA_ROBOT_1”，导致IO一直断断续续掉线，排查了很久。这个坑写在这里，希望你们绕过去。

在TIA Portal里新建PROFINET IO系统，分配设备名，然后创建“GSD文件”导入KUKA的GSDML描述文件，完成后就可以在下挂IO设备下看到KUKA传送的输入输出模块了。通信周期默认是8ms，对大多数机器人同步信号够用，对节拍特别快的产线，可以考虑把通信周期压到4ms，但CPU负载也会同步上升。

4. 常见问题与排查技巧实录

4.1 通讯超时与掉线

这一类问题占了我调试时间的七成。先说现象：MODBUS RTU轮询偶尔返回错误，严重的每隔几十分钟就掉一次线。排查顺序建议是：

1. 检查接线：RS485的A/B千万别接反，屏蔽层要单端接地
2. 检查终端电阻：总线两端各接一个120欧电阻，如果就两台设备，每台内部终端电阻打开也有效
3. 检查波特率与数据格式：9600 8E1要两边完全一致，有的变频器默认是8N1
4. 用串口抓包工具看报文，确认从站到底有没有响应

我遇到过一个诡异问题：S7-200 SMART发请求后，森兰SB200偶尔响应，偶尔不响应。后来发现是变频器的“通信超时时间”设得太短，PLC每隔100ms轮询一次，变频器觉得通信中断，自动跳了故障。把变频器的通信超时时间从0.5秒改到2秒，问题就消失了。这个细节变频器手册写得不明显，但调试中很致命。

4.2 报文错位与字节序

MODBUS RTU读回来的寄存器是16位无符号整数，如果你在PLC里读回频率后强行转换为REAL，数值大概率是错的。实际工作中我犯过一个错：把寄存器值直接乘0.01当频率用，结果发现数值对不上，最后才发现森兰SB200返回的是放大100倍的百分比整数（0到10000），而错误在于我没有先把寄存器值除以10000再乘以50Hz。

字节序问题主要出现在PROFINET或以太网通信中，大小端不统一会导致数据变成乱码。S7-1500默认是大端模式，而很多第三方设备默认是小端，在做TSEND_C/TRCV_C通信时要在PLC里做字节交换。TIA Portal里可以使用“SWAP”指令对WORD、DWORD进行字节序转换，也可以用MOVE_BLK配合移位做批量处理。

4.3 跨网段通讯的典型错误

前面提到MCGS跨网段访问S7-1500，我再说一个细节：MCGS驱动的“目标设备IP”通常填1500的IP，但如果MCGS本机地址和1500不在同一子网，且没有配置网关，TCP握手是发不出去的。排查时先用网线直连MCGS和一台普通电脑，确认网络地址配置正确后，再接入现场交换机。逐步缩小范围是排查通信问题最笨也最有效的方法。

4.4 驱动控制FB间数据不同步

当我从200 SMART的MODBUS轮询FB向1500的驱动控制FB传数据时，遇到过数据不同步的问题。数据是一个字一个字传的，在传输过程中有短暂的不一致窗口，如果驱动控制FB正好在读取，就可能读到错误的频率值。AF框架的建议是把通信数据和工艺数据分别存放在不同DB，通信层把原始值写入“通信缓冲区”，再用一个同步指令整体复制到“工艺缓冲区”，确保驱动功能层永远只读取一致的数据快照。

我用TIA Portal的全局DB读写机制配合一个DONE信号，完成这种双缓冲区切换。写代码时注意：缓冲区的更新代码要放在OB1末尾或循环中断里，避免在一个扫描周期内被多次访问。

4.5 排查工具与思路分享

我自己常用的排查工具分为三类：TIA Portal自带的在线诊断视图、第三方串口调试助手（用于MODBUS RTU抓包）、以及Wireshark做以太网帧分析。TIA Portal在线诊断视图能显示CPU和PN接口的通信错误统计，比如丢包数和CRC错误计数，这两个数值如果持续增长，基本可以锁定物理层问题。串口调试助手能直接看到RS485总线上的报文流，发什么收什么一目了然，比自己对着程序猜快得多。

经验是：不要在程序里加一堆临时变量来“观察”通信数据，直接旁路抓包最直观。如果抓包发现在规定时间内没有响应帧，问题大概率出在从站配置或物理链路；如果响应帧存在但是在PLC里没拿到数据，那问题在PLC侧寻址或数据转换。

5. 第十三章之外的补充实践

5.1 从AF框架到自己的项目：如何裁剪和扩展

框架不是拿来直接跑的，而是拿来裁剪的。我参照第十三章建标准通信层时，实际项目只有6台变频器和2台机器人，不需要框架里完整的诊断与冗余机制，所以我把通信管理FB简化成了“轮询状态机+错误计数+心跳超时”，保留了框架的层次划分，但是删掉了与现场无关的多余功能。这样做的好处是程序仍然规范，但代码量少了，维护成本也低了。

反过来，如果项目规模大，要扩展到几十台驱动设备，那么第十三章里的“分组轮询”和“优先级调度”就能派上用场。把不同的驱动设备分配到不同的轮询组，通过调整组间的调度权重，让关键设备获得更快的刷新周期，非关键设备则放低优先级。这种设计在面对大型产线时特别有价值。

5.2 版本管理与文档沉淀

翻译第十三章的过程中，我同步做了一件重要的事：把项目里所有的通信参数整理成一份统一的配置表，包括设备名、站号、IP地址、通信协议、寄存器地址、换算系数、超时时间。这个表格放到团队共享盘里，并纳入公司项目交付文档的附录。谁在调试时碰到问题，第一件事就去查这张表，而不是打开电脑翻程序找。

版本管理也是重点。AF框架更新后，底层的库文件和功能块都会变，如果你把框架代码直接复制到项目中，后期升级会非常痛苦。我的习惯是用TIA Portal的库功能，把通信FB和驱动控制FB保存到“全局库”，并给库加版本号。项目组从全局库调用时，统一引用一个版本，避免不同项目各改各的，最后库和项目分道扬镳。

5.3 对未来自动化工程师的一点建议

第十三章写的是通信框架，但真正难的不是通信本身，而是建立一种“所有设备都能被统一管理”的全局视角。我见过很多工程师，写PLC逻辑时用一套思路，配HMI时用另一套思路，调通信时又换了一种风格，最后整个系统像拼凑出来的，出了问题谁也说不清。AF框架最大的价值，是逼着你用一种结构化的方式去面对整条线。

如果你刚接触这部分内容，我的建议是别急着写代码，先把手册里的数据结构、命名规范、通信分层图看明白，再对照现场设备一步步搭建。等你亲手完成一套变频器、触摸屏、机器人联调，再回头翻第十三章，你会发现自己已经能读懂字里行间的设计意图了。