企业官网建设流程全解析

简介：这份文档面向工业自动化领域的电气工程师、PLC 编程人员及自学者，聚焦西门子 S7-1500 与巴鲁夫 RFID 的读写控制实现，帮助读者在流水线工件追踪、托盘信息记忆等场合建立从硬件组态到程序编写的完整思路。资源为 1 个 docx 文件，压缩包约 708KB，内容围绕硬件配置、实现步骤与程序实例展开，属于轻量但结构完整的工程笔记。文档先说明巴鲁夫 RFID 由分析单元、读写头和数据载体三部分组成，再介绍 CPU1511-1 PN 与博图 V15 的软硬件环境，随后依次讲解 GSD 文件导入与 I/O、IP 配置、FB31 示例块调用及 DB 块划分，并给出初始化、复位、读取、写入与数据转移的编程示例，涉及 MOVE、FILL、延时等指令的用法；末章还总结了程序的通用性与数据填充长度的注意事项。已有 1859 人学习，适合需要快速上手或对照排错的一线技术人员参考。

1. 托盘上的工件信息，为什么值得用 RFID 记住

一条装配线上，托盘载着工件依次经过压装、检测、拧紧几个工位。每一站都要回答同一个问题：这块料是谁、上一站做了什么、这一站该不该放行。用条码贴在托盘侧面也能扫，但条码怕油污、怕磕碰，托盘回程清洗一遍就模糊了；用视觉识别又得每站配相机和光源，成本压不住。用西门子 1500 PLC 配巴鲁夫 RFID 做读写，是我见过比较克制的一种做法：载体跟着托盘一路走，PLC 只在工位边界把数据读出来、再写回去，识别这件事就退化成了几个字节的搬运。这套方案要解决的核心不是「能不能读到」，而是「读到的数据怎么在 PLC 里组织、怎么写回去不丢不重、怎么让操作工在触摸屏上看得懂」。适合正在做产线追踪类毕设、课程设计，或者要给一条老线补上工件追溯能力的同学和现场工程师。

2. 总体方案设计：三层硬件分工与一条数据链路

2.1 巴鲁夫 RFID 三个部件各自的职责边界

一套巴鲁夫 RFID 拆开看是三件东西，很多人上手时把它们混成一件事，结果调试时连「读不到数该去查哪一层」都说不清。

分析单元是收到数据后进行处理的硬件，本质上是射频侧和工业以太网侧之间的翻译官，它负责通道管理、射频功率输出、协议转换。一个分析单元最多可以插 4 个读写头，这个数字很关键：它意味着一台分析单元能覆盖四个工位，成本按工位摊薄，但反过来也意味着四个读写头共用一套通信资源和一份诊断信息，一个头出问题，诊断缓冲区里的报错可能是混在一起的。

读写头负责真正的射频收发，读出载体里的数据、把数据写进载体。它上面有绿色的电源指示灯和橙色的工作指示灯，正常工作时橙色灯会闪烁。调试时这两个灯就是第一手的现场信息，绿灯不亮说明供电或总线没通，绿灯亮但橙灯常亮不闪，多半是射频侧没建立起来，比如载体不在有效距离内，或者通道号配错了。

数据载体是存储数据的那一方，一般跟着工件或托盘移动。它不是一张只读的身份证，而是有可读写存储区的，能反复擦写。正因为可写，才引出了后面的设计问题：哪些数据该跟着工件走，哪些不该。

我一般的划分是：载体上只放「跟着工件必须走」的信息——工件编号、当前工序号、工艺结论（合格/返修/报废）、关键拧紧扭矩这类短小的结论值。至于某个工位采了哪些过程曲线、采了多少个点，那些留在上位机或 PLC 的数据记录里，载体放不下也不该放。这个边界定不清楚，后面 DB 块的长度就会一直改，改一次组态、程序、触摸屏三处都要跟着动，血泪经验。

2.2 CPU1511-1 PN 的选型余量与 I/O 预算

这套方案的主控是西门子 1500 系列的 CPU1511-1 PN，编程用博图 V15。1511-1 PN 在 1500 家族里属于偏小的那一档，自带一个 PROFINET 接口，拿来带一台 RFID 分析单元加几个远程 I/O，余量是够的，但不能当成没有上限。

真正要算的是三笔账。第一笔是 I/O 地址账：分析单元在博图里是以 GSD 设备的形式挂上去的，每个读写头通道会占用一段输入字节和一段输出字节，读写各占多少，由 GSD 文件里定义的模块长度决定，组态时在设备视图里能直接看到起始地址和长度。四个通道插满，输入输出地址就要连着排下去，排在后面的远程 I/O 或伺服就得往后挪，规划时最好留出一段空隙，别排得满满当当。

第二笔是存储账：FB31 是官方示例程序块，本身要占背景 DB，读写数据各要占 DB，给触摸屏做交互又是两个 DB，再加上你自己的工艺逻辑，DB 编号和块号最好一次性规划好，别等到程序写了一多半才发现 FB 号和系统保留块撞了。

第三笔是通信账：分析单元走 PROFINET，和 PLC 之间是周期性的过程数据交换，1511-1 PN 的通信资源够用，但如果你在这条线上还挂了远程 I/O、变频器、HMI，刷新周期就要留意。RFID 的读写本身不是高频动作，一个托盘到一个工位才触发一次，周期放宽一点对实时性没有影响，反而让总线更稳。这一点我一般会在组态里把分析单元的看门狗时间适当放宽，避免个别读写头响应慢导致整站掉站。

2.3 数据从载体到 DB 的完整流转路径

把链路画直了，后面所有程序都是围着这条线转：

载体（跟着托盘走）→ 射频 → 读写头 → 分析单元（通道管理、协议转换）→ PROFINET → PLC 过程映像区 → FB31（示例块内部完成帧组装与握手）→ 读 DB / 写 DB → FC 调度层（工艺判断、状态机）→ HMI 交互 DB。

看清楚这条链路，就会明白一件事：PLC 程序里你真正能控制的只有后半段。前半段——射频能不能读到、分析单元有没有把数据送上来——靠的是组态和现场安装，程序写得再漂亮也救不了天线装歪。所以我的调试顺序永远是先通链路、再做逻辑：先让 FB31 能把载体里的一段原始字节稳定地搬到读 DB 里，哪怕搬上来的是乱码，只要字节在动，链路就是通的；再去管字节里的内容对不对、工艺流程怎么判。反过来，一上来就写业务逻辑，出了问题是组态问题还是程序问题，你会分不清，那才是真玄学。

3. 硬件组态落地：GSD 文件导入到设备名分配

3.1 GSD 文件安装与硬件目录定位

巴鲁夫 RFID 分析单元不是博图自带目录里的设备，得靠厂商提供的 GSD 文件把它「教会」博图认识这个设备。做法是在博图的「选项」菜单里找到「管理通用站描述文件」，选中 GSD 文件所在目录，勾选要安装的那一条，安装完成后重启一下硬件目录的刷新。

这里有两个容易忽略的点。一是 GSD 文件通常分版本，同一款分析单元可能有 PROFINET 版和别的总线版本，装错了在硬件目录里能找到设备，但挂到网络视图上就是连不通。二是安装时源目录里最好只放这一个文件，不要和别的设备的 GSD 混在一个文件夹里，否则勾选时容易选错行。

安装成功后，在硬件目录的「其它现场设备 → PROFINET IO」下面能找到这台分析单元，把它拖到网络视图里，和 CPU 的 PROFINET 口连起来。这时候网络视图上会出现一条绿色的网线，说明逻辑连接建立了，但物理上通不通，还得看后面的设备名和 IP。

3.2 I/O 点配置与地址规划

双击设备视图里的分析单元，进入配置界面。这里要做的第一件事是把通道使能——你实际插了几个读写头，就使能几个通道，没插的通道关掉。这一步看着无关紧要，实际上关掉未使用通道能减少无效的诊断报警，调试时不至于被一堆「通道未连接」的报错淹没。

接着是 I/O 地址。组态会根据 GSD 里定义的模块长度自动分配输入输出的起始地址，你可以手工改，但改完要记下来。下面这份规划示意，是我在四通道场景下常用的排法，实际地址以你组态里自动分配的为准：

长度的具体数值以 GSD 里给的为准，这份表只说明排布思路：每个通道的输入输出要成对留够，通道之间不要交叉，后面接远程 I/O 时从最后一个通道之后开始排。中间留一段空隙是个好习惯，将来加一个通道或者换成数据长度更大的型号，不用把后面的地址全推倒重来。

配置好 I/O 之后，在设备属性里设置 IP 地址和 PROFINET 设备名称。IP 要落在和 CPU 同一个网段，设备名建议带工位含义，比如按「工位+设备类型」的规则起名，别用默认的一长串字母数字，现场查线的时候你会感谢自己。

3.3 IP 地址与设备名谁先谁后

这一步是新手最容易翻车的地方。PROFINET 的设备寻址靠的是设备名，不是 IP。你把 IP 设对了，设备名没分配或者分配错了，PLC 一样找不到这个设备，诊断缓冲区里报的是站故障或者设备名无法解析。

正确的顺序是：先在组态里把设备名和 IP 都填好，下载组态，然后用「分配设备名称」这个在线功能，把组态里的名字真正写进分析单元里去。这一步需要在线扫描，扫描出来的设备会显示它的 MAC 地址和当前设备名，选中之后点分配，名字才落地。

提示：换了备件或者把分析单元拿去别处用过，设备名会被清掉或者残留旧名字，重新上线前必须再做一次分配设备名称，否则你会在现场对着一台完好的设备查半天。

设备名分配完，再看设备视图里模块的诊断状态，正常情况下应该全是绿色。这一步做完，才轮到下载程序。四步顺序别跳：装 GSD → 组态 I/O 与 IP → 下载组态 → 分配设备名称。

3.4 下载组态后的在线初检

组态下载进 PLC 之后，不要急着写程序，先做三件事。

第一件，打开在线诊断，看分析单元是不是真的在线、有没有报警。硬件目录里挂上了但物理没通，设备图标上会有红色的断开标记。

第二件，看模块的输入区有没有在动。读写头对着一个放在有效距离内的载体，输入区里至少会有一两个状态字节在变化。如果全是零，说明射频侧还没建立，回去查天线、查通道使能、查载体是不是真的在这一个读写头的覆盖范围内。

第三件，手动触发一次读。这一步可以借用示例程序块的调试面板，也可以临时写两行 MOVE 把控制字打进命令区，只要能看到输入区里出现一帧有规律的数据，链路就算通了。这三件事加起来十几分钟，但能省掉后面几个小时的扯皮。

4. 程序结构设计：FB31 封装 + FC 调度 + 四类 DB 的职责划分

4.1 FB31 示例块的调用方式

官方提供的 RFID 示例程序是一个编号为 FB31 的 FB 块，它内部已经把帧头、长度、校验、握手时序这些脏活封装好了，对外只露出命令字、写缓冲、读缓冲和几个状态位。你要做的是把它当成一个「射频驱动」来用，而不是拆开去改里面。

用法上，新建一个 FC 块作为调度层，在 FC 里调用 FB31。因为 FB31 是 FB，调用时必须给它一个背景 DB 来保存内部状态，这个背景 DB 可以在调用时直接新建，命名上体现用途，比如按「工位+RFID背景」来起。原文里提到的「新建 2 个 DB 块分别用作块的读取和写入」，指的是给 FB31 的读缓冲和写缓冲各配一个数据 DB；「为了方便触摸屏上操作再新建两个 DB」，是给 HMI 做画面绑定用的交互 DB。加上背景 DB，一个通道大概要占 5 个 DB 块。四个通道就是二十个块，块号规划一定要提前做，我的习惯是每通道预留 10 个块号，中间空着不用，方便后面加功能。

调度层的结构大致是这样：

// FC 调度层：一个通道一段，段与段之间互不干扰 // 通道1：上料工位——只读不写 "CALL_FB31_CH1"(EN := TRUE, cmdWord := "RFID_Cmd_CH1".cmdWord, wrData := "RFID_Write_CH1".payload, rdData => "RFID_Read_CH1".payload, busy => "RFID_Status_CH1".busy, done => "RFID_Status_CH1".done, error => "RFID_Status_CH1".error); // 通道2：压装工位——只写不读 "CALL_FB31_CH2"(EN := TRUE, cmdWord := "RFID_Cmd_CH2".cmdWord, wrData := "RFID_Write_CH2".payload, rdData => "RFID_Read_CH2".payload, busy => "RFID_Status_CH2".busy, done => "RFID_Status_CH2".done, error => "RFID_Status_CH2".error);

这段代码里，cmdWord是你发给 FB31 的命令字，决定这一次是做读还是做写；wrData和rdData是写入缓冲和读取缓冲，类型要和 DB 里的数组对齐；busy / done / error是握手状态，业务逻辑只认这三个位，不关心 FB31 内部怎么跑。引脚名以你手上那份示例块的实际定义为准，各版本可能有出入，但结构就是这个结构。

4.2 四类 DB 各管什么

DB 分不清职责，是这类项目里最常见的结构性错误。我按用途把它们分成四类，各自只干一件事：

关键在最后一行。HMI 交互 DB 是界面和逻辑之间的隔离带，不是数据的主副本。屏上按一下「读取」，HMI 往交互 DB 里写一个按钮位，PLC 的调度层看到这个位，去做边沿判断、装载命令字、触发 FB31。数据读回来之后，PLC 再把结果搬到交互 DB 的显示区给屏看。中间隔了这一层，屏换型号、画面改布局，都不用动底层逻辑；反之把画面直接绑到 FB31 的缓冲 DB 上，改一次画面就有可能把缓冲数据覆盖掉，这种后悔药没处买。

4.3 控制字时序：初始化、复位、读、写、开始五段程序

整个读写动作拆成五段程序，原文里也是这个分法，顺序不能乱。

初始化程序在 PLC 启动时跑一次，把 RFID 分析单元拉到可工作的状态，清掉残留的命令字和缓冲，把状态机置到空闲。这段程序要用首次扫描位做条件，不要放在循环里反复执行，反复初始化会让分析单元一直重启通道。

复位程序负责复位 RFID 的报错或者读写状态。现场最常见的场景是读写头被工件蹭了一下、或者载体贴歪了读失败，报错位挂住之后不复位，后面所有命令都发不出去。复位要做两件事：清 error 位，把状态机拉回空闲。但复位不能无脑自动重试，重试次数要限，不然一个真的坏掉的读写头会被程序反复触发，把诊断缓冲区刷满。

读取程序负责把读命令的控制字送进 FB31。原文里的做法是用 MOVE 指令把控制字移动到 MW136 这个中间寄存器里，再由 FB31 取走：

// 读取触发：按钮上升沿 → 装载读控制字 → 置忙 #edgeRead := "HMI_Cmd".btnRead AND NOT #edgeReadMem; #edgeReadMem := "HMI_Cmd".btnRead; IF #edgeRead AND NOT "RFID_Status_CH1".busy THEN // MOVE：把读命令控制字送进中间寄存器，再由 FB31 取走 "RFID_Cmd_CH1".cmdWord := 16#0001; // 读命令码，位定义以示例块手册为准 "RFID_Status_CH1".busy := TRUE; "RFID_Status_CH1".step := 10; // 状态机：10 = 命令已装载 END_IF;

这里的16#0001只是一个占位说明，真正的命令字编码要看示例块配套的说明，别照抄。中间寄存器 MW136 的作用是给命令字一个稳定的落点，调试时可以在监控表里直接盯这个字，比一层层翻 DB 快得多。

写入程序的思路一样，只是命令字换成写命令，并且要先把待写数据准备好。开始程序是当控制字写进去之后，让 RFID 真正动起来的那一段，它负责发启动条件、等 done 或 error、做超时判断。三段合起来是一个典型的状态机：装载命令 → 启动 → 等待 → 收尾。

注意：读取和写入共用同一个 FB31 实例时，两条命令不能同时发。必须等上一条的 done 或 error 回来、busy 落下去，才能装载下一条。这条约束不写在程序里做互锁，现场就会出现「读一半被写打断」的数据错位故障，而且极难复现。

4.4 FILL 与 MOVE 在数据搬运中的分工

数据搬运这一段，原文点得很实在：把读出来或者要写入的数据写到一个 DB 块内，然后用 FILL 指令把这里面的数据复制填充到块的 DB 里。

MOVE 管的是单个值或者短数据，比如把控制字送进命令寄存器、把工件编号从一个字搬到另一个字。它的语义是赋值，一次一个。

FILL 管的是整片区域的填充，语义是「用同一个源，铺满目标区」。它在你需要把一整帧缓冲清空、或者把一份准备好的数据整体铺到发送缓冲里时特别顺手：

// 写之前的准备：先用 FILL 把发送缓冲整片清零，避免残留上一件的数据 FILL_BLK(in := 0, count := 32, // 填充元素个数 = 数组实际元素数 out := "RFID_Frame_CH2".writeBuffer); // 把工艺数据整体铺进发送缓冲 FILL_BLK(in := "RFID_Write_CH2".payload, count := 32, out := "RFID_Frame_CH2".writeBuffer);

count这个参数是全篇最值得盯的一个数字：你自己建了多长的数组，就填多少位。建了 32 个元素只填 16 个，后 16 个就是上一件工件残留的脏数据，写进载体之后读出来全是错的，而且错得很有规律，最容易让人误判成硬件问题。反过来填超了，编译或运行时会报区域越界。我的做法是把长度定义成一个常量，DB 数组声明、FILL 的 count、FB31 的缓冲长度三处全部引用这个常量，改一处就全改，不给手抖留机会。

5. 避坑与排查：调试现场最容易翻车的五个点

5.1 组态下载完，设备图标一直红着

现象：组态编译下载都成功，但在线一看分析单元的图标是红的，诊断缓冲区里报站故障或者设备名无法解析。

原因几乎都是设备名没落地。PROFINET 靠设备名寻址，组态里的名字只是一个「期望值」，没有真正写进设备。新设备出厂、备件更换、设备被拿到别的地方用过，名字都可能对不上。

解决：用「分配设备名称」的在线功能扫描，按 MAC 地址认人，把组态里的名字写进去。写完之后断电重启一次分析单元，再看诊断。这一条我在每个项目上都会在调试记录里单独列一行，因为它太常见，常见到容易被当成玄学。

5.2 灯在闪，就是读不到数

现象：读写头绿灯亮、橙灯也在闪，说明供电和射频都在工作，但 PLC 的读缓冲里始终是零，或者一直是上一次的数据。

原因按概率排：一是载体不在有效读写距离内，或者贴的方向不对，尤其是金属托盘，载体的安装面有讲究；二是通道号和程序里的不一致，组态时使能的是 CH2，程序里操作的却是 CH1 的地址；三是同一区域两个读写头的射频互相干扰，尤其是两个工位挨得很近的时候。

解决：拔掉其它三个通道，只留一个，用单个载体在读写头前面慢慢移动，看输入区有没有反应。单通道能读到，再一个个加回来，哪一只加回来就失效，干扰源就找到了。这一步纯体力活，但比对着程序猜快得多。

5.3 数据只对了一半，后半段是上一件的

现象：读出来的工件编号是对的，后面的工艺数据却是上一件托盘的，或者干脆是乱码。

原因就是 4.4 里说的长度不匹配。FILL 的 count 小于数组实际长度，尾部残留没被覆盖；或者写缓冲 DB 和读缓冲 DB 长度不一致，写进去 32 字节，读的时候只取了 16 字节。

解决：把长度定成常量，三处引用同一个常量；写之前先整片清零再填数据，别指望「覆盖」能清干净；读回来之后加一段合理性校验，比如校验位或者固定帧头，校验不过就丢弃重读，不要拿脏数据去做工艺判断。

5.4 按钮按住不放，数据开始错位

现象：手动调试时按住触摸屏上的「读取」不放，前几次正常，多按几秒之后读出来的数据就乱了，或者 FB31 直接报错。

原因是没有做边沿触发。电平信号一直保持，调度层每个扫描周期都在装载命令字，FB31 收到的是连续命令，握手时序被打乱。

解决：所有手动命令都走上升沿，用「当前值 AND NOT 上一周期值」的写法，边沿标志位放在静态变量或者全局 DB 里；同时在命令装载前加互锁条件NOT busy，busy 期间不接受新命令；再加一个超时监控，命令发出后若干毫秒没有 done 也没有 error，就强制复位状态机并报一条超时。这三件套配齐，连续触发类的问题基本绝迹。

5.5 屏上改了参数，PLC 里还是旧值

现象：在触摸屏上把工件编号改成新值，按下写入，载体里写进去的还是旧编号。

原因：HMI 交互 DB 和真正的写缓冲 DB 是两份数据，画面绑在交互 DB 上，写缓冲 DB 没做搬移，或者搬移的方向反了。

解决：在调度层明确一段「数据同步」程序，规定谁是主副本。我的习惯是写缓冲 DB 为主，HMI 只写交互 DB，调度层在每个扫描周期把交互 DB 的设定值搬到写缓冲 DB，把读缓冲 DB 的结果搬到交互 DB 的显示区，单向搬运，不做双向自动同步，避免两边互相覆盖。方向定死之后，再出这类问题，一眼就能定位到是哪一段搬移漏了。

6. 验收与答辩：怎么证明这条读写链路真的通了

验收这件事，最怕的是「演示的时候好的，交上去就坏了」。所以我一般按阶段验收，每一阶段都有明确的通过标准，不通过就不往下走。

这张表里，真正拉开差距的是后两行。前面四行只要肯花时间都能过，异常恢复和断电保持才是评审和现场验收会盯着看的部分。答辩时被追问最多的也是这两块。

被问到「这套程序通不通用」，回答要落到可复用的边界上：FB31 示例块封装了协议，任何走同一套分析单元的读写头都能用；FC 调度层按通道复制，换工位只改地址和 DB 号；真正要动的是长度常量，换了载体型号、存储区变大变小，改这一个常量，三处一起生效。把这条讲清楚，比说「通用性很强」有说服力得多。

被问到「怎么保证不写错工件」，答案在时序上：写入前必须读到当前载体的唯一编号，和 PLC 侧记录的托盘号比对，一致才允许写，不一致就报警拦停。这一步是软件上的防呆，比任何硬件检测都便宜。

被问到「为什么用 1511 而不是更小的 CPU」，就报那三笔账：I/O 地址要留余量、DB 块和块号要留余量、PROFINET 上还挂了几个站要留通信余量。把数字摆出来，比讲性能参数有用。

从那以后我每次做这类带 RFID 的项目，验收前都强制走一遍「拔载体、断电、写超长」这三步，不管甲方催得多急。这三步花不了半小时，却能提前把八成现场故障挡在交付之前。希望帮到你。

本文还有配套的精品资源，点击获取