企业官网建设流程全解析

1. 一条报文两种成分：先把 PKW 和 PZD 的分工说清楚

如果你拆开一条 PROFIdrive 报文，会看到它被硬生生切成了两块：一块叫 PKW，一块叫 PZD。很多刚接触驱动通信的朋友第一次看到 PPO1、PPO3 或者"标准报文 1、标准报文 3"这种说法时，脑子里是一团浆糊——明明都是 16 位字，为什么有的字能启动电机，有的字却要等好几秒才有回应？答案就藏在 PKW 和 PZD 这两个缩写里。

PROFIdrive 是针对传动设备的一条通信行规，它规定了 PLC 和变频器、伺服驱动器之间"怎么说话"。这条行规最核心的设计思路，就是把数据按"实时性"和"非实时性"分成两条通道：PZD 负责跑得快的事，PKW 负责跑得慢的事。PZD 是过程数据，每毫秒都在刷新，承载的是控制字、状态字、转速设定值、电流实际值这类周期性数据；PKW 是参数通道，一次只能问一个参数、答一个参数，承载的是你要改 p1082、读 r0021 这类偶尔发生但必须准确的配置动作。

这篇文章适合三类人看：刚上手 G120/S120/MM4 系列驱动、需要自己做报文解析的电气工程师；在 PLC 侧要写参数读写程序、被"PKW 轮询写不出来"卡过的程序员；以及做上位机、做产线调试工具、需要裸解析 PROFIdrive 报文的软件开发者。下面我按"概念—结构—选型—实操—排错"的顺序，把这两个概念彻底拆开讲透，中间穿插大量我实际调试时记录的参数和代码，能直接抄。

1.1 为什么驱动通信一定要分成两条通道

先想一个很朴素的场景。产线上电机正在 1200 rpm 稳定运行，此时你想把加速时间从 10 秒改成 5 秒。如果你把这个"改参数"的动作塞进每毫秒刷新一次的过程数据里，会发生什么？首先是带宽被浪费——参数修改一年也没几次，却要占用每个周期的固定字节。更糟的是时序问题：驱动器收到参数请求后需要查表、校验、写 EEPROM，耗时可能是几十毫秒，而过程数据必须每毫秒响应，两者的时间尺度差了三个数量级。

所以 PROFIdrive 的做法非常工程化：周期性数据走固定映射的 PZD，非周期性数据走请求-应答式的 PKW。PZD 不需要"确认"，写进去就生效，下一个周期状态字就会反映结果；PKW 必须一问一答，发一个请求，等到应答才能发下一个。这个设计决定了很多现象，比如你在程序里连续写 10 个参数，如果不做排队，后面的请求会把前面的冲掉，最终只有第一个生效——这是新手最常见的坑之一。

1.2 PKW 与 PZD 的一张大对照表

把两者的差异摆在一张表里，后面所有细节都是从这张表派生出来的。

需要提醒一句：PKW 的具体字定义在不同厂商、不同固件版本之间存在差异，本文以业内最常见的西门子 SINAMICS 与 SIMOVERT 体系为蓝本讲解。你手头设备的手册里那张"PKW 结构"表，才是最终裁判。但只要你理解了它的设计逻辑，换任何品牌都能一看就懂。

2. PKW 参数通道拆解：PKE、IND、PWE 三个格子怎么填

PKW 的长度是固定的 4 个字，也就是 8 个字节，分别是 PKE、IND、PWE1、PWE2。这 8 个字节像一张寄快递的单子：PKE 是"收件人和业务类型"，IND 是"楼层和房间号"，PWE1+PWE2 是"包裹本身"。把这张单子填对，参数读写就成了。

2.1 PKE：一半是参数号，一半是任务码

PKE 是一个 16 位字，内部又被切成三段。高 4 位（bit 12~15）是AK，也就是任务/应答标识，说白了就是"我要干什么"；bit 11 在部分手册里叫 SPM 位或者保留位，通常写 0；低 11 位（bit 0~10）是PNU，也就是参数号本身，取值范围 1~1999。

任务码 AK 的常用取值我整理成下面这张表，这是整个 PKW 机制里最需要背下来的东西：

应答方向的 AK 值基本与请求一一对应，1/2/4/5/6/7 表示"正常传送参数值"，0 表示"驱动器还没处理完，暂时无应答"，9 及以上表示任务被拒绝，此时 PWE1 里装的是错误码。这里的"数组"指带下标的参数，比如 p2051[0]、p2051[1] 这种，下标通过 IND 传递。

错误码是排查问题的关键，最常撞见的几个列在下面：

注意：应答 AK 为 9 及以上时，别急着怀疑通信，先在 PWE1 里把错误码读出来。90% 的"参数写不进去"都是错误码 2 或 6，属于驱动器在正常拒绝你，不是通信故障。

2.2 IND：下标和参数号溢出的那个"夹层"

参数号超过 1999 怎么办？PNU 字段只有 11 位，塞不下 2051、2090 这些参数。解决办法就是 IND 的低字节 bit 0 当作"页号"：当参数号大于等于 2000 时，把页号置 1，PNU 字段里只填"参数号减 2000"。

举个例子，p2051（PZD 发送互联）的真实写法是：页号 = 1，PNU = 2051 - 2000 = 51，IND 的 bit 0 置 1。对应 PKE 的低 11 位就是 51，十进制写作 0x033。

IND 的高字节用来放子索引，也就是方括号里的那个数字。两者拼起来：IND = （子索引 << 8）| 页号。所以读 p2051[0] 的时候，IND = 0x0001；读 p2051[3] 的时候，IND = 0x0301。这个位运算很容易记混，我在现场见过不止一个人把子索引写进低字节，结果报错误码 3。

提示：SINAMICS 的多数参数是 p0xxx、p1xxx、r0xxx、r1xxx 区间，超过 1999 的以 p2xxx、r2xxx 为主。每次填写前先做一次心算，把页号和 PNU 拆干净，能省掉大量反复试错的时间。

2.3 PWE：数值是怎么塞进两个字的

PWE1 和 PWE2 是两个 16 位字，合起来 32 位。对于 16 位参数，只有 PWE2 有意义，PWE1 填 0；对于 32 位参数，PWE1 是高 16 位，PWE2 是低 16 位。这里的字节序是大端，也就是高字节在前的"网络序"，这一点在写上位机解析程序时特别容易翻车。

真正需要重点理解的是数值的表示方式。SINAMICS 的浮点参数在 PKW 通道里并不是 IEEE 754 格式，而是标幺化的定点数，规则是16384（0x4000）对应 100%，这个 100% 的物理意义由参考量决定：转速对应 p2000，电压对应 p2001，电流对应 p2002，转矩对应 p2003，功率对应 p2004。

举个完整的换算例子。假设 p2000 = 1500 rpm，你要通过 PKW 把 p1082（最大转速）设成 1200 rpm。1200 / 1500 = 0.8，0.8 × 16384 = 13107.2，取整 13107 = 0x3333。那么 PWE1 = 0x0000，PWE2 = 0x3333，AK 用 3（修改双字参数），PNU = 1082。

这个标幺化机制的好处是：同一套程序逻辑，换一台参考转速不同的电机，只要参考量设置正确，程序里的数值比例关系完全不用改。坏处也很明显——忘了乘参考量，写进去的值就会离谱地大或者小。

2.4 一次完整读写的字节推演

把前面几块拼起来，我们用"读 r0021[0]（实际转速实际值）"做一次完整推演。r0021 小于 2000，不需要页号，IND 的低字节为 0；它是带下标的参数，AK 用 6（请求数组字），但它是浮点双字，所以 AK 用 7（请求数组双字）更合适；下标写 0。

于是请求帧是：PKE = 0x7035（AK=7，PNU=0x35=53？注意这里有个陷阱）。这里必须澄清一个容易搞错的地方：r0021 的 PNU 就是 21，不是 53。PKE 的低 11 位直接写十进制 21，也就是 0x015，所以 PKE = 0x7015。我见过有人把参数号当成十六进制写进去，结果读到别人的参数，非常危险。

应答帧回来时，PKE = 0x7015，IND = 0x0000，PWE1 和 PWE2 组成 32 位定点值。假设 PWE1 = 0x0000、PWE2 = 0x2000，那么值 = 8192，转速 = 8192 / 16384 × 1500 = 750 rpm。整个过程在 20~50 ms 内完成，比 PZD 慢得多，但完全够用——毕竟你改参数不需要每毫秒改一次。

3. PZD 过程通道拆解：控制字、状态字和标幺值

PZD 是真正让人有"实时控制感"的部分。它的字是固定映射的，顺序不能乱：PLC 发出去的前两个字通常是 STW1（控制字 1）和 HSW（主设定值），驱动器回来的前两个字通常是 ZSW1（状态字 1）和 HIW（主实际值）。这个"2/2"结构是使用频率最高的组合，绝大多数启停调速场景用它就够了。

3.1 STW1 控制字：16 个位就是 16 个开关

STW1 的每一个位都是一个独立命令，这种设计让一个字的传输就能完成完整的启停控制，不需要额外的过程数据。核心位的含义如下：

实际操作中最常用的三个状态码是：0x047E（准备状态，OFF2、OFF3 释放，使能位置 1，但 ON/OFF1 为 0，电机不转）、0x047F（启动，等于在 0x047E 基础上把 bit 0 置 1）、以及把 bit 7 置 1 再清 0 来复位故障。这三个数值我几乎每个项目都要用，背下来能省很多翻手册的时间。

注意：bit 10"由 PLC 控制"必须为 1，否则你在总线上发什么驱动器都不理你，状态字里 bit 9 也不会给出"PZD 控制请求"的有效反馈。这个坑非常隐蔽，因为通信看起来一切正常，就是电机不转。

3.2 ZSW1 状态字：驱动器在跟你汇报什么

ZSW1 是驱动器的"回话"，PLC 侧要通过它判断当前能不能启动、有没有故障。几个关键位：

一个合格的启动时序必须检查 ZSW1 的 bit 0 和 bit 1，两者都为 1 才发送 0x047F。如果 bit 3 为 1，说明有故障，必须先发复位脉冲。很多人写程序时直接一把梭把 0x047F 发出去，然后抱怨"驱动器不理我"，其实是驱动器根本没准备就绪。

3.3 设定值与实际值的标幺换算

HSW 和 HIW 用的也是 16384 = 100% 的规则，参考量同样是 p2000 这类参数。如果 p2000 = 1500 rpm，你想跑 900 rpm，那么 HSW = 900 / 1500 × 16384 = 9830.4，取整 9830 = 0x2666。反过来，HIW 读到 0x4000 就是 16384，对应 1500 rpm。

这里有一个很实用的技巧：先把参考量统一设成工艺上最常用的值。比如设备主要工作在 1450 rpm 附近，那就把 p2000 设成 1500，这样 100% 附近的分辨率最高，计算也顺手。如果你把 p2000 设成 3000 而实际只用 750 rpm，那么 25% 的量程意味着有效位数被浪费了一大半。

在 SCL 里我习惯封装两个函数，一个负责标幺转物理，一个负责物理转标幺，参数是参考量：

FUNCTION "ScaleToPerUnit" : DINT VAR_INPUT rPhysValue : REAL; // 物理值，如 rpm rReference : REAL; // 参考量，如 p2000 END_VAR BEGIN IF #rReference = 0.0 THEN "ScaleToPerUnit" := 0; ELSE "ScaleToPerUnit" := REAL_TO_DINT(#rPhysValue / #rReference * 16384.0); END_IF; END_FUNCTION

注意要用REAL_TO_DINT而不是截断，并且在使用前判断参考量非零，否则会触发浮点异常。

3.4 PZD 互联映射：字里装什么由谁决定

PZD 的每个字具体对应哪个物理量，是靠互联参数决定的，不是固定死的。在 SINAMICS G120 上，接收方向（PLC→驱动器）由 p2080[0..15] 定义，发送方向（驱动器→PLC）由 p2051[0..15] 定义，而 r2090[0..15] 和 r2089[0..15] 则是这两个方向的"中转站"。

默认状态下，p2080[0] 通常互联到 r2090.0，也就是 STW1；p2080[1] 互联到 HSW；p2051[0] 互联到 r0052（状态字 1）；p2051[1] 互联到 r0063（转速实际值）。如果你想在第三个 PZD 字里传转矩实际值，就得把 p2051[2] 改成 r0080 之类的连接器。改完之后要注意，PLC 侧的报文长度也必须同步调整，否则整个 PZD 区会错位。

提示：改互联参数之前先把当前的连接关系抄下来。我就吃过一次亏，把 p2051[1] 改成别的信号之后忘了改回来，后面调试时实际值一直不对，查了一下午才发现是互联被改了。

4. 报文结构选型：PPO 与标准报文怎么配

PKW 和 PZD 不是二选一，而是要根据场景组合。组合之后形成的固定结构，在 PROFIBUS 时代叫 PPO，在 PROFINET 时代叫标准报文。选对了，后面所有工作都顺；选错了，要么带宽浪费，要么功能不够用。

4.1 PROFIBUS 上的 PPO 类型

PPO 是"参数/过程数据对象"的缩写，几种常见类型如下：

可以看到规律：带 PKW 的 PPO 编号是 1、2、5，不带的是 3、4。带宽紧张的时候选 PPO3/4，需要总线写参数就选 PPO1/2。PPO5 一般用在多轴伺服上，10 个 PZD 字可以放多个轴的控制字和设定值。

4.2 PROFINET 上的标准报文

到了 PROFINET，西门子把这套东西重命名成"标准报文"，用数字编号：

选择逻辑很清晰：先用"要不要通过总线改参数"决定带不带 PKW，再用"要传几个过程量"决定 PZD 长度。需要注意，不同固件版本对报文编号的支持范围不同，某些报文在旧固件上不存在，组态时选不到就是选不到，别硬凑。

4.3 选型时我踩过的几个坑

第一个坑是贪大。有人觉得 PPO5 最全，一律选最大的，结果 IO 数据长度撑到 32 字节，PROFINET 的更新周期被拉长，控制响应变慢。报文长度和刷新周期是此消彼长的关系，够用就好。

第二个坑是以为 PKW 越多越好。其实 PKW 只有 4 个字，一次只能处理一个任务，加长也不会变快。如果参数访问频繁，更现实的做法是走非周期通信，比如通过记录读写（Record Read/Write）的方式背靠背访问，效率比反复走 PKW 高得多。

第三个坑是组态报文和驱动器参数不一致。SINAMICS 上要用 p0922 选择报文，或者手动改 p2051/p2080 做自由互联。如果你在 PLC 侧选了标准报文 1，驱动器侧却还停留在自由互联状态，通信能建立，但数据是乱的，症状是状态字读出来一堆无意义的位。

5. 实操：从零写一个 PKW 轮询状态机

PKW 最让人头疼的地方在于它是"一问一答"，而 PLC 的扫描周期是连续的。你不能在一个周期里发请求，又在同一周期读应答——应答根本还没回来。所以必须写状态机，用若干个扫描周期完成一次事务。

5.1 先定义好数据结构

我习惯做一个 UDT，把 4 个字打包，这样输入输出各占一个管脚，接线清爽：

TYPE "UDT_PKW" STRUCT PKE : WORD; // 参数标识：AK + PNU IND : WORD; // 高字节为下标，低字节 bit0 为页号 PWE1 : WORD; // 值高字 PWE2 : WORD; // 值低字 END_STRUCT END_TYPE

IO 映射上，输出的 4 个字映射到 PQW（发送区），输入的 4 个字映射到 PIW（接收区）。注意发送区和接收区在报文里是分开的两段，别试图把接收数据写回发送区。

5.2 状态机的四个状态

我一般用四个状态就够：空闲、装载请求、等待应答、解析结果。

• 空闲态：PKE 写 0，等外部触发。
• 装载态：根据参数号算出 PKE 和 IND，把值填进 PWE，置位一个"请求已发出"的标记。
• 等待态：每周期检查输入 PKE 的高 4 位。如果为 0，说明驱动器还没处理完，继续等；如果不为 0，进入解析。
• 解析态：判断应答 AK 是否等于请求 AK。相等说明成功，读 PWE 取数据；如果大于等于 9，说明失败，从 PWE1 取错误码。

这里有个细节值得说：等待应答时一定要加超时。正常情况下应答在几十毫秒内回来，如果超过 500 ms 还没动静，基本可以判定是参数号写错或者通道被占用，这时候应该放弃本次事务并报错，而不是无限等下去。

5.3 SCL 代码骨架

下面这段是我常用的骨架，去掉了业务逻辑，只保留核心流转：

FUNCTION_BLOCK "FB_PKW_POLL" VAR_INPUT xStart : BOOL; // 上升沿触发一次事务 iAK : INT; // 任务码 iPNU : INT; // 参数号 iSubIdx : INT; // 子索引 diValue : DINT; // 写入时使用 tTimeout : TIME := T#500ms; END_VAR VAR_IN_OUT pkwOut : "UDT_PKW"; pkwIn : "UDT_PKW"; END_VAR VAR iState : INT; tonWait : TON; xDone : BOOL; iErrCode : INT; END_VAR BEGIN CASE #iState OF 0: // 空闲 #pkwOut.PKE := 16#0000; #pkwOut.IND := 16#0000; #pkwOut.PWE1 := 16#0000; #pkwOut.PWE2 := 16#0000; IF #xStart THEN #iState := 10; END_IF; 10: // 装载请求 IF #iPNU >= 2000 THEN #pkwOut.IND := WORD#16#0001 + INT_TO_WORD(#iSubIdx) * 256; #pkwOut.PKE := INT_TO_WORD(#iAK * 4096 + #iPNU - 2000); ELSE #pkwOut.IND := INT_TO_WORD(#iSubIdx) * 256; #pkwOut.PKE := INT_TO_WORD(#iAK * 4096 + #iPNU); END_IF; #pkwOut.PWE1 := DINT_TO_WORD(SHR(IN := #diValue, N := 16)); #pkwOut.PWE2 := DINT_TO_WORD(#diValue AND 16#FFFF); #tonWait(IN := TRUE, PT := #tTimeout); #iState := 20; 20: // 等待应答 IF #pkwIn.PKE <> 16#0000 THEN #tonWait(IN := FALSE); #iState := 30; ELSIF #tonWait.Q THEN #iErrCode := -1; // 超时 #iState := 0; END_IF; 30: // 解析 IF (SHR(IN := #pkwIn.PKE, N := 12) AND 16#000F) >= 9 THEN #iErrCode := WORD_TO_INT(#pkwIn.PWE1); ELSE #iErrCode := 0; END_IF; #xDone := TRUE; #iState := 0; END_CASE; END_FUNCTION_BLOCK

有个容易忽略的点：PKE 写请求前必须先清零，否则上一轮的残值会让驱动器误判。代码里在空闲态强制清零就是这个目的。另外，状态机的输入触发要用上升沿，不然会连续发起请求。

5.4 PZD 侧的启停时序

PKW 讲完，PZD 的实操反而简单，因为它不需要状态机，只要按时序发字就行。我一般按这个流程走：

1. 上电后先发 0x047E，保持至少两个总线周期。
2. 检查 ZSW1 的 bit 0 和 bit 1 是否都为 1。
3. 若 bit 3（故障）为 1，把 bit 7 置 1 保持一个周期再清 0。
4. 条件满足后写 HSW，再发 0x047F。
5. 运行中监控 ZSW1 的 bit 8，判断是否已跟随到设定值。
6. 停机时发 0x047E，用 OFF1 斜坡停车。

整个过程里最容易出错的是第 3 步——复位脉冲太短，驱动器采样不到。建议故障复位位保持 100 ms 以上，别用一个扫描周期就清掉。

5.5 上位机侧用 Python 做离线解析

做调试工具或者事后分析故障时，我经常用 Python 直接解析记录下来的报文，比在 PLC 里加监控快得多：

def parse_pkw(pke, ind, pwe1, pwe2): """把 PKW 四个字拆成可读信息""" ak = (pke >> 12) & 0x0F pnu_raw = pke & 0x07FF page = ind & 0x0001 sub_index = (ind >> 8) & 0xFF pnu = pnu_raw + (2000 if page else 0) raw_value = (pwe1 << 16) | pwe2 return { "AK": ak, "PNU": pnu, "SubIndex": sub_index, "RawValue": raw_value, } # 例：应答返回 PKE=0x7015, IND=0x0000, PWE1=0x0000, PWE2=0x2000 print(parse_pkw(0x7015, 0x0000, 0x0000, 0x2000)) # {'AK': 7, 'PNU': 21, 'SubIndex': 0, 'RawValue': 8192}

拿到 RawValue 之后再除以 16384 乘参考量，就得到物理值。这个脚本我一般会做成命令行工具，支持直接贴十六进制字符串，排查现场问题非常快。

6. 常见问题与排查速查表

PKW 和 PZD 的故障现象差异很大：PZD 出问题通常是"电机不转、状态字异常"，PKW 出问题通常是"参数读写没反应、返回错误码"。分开判断能少走很多弯路。

6.1 几个高频现象和它们的根因

现象一：PZD 数据全零，驱动器像没收到。十有八九是报文组态不匹配。PLC 侧选了报文 1，驱动器侧 p0922 没设或者设成了别的，通信能建立，但数据映射对不上。检查方法很简单：在驱动器侧看 r2090[0] 的值，如果一直是 0，说明接收映射没生效。

现象二：参数写进去，断电就丢了。这是把参数写到了 RAM 而不是 EEPROM。部分参数需要额外的"复制到 ROM"操作才会掉电保持，比如某些品牌的 p0971 之类的参数。写完关键参数后主动做一次保存，比事后追责强。

现象三：读回来的值大得离谱。大概率是标幺换算没做。比如读 r0021 得到 8192，直接当成 8192 rpm 报给了上位机。养成习惯：凡是浮点参数，先除以 16384 再乘参考量。

现象四：连续写多个参数只有第一个生效。典型的没做排队。PKW 一次只能一个任务，必须等应答回来才能发下一个。如果你的程序在 for 循环里连续写 4 个字，那只有第一个会被处理。

现象五：写参数返回错误码 6。参数要求停机修改，但驱动器正在运行。要么先停机再写，要么找找有没有对应的"运行中可改"参数。

6.2 速查表

6.3 几条现场心得

第一条，先把 PZD 调通，再调 PKW。PZD 通了说明物理层、组态、映射都没问题，PKW 不顺只是逻辑问题。反过来，如果两个一起调，你分不清是通信问题还是逻辑问题。

第二条，用面板做对照实验。驱动器面板上能查到任何参数的值，用 PKW 读出来的值跟面板对比，能立刻判断是读错了参数还是解析错了格式。

第三条，把错误码打印出来，不要只判断成功失败。一个 iErrCode 变量加上一个能显示的地方，能帮你省掉大量猜测时间。我现在的模板里，错误码是强制显示的。

第四条，注意字节序。西门子的 PLC 存储字的时候是高字节在前，但某些第三方抓包工具显示的顺序可能不同，比对的时候要统一口径。

7. 我个人在这些项目里的一点体会

刚开始接触 PROFIdrive 的时候，我最不理解的就是"为什么参数通道非要设计成一次一个"。后来自己做了一个需要动态切换 20 多个参数的配方系统，才明白这个限制其实是保护：它逼着你去思考访问顺序、超时处理和错误恢复，而不是一股脑把请求全推出去。真要做批量参数访问，正确姿势是维护一个队列，队首处理完再出队，配合超时和重试，稳定性比"并发"高得多。

另外一点，报表和文档里最常见的信息是"报文号是多少、PZD 几个字"，但真正决定项目能不能按时调完的，是那些边角细节：p2000 设成多少、STW1 的复位脉冲保持多久、PKW 的错误码怎么显示出来、互联参数改完有没有备份。这些东西手册上都有，只是散落在不同章节。我现在习惯在项目开始阶段就建一张"通信参数清单"，把参考量、报文号、互联关系、关键位定义全部记在一页纸上，后面调试时省事得多。

如果这个项目后面要继续扩展，我建议往两个方向走：一是把 PKW 访问封装成通用功能块，参数号、下标、读写类型做成输入，直接用，不再重复写状态机；二是考虑把非周期通信用起来，把频繁访问的参数搬到记录读写通道上，让 PKW 只处理少量关键任务。这两步做完，整个驱动通信层的代码量能砍掉一半，可维护性会明显变好。