上周把AF框架第十三章的翻译稿交出去总算松了一口气。这章稿子在我手里压了三周不是篇幅长而是通讯这块内容太容易翻错。作为长期做西门子自动化项目的人我太清楚通讯在整个项目里的分量了S7-1500要和变频器说话S7-200 SMART要接触摸屏上位机要通过OPC UA把数据拿走产线上还有库卡机器人在等着交换信号。任何一个环节出了偏差现场就是十几号人盯着红彤彤的报警灯发呆。这一章在AF框架Automation Framework自动化框架整套文档里的地位很特别。AF框架本身不是某个固件或某个软件它是一套在TIA Portal环境里组织PLC程序的方法论核心思路是把设备驱动、数据管理和工艺逻辑拆开让程序不因为硬件变了就整个重写。而第十三章讲的就是这套框架里最容易被忽视、也最影响落地效果的部分——数据通讯与设备集成。说人话就是当你的PLC需要同时伺候一堆外部设备时程序结构该怎么搭才不会乱。这篇内容是我翻译过程中的梳理和延伸同时结合了国内工程师经常遇到的场景S7-1500跨网段连MCGS触摸屏、KepServer 4.5怎么接S7-1500、森兰SB200和三菱变频器的Modbus RTU细节以及Process Simulate通过OPC UA和PLC做联动。不管你是做设备调试、产线集成还是纯粹想搞懂AF框架通讯模块的设计逻辑这篇应该都能给你一些能直接用的东西。1. 第十三章在AF框架中的定位为什么通讯内容最难翻1.1 先搞清楚AF框架到底是什么AF框架并不是一个你安装之后点两下就能用的软件包。它更接近一套“程序组织的规范”加上一组封装好的功能块FB、全局数据块DB和调用规则。你可以在西门子技术社区、官方文档以及很多大型设备商的标准化程序里看到它的影子。我翻译的这套AF框架文档核心逻辑围绕四个层级展开设备层负责和外部硬件打交道比如读写变频器、读取阀岛状态、跟机器人互发信号。数据层用全局DB作为“数据池”设备层采集到的数据先落到这里逻辑层也从这里取数据避免各个FB之间直接点对点纠缠。逻辑层处理工艺逻辑、顺序控制、报警判断它不关心数据是从哪个变频器来的。交互层给HMI、上位机、SCADA提供统一的读写入口面板上看到的所有变量都来自数据池而不是东拼西凑。第十三章在整套体系里对应的就是“设备层数据层”如何协同工作。翻译到这一章时我的第一感觉是前面十二章都在讲怎么把程序结构搭得清爽到了第十三章突然开始面对一个极其现实的问题——设备之间到底怎么把数据对上话这一章的英文原稿标题直译过来大概就是“通讯与数据集成”。西门子文档里很少用花哨的词但内容却非常硬核。1.2 第十三章解决的是“设备之间的对话问题”一个典型的自动化项目里PLC往往同时面对好几种“说话对象”。对象不同通讯协议就不同数据格式也不同。最常见的组合是PLC与变频器Modbus RTU、USS、PROFINET取决于变频器品牌和PLC型号。PLC与触摸屏通常走以太网但跨网段时涉及路由配置。PLC与上位机/KepServer/SCADAOPC UA、S7通讯、Modbus TCP。PLC与机器人PROFINET IO、TCP/IP裸协议甚至基于OPC UA的交互。PLC与PLCS7通讯、PUT/GET、PROFINET IO。如果这些通讯全部用“裸功能块”散落在程序各处项目初期调试还好一旦投产之后某个变频器地址变了、某个机器人加了新信号维护的人就要在程序里翻箱倒柜找半天。AF框架第十三章的核心正是教你怎么把这些“对话”统一收口用标准接口屏蔽设备差异。这也是我翻译时特别认同的一点通讯问题本质上是架构问题不是指令问题。1.3 这一章原文的翻译难点在哪里翻译第十三章最棘手的是术语密集。通讯章节里每一段都涉及协议名称、寄存器地址、功能码、错误代码、数据类型。德语原文里很多复合词比如“Datenaustausch”数据交换、“Sollwertvorgabe”设定值给定直接逐字翻译很容易变成“设定值预给定”这种拗口的话。我必须结合上下文改成中文工程师习惯的表达“设定值下发”“给定赋值”。另一个坑是错误码。西门子通讯相关的错误代码非常多比如Modbus功能块返回的16#8184、16#8204这类异常码官方文档里的解释是英文或德文直译过来经常让人看不懂。我不能只做词汇转换得把这些错误码翻译成工程师能理解的排查方向比如“从站无响应检查站地址和接线”“功能码不支持检查从站协议版本”。这也是这一章翻译稿投入产出比最高的地方。2. 从S7-1500到200 SMART通讯能力边界必须事先画清楚2.1 三款主流CPU的通信能力对比很多做项目的朋友来问我第一句话通常是“我能不能用S7-200 SMART和S7-1500直接走S7通讯”这个问题背后其实是没搞清楚不同型号PLC的通讯边界。AF框架第十三章里花了不小篇幅讲设备选型我看完之后的感受是通讯能力边界必须在项目一开始就画清楚不然后期全是补丁。我把三款最常见的CPU通讯能力整理成了一张表方便选型时对照通讯能力S7-1500S7-1200S7-200 SMARTPROFINET IO 控制器支持支持有限不支持PROFINET IO 设备支持支持不支持Modbus TCP 客户端/服务器支持库或固件功能支持库支持库Modbus RTU 主站/从站需CM/CP模块需CM1241通信模块支持RS485口USS协议需CM/CP模块需CM1241支持库指令S7通讯PUT/GET作为服务器/客户端均支持支持不支持只能做TCP/IPOPC UA服务器内置支持固件4.4起有限支持不支持OPC UA客户端支持支持不支持开放式TCP/IP/UDP支持TCON/TSEND/TRCV支持支持有限这张表看起来平淡但它解决了我翻译过程中最纠结的一个问题AF框架中很多“标准通讯方案”只针对于S7-1500到了S7-200 SMART这一档很多方案要降级用Modbus RTU或者开放式TCP。如果读者不先知道这个边界照着AF框架的示例抄到S7-200 SMART上根本编译不过。2.2 AF框架眼中的设备分类标准化设备、杂牌设备和IT系统第十三章里对通讯对象做了三种分类。这个分类方式我觉得很有参考价值因为它直接决定了你在程序里用哪种通讯封装策略。第一类是标准化设备。比如西门子V90伺服、G120变频器、S7-1500之间互联它们支持PROFINET、S7通讯、OPC UA这些“正规军”协议AF框架可以直接调用封装好的标准功能块。第二类是第三方或老式设备。比如森兰变频器、三菱变频器、一些国产温控表它们只支持Modbus RTU地址表五花八门寄存器含义千奇百怪。对这类设备AF框架的做法是单独做一个“设备适配块”把设备的寄存器映射表封装进去对外只暴露几个统一的接口比如“频率设定”“运行状态”“电流反馈”。第三类是IT系统。比如MES、SCADA、KepServer、数据库它们通常走OPC UA或者Modbus TCP数据量可能很大但实时性要求没那么苛刻。AF框架中对这类对象的通讯往往放到一个专门的“数据网关”区域里避免与实时控制逻辑抢扫描周期。我实际做项目时特别推崇这个分类。因为很多工程师习惯把所有通讯对象一视同仁变频器用Modbus上位机也用Modbus结果程序里全是五花八门的指令出了故障排查异常困难。先分类再设计这是AF框架第十三章给我最大的启发之一。2.3 通讯选型的判断逻辑第十三章原文并没有直接给出一张“选型决策表”但我在翻译过程中把它总结成了几条判断逻辑设备支持PROFINET且PLC是S7-1500/1200优先走PROFINET不要为了省一个网络节点去用Modbus。设备只支持RS485串口再看PLC侧有没有自带串口。S7-200 SMART自带RS485口可以直接用S7-1200必须加CM1241通信模块S7-1500同样需要CM/CP模块。上位机/MES要求数据访问优先把OPC UA服务器放在S7-1500侧如果PLC档次不够再加KepServer之类的网关软件。两台西门子PLC之间需要交换大量数据S7-1500之间用S7通讯跨网段则考虑Profinet路由或者S7路由。如果只是HMI读几个变量触摸屏和PLC直接用以太网驱动就好不要绕一圈OPC UA。这套判断逻辑我后来在自己的项目规划文档里反复用过基本没有出过大的选型失误。通讯这件事选对了路后面调试就是填参数选错了路后面就是无休止地打补丁。3. 变频器实操森兰SB200与三菱变频器接入时的寄存器与报文细节3.1 S7-200 SMART对森兰SB200的Modbus RTU接线与初始化第十三章里变频器通讯占了很大篇幅因为变频器是产线上最常接的设备。我挑两个典型的国内场景详细讲讲一个是森兰SB200一个是三菱变频器。先说森兰SB200。很多老项目里用的是S7-200 SMART加森兰SB200系列变频器走RS485用Modbus RTU协议。接线本身不复杂变频器侧的RS485端子通常是A和B-接到S7-200 SMART的通信口Port0上。Port0的引脚定义要注意3脚是RS485的B对应D-8脚是A对应D。新手最容易犯的错是把A和B接反结果通讯时好时坏偶尔能读到一次数据然后一直报超时。森兰SB200的Modbus RTU站号默认通常是1波特率要看变频器面板设置常见的有9600和19200。数据格式一般是8位数据位、1位停止位、无校验或者8E1偶校验具体查变频器手册的通讯参数表。S7-200 SMART自带的Modbus RTU库指令是MB_MASTER和MB_SLAVE编程时先用MB_CTRL指令初始化端口把模式设为1主站波特率和校验方式要和变频器完全一致。我翻译这一部分时特意核对过寄存器映射的表述。森兰变频器典型的保持寄存器包括通讯控制字、频率设定值、运行频率、输出电压、输出电流。频率设定值一般是一个16位寄存器比如40001对应控制字40002对应频率设定单位可能是0.01Hz。写频率时先写控制字比如0001启动、0007正转启动等再写频率值这一点不同品牌变频器差异很大必须以具体手册为准。3.2 三菱变频器与西门子PLC通讯时的兼容性细节三菱变频器比如FR-E700系列和西门子PLC之间的Modbus RTU通讯是另一个高频场景。三菱出厂默认很多参数是“适合自己的PLC来用的”接到西门子PLC上需要改几个参数站号Pr.117设为1到247之间的一个值和PLC侧MB_MASTER里的从站地址保持一致。通讯速率Pr.118常见设为9600或19200。数据格式Pr.119三菱默认是8位数据位、偶校验、1位停止位停止位有时是2位。如果西门子侧配置为8N1则必须把Pr.119改成对应格式否则通信永远异常。从站允许Pr.338、Pr.339这类和通讯运行指令相关的参数需要根据实际控制需求打开。我在现场就遇到过这样一个坑三菱变频器在面板上可以正常操作但S7-200 SMART发Modbus请求变频器完全不回应。查了半天发现是Pr.117站号被改成了0而Modbus协议里站号0是广播地址变频器作为从站不应该回应广播帧。把站号改成1之后立刻正常。另外一个注意点是寄存器地址偏移。三菱变频器的Modbus地址映射和森兰不完全一样比如运行指令频率可能在寄存器“40010”等位置但很多手册写的是“地址10”协议帧里实际地址是0x0009从零开始。S7-200 SMART的MB_MASTER指令中数据地址参数填的是“地址从1开始”的Modbus地址还是“协议地址”不同库版本有差异。我的经验是先看库指令手册中地址的解释再结合从站手册里的“协议地址/寄存器编号”来换算不要想当然地直接填。3.3 在AF框架中封装变频器指令而不是到处裸调第十三章里反复强调一个理念通讯指令不要散落在OB1或者各个FC里一定要封装成独立的FB。我见过太多项目一个项目里有七八处调用MB_MASTER各自读写不同的变频器参数结果一查程序连谁在写频率设定值都理不清。AF框架的做法是这样为每台变频器建一个“设备控制FB”对外接口就几个变频器编号、启停命令、频率设定值、当前反馈、故障复位。FB内部维护通讯状态机定时触发读写把读到的最新值写到全局DB对应的地址区。逻辑层想控制变频器只调这个FB的接口就行完全不用关心Modbus指令细节。这样封装还有一个好处换变频器品牌时只需要重写这个FB内部的寄存器映射和报文构造外部的逻辑层、HMI层完全不动。翻译第十三章时我对这个设计印象极深因为原稿用一个对照图展示了“逻辑层-设备适配层-硬件”之间的关系虽然图我没法在这里复现但核心思想就是“变化的东西必须隔离在最小范围内”。4. 跨网段、跨平台的数据打通MCGS、KepServer、OPC UA与库卡4.1 MCGS触摸屏跨网段访问S7-1500国内用MCGS触摸屏配合西门子PLC的项目非常多。常规做法是触摸屏和PLC在同一个网段比如PLC是192.168.0.1触摸屏是192.168.0.2驱动配置直接填IP就能通信。但有些工厂网络环境复杂触摸屏所在的网段和PLC不在同一个网段这时候不能简单地把IP改到同网段因为现场可能还有别的设备在用这个网段。跨网段通讯的本质是两端都要有到达对方网段的路由路径。S7-1500的PROFINET接口支持配置默认网关。比如PLC在192.168.1.10/24触摸屏在192.168.2.20/24中间有一台路由器或者三层交换机那么PLC侧需要把默认网关设为192.168.1.1触摸屏侧网关设为192.168.2.1两边路由可达后MCGS驱动里仍然填PLC的IP地址192.168.1.10通讯就能通。如果中间没有三层设备只是两台设备用一根网线直连跨网段是绝对不行的这时候要么改一端的IP地址要么在PLC侧加一个“辅助IP地址”。S7-1500在TIA Portal的以太网地址属性里支持设置多个IP地址操作路径是设备视图选中CPU的PROFINET接口以太网地址选项卡添加附加地址。这样PLC可以同时挂两个网段触摸屏通过其中一个网段访问上位机通过另一个网段访问互不干扰。4.2 KepServer 4.5连接S7-1500的配置与常见失败点KepServer现在叫Kepware是工业数据网关里非常常见的一个。很多SCADA系统的数据链路是这样的KepServer通过S7协议把S7-1500的数据读出来再以OPC UA服务器身份把数据交给上层应用。4.5版本在国内存量很大新项目也有不少用它的。连接S7-1500时KepServer里通常用“Siemens TCP/IP Ethernet”驱动注意不是S7-200驱动。新建通道后在设备属性里填写PLC的IP地址然后要设置Rack和Slot。S7-1500和S7-300不一样默认机架是0槽号也是0不是S7-300时代的Rack 0 Slot 2/3。我第一次配置时就按老经验填了Slot 2结果通道状态一直是“Device Not Connected”或者“Communication Error”。另外一个高频坑是S7-1500的DB块默认启用了“优化块访问”。优化块访问开启后DB变量没有固定的偏移地址而是通过符号名访问。KepServer的传统S7协议驱动依赖绝对地址比如DB1.DBD0遇到优化块访问就容易读不到数据。解决办法有两个要么把需要被KepServer读取的DB取消“优化块访问”在DB属性里把“优化块访问”复选框去掉要么用Kepware较新版本中对符号化访问支持的驱动。我的习惯是专门为上位机通讯建一个独立的DB取消优化访问所有需要暴露给上位机的数据都集中放这里这样KepServer配置起来清晰程序侧也安全。4.3 Process Simulate通过OPC UA与PLC联动的配置Process Simulate是Tecnomatix产品线里的工艺仿真软件。很多做产线规划的人用它做虚拟调试也就是把PLC程序和仿真模型连起来跑提前发现问题。第十三章翻译稿中OPC UA通讯部分正好覆盖了这个场景。S7-1500从固件V2.0开始内置OPC UA服务器默认端口4840。要和Process Simulate做OPC UA联动流程上要做三件事。第一在TIA Portal里启用OPC UA服务器。CPU属性中找到“OPC UA”勾选激活OPC UA服务器设置端口号。安全策略至少保留“None”用于测试正式使用建议用“Basic256Sha256”并配置用户名密码或证书。第二在PLC程序中准备需要暴露给OPC UA的数据。OPC UA服务器不会自动暴露所有DB需要在DB属性里勾选“发布到OPC UA”或者通过“OPC UA XML设备描述”进行映射。第三Process Simulate里配置OPC UA客户端新建连接填入PLC的OPC UA地址比如opc.tcp://192.168.1.10:4840。连接建立后仿真端就可以读写PLC里的变量了。我在验证这个流程时遇到过一个有意思的问题OPC UA地址明明填对了安全策略也对但Process Simulate就是连不上报错信息是“BadSecurityModeRejected”。原因是我在PLC侧启用安全策略时选了“用户名和密码”但Process Simulate的客户端配置里还是匿名方式。把两侧的安全策略改成一致问题立刻消失。这个经验写在这里大家少走弯路。4.4 库卡机器人交互怎么接和库卡机器人交互是第十三章后面补充章节经常被问到的问题。库卡KR C4/KRC4机器人控制器和S7-1500之间最常用的是PROFINET IO通讯也就是机器人作为IO设备PLC作为IO控制器。需要在机器人的WorkVisual软件里配置一个“Profinet设备”分配输入/输出地址区长度比如输入32字节输出32字节PLC侧在TIA Portal里将机器人配置为PROFINET IO设备分配设备名称和IP地址组态IO地址。这种交互方式本质上是一种“信号交换”PLC把启动信号、工件号、允许运行等布尔量和少量数据写到输出区机器人把完成信号、故障代码、当前状态写到输入区。由于是周期性IO实时性有保障调试时用博图的在线监控可以非常直观地看到信号变化。如果项目要求交互的数据量很大比如要读写机器人的坐标、工艺参数PROFINET IO固定字节区就不够灵活了可以考虑走OPC UA。新一代库卡控制器对OPC UA的支持已经比较成熟S7-1500作为OPC UA服务器或者客户端都可以两者之间通过信息模型进行数据交换。这种做法的好处是数据类型丰富、可扩展性好缺点是实时性不如PROFINET IO适合数据密集型但非实时控制的场景。5. 翻译第十三章时的术语处理对照表与还原性检查5.1 高频术语的德英中对照翻译章节时我做了一个术语对照表长期做西门子项目的朋友可以直接参考德语/英文原词中文常见译法说明Datenaustausch / Data exchange数据交换不要译成“数据交流”Sollwertvorgabe / Setpoint specification设定值下发不要直译成“设定值预给定”Istwert / Actual value实际值/反馈值控制术语中常译作“反馈”Übertragungsrate / Baud rate波特率保持行业习惯不译成“传输速率”Telegramm / Telegram数据报文通讯领域固定叫“报文”Störung / Fault故障不要和“报警Alarm”混用Quittierung / Acknowledge确认/复位现场常用“复位”或“确认”Schnittstelle / Interface接口也常译作“通道”或“界面”依上下文定这个表看起来简单但实际翻译时每个词都可能造成理解偏差。比如“Störung”在变频器语境下通常指“故障”在PLC报警系统里又可能指“扰动”必须结合上下文判断。5.2 数据类型与寄存器地址是本地化的重灾区通讯章节里最怕翻错的是数据类型和寄存器地址。原文中如果有“Dword”而译者译成“双字”还好最怕的是把“Word”译成“单字”这种翻法读者完全不知道是多少位。我统一采用约定俗成的译法Bool布尔型Byte字节Word字16位Dword双字32位Real实数。寄存器地址描述则保留16进制写法因为现场对照手册时工程师一定会看协议帧里的十六进制地址翻成十进制反而容易出错。另一个让我纠结的是西门子通讯中的“Unit ID”概念。在Modbus TCP报文里Unit ID通常填1或者255很多人直接叫“站号”或“单元号”。我在译稿中统一用“单元标识”并在第一次出现时加括号说明“即习惯上说的站号/从站地址”这样既严谨又贴近现场表达。5.3 诊断信息不能一刀切直译通讯错误诊断信息是最容易翻译成“正确的废话”的地方。比如“Connection timed out”直译是“连接超时”单独的“连接超时”对现场工程师几乎没用。AF框架第九章、第十三章的错误排查表格里这种信息往往配了“可能原因”和“处理建议”。我翻译的原则是错误描述保留标准说法但后面一定要补上可执行的中文排查提示。举几个例子“No data received”译作“未接收到数据”补充提示“检查从站是否上电、RS485接线A/B是否接反、站号是否匹配”。“Illegal data address”译作“非法数据地址”补充提示“寄存器地址超出从站有效范围对照从站手册确认地址映射”。“Slave device busy”译作“从站设备忙”补充提示“从站正处理上一条请求可适当增大请求间隔时间”。这样处理后中文译文不再是生硬的词汇转换而是能让工程师直接照着干活的操作指导。5.4 可复现性检查清单翻译涉及程序示例的章节时我留了一个检查清单每次交稿前逐项打勾功能块接口参数名是否与英文原版一一对应避免两个版本不一致导致读者对照官方文档时找不到变量。DB编号、I/O地址、定时器编号保持不变不因为翻译顺手改成“更合理”的编号。寄存器地址、功能码、错误码全部保留十六进制原始写法。示例程序中注释的翻译保持简洁操作步骤不改变。涉及安全提示的警告、注意必须原样保留不要因为话多而删减。这个清单没什么高深技术但保证了我翻译出来的第十三章不是“中文化的版本”而是“中文环境下可以直接对照原工程实施的技术资料”。6. 把翻译稿丢进真实项目的验证心得6.1 博图在线调试中的验证翻译稿完成之后我并没有直接交付而是花了两个晚上用TIA Portal V17搭了一个最小验证环境。没有真实硬件我用PLCSIM模拟S7-1500再配合一个Modbus TCP从站仿真工具把第十三章里“Modbus TCP通讯块封装”的示例跑了一遍。这一步比我预想的更有价值。仿真环境里我首先验证了通讯块的初始化参数以及错误码后处理逻辑。原稿建议当通讯功能块返回错误码时不要把错误码直接丢给HMI显示而是先经过一个“错误解析FC”转化成文本字符串再显示在触摸屏上。这套机制在模拟环境里一切正常但我也发现一个问题有些错误是瞬时的比如偶发超时如果每次都弹报警操作工会疯掉。于是我在实现层面加了一个“连续三次错误才确认报警”的滤波逻辑这个经验在原稿中并没有详细展开但我觉得非常实用。6.2 时间锁程序案例与AF框架的结合第十三章里有一个小例子讲的是用PLC的实时时钟做设备使用时段控制也就是大家常说的“时间锁”程序。很多设备在交付后回款节点之前会限制部分功能等收款后通过密码、或者HMI里的授权界面解除限制。AF框架对这个功能的处理比较规范时间锁判断被做成了一个独立的FC输入参数是当前时间和授权截止时间输出参数是“是否允许运行”。逻辑层只在启动流程里调用这个FC而不是把时间判断散落在各个动作里。这样后期解除授权时只需修改一个全局DB里的截止时间或者通过一个高位密码进行在线修改。我特别想提醒一句时间锁功能的实现本身是合法的设备管理手段但不要把精力花在研究怎么绕过别人的时间锁上。作为设备交付方规范做法是合同里写清楚授权条款程序里预留解除授权入口作为使用方如果设备因为授权问题停机走商务流程解决比研究破解方案稳妥得多。6.3 我最后想说的几句实在话翻译第十三章这个过程对我自己也是一种提升。很多原来“凭经验做”的通讯设计在这套文档的体系里找到了理论依据。比如我以前也喜欢把通讯指令封装成FB但没有想过要从设备分类开始设计我以前也喜欢把上位机数据集中到一个DB但没有那么刻意地保证“这个DB可以被KepServer通过绝对地址访问”。如果你看完这篇文章想在自己的项目里试着落地AF框架的通讯思路我建议从两件小事开始第一把项目里所有通讯对象列一张清单按“标准化设备/第三方设备/IT系统”分类给每类定一种统一的通讯封装方式第二专门建一个“通讯数据池DB”所有进出的数据都经过这里HMI和上位机只跟这个DB打交道。这两件事做完你会发现不管后面接多少设备程序都不会乱到哪里去。