企业官网建设流程全解析

简介：面向工业自动化工程师与西门子PLC初学者的实操文档，围绕CPU1511-1 PN与巴鲁夫RFID系统的读写控制展开，解决流水线工件追踪与托盘信息记忆的落地问题。资源为单个docx文件，约708KB，体量轻便，适合作为随查随用的配置手册。内容按功能应用、硬件配置、实现步骤与项目通用性四部分组织：先说明RFID分析单元、读写头与数据载体的组成与分工，再给出PLC型号与博图V15的软件环境，随后依次记录GSD文件组态、I/O与IP设置、FB31示例块的调用、读写用DB块划分等要点，并附位逻辑、MOVE、延时与FILL指令在初始化、复位、读取、写入流程中的用法说明。已有1859人学习，适合需要快速复现RFID读写逻辑、理清程序块结构与数据转移思路的读者参考。

1. 需求与适用场合：托盘追踪为什么先定读写边界

托盘追溯最容易被做成“贴二维码 + 人工补录”，但产线油污、重复上下料、工位遮挡会把二维码方案拖进维护泥潭。这套方案用 1500 系列 PLC 直接读写工业 RFID，把工件状态写在随行载体里，PLC 只负责调度读写动作并把结果落进 DB，适合流水线托盘追踪、工件过站记忆、返修回流识别这类场景。它不适合把 RFID 当“万能数据库”的人：载体容量有限，读写节拍受工艺位置限制，方案第一件事不是选型，而是把“写什么、什么时候写、写多长”定清楚。RFID 与 1500 PLC 的组合能落地，靠的是分析单元、读写头、载体和程序块之间的边界清楚，而不是堆指令。

2. 总体方案设计：分析单元、读写头、载体与 PLC 的职责划分

托盘追踪的需求听起来简单：工件到站，读托盘上的载体，判断型号和工序，再把新状态写回去。真正落地时，最容易混的是职责：到底由 PLC 判断数据合不合法，还是由 RFID 分析单元处理；读写头读到的是原始字节还是已经整理好的工艺字段；触摸屏上改的数据该写进哪个 DB。把这些问题拆开，方案才不会在联调时变成一团线。

2.1 从工件追踪需求拆出三个数据对象

这套方案里通常会出现三个数据对象：工件身份、工艺状态、读写控制。工件身份是载体里的唯一编号或托盘号，长度固定，写入后很少改；工艺状态是当前工序、检验结果、返修标记，过站时频繁更新；读写控制是 PLC 发给 FB31 的控制字、命令触发、忙状态和错误码，属于程序内部调度数据。三者混在同一个 DB 里，短期能跑，长期一定翻车：操作员在触摸屏上改了一个字节，可能刚好覆盖了控制字；读回的数据长度变了，FILL 填充跟着越界。

我一般会把数据对象先落成表，再决定 DB 怎么分。下面这张表是方案阶段的职责表，不是最终地址表，地址要等硬件组态完成后按实际 I/O 对齐。

这张表的作用是逼着方案阶段回答“谁写谁读”。工件身份只读，就不允许触摸屏改写；工艺状态可写，就要规定写之前先读一次，避免把旧托盘状态带到新工件上；读写控制只留在控制 DB，不暴露给操作员。后面程序块再复杂，也不会把控制字和数据区搅在一起。

2.2 分析单元、读写头、载体的职责边界

一套 RFID 通常包含分析单元、数据读写头、数据载体。分析单元负责接收读写头数据并处理，最多可以插 4 个读写头；读写头负责读出载体数据和写入数据，上面有绿色电源指示灯和橙色工作指示灯，工作时灯会闪烁；载体用来存储数据，一般跟随工件移动。这个硬件结构决定了程序不能绕过分析单元直接“访问载体”，PLC 看到的是分析单元映射出来的 I/O 数据和 FB31 的状态字。

职责边界要这样定：读写头负责物理层读写，分析单元负责通道调度和结果缓存，PLC 负责工艺判断和动作时序。很多现场问题不是程序写错，而是把边界搞反了：工件还没到位就触发读，读写头读到的还是上一个托盘；分析单元还在忙，PLC 又发第二条命令，状态字卡在忙；载体写保护或距离不够，程序却只等“读完成”信号，最后超时复位把错误码冲掉，现场只剩一个黑匣子。

提示：方案阶段先确认读写头的安装位置和工件到位检测方式。RFID 不是“靠近就能读”，读写窗口、载体朝向、金属遮挡都会影响结果，程序里的延时和超时都要围绕这个物理窗口设计。

2.3 PLC 程序分层与 DB 规划

PLC 程序我通常分三层：设备层负责 FB31 调用和 I/O 映射；调度层负责初始化、复位、读、写、开始这几个动作的时序；交互层负责触摸屏 DB 和上位数据。设备层不判断工艺，只回答“命令发出去没有、完成没有、错误码是什么”；调度层决定什么时候发读、什么时候发写；交互层只读写允许操作的字段。

DB 规划按“控制、读、写、交互”四块拆。控制 DB 放控制字、命令触发、忙、错误码、超时计数；读 DB 放读回缓冲区和读完成标志；写 DB 放待写数据和写完成标志；交互 DB 给触摸屏用，只映射可改字段和显示字段。这样做的好处是，FILL 填充只在自己那块写 DB 里做，不会误伤控制字；读回数据长度变化时，只改读 DB 的数组长度和 FILL 的 COUNT。

程序分层后，FB31 的调用次数要收口。一个分析单元最多带 4 个读写头，如果每个读写头都复制一套 FB31 调用，初始化、复位、错误处理会散落在多处。通常的做法是：按读写头端口建多个实例 DB，但调度逻辑用同一个 FC 封装，端口号作为参数传进去。这样新增一个工位时，改的是参数和实例 DB，不是复制一整段梯形图。

2.4 适用边界与通用性判断

这套程序对大部分使用 RFID 的设备都适用，属于通用型程序，但通用不等于照搬。通用性成立的前提是：数据长度自己定，填充时写多少位就填多少位；控制字含义以实际 FB31 定义为准；读写头端口和分析单元通道要一一对应。换一个现场，如果载体容量变了、工艺字段加了、读写头从 1 个变成 3 个，程序结构不用推翻，但 DB 数组长度、FILL 的 COUNT、端口映射表必须同步改。

不适用的情况也要提前说清：需要毫秒级连续读写的分拣线，RFID 的读写窗口可能不够；载体要存图片或大段工艺参数，容量和节拍都不合适；现场金属干扰严重又没有做安装隔离，读写头会时好时坏。方案文里把这些边界写出来，比只写“适用范围广”更让人信服。

3. 硬件组态落地：GSD 文件导入、I/O 与 IP 名称配置

硬件组态是这套方案里最像“体力活”的一段，但翻车往往就出在这里。GSD 文件没导入，硬件列表里找不到设备；I/O 地址和程序里的 MW136、DB 地址对不上；IP 和设备名称没分配，下载后模块报错。血泪经验是：程序块可以慢慢调，组态地址一旦错位，后面所有读写都像玄学。

3.1 GSD 文件导入与设备添加

GSD 文件描述 RFID 设备在组态软件里的身份和 I/O 能力。操作顺序通常是：打开硬件组态界面，在硬件列表里找到该 RFID 的选项，把文件添加到组态，双击进入配置 I/O 点，再在属性里设置 IP 及名称，最后把组态下载进 PLC。这里每一步都要留检查点，不能一路点“下一步”。

导入 GSD 后，先看设备是否出现在硬件目录的正确分类下，再看订货号或设备版本是否与现场一致。现场设备版本和 GSD 版本不匹配时，组态能下载，但 I/O 模块可能报错，或者读写头通道数不对。添加设备时，分析单元和读写头的顺序要按实际安装来，别把端口 1 的读写头配成端口 2，程序里再按端口号发命令就会读错工位。

# 组态前检查清单（按现场实际路径替换） 1. GSD 文件已安装，硬件目录能检索到设备 2. 设备版本与现场铭牌一致 3. 分析单元通道数与实际读写头数量一致 4. 每个读写头端口号与安装位置对应 5. 组态编译无报错，再下载

这段不是命令，是组态前要走的检查顺序。GSD 导入本身不复杂，复杂的是“导入了但没对上”。先编译再下载，能把大部分地址冲突和版本不匹配挡在下载前。

3.2 I/O 点与 IP 名称配置

双击设备进入配置后，I/O 点要按实际数据长度配。读回数据区和写入数据区通常各占一段连续地址，程序里用 DB 和 MOVE/FILL 搬运。这里最容易犯的错是：组态里配了 32 字节，程序里 FILL 填了 64 字节，编译不报错，运行时越界；或者组态里读写区顺序反了，程序把写入数据发到了读区。

IP 及名称配置要和 PLC 在同一网段，设备名称要唯一。名称不是备注，下载后 PLC 靠它识别设备。名称重复或没分配，在线诊断里会看到设备不可用。配置完成后先编译硬件组态，确认没有地址冲突，再下载到 PLC。下载后不要马上跑程序，先在线看模块诊断，确认读写头电源指示灯绿色、工作指示灯在触发时橙色闪烁。

这张表建议在组态完成后直接截图存档，后面程序地址对齐、触摸屏映射、验收记录都用同一张表。地址表不是给组态看的，是给联调时“对账”用的。

3.3 下载前检查与在线诊断

下载前检查分三步：硬件组态编译无报错；PLC 与 RFID 设备 IP 名称匹配；程序里的 I/O 地址与组态地址一致。下载后先看在线诊断，再看读写头指示灯，最后才触发程序。顺序反了，程序一跑就是一堆错误码，分不清是组态问题还是程序问题。

在线诊断里重点看三个信息：设备是否可用、I/O 模块是否有通道错误、分析单元是否报通道故障。读写头绿色电源灯不亮，先查供电和线缆；绿色亮但橙色工作灯不闪，查触发条件和端口号；灯闪但程序收不到完成信号，查 FB31 的完成位和 DB 地址。把现象和诊断信息对上，比盲改程序快得多。

注意：下载硬件组态后如果设备名称变了，PLC 可能仍然认旧名称。改名称要重新分配设备名称并下载，不能只改 IP。

3.4 组态与程序地址对齐表

程序里用到的 MW136、读 DB、写 DB、控制 DB 都要和组态地址对齐。我的习惯是做一张对齐表，左边是组态地址，右边是程序符号，中间写数据长度和用途。联调时谁改了地址，表上必须留痕。没有这张表，过两周再回来查，MW136 到底是控制字还是状态字都说不清。

地址对齐表不用写进程序注释就完事，要放在联调记录里。后面验收时，读回数据长度、写入数据长度、FILL 的 COUNT 都从这张表推出来，不靠记忆。

4. 程序结构实现：FB31 调用、FC 封装与 DB 读写时序

程序部分最容易写成“能跑就行”：初始化一段、复位一段、读一段、写一段，全部堆在 OB1 里。短期能交差，换一个工位就要复制一遍，错误处理也各写各的。这套方案用 FB31 做设备层，用 FC 做调度层，用 DB 做数据和交互，结构不新，但边界清楚，后面改数据长度和端口号时不用推倒重来。

4.1 FB31 与 FC 的分层调用

FB31 是厂商示例程序块，负责和 RFID 分析单元做底层交互。新建一个 FC 块，在 FC 里调用 FB31，再给 FB31 配实例 DB。FC 的职责不是替代 FB31，而是把“什么时候初始化、什么时候读、什么时候写、什么时候复位”按工艺时序排好。FB31 只回答“命令收没收到、完成没有、错误码是多少”。

下面是一个调度 FC 的示例骨架，引脚名按实际 FB31 声明替换，控制字数值仅作结构说明，不能直接当协议用。

// FC120：RFID 读写调度骨架 // 说明：FB31 引脚名以实际示例块为准，控制字数值仅作结构示例 // 初始化：上电或操作员按下初始化按钮时触发 IF "RFID_CtrlDB".InitReq THEN "RFID_CtrlDB".CtrlWord := 16#0001; // 示例控制字：初始化 "RFID_CtrlDB".CmdReq := TRUE; "RFID_CtrlDB".InitReq := FALSE; END_IF; // 读请求：工件到位且当前不忙时发读命令 IF "RFID_CtrlDB".ReadReq AND NOT "RFID_CtrlDB".Busy THEN "RFID_CtrlDB".CtrlWord := 16#0002; // 示例控制字：读 "MW136" := "RFID_CtrlDB".CtrlWord; // 按实际地址替换 "RFID_CtrlDB".CmdReq := TRUE; END_IF; // 写请求：待写数据准备好且当前不忙时发写命令 IF "RFID_CtrlDB".WriteReq AND NOT "RFID_CtrlDB".Busy THEN "RFID_CtrlDB".CtrlWord := 16#0004; // 示例控制字：写 "MW136" := "RFID_CtrlDB".CtrlWord; "RFID_CtrlDB".CmdReq := TRUE; END_IF; // 复位：错误或超时后清除状态 IF "RFID_CtrlDB".ResetReq THEN "RFID_CtrlDB".CtrlWord := 16#0008; // 示例控制字：复位 "RFID_CtrlDB".CmdReq := TRUE; "RFID_CtrlDB".ResetReq := FALSE; END_IF; // FB31 调用：实例 DB 按端口建，StationNo 区分读写头 "RFID_FB31_DB"( Enable := "RFID_CtrlDB".Enable, Cmd := "RFID_CtrlDB".CmdReq, Ctrl := "MW136", Station := "RFID_CtrlDB".StationNo, Done => "RFID_CtrlDB".Done, Busy => "RFID_CtrlDB".Busy, Error => "RFID_CtrlDB".Error, Status => "RFID_CtrlDB".Status );

这段代码的重点不是控制字本身，而是调度顺序：初始化优先，读写在“不忙”条件下发，复位单独触发，FB31 只调用一次。参数说明里，CmdReq是命令触发位，发完要在 FB31 完成或超时后复位；Busy用来挡住重复命令；StationNo对应分析单元端口，不能和安装位置错位；MW136是控制字地址示例，实际地址按组态对齐表改。控制字数值必须按 FB31 定义确认，不能把示例值直接上机。

4.2 DB 块规划与触摸屏交互

新建两个 DB 块，分别用作读取和写入，为了方便触摸屏操作再新建两个 DB。这个做法本身没问题，关键是要规定每个 DB 的字段顺序。读 DB 和写 DB 的数组长度要一致，交互 DB 只映射允许操作的字段，控制 DB 不暴露给触摸屏。

触摸屏交互最容易出的问题是“屏上改了，载体没变”。原因通常是交互 DB 和写 DB 之间没有搬运逻辑，或者写命令触发条件没加“数据已准备”。我的做法是：触摸屏只改写 DB 的允许字段，按“保存”后置位WriteReq，FC 检测到WriteReq且不忙才发写命令，写完清WriteReq，失败则保留错误码给屏上显示。这样操作员看到的是“写入失败”，不是“改完没反应”。

4.3 初始化、复位、读写与开始时序

初始化是对 RFID 进行初始化的程序；复位程序是复位 RFID 的报错或者读写状态；读取程序是将控制字发送给 FB 块程序，使 RFID 进行读取动作；写入程序是将控制字发送给 FB 块程序，使 RFID 进行写入动作；开始程序用来当控制字写入之后控制 RFID 进行工作。这几段不要写成互不相干的梯形图，要有明确时序。

我通常按时序排：上电先初始化，初始化完成后再允许读写；工件到位触发读，读完成把数据搬进读 DB；工艺判断后组织写数据，写完成清命令；任何一步超时或错误，先复位再重新初始化，不带着错误状态继续发命令。延时只用在两个地方：工件到位后的稳定延时，以及命令发出后的超时监控。延时不是越多越好，延时太长节拍拖慢，延时太短读写窗口没到，都会在现场被当成玄学。

// 超时监控示例：命令发出后 2 秒未完成则报错 IF "RFID_CtrlDB".CmdReq AND NOT "RFID_CtrlDB".Done THEN "RFID_CtrlDB".TimeoutTimer(IN := TRUE, PT := T#2S); IF "RFID_CtrlDB".TimeoutTimer.Q THEN "RFID_CtrlDB".Error := TRUE; "RFID_CtrlDB".ErrorCode := 16#0101; // 示例：读写超时 "RFID_CtrlDB".CmdReq := FALSE; END_IF; ELSE "RFID_CtrlDB".TimeoutTimer(IN := FALSE); END_IF;

这段超时逻辑要放在命令触发之后、完成信号之前。PT按现场读写节拍调，工件移动快就短一点，读写头窗口窄就长一点；ErrorCode是自定义诊断码，方便触摸屏显示“超时”而不是只亮红灯。超时后必须清CmdReq，否则下一轮调度会以为命令还在发。

4.4 数据转移与 FILL 填充边界

数据转移部分是将读取出来或者要写入的数据写到一个 DB 块内，然后用 FILL 指令将这里面的数据复制填充到块的 DB 里面。读取的数据内容可以在读取 DB 块里查看，要写入的内容也可以在写入 DB 块里修改。这里的关键是长度：自己建了多少位，填充时就写多少位。

// 读完成后把缓冲区数据填充到读 DB IF "RFID_CtrlDB".ReadDone THEN "RFID_ReadDB".Valid := FALSE; FILL(IN := 16#00, COUNT := "RFID_CfgDB".DataLen, OUT := "RFID_ReadDB".Data); // 实际项目在这里把 FB31 缓冲区搬到 ReadDB.Data "RFID_ReadDB".Valid := TRUE; "RFID_CtrlDB".ReadDone := FALSE; END_IF;

COUNT必须等于读 DB 数组长度，也要小于等于组态读区长度。OUT指向的数组不能比COUNT短，否则运行时越界。FILL 之前先清Valid，填充完再置位，触摸屏就不会读到半截数据。写入方向同理：先确认WriteDB.Data已准备好，再按同样长度搬到 FB31 写缓冲区，长度不一致时宁可不发命令，也不要写半条数据。

5. 避坑与排查：读写失败、地址错位、数据越界的常见问题

RFID 联调最怕“现象一堆，原因一个”。读写头不闪、程序不收完成、数据长度不对、状态卡在忙，看起来是四个问题，实际可能都指向组态地址或命令时序。这一章按现象、原因、解决三步写，都是项目里最容易翻车的点。

5.1 读写头无响应：先看灯，再看端口

现象：程序发读命令，读写头绿色电源灯亮，橙色工作灯不闪，FB31 一直不完成。

原因通常有三类：读写头端口号配错，命令发到了另一个通道；工件未到位或读写窗口没覆盖，读写头没有可读载体；分析单元通道被禁用或线缆松动。灯亮只说明供电正常，不代表通道可用。

解决：先在线看 FB31 的Status和Error，再对照端口映射表确认StationNo与安装位置一致；然后手动放一个已知载体在读写窗口内，触发一次读，看工作灯是否闪烁；最后查分析单元通道诊断和线缆。不要一上来就改程序延时，灯不闪时改延时只是把问题往后拖。

5.2 组态下载后模块报错：GSD 版本与 I/O 长度对不上

现象：硬件组态能编译，下载后模块报错，或者程序读写地址全部偏移。

原因：GSD 文件版本与现场设备不一致；组态里读区、写区长度和程序 DB 数组不一致；设备名称重复或未分配。组态地址偏移后，程序里的 MW136 可能落到状态字上，读写命令自然不动作。

解决：先在线诊断看模块通道错误，再核对设备铭牌和 GSD 版本；用地址对齐表逐项核对读区、写区、控制字、状态字；改完组态后重新编译、重新分配设备名称、再下载。地址表要跟着改，不能只改程序不改组态。

5.3 读回数据错位：FILL 长度大于实际数据长度

现象：读回的数据前几位对，后面全是 0 或旧数据；写入时载体里的内容被截断。

原因：FILL 的COUNT大于 DB 数组长度，或者大于组态读区长度；读 DB 和写 DB 数组长度不一致；数据转移时先置了Valid再填充，触摸屏读到半截数据。

解决：把DataLen做成配置常量，DB 数组长度、FILL 的COUNT、组态读写长度三处一致；填充前清Valid，填充完再置位；写入前检查待写数据长度，不够就报错，不发送半条数据。自己建了多少位就填多少位，这句话要写进程序注释。

5.4 状态卡在忙：命令触发没有复位

现象：第一次读写正常，第二次发命令没反应，Busy一直为真，复位后又能跑一次。

原因：CmdReq发出后没有在完成或超时后复位；FB31 的完成位是脉冲信号，程序用自锁方式取完成，导致下一轮调度以为命令还在执行；超时监控没清命令。

解决：命令触发用“置位—完成/超时—复位”的闭环，不在 OB1 里常驻为真；完成位只取一个扫描周期，用它复位CmdReq并锁存结果；超时分支必须清CmdReq和Busy相关状态。状态机卡死时，先看CmdReq和Busy的时序，不要盲加延时。

5.5 多读写头混读：端口映射与载体流向不一致

现象：1 号工位读到 2 号工位的数据，或者同一托盘在两个工位读到不同结果。

原因：分析单元最多插 4 个读写头，程序里按端口建了实例 DB，但端口号和安装位置没对应；工件流向改变后，程序还按旧映射读；多个读写头同时触发，分析单元通道调度不过来。

解决：做一张端口映射表，左列写物理工位，右列写StationNo和实例 DB，联调时逐点核对；同一时刻只允许一个读写头触发，或者按工艺节拍排队；工件流向变更时，映射表和程序参数一起改。多读写头项目里，这张表比程序注释管用。

6. 验收与答辩：用一张联调记录表把读写流程讲清楚

验收时不要只说“能读能写”，要把读写流程拆成可检查的动作。我通常用一张联调记录表，按“上电初始化—工件到位—读—工艺判断—写—复位”走一遍，每个动作记录现象、结果和异常处理。答辩时老师或评审问“怎么证明稳定”，拿这张表比讲原理更有说服力。

答辩时重点讲三个边界：数据长度边界、端口映射边界、命令时序边界。长度边界回答“为什么 FILL 不会越界”，端口映射回答“为什么 4 个读写头不会混读”，命令时序回答“为什么忙状态不会卡死”。把这三个边界讲清楚，程序结构就不用逐行念。

我把组态检查表、DB 结构表和 FB31 调用样例整理成一份资料包，和这套方案配套使用；现场调试时先拿它对照，比从头翻手册快。从那以后我每次上电联调前，都强制走一遍“先看指示灯、再查地址、最后读长度”的三步检查，哪怕项目再小也不省。希望帮到你。

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