上个月我把手头的《西门子AF框架》英文文档翻译到了第十六章正好卡在通信这一块。AF框架Application Framework应用框架是西门子做标准化自动化项目时常用的一套工程规范从变量命名、程序块划分到HMI画面和通信服务都有固定的搭法。这套东西平时散落在各个项目里很少有人把英文原版一页页啃下来所以我在翻译的时候就想着与其闷头翻完就丢不如把第十六章的翻译思路和对应的实操校验一起整理出来给同样在搞S7-1500、TIA Portal博途通信调试的同行省点时间。先给结论我手上这个版本文档第十六章讲的是AF框架的通信层大约五十多页核心围绕“对象模型—通信服务—协议映射”三件事展开。翻译本身不难难的是文档里每个抽象名词背后都挂着大量工程细节——这些原文不会写但调试现场只要有一个对不上就得白折腾半天。下面我按章节拆开讲文末还放了一份可以直接抄的通信调试检查清单。1. 先弄清楚AF框架是什么我为什么要把第十六章单独拎出来1.1 框架不是软件是“搭项目”的规矩很多刚入行的工程师一听到“框架”这个词第一反应是某个软件包或某个安装文件。实际不是。AF框架更像一套“搭项目的规矩”它规定了你在TIA Portal里怎么建文件夹、怎么给变量命名、程序块各自负责什么、HMI画面和上位机怎么跟PLC交换数据。打个比方同样盖一栋楼有施工规范和无施工规范的差别不在于每块砖本身有什么不同而在于楼建成后能不能统一维护、快速复制。AF框架解决的就是自动化项目的“可复制性”和“可维护性”。企业用同一套AF框架做十个类似产线新来的工程师能很快看懂第二个产线的程序因为命名、结构、接口都是约定的。我在翻译第十六章的时候最大的感受就是前面十五章讲的都是“规矩本身”第十六章讲的是“这些规矩怎么和外部的设备、系统对话”。前面的章节你可以不懂通信也能翻但第十六章不行这一章要求翻译的人不仅懂英语还得懂OPC UA、PROFINET、Modbus这些协议的基本工作原理。1.2 第十六章在整套文档里的位置我这套AF框架文档的结构大致是这样的最开始是项目规划、硬件组态中间是程序块库和HMI画面模板再往后就是通信服务然后收尾是诊断维护。第十六章恰好排在可视化章节之后是全文档中第一道“跨系统”的分界线所以它的存在感特别强。为什么通信章节值得单独翻译因为它把两个世界接在了一起一边是PLC里按AF框架搭好的DB块、工艺对象另一边是MES、SCADA、机器人、变频器、仿真软件这些“外部系统”。你在搜的那些场景比如S7-1500和KUKA机器人交互、Process Simulate通过OPC UA和PLC通信、KepServer连接S7-1500、S7-200 SMART和变频器做RS485通信本质上都属于这一章的范畴。1.3 翻译这章需要哪些前置知识我不是专业翻译出身就是一线做项目顺手翻文档的工程师。翻通信章节之前我自己列了个前置知识清单缺哪块补哪块TIA Portal基本操作至少会建项目、组态PLC、写简单程序。S7-1500硬件特性知道固件版本、IP设置、PROFINET接口这些基础概念。OPC UA基础知道Server/Client是什么、端点Endpoint、安全策略、节点浏览这些词。Modbus RTU基础知道功能码03和04的区别、保持寄存器和输入寄存器的区别。PROFINET基础知道设备名、GSD文件、IP和设备名绑定这些概念。没有这些前置知识第十六章很多句子是没法翻的。比如原文写“The communication service is routed via the configured channel”如果你不知道channel在这里指硬件接口和驱动通道很容易翻出“通信服务通过已配置的渠道被路由”这种谁也看不懂的话。2. 第十六章的主线对象模型、通信服务、协议映射2.1 对象模型逻辑设备和物理连接必须分开理解AF框架文档里有个贯穿始终的概念叫“对象模型”。在通信章节它反复强调一件事逻辑设备和物理连接是两回事。逻辑设备指的是你在框架里创建的工艺对象比如一台泵、一个风机、一个电机驱动。物理连接指的是这个对象的数据到底通过哪个接口、哪条线、哪种协议进出PLC。文档里用“通信对象communication object”“通道channel”“服务service”三个词把这层关系固定下来。我在翻译时特别注意区分“对象”和“实例”这两个词。原文里的object泛指框架里的工艺对象instance特指某个具体程序块的实例化数据。这两个词在不同章节里频繁混用如果术语表不提前定好第十六章翻完了回头一看上下文是打架的。2.2 OPC UA、PROFINET、Modbus 在第十六章的戏份是怎么分配的不同协议在这一章里的篇幅差异很大翻译时也必须区别对待。我按自己的理解做了个归类服务类型典型应用场景第十六章里讲的重点OPC UA上位机、MES、仿真软件、跨系统数据交换服务器启用、端点配置、安全策略、节点浏览PROFINET分布式IO、机器人、伺服、智能设备设备组态、GSD文件、共享设备、I/O地址映射Modbus RTU/TCP变频器、仪表、老设备、第三方控制器功能码、寄存器映射、主从站配置另外有个容易忽略的点AF框架的程序块库里不只有电机、阀门这些基础块还有安全类的功能块比如很多人在搜的muting功能块。这个块做的是安全光幕的短时屏蔽逻辑牵涉AOPD、ESPE、屏蔽时间这些安全术语在文档里会和PROFIsafe通信放在相近的位置。翻译这种内容时安全术语必须查标准不能自己发挥否则会出大问题。2.3 最容易翻错的五个术语翻译不光是单词对应更重要的是“单看都对连起来不对”的情况。第十六章里我整理出五个最容易翻错的术语英文术语我的译法为什么这样翻tag变量西门子语境里tag就是PLC变量或HMI变量译成“标签”很误导channel通道指通信驱动的接口实体不要译成“渠道”service服务指通信服务这个整体机制译成“业务”会跟业务逻辑混淆instance实例程序块实例化保持和TIA Portal界面术语一致muting屏蔽安全光幕短时屏蔽常被误译成“静音”如果你也在翻西门子文档建议从一开始就建一张术语对照表后面所有章节都按同一套译法走否则“同样的英文词在不同章节出现不同中文”读的人一定会被绕晕。3. 文档没写但调试必须知道用实操校验第十六章翻译第十六章的过程中我把文档里描述的通信服务在真机上验证了一遍。文档只讲“应该怎么做”没讲“做的时候会踩什么坑”。这一节我专门说文档没写到、但调试现场一定会遇到的事。3.1 S7-1500 开 OPC UA Server让 Process Simulate 和 KepServer 来读S7-1500固件版本在2.0以上基本都支持OPC UA服务器功能。启用方法是在TIA Portal里选中PLC打开设备组态在属性里找到“OPC UA”设置勾选“启用OPC UA服务器”然后配置端口号默认4840和安全策略。测试阶段建议先选“匿名访问”等把数据读通了再上签名加密不然证书那一步就能卡住你一下午。我之前用KepServer 4.5连接S7-1500时走的就是OPC UA通道。在Kepware里新建一个“OPC UA Client”驱动填上PLC的端点地址格式为opc.tcp://192.168.0.10:4840然后浏览节点树找到Objects → DeviceSet → PLC_1 → Program blocks把需要的DB变量拖进来。Process Simulate连PLC也是同一个思路。仿真软件作为OPC UA客户端PLC作为服务器两边都配好之后在Process Simulate里关联PLC信号就能做虚拟调试。这里有个细节S7-1500的程序块默认是优化访问的外部OPC UA客户端能不能看到变量取决于DB块的访问属性设置。翻第十六章时你就知道文档里提过“通信服务的可见性由块属性控制”这句话是什么意思——实际项目里你新建的全局DB如果没把“从OPC UA可访问”打开外部客户端是浏览不到这个DB的。3.2 SMART 200 做 Modbus RTU 主站寄存器偏移永远是第一道坎S7-200 SMART做Modbus RTU主站用的是库指令MBUS_CTRL和MBUS_MSG。很多第一次接触的人直接卡在寄存器地址上。Modbus协议里保持寄存器是从40001开始编号的但协议内部实际使用的是偏移量。MBUS_MSG指令里的“Addr”参数我习惯直接按设备手册给的功能码地址来写例如手册里说“运行频率地址为40009”那么Addr就写40009功能码写3。但要注意如果你的设备手册给的是“数据寄存器编号40009”而实际协议地址是“0x0008”你就得先把寄存器号减去40001再换算这个换算错一位读出来的数据要么是零要么是乱跳的。还有从站地址MBUS_MSG的“Slave”参数范围是0到247但Protocol规定从站地址1对应这里的0。也就是说你给驱动设的Modbus从站地址是1PLC这边Slave参数要填0驱动设为2PLC这边填1。这个映射关系我在一个项目里带过三个新人三个都栽在同一处。3.3 ModScan 能读串口而西门子侧读不到完整的排查链路之前论坛里有人问过一个问题“ModScan能读取串口数据但西门子组态软件不能读。”这个问题我在实际项目里帮人排查过完整链路如下。ModScan本质上是一个Modbus主站模拟调试工具它通过USB转RS485接在串口线上能读到设备数据说明设备侧没问题、线也没有物理断掉。但同样的线接到S7-200 SMART的通信板上程序轮询就是读不到这种情况下按以下顺序排查检查RS485的A/B极性。很多USB转485适配器有自动极性识别或者你之前随手接反了也能用而PLC的485口是固定极性A/B接反必然通信失败。这也是“ModScan能用、PLC不能用”最常见的原因。检查共地。RS485虽然靠差分信号传输但A/B线之间没有公共地电位的时候干扰会非常明显。很多变频器现场PLC和设备之间地电位不均衡直接把两边的信号地并一根线就好多了。检查波特率和校验位。ModScan默认波特率往往和组态软件设的不一致比如ModScan用9600能读PLC侧组态成了19200照样读不到。检查从站地址映射。ModScan里的“Slave ID”填的是设备实际地址而SMART库的Slave参数需要减1两者搞混PLC这边一直报“从站无响应”。检查功能码。有的设备把参数放在保持寄存器功能码03有的放在输入寄存器功能码04ModScan两个都试了能读不代表PLC侧组态的功能码也选了正确的那一个。排查完之后看MBUS_MSG的“Error”输出常见错误码含义如下错误码含义常见原因0无错误正常1校验错误波特率、校验位不一致2从站无响应从站地址错、线没接好3接收超时从站响应慢超时时间设得太短6总线忙上一次发送未完成就开始下一次这套排查顺序我后来直接写进了自己项目的调试模板。文档里永远不会有这一页但它比好几章理论知识都有用。3.4 变频器、机器人这些三方设备AF框架管到哪一层第十六章标题虽然是“通信服务”但它讲的是AF框架这一侧的规矩。ABB变频器、三菱变频器、森兰SB200这些非西门子设备的寄存器映射文档基本不管你得自己去查各家手册。翻译时我也专门做了个备注文档只负责“通信通道”这一层谁的数据站在哪个寄存器上是设备厂家定义的。S7-1500和KUKA机器人交互也是同理。机器人侧通常作为PROFINET IO设备你需要在TIA Portal里导入对应的GSD文件设置设备名并且在机器人控制器里把设备名和IP配成一致两边才能握手成功。这条链路里AF框架只规范了PLC侧的接口区怎么建DB、怎么映射I/O机器人那套编程属于另一个体系。我翻译时特别提醒自己不要因为AF框架里写了很多标准做法就以为整个通信链路都是它的范围。4. 翻译方法论术语统一、长句拆解、治“手册腔”这一节算是我翻了十几章攒出来的方法不涉及具体项目但对经常啃英文技术文档的同行应该有用。4.1 先建术语表跨章引用才不会打架AF框架文档章节之间互相引用特别多第十六章会引用前面“程序块库”的内容也会给后面“诊断”章节埋钩子。如果每个章节各翻各的同一个词就会出现多种译法。我用的方法是先建一张术语表四列英文原文、标准译法、使用场景、备注。比如英文译法使用场景备注framework框架全文不用“架构”因为会跟architecture混淆block type块类型程序块章节对应TIA Portal里的“块类型”faceplate画面模板HMI章节不译成“面板”commissioning调试/投运全文手动调试用“调试”整体交付用“投运”有了术语表第十六章翻起来就快得多遇到拿不准的词先查表没有的再补进去。翻译到后期这张表反而成了比译文本身更有价值的成果。4.2 西门子文档里的德式长句怎么拆西门子的英文文档很多是从德文转译的句子结构偏长偏绕。第十六章里像“The parameterization of the communication services of the automation framework via the TIA Portal configuration interface is described”这种句子不少。直译成中文会非常干涩根本没法读。我的拆法是三步先找句子的主干也就是主语、谓语、宾语再把所有介词短语拆成独立短句最后按中文的语序重组该加“通过”“利用”“在……中”就加不能让定语全部堆在名词前面。上面那句我改成“本章描述如何通过TIA Portal组态界面对AF框架的通信服务进行参数化设置。”读起来顺意思也不丢。翻译技术文档不能追求“字字对应”追求的是“工程师读完能直接上手干活”。4.3 三个办法治“手册腔”技术文档翻出来如果一股“手册腔”读者是看不下去的。我自己总结的三个办法是把被动语态改成主动语态。原文写“parameterization is performed by the user”我改成“用户完成参数化设置”主语明确、动作清晰。把动词名词化结构改回动词。原文的“perform parameterization”直译成“执行参数化”我改成“设置参数”。这个细节看着小但对阅读体验影响极大。翻完一节加一段实操备注。这就是前面第三节做的事。文档说“通信服务可以在通道不可用时报告错误”我就备注一句“什么意思通道断线后DB里的状态字会置位HMI上要做报警提示否则现场根本不知道通信断了”。这些备注不属于原文档但它们让整篇译文活了起来。5. 照第十六章做一遍两个最小通信工程和一张检查清单5.1 最小工程一S7-1500 的 OPC UA 服务让外部客户端读到实时数据我建议想验证这一章内容的人先搭一个最小的OPC UA工程一台S7-1500、一个TIA项目、一台电脑上的OPC UA客户端。在PLC里写一小段程序用SCL往全局DB里写一个递增数值。比如新建DB名为CommDB里面放一个DINT类型变量Counter主程序里写#count : #count 1; #count : #count MOD 1000; CommDB.Counter : #count;然后到PLC属性里启用OPC UA服务器把CommDB设为外部可访问。电脑上用UA Expert或者KepServer建立连接浏览节点找到CommDB.Counter看到数值在变化这一章最核心的概念就算落地了。如果你还要进一步验证就在HMI上绑定这个变量做画面显示看看HMI标签和OPC UA读到的值是否一致。这里其实隐藏着一个原文档讲得比较绕的点HMI访问和OPC UA访问走的是同一条数据链路数据一致性比传统的DP通信要可靠得多。5.2 最小工程二SMART 200 轮询变频器并处理错误码第二个最小工程更偏现场S7-200 SMART接一个RS485变频器轮询读取运行频率和电流。组态思路是每个扫描周期都调用MBUS_CTRL进行主站初始化然后在需要的时候用MBUS_MSG做单次读写。注意MBUS_MSG同一时间只能有一个调用在运行所以一般用一个定时触发加标志位来做轮询。我习惯把轮询逻辑写成Train先读频率读完置位标志再读电流读完复位标志重新开始。这样保证总线上同一时刻只有一个请求。至于读写的数据记住前面说过的寄存器偏移换算。设备手册给的频率寄存器是40009实际换算后协议地址是8但在MBUS_MSG里我直接填设备侧地址加功能码的组合不自己多绕一层。具体以你用的指令库版本和驱动手册为准但思路是固定的。这个工程做完再加上3.3节那套排查链路第十六章的Modbus内容就基本吃透了。5.3 通信调试检查清单可直接抄下面这份清单是我从多个项目里攒出来的可以直接复制到你的调试文档里确认RS485极性A/B正确屏蔽层单端接地。确认PLC与设备之间共地避免电位差。终端电阻只在总线两端连接中间节点不接。波特率、数据位、校验位、停止位两端完全一致。从站ID确认注意部分指令库从0开始对应实际地址1。功能码和寄存器区选择正确03保持寄存器、04输入寄存器。寄存器编号按设备手册换算减去协议偏移后验证。浮点数注意字节序大端还是小端32位还是16位。轮询周期不要太短给从站留够响应时间。首次联调用ModScan加串口监听把协议报文先调通再接PLC。这一张清单救过我很多次现场比任何工具都好用。5.4 第十六章翻完之后第十七章大概率是什么按AF框架文档的套路通信章节后面一般跟着诊断和维护。常见的下一章内容会涉及PLC诊断缓冲区、OB82/OB86这些诊断组织块、HMI报警组态、设备状态字和故障字的设计。如果你正在准备往下翻建议提前熟悉Get_IM_Data、PROFINET诊断记录这类PLC侧的东西那样第十七章就不会太吃力。我在实际翻译中还有一个体会通信章节是所有章节里最需要“硬件在场”的一章。光坐在电脑前翻很多句子只能靠猜旁边的试验台上放着一台S7-1500和一根串口线翻译质量立刻就不一样。所以我后来建议公司里其他做文档翻译的同事动手翻之前先把手头项目相关的设备跑一遍哪怕只是通个电、看看在线变量也比纯看词典强。这也是我这十六章翻完后最想传达给同行的一件事。