1. 这一章在AF框架里的位置程序骨架和外部世界的连接层先说个背景。AF框架Automation Framework自动化框架在西门子工程圈里通常指的是以 TIA Portal 为开发环境的一套标准化程序架构。它把一套 PLC 程序抽象成几个固定层——安全层、逻辑控制层、设备层、通讯层、诊断层。每一层各管各的事互相之间通过统一的接口接口DB、命名规范、UDT 结构交互。这样做的直接好处是不管项目是单台设备还是整条产线程序结构都是一样的调试的人换了一个又一个程序翻起来还是同一个味道。我翻译的第十九章放在整套 AF 框架里的位置相当微妙。前面的章节把 CPU 选型、IO 规划、安全回路、基本功能块都讲透了到第十九章时要解决的问题已经从这台设备怎么动升级成了这台设备怎么跟别人说话。说得直白一点这一章讲的是通讯集成和外部设备协同包括 PROFINET 现场总线上的从站管理、变频器驱动、机器人握手、以及和上位系统做数据交换的几种方式。为什么这一章难翻译因为它不光是语法层面的英译中更麻烦的是术语背后的语境。比如 telegram 在西门子报文语境里指的是周期性数据块结构不能按单词直译成电报muting 在安全光栅场景里指的是屏蔽而不是静音。这些都是翻译过程中的大坑也是我这一章花时间最多的地方。另外值得说一句第十九章在整套框架中作了一个非常关键的承上启下动作——把前面定义好的功能块和具体的外部设备通讯打通。也就是说你在程序里看到的 FB 调用、DB 数据不再只是内部逻辑的演练而是真正变成了控制现场变频器、接收机器人状态、向第三方系统提供 OPC UA 服务的一条条真实数据流。理解清楚这一层关系是读懂这一章的前提。2. 通讯组态的地基先从 PROFINET 设备视图讲起2.1 设备组态里最容易被忽略的设备名称和IP地址的配合第十九章上来第一步就讲 PROFINET 设备怎么接入项目。很多朋友在 TIA Portal 里添加 PROFINET IO 设备的时候习惯性点一下自动分配设备名称就过了。但实际现场报错的时候八成都出在这个看似简单的环节上。PROFINET 和普通以太网最大的一点区别就是它并不靠 IP 地址来确定设备身份而是靠一个叫设备名称Device Name的东西。你在 TIA Portal 的组态里指定了设备名称后硬件本身也得通过PST工具或者在线分配的方式写上这个名字。两边名字对不上设备显示的在线状态就是不可用。我在实际调试中遇到过一种很典型的情况用第三方工具比如 Wireshark 抓包去看设备明明在线MAC 地址、IP 都能看到但 TIA Portal 里就是找不到设备。后来一查是设备名称里的大小写不一致。PROFINET 的设备名称规范比较严格只能用小写字母、数字和连字符设备名称不能以下划线开头不能有空格。很多国产第三方设备比如某些协议转换网关、伺服驱动器对这套规则支持得不太好写设备名的时候强制要求大写或者允许带下划线组态的时候一眼看上去没问题下载到 PLC 之后就是通讯不上。提示如果你用的是西门子自家的 G120 变频器或者 ET200 分布式 IO设备名称这一关一般很顺畅。但只要是第三方 PROFINET 设备一定要先去查设备手册里对设备名称的约定再对照 PROFINET 命名规范做一次强制转换否则后面排查会折腾很久。2.2 报文结构的选择直接决定了你编程时面对的数据结构框架文档里反复强调一个概念西门子 PROFINET 通讯中报文就是数据交换的最小周期单元。你在设备视图里给变频器拖一个报文比如标准报文 1PKWPZD其实就已经决定了你后面在程序里看到的是什么样的数据结构。具体到翻译内容第十九章里对报文解释得比较系统。报文分两部分PKW 区是参数区用来读写变频器内部的参数号PZD 区是过程数据区用来实时传递控制字、状态字、速度给定值和实际值。平时我们做速度控制走的是 PZD要修改变频器的加减速时间这类参数走的是 PKW。但注意一个容易踩坑的点报文长度一旦选定了后面想要改不只是删掉重拖那么简单。你在用户程序里依赖的接口变量比如变频器转速实际值对应的地址会跟着变工艺逻辑上到处都引用到这个地址的话改动量不小。所以选报文之前先想清楚现场到底要传几个控制字、几个给定值、几个反馈值。我一般模块化设备选标准报文 20带五个 PZD不需要太多数据就把整定、使能、复位、速度给定、实际电流全放下了如果只是简单启停调速标准报文 1 足够。2.3 非周期通讯什么时候用什么时候不碰很多搞了几年 PLC 的人对周期性报文很熟但对读写请求非周期通讯一直模模糊糊。第十九章里用了一整节来讲控制器如何读写 IO 设备中的任意参数翻译到这里我自己也重新理了一遍。非周期通讯的作用场景很清晰比如设备运行中你想动态改一个变频器的斜坡时间又不想重新下载硬件组态。这个时候你通过WRREC写入记录或者调用驱动库自带的参数读写功能块把目标参数号打包成一条请求发出去设备在后台处理完再给应答。周期报文里没有这个参数但非周期通讯能办到。不过要泼一盆冷水非周期通讯的响应时间取决于设备的处理能力和总线负载千万不要把它当成可规划的控制路径。有人为了图省事把一个需要实时响应的速度修正逻辑用WRREC去写变频器参数结果现场数据刷新慢整个工艺被拖垮。AF 框架里面的原则很明确——周期报文走控制非周期报文走组态和参数维护两者绝不能混用。3. 跟变频器做邻居AF 框架里的驱动块是怎么设计的3.1 从热词abb变频器与西门子plc展开第三方驱动要不要用库网络热搜词里面恰好有ABB 变频器与西门子 PLC这种组合这个其实特别能代表 AF 框架应用时的一个现实问题很多产线不是全西门子的设备变频器可能是国产的成套设备里又是 ABB 的控制层却是西门子 PLC。这时候如果强行要求都用 PROFIdrive 协议上 PROFINET很多第三方变频器虽然支持扩展报文但细节上和西门子自己的 G120 系列总有差别。我的观点是这样能用标准报文解决的就用标准报文省事涉及到专用功能、专用参数的就在设备层自己封装一个驱动功能块。AF 框架对设备层的定义就是可替换。你把一个逻辑控制层的接口 DB 定义好——控制字、速度给定、运行反馈、故障反馈——至于里面调的是西门子官方 FB 还是第三方写的自定义 FB逻辑控制层根本不用关心。之前我在一条包装线上干过一件事四台变频器两台西门子 G120两台国产某品牌用的都是 RS485 Modbus RTU 接入 S7-1200 的 CM1241 通讯模块。因为 G120 自带 PROFINET 接口国产那两台没有只能走串口。我为两套设备各写了一个功能块面向逻辑层暴露一模一样的接口启停、故障复位、速度设定、实际速度、电流反馈。逻辑层根本不关心这层差异只要接口一致就行。这就是 AF 框架里设备驱动应封装差异的真实含义。3.2 Modbus RTU 通讯的实操参数从波特率到数据格式说到串口通讯这其实是很多人眼里的老大难但原理搞清楚了反而特别稳。Modbus RTU 是一种很老的协议结构简单一主多从基于 RS485 半双工。要在 TIA Portal 里把它调通有几个参数几乎是必查的参数常见取值备注波特率9600 / 19200 / 38400现场干扰大时用低一点600 米以内跑 38400 问题不大数据位8Modbus RTU 固定 8 位一般不可改校验位Even / None带校验时数据信心更高主从站必须一致停止位1 或 2从站文档为准建议跟校验位一起检查从站地址1~247不可重复和变频器面板参数对应贴一段我常用的 S7-1200 调用 Modbus 指令的骨架代码LAD 里不方便看用 SCL 描述一下逻辑// 使用 MB_COMM_LOAD 建立背景连接 MB_COMM_LOAD(slot : 1, port : 1, baud : 19200, parity : 0, // 0无校验, 1偶校验 flowCtrl : 0, timeout : 1000, echo : 0, mode : 1); // 1RS485 半双工注意接线 // 使用 MB_MASTER 或 MB_SLAVE 建立周期读写 MB_MASTER(REQ : readTrigger, MB_ADDR : 16#01, // 从站地址 MODE : 0, // 0读保持寄存器 DATA_ADDR : 40001, // 起始地址注意 40001 可能对应地址 0x0000 DATA_LEN : 4, DATA_PTR : ReadBuffer, DONE mbDone, ERROR mbError, STATUS mbStatus);这里特别想强调一个地址映射的坑很多国产变频器的报文起始地址比如速度给定地址跟 Modbus 协议地址之间有一个偏移。比如有的变频器手册里写通讯地址 1000H翻译成 Modbus 数据地址的时候用户很容易直接把 16#1000 填进去结果读出来的数据完全不对。正确做法是先看设备寄存器映射表再把地址换算好。3.3 博途里组态第三方变频器的另一个选择GSD 文件如果你不想写串口通讯第三方变频器也有不少支持 PROFINET 接口的型号这些设备会随 Box 附带一个 GSD 文件或者 GSDML 文件。TIA Portal 里在设备和网络视图的空闲处右键选择从文件中安装 GSD 文件导入后就能像添加西门子设备一样把它拖到 PROFINET 网络上。加了 GSD 文件之后组态视图里会多出一堆报文类型但第三方设备的报文数据格式和西门子的标准报文不完全一样你得对着厂家给的映射表整理一遍输入输出的字。这个工作量不大但需要细心。我之前导入一款伺服驱动器的 GSD 时它的报文字节序和西门子默认的字节序不一样结果现场试运行的时候速度给定值完全是乱的。后来在驱动器的配置软件里把数据格式调成匹配的字节序问题立刻就消失了。翻译第十九章里组态数据一致性那一小节时我很自然地联想到了这个案例。4. 设备协同的高阶玩法机器人握手和 Muting 功能块4.1 西门子 PLC 和库卡机器人交互的信号握手设计热搜词里有西门子1500和库卡机器人交互这也是 AF 框架第十九章里讲得比较重的内容因为现代产线里 PLC 和机器人的协同监管直接影响节拍和安全。搞过的人都知道机器人和 PLC 之间的交互本质上是信号握手不是数据的简单搬运。先说最基础的 IO 握手。库卡机器人一般提供两组信号给 PLC一组是机器人当前的工作状态比如运行中程序已停止急停异常报警另一组是外部自动请求信号比如允许启动程序复位暂停。PLC 侧呢一般定义一套启动序列机器人安全门关闭、无报警、夹具在初始位置、所有伺服使能正常然后 PLC 输出一个允许自动运行的信号给机器人。机器人收到后执行主程序到某个位置时输出周期完成信号PLC 收到后控制夹具打开、放行输送线。这个过程中最常见的问题是什么信号竞争。比如 PLC 发了允许启动下一秒条件变了安全光栅被挡住、急停被拍下PLC 又把它撤掉但机器人已经进入了启动序列双方各执一词最后停在半中间。我自己的经验是在 PLC 侧对输出信号做脉冲保持处理即对方没有确认收到之前输出必须要保持有效且可验证如果条件中途丢失不能直接撤信号要先走一个请求取消的互锁逻辑等机器人回一个启动取消确认再复位。这样两边才有明确的应答闭环。这套信号握手的细节如果只是看官方文档里的函数手册其实是很难自己全部推出来的因为官方文档只告诉你输入输出的定义不会教你怎么设计时序。AF 框架的价值就在这——它把这类经验变成了一套可复用的结构化逻辑我在翻译第十九章时特别把这部分内容对照了自己的现场经验做了补充注释。4.2 Muting 功能块安全屏蔽不是把安全功能关掉热词里还出现了西门子muting功能块。Muting 存在感很强但误用率也高因为大家搞不清屏蔽和旁路的区别。在安全术语里Muting 指的是在特定条件下暂时屏蔽一个安全传感器通常是光栅或者安全门的信号屏蔽期间允许人员或物料通过屏蔽结束后传感器恢复正常保护功能。关键点是Muting 是有条件的、有时间的、有方向的。你不能因为这里要上料方便就干脆把光栅给旁路了——那是移除安全功能性质完全不同。举一个实际场景AGV 小车要从一个安全光栅隔离的区域穿过光栅检测到 AGV 进入时肯定要触发急停但工艺要求 AGV 可以以低速穿过。这时候解决方案是在光栅两侧再装两个传感器当两个传感器都同时被遮挡时系统判断有一个体积较大的实体AGV 而不是人正在经过于是临时屏蔽光栅的输出。这个屏蔽只能持续有限的周期如果超过时间或者传感器状态不满足条件屏蔽立刻终止设备回落到安全停机状态。在博途里实现这个逻辑习惯上会写到安全程序中用 F-CPU故障安全 CPU的话需要在安全程序里调用安全相关指令。非安全 CPU 的普通程序里做 Muting 只能做逻辑仿真不能真正满足 ISO 13849 或 IEC 61508 的安全要求这点一定得写清楚。具体实现时有几个条件我记得特别牢Muting 条件要求Muting 信号类别必须是 A 类或 B 类信号不能随手接一个普通 IO时序要求Muting 信号之间的到达顺序要严格符合逻辑定义持续时间Muting 最长不能超过工艺窗口时间时间到必须停止复位要求屏蔽结束后必须收到传感器状态恢复信号才能继续自动运行这个功能块翻译过来放在 AF 框架的安全层里本质上它是一个带状态机的安全逻辑空闲 - 请求屏蔽 - 屏蔽中 - 屏蔽结束 - 等待复位。任何一步异常整条线就走故障分支。我在实际项目里是放在 S7-1500F 的 F 运行组里的用 F-FB 来写调试起来要特别注意 F 程序块的版本管理因为安全程序改动是要重新验证签名的。4.3 延续一下库卡机器人和西门子的总线耦合方式除了硬接线 IO 握手现在更主流的方式是通过 PROFINET 把机器人作为智能设备集成到 PLC 网络里。库卡机器人一般会配一个总线耦合卡比如 CX1000 控制器的倍福 EtherCAT 或西门子侧的 PN/PN Coupler 方案。用 PROFINET 集成机器人时整个通讯本质上还是报文收发。PLC 往机器人侧周期发数据块里面包括运行命令路径选择速度倍率输出同时从机器人侧周期读取当前位置当前状态程序行号等。这部分跟直接接 IO 的区别在于交换机网里能传的数据量大得多而且诊断信息更全。但风险也大——一旦网络有延迟抖动机器人的安全回路可能先自己动作因为机器人的安全继电器通常会监控通讯信号中断的情况。我见过一个项目PLC 和机器人通过 PROFINET 通讯中间网络交换机故障导致通讯闪断机器人立刻报外部自动停止。因为现场的布线跨了一个很长距离链路质量不好闪断几乎每隔十几分钟发生一次。后来把交换机的端口强制成 100M 全双工禁止自动协商故障就压下来了。这种排查经验一般文档里不会写但凡是实际调过通讯的应该都懂。5. 上层与边缘侧OPC UA 和第三方上位系统的对接经验5.1 OPC UA 在 AF 框架中的定位把数据开放出去的安全姿势热词里反复出现process simulate-通过opcua与西门子plc进行通讯和kepserver4.5连接西门子1500plc这两个场景本质上是同一件事外部系统以 OPC UA 客户端的身份向西门子 PLC 读写数据。S7-1500 从固件版本 V2.0 开始原生支持 OPC UA 服务器不需要额外硬件。在 TIA Portal 里启用 OPC UA 服务器之后需要做三件事在在线访问里打开 OPC UA 服务的证书和安全策略规划好数据映射——是暴露整个 DB还是通过 UA 定义好的节点集为不同的客户端设置用户权限最小权限原则。第二点是我特别想展开的。很多人图省事直接在 OPC UA 服务器配置里把整个数据块暴露出去结果 MES 系统一上来就扫描到一大堆内部变量查问题的时候头都是大的。正确做法是定义一个专门的交互接口 DB只放那些需要给上位系统读写的数据。这个 DB 实际上起的是API 网关的作用——PLC 内部随便怎么变上位系统访问的永远是同一个地址和结构。我在很多项目的通讯规范里就明确要求开放给 OPC UA 的地址范围只允许映射到接口 DB 区间任何内部 DB 不得直接暴漏。5.2 KepServer 连接 S7-1500 的两个常见问题说到 Kepware现在叫 KEPServerEX这是工业界非常常用的第三方网关软件。KepServer 4.5 连接 S7-1500 的时候最常见的两个坑是第一个是版本兼容性。KepServer 早期版本对 S7-1500 的驱动支持是通过 S7 协议做的老版本容易遇到设备型号不匹配的问题。建议有条件的话升级到较新的版本比如 6.x并且确保通道设置里的设备驱动选的是Siemens S7-1500而不是老的Siemens S7-300/400。第二个坑是连接分区的问题。当你通过 S7-1500 的集成 PN 口访问数据时CPU 里面有个连接资源的概念每路 OPC UA 或 HMI 连接都会占用资源。如果 CPU 的资源池已经满了比如有十几个 HMI、30 多个 PUT/GET 连接KepServer 连接就会异常满时不工作你需要去 CPU 属性里调大通信资源的预留比例。注意这个修改会改变 CPU 的处理周期所以不能无脑开到最大。我见过最极端的情况某项目 CPU 是 1511-1 PNHMI 有 10 组MES 接口、过程数据采集接口都在跑导致 KepServer 连接上一会儿就断开。后来把 CPU 的通信接口内存调整了一下又把 KepServer 的请求速率降了下来原来是 100ms 循环读取改成 500ms现场就稳定了。所以说读太快有时候反而是问题的源头上位系统的采集频率要结合 CPU 负载来定不是越快越好。5.3 Process Simulate 联合 OPC UA 仿真对调试的价值Process Simulate 和西门子 PLC 通过 OPC UA 通讯这种模式非常适合产线虚拟调试Virtual Commissioning。在 AF 框架的理念里程序应该先跟虚拟设备跑通再下现场。因为很多逻辑性问题比如机器人是否碰触工装、传感器信号时序是否正确根本不需要物理设备就能暴露出来。我自己做虚拟调试的时候发现一个特别实用的技巧用 OPC UA 连接时给 Process Simulate 里的传感器信号加一个小的时间抖动比如 ±50ms 的随机差异。为什么因为真实传感器是有响应延迟和抖动误差的如果仿真里所有信号都咔嗒一下瞬间切换PLC 逻辑看不到真实环境的滤波问题到了现场才爆雷。用一个简单的随机量模拟传感器的不确定性反而能让程序更耐操。这一条虽然不完全算翻译第十九章的直接内容但写出来是因为它跟第十九章数据交换的可靠性这一主题也有关系。可靠的数据交换不只是通讯链路的事更包括你对数据时刻性的判断。仿真阶段就锻炼这种意识现场会少踩很多雷。6. 翻译稿成稿后我按此复查了一遍几个重点问题值得再强调到这里西门子 AF 框架第十九章的主要内容基本梳理完了。这个章节的翻译初稿已经完成后我又结合现场经验从头核对了一遍发现整理出几条比较一致的高频注意事项放在这里集中说一次第一约定大于配置。AF 框架里面对名字、地址、报文、接口 DB 的命名有强制规范翻译成中文文档后我把这些规范整理成了一张项目开发前必须对照的表格比如逻辑层接口 DB 统一以If_前缀开头设备层功能块统一以Drv_前缀开头硬件组态里的设备名称全部小写字符OPC UA 暴露的数据地址全部限定在If_区段内。这种约定越细后面各工程师之间的交接成本就越低。越到后期越能体会到在调试阶段真正消耗时间的往往不是代码本身写得有多复杂而是大家各写各的、冲突和歧义满天飞。第二报文不只是拖一个默认的那么简单。选报文要按工艺功能来选选完后不要轻易改要改就得过一遍验收流程。框架文档里有一条写得很好报文是程序和设备之间的契约改契约是要走变更管理的。第三安全功能块比如 Muting绝对不在普通程序里实现。如果项目有安全设计需求一开始就要用带 F 功能的 CPU并把安全相关逻辑放入 F 运行组。很多新入行的工程师会把 Muting 当成一个普通 FB 去试验这是非常危险的事我在第 4 节里也提到了这一点。第四OPC UA 和 KepServer 这一类上位通讯花一点时间把接口 DB 设计清楚后面能省大量麻烦。接口 DB 就是系统的外交窗口——只开需要的端口只传该传的数据。很多人为了避免前期设计在一个 DB 里堆了几百上千个变量最后做上位联调的时候效率极低甚至还会影响扫描周期。我在实际操作中还有一个感受翻译这类技术文档最怕的不是单词看不懂而是没有现场经验的直译会误导读者。比如device name直译成设备名大家可能还能理解parameter telegram如果直译成参数电报新手就完全懵了。所以我的处理方式是遇到这类术语保留西门子原文同时加一个括号注释把它在工程里的实际作用解释清楚。第十九章翻译完成后我又在文章末尾加了一个术语对照表把章节里出现的原文、中文翻译和实际工程含义三者列在一起方便读者随时翻阅。最后分享一个基于这套 AF 框架的实践判断如果你手上的项目只是 20 个 IO、一台 PLC、一条单机设备那么这套框架的前期投入成本可能真有点大完全可以简化但如果是个几十个设备、数百个信号的产线项目没有一套类似 AF 的标准化框架到了后期维护和扩展的时候你会发现自己每天都活在改了这个功能块会不会搞坏另一个功能块的恐惧里。框架这东西越早意识到它对你的意义你后面的项目就越轻松。