简介这份 PDF 样题面向备战工业互联网集成应用赛项的高职师生也可供智能制造、工业互联网相关课程实训参考。内容围绕竞赛须知、职业素养与安全规范、竞赛任务及模块一设备安装调试展开包含加盖拧盖与智能物流单元的工作流程、RFID 读写器安装接线、设备 IP 地址分配、PLC 与 RFID 通讯编程要求以及截图提交和现场核验要点便于读者理解赛题结构、梳理任务边界与评分关注点。资源包共 1 个 PDF 文件约 360KB轻量便携适合打印或平板上查阅。已有 274 人学习可作为赛前熟悉题型、教师命题转化和实训任务拆解的参考材料。1. 从一份赛题样卷说起它其实是份没写完的需求规格书把“工业互联网集成应用”这几个字挂在嘴边的项目不少但真正能拿出完整一条“制造 互联网”链路的样本不多这份高职技能大赛样题算一个。多数人拿到 PDF 的第一反应是打印出来划重点、背流程、数分值我第一遍也是这么干的结果发现背下来的东西一到设备旁就散架——因为里面写的是任务不是实现。换个读法就不一样了把它当成甲方丢过来的需求规格说明书。加盖拧盖单元要干什么、智能物流单元按什么规则分区、平台的三种状态怎么互相约束、哪些数据必须落到指定变量和指定 DB 地址这些全是接口约束只不过没配时序图得自己补。适合两类人手里有类似工作站但程序是半成品想找一条能落地的通讯链路或者没有硬件想照着把 PLC 侧和平台侧的骨架搭出来跑通逻辑。2. 系统全景拆解两个单元、三层网络与一份 U 盘资料目录这套工作站是典型的小型离散制造产线缩微版从物料瓶投料到成品入仓全程自动中间夹着标识解析和数据上云。拆之前先把“有哪些东西”列清楚不然后面看任务书会觉得任务 1-1 到 2-3 是散的。2.1 两个单元的职责边界与物理动作链加盖拧盖单元负责“让瓶子变成合格品”。物料瓶由人放到输送带始端输送到加盖机构下方加盖定位机构先把瓶身固定死加盖机构再动作伸缩气缸推出、升降气缸下压把盖子压到瓶口完成后继续往拧盖机构送拧盖定位机构重复一遍固定动作拧盖电机带动夹爪旋转把盖拧紧。整个过程依赖六个位置信号——加盖前限、加盖后限、加盖上限、加盖下限、加盖定位后限、拧盖定位后限少一个到位信号动作链就卡死在那里不动。智能物流单元负责“把合格品按规则放好”。分拣 A 位、B 位是两条短输送带对应的推料工位搬运机构是伺服带动的三轴机构左右、前后、上下都有原点与限位负责把瓶子抓起来送进 3 号平面存储仓。容量上有硬约束1 号存储区最多 4 个成品2 号存储区最多 4 个成品3 号存储区最多 6 个成品。这个容量表在写分拣逻辑时非常关键很多人只盯着分配规则算序号忘了区域满了要挡住结果瓶子在输送带上撞成一排。分配管理有单机和联机两套规则这是容易看漏的地方。单机模式下统计进入物流单元的累计瓶数 n按 6 为周期循环n 对 6 取模后落在 1、2 的进 3 号仓落在 3、4 的进 2 号输送带落在 5、0 的进 1 号输送带。也就是 1、2 号瓶进 3 号仓3、4 号进 2 号区5、6 号进 1 号区7、8 号回到 3 号仓9、10 号回到 2 号区如此类推。联机模式则简化成全部放 1 号区1 号区满 4 个就提示人工取走。两套规则的存在意味着 PLC 里得有一个模式位来切分支否则联机跑起来会一直往三个区乱丢。投料前还有两条现场操作要求物料瓶必须贴 RFID 标签放置时别误碰输送带始端的传感器启动智能物流单元之前1、2、3 号存储区必须清空。这两条看着像废话实际是最常见的翻车源——瓶子上没标签RFID 读出来全是空程序判 16#C8 失败一直重试存储区没清空累计计数从 4 开始算第一批瓶子直接全进 2 号区。2.2 U 盘“参考资料”的目录结构决定了你少走多少弯路任务书里反复出现“见 U 盘中参考资料文件夹”这句话不是免责声明是索引。按任务 1-1 里给的路径写法参考资料的组织方式大致是这样一套结构参考资料/ ├── 01_RFID读写器/ │ ├── 读写器说明书.pdf │ ├── 通讯协议与命令字.pdf │ └── 示例报文.txt ├── 02_智能阀岛与智能IO/ │ ├── GSD文件/ # 组态用的设备描述文件 │ └── IO模块接线与地址说明.pdf ├── 03_伺服驱动器/ │ └── 参数手册.pdf ├── 04_单元参考程序/ │ ├── 加盖拧盖单元_参考程序.ap** # 已含控制逻辑与平台对接 │ └── 智能物流单元_参考程序.ap** └── 05_模块二资料/ ├── 设备属性与点位表.xlsx └── 平台操作手册.pdf这个结构的价值在于任务和资料是一一对应的做 1-1 只翻 01 和 04做 1-2 只翻 02 和 04做 1-3 要 02、03、04 三份一起看模块二只翻 05。四小时里最贵的成本是翻文件夹先把这套结构在脑子里建起来比多背两页协议有用。提示GSD 文件如果版本对不上组态里设备会显示成灰色问号网络参数一个都填不进去。动手前先确认 GSD 的版本号和实物模块外壳上的订货号一致。2.3 三层网络拓扑与 IP 地址规划整个系统的通讯是三层现场设备层PLC 与智能 IO、伺服、RFID 读写头、单元互联层两个单元 PLC 之间、PLC 与平台网关之间、平台应用层网关北向对接平台。地址规划在任务书里给得很死照着填就行别自作主张改网段。所属单元设备IP 地址备注加盖拧盖PLC192.168.1.21主站跑控制逻辑加盖拧盖智能阀岛 / 智能 IO192.168.1.22设备名 pn-dev2加盖拧盖RFID 读写头192.168.1.24端口 9000智能物流PLC192.168.1.51主站智能物流RFID 读写头192.168.1.54端口 9000平台侧工业互联网平台192.168.1.100:30000Web 入口两个单元各自一个网段前缀相同的子网中间靠交换机串起来再由其中一台 PLC 或独立网关往上走。RFID 读写头走的是以太网通讯而不是串口端口 9000 是它对外暴露的固定服务端口这一点很关键调试阶段可以用电脑直连读写头先确认 9000 端口能通再去查 PLC 侧的收发程序能把问题范围砍掉一半。常见做法是先 ping 通、再用 TCP 工具发一帧手工报文能收到回包就说明读写头和标签都没问题剩下的全是 PLC 里的程序问题。平台的三种状态约束是跨单元的停止状态下只能执行复位复位状态下才能执行停止或启动启动状态下平台只能下达一个生产订单订单执行完必须重新启动才能接下一单。这个状态机不是 PLC 单方面实现的PLC 和平台两边都得维护一份任何一边跳步平台会拒绝下发或者设备收到指令后不动作。3. 标识解析链路PLC 与 RFID 读写器的收发状态机怎么写标识解析是这套系统里真正带“互联网”味道的一段瓶子上的 RFID 标签是物理世界的身份读写器把它变成字节流PLC 把字节流塞进指定 DB平台再把 DB 里的点位采上去。链条不长但每一环都有硬性约定。3.1 读写器接线与 9000 端口背后的通讯前提接线按布局图和网络接线图走读写头的电源、网口、以及和 PLC 之间的信号线如果走硬线触发都要接对。真正容易出问题的是网络这一层——读写头出厂默认 IP 未必是 192.168.1.24得先用配置软件改成表里的地址改完再确认端口 9000 处于监听状态。调试顺序上我一般按这个次序推进每一步都能独立验证电脑改到同网段ping 192.168.1.24 通说明物理链路和 IP 配置没问题。用 TCP 客户端连 192.168.1.24:9000能建立连接说明服务在跑。手工发一帧读标签命令收到首字节 16#C5 的回包说明标签在读取范围内、协议对得上。以上三步都过了才动 PLC 程序任何一步没过先解决那一步。第四步之前的所有动作都是纯网络调试跟 PLC 程序无关。跳过前三步直接改程序最后报错时你分不清是程序写错了还是读写头根本没响应只能一遍遍瞎改。3.2 发送与接收缓冲区为什么是 72 个字节任务书里给的两个变量定义很明确RFID 数据.发送和RFID 数据.接收类型都是Array[0..71] of Byte接收区落在DB1.DBX0.0。72 个字节不是随便定的它是这套读写器一帧报文的最大长度命令头、站号、起始地址、长度、数据区、校验位全算进去定长传输比变长好处理收发两端不用协商长度直接按 72 切。// 全局数据块 DB1 中的定义非优化访问保证绝对地址可用 DATA_BLOCK RFID 数据 { S7_Optimized_Access : FALSE } VERSION : 0.1 NON_RETAIN STRUCT 发送 : Array[0..71] of Byte; // 起始地址 DB1.DBX72.0 接收 : Array[0..71] of Byte; // 任务书要求落在 DB1.DBX0.0 END_STRUCT; BEGIN END_DATA_BLOCK这里有个顺序细节任务书要求接收区在DB1.DBX0.0那就得让“接收”结构体排在“发送”前面否则偏移全错。启用“优化的块访问”后绝对地址会失效DB1.DBX0.0 这种写法编译直接报错所以这个 DB 必须关掉优化访问。很多人是从新建 DB 开始做的默认优化访问是开着的编译报错后到处找原因其实是块属性里一个勾。定长还有个附带好处接收区可以直接整块送进平台点位不用做长度判断。平台侧按byte_array、长度 72 建一个点位采上来就是一串十六进制前几个字节就是命令字和状态码。3.3 “RFID” 函数的六步状态机任务书里给了一段流程描述a 到 f 六个步骤写得很“人话”但翻译成 PLC 代码时需要落成状态机不能写成六个串联的 IF。串联 IF 的问题是每个扫描周期都会从头执行一遍发送和接收这种耗时的异步动作会被反复触发。FUNCTION_BLOCK FB_RFID_Read VAR step : Int; // 0 空闲 1 组帧 2 发送 3 判发送 4 接收 5 判结果 6 收尾 retry : Int; // 重试计数上限 3 次 sendBuf : Array[0..71] of Byte; // 与 RFID 数据.发送 同构 recvBuf : Array[0..71] of Byte; // 与 RFID 数据.接收 同构 END_VAR VAR_INPUT trigger : Bool; // M21.1 触发读取标签 reset : Bool; // 复位回到 step 0 END_VAR VAR_OUTPUT done : Bool; // M20.5 读取标签成功 busy : Bool; error : Bool; END_VAR VAR_TEMP i : Int; END_VAR BEGIN // 复位优先任何时刻拉高都回到空闲 IF reset THEN step : 0; retry : 0; busy : FALSE; error : FALSE; END_IF; // 上升沿进入trigger 为真且当前空闲 IF trigger AND NOT busy AND NOT done THEN step : 1; retry : 0; busy : TRUE; done : FALSE; error : FALSE; END_IF; CASE step OF 0: ; // 空闲什么都不做 1: // 组帧命令字 站号 起始块 读取长度 sendBuf[0] : 16#01; // 读标签命令 sendBuf[1] : 16#00; // 读写头站号按现场拨码修改 sendBuf[2] : 16#00; // 起始块地址高字节 sendBuf[3] : 16#00; // 起始块地址低字节 sendBuf[4] : 16#04; // 读取长度4 字节 EPC sendBuf[5] : 16#00; FOR #i : 6 TO 71 DO sendBuf[#i] : 16#00; // 补零到定长 72 END_FOR; RFID 数据.发送 : sendBuf; 标签读取延时 : FALSE; // M21.5 清延时标志 step : 2; 2: // 发送置发送请求等 sendDone 回来 #sendReq : TRUE; step : 3; 3: // 判发送结果 IF #sendDone THEN #sendReq : FALSE; step : 4; ELSIF #sendErr THEN #sendReq : FALSE; retry : retry 1; IF retry 3 THEN error : TRUE; busy : FALSE; step : 0; ELSE step : 2; // 回第 2 步重发 END_IF; END_IF; 4: // 接收把 72 字节回包整块写入 RFID 数据.接收 #recvReq : TRUE; IF #recvDone THEN RFID 数据.接收 : recvBuf; #recvReq : FALSE; step : 5; ELSIF #recvTimeout THEN // 看门狗超时按失败处理 #recvReq : FALSE; retry : retry 1; step : 2; END_IF; 5: // 判结果16#C5 成功16#C8 失败 IF RFID 数据.接收[0] 16#C5 THEN step : 6; ELSIF RFID 数据.接收[0] 16#C8 THEN retry : retry 1; IF retry 3 THEN error : TRUE; busy : FALSE; step : 0; ELSE step : 2; END_IF; END_IF; 6: // 收尾置成功标志与延时标志交出控制权 读取标签成功 : TRUE; // M20.5 标签读取延时 : TRUE; // M21.5 busy : FALSE; done : TRUE; step : 0; END_CASE; END_FUNCTION_BLOCK逐块说清楚。step是整段逻辑的骨架六个状态对应任务书 a 到 f任何一次跳转都必须把step显式改掉绝不靠自然顺序往下滑。retry是保命的没有它一个读不到的标签会让程序在 2→3→2 之间死循环扫描周期被撑爆其他动作全部停摆到 3 次就认输、置error退出让上游去决定是报警还是跳过这个瓶子。sendBuf和recvBuf设计成块内静态变量而不是直接读写 DB多了一层拷贝但换来的是组帧过程不受外部干扰——如果一边组帧一边有别的逻辑改RFID 数据.发送发出去的报文就是半新半旧的。组帧完一次性赋值语义干净。第 4 步的recvTimeout是看门狗读写头正常回包在几十毫秒内超过 500 毫秒基本就是掉线或标签不在场不能无限等。这个信号在块外用一个 TON 定时器做#recvReq为真时启动到时置位超时标志#recvReq变假立刻复位定时器。注意任务书里给的是“函数”FCFC 没有静态变量step和retry存不住。实际工程里我一般写成 FB 配一个背景 DB如果非要用题目给的那个 FC就把step、retry全部换成 M 区或 DB 里的静态位别写在 TEMP 里——临时变量每个扫描周期都重新分配状态机根本跑不起来。3.4 16#C5 与 16#C8判结果为什么要看首字节读写器的回包是定长 72 字节第一个字节是状态码16#C5表示本次读写成功16#C8表示失败。判结果只看RFID 数据.接收[0]不看长度、不看校验这是协议本身的设计——长度固定校验位在读写器内部已经做过一遍。这条规则有个副作用如果程序没收到完整回包接收[0]里留着的是上一帧的旧数据很可能是16#C5于是失败被误判成成功。这就是为什么第 4 步一定要有超时看门狗并且接收必须整块覆盖——RFID 数据.接收 : recvBuf这一句是整块赋值不是逐字节写只要recvDone为真72 个字节一起换掉不会出现半新半旧。读写成功之后M20.5置位这个位是跟主流程的握手信号。加盖拧盖单元的主流程在“取标签数据”节点上等这个位等到了就去读 DB 里的 EPC读完了把M20.5复位然后走下一个动作。这中间如果M21.5标签读取延时没被正确复位下一次触发会被误判成同一个标签的重复读取所以流程里第 1 步专门把M21.5清零。4. 数据采集与平台接入从智能 IO 组态到数字化建模与告警规则模块一的后两个任务和模块二本质是同一件事的两端设备侧把信号变成可寻址的地址平台侧把地址变成带语义的点位。中间任何一段接不上大屏上就是一片灰。4.1 地址分配表怎么落成真实的 IO 映射任务书里的地址表有个特别容易被忽略的细节硬件接线和软件地址不是一一对应的。加盖拧盖单元的表里硬件端子I0:0对应软件地址I2.0I0:1对应I2.1一路顺延到I1:1对应I3.1输出侧Q0:0对应Q2.0Q1:4对应Q4.4。硬件接线软件地址功能描述I0:0I2.0瓶盖料筒检测I0:1I2.1加盖位检测I0:2I2.2拧盖位检测I0:3I2.3加盖前限I0:5I2.5加盖上限I1:0I3.0拧盖定位后限Q0:0Q2.0输送带电机Q1:0Q4.0加盖伸缩气缸这个偏移不是笔误是模块化 IO 的槽位预留CPU 后面挂了通讯模块或占位模块前面的字节被占掉实际 IO 从 I2 开始。写程序时如果照着硬件端子号写I0.0编译能过、下载能跑但那个地址上没有任何物理信号表现为“程序里所有到位检测永远是 0设备一动不动的黑匣子状态”。我见过有人在这上面耗掉四十分钟最后发现是地址差了两个字节。正确做法是把这张表原样录进 PLC 的变量表用符号名编程程序里只出现加盖位检测这种名字不出现绝对地址。这样即使后面地址再变改一处变量表就行。智能物流单元的表同理X100、Y100这种写法说明那个单元的 IO 是按另一套寻址方式编的混合编程时两套地址不能互相套用。4.2 组态、网络参数、IO 地址三段配置智能阀岛/智能 IO 的接入分三段顺序不能反第一段是组态。在编程软件里导入 GSD 文件把设备拖到网络视图上跟 PLC 连到同一根总线。这一步做完设备会出现在硬件目录下但还没有名字。第二段是网络参数。给设备分配设备名pn-dev2和 IP 地址 192.168.1.22。设备名比 IP 更重要——PROFINET 靠设备名寻址名字对不上IP 填得再对也连不通。分配完名字后设备上的指示灯通常会从闪烁变成常亮这是最直观的成功信号。第三段是 IO 地址。把模块的输入输出字节映射到 PLC 的地址区也就是 4.1 那张表的来源。这一段做完编好的程序里那些符号名才有实际落点。// 用符号名访问避免绝对地址偏移带来的误判 输送带电机 : 启动 AND NOT 停止 AND NOT 急停; 加盖伸缩气缸 : 加盖位检测 AND 加盖前限 AND 加盖上限; // 拧盖动作定位到位 上限到位才允许启动电机 IF 拧盖定位后限 AND 拧盖上限 THEN 拧盖电机 : TRUE; END_IF;这段短逻辑比长代码更值得看所有条件都用符号名表达可读性直接决定四小时后你还改不改得动。急停放在输出条件里做串联是最后一道硬保护任何输出都得先过它。智能物流单元那边还多一个伺服驱动器接线按图 1-2 和图 1-4 走参数配置的重点是原点回归方式和左右、前后、上下三组限位的逻辑电平限位接反了会出现“一上电就往一个方向顶死”的经典场面。4.3 平台侧模型、设备、点位、北向的四级创建顺序平台地址是 192.168.1.100:30000登录信息在任务书里给出。模块二任务 2-1 列的六项提交内容其实是四级对象的创建顺序先建网关模型和设备模型把“加盖拧盖单元”和“智能物流单元”抽象成两类模型再给模型做功能定义也就是属性列表——瓶盖料筒检测、加盖位检测这些开关量加上累计计数、订单数量这类数值量然后基于模型创建设备实例一个模型可以建多个设备最后在网关里配 PLC 连接、子设备、点位和通讯参数导出的点位表就是南北向打通的凭证。网关导出的点位结构大致长这样字段名各平台不同但语义一致{ gateway: gw-press-01, protocol: S7, plcIp: 192.168.1.21, points: [ {name: rfid_recv, addr: DB1.DBX0.0, type: byte_array, len: 72, desc: RFID 接收缓冲区}, {name: cap_pos, addr: I2.1, type: bool, desc: 加盖位检测}, {name: conveyor, addr: Q2.0, type: bool, desc: 输送带电机} ] }byte_array这种类型在多数平台上是支持的但要注意字节序和长度导出的长度如果写成默认 8采上来的就是前 8 个字节看不到完整 EPC。北向配置是平台对上层应用暴露的出口配完之后设备监控页面才能拿到数据这一步的顺序是“先南向通、再北向配”反过来配完发现南向没通大屏上全是空值又得回头查。4.4 三指令下发与 1 秒延时生产排程的时序约束任务 2-2 的订单是 5 瓶钙片、每瓶 2 粒分三批做第一批 60%也就是 3 瓶。可视化页面上点预览、远程启动、绑定点位这些都是操作层面的真正容易翻车的是指令下发方式。任务书里写得很明确下发控制指令时一个动作要发 3 个指令比如开机要设定“停机0、复位0、开机1”值为 1 的指令放在最后三个指令之间需要延时 1 秒。这是一个典型的三段式状态复位——先把可能残留的状态位清零再置位目标状态。少发一条设备可能停在“既没停机也没开机”的中间态顺序发反先置开机再清停机设备收到开机命令后立刻又被清掉表现为按了没反应。import time, requests BASE http://192.168.1.100:30000/api/v1 DEV press_unit_01 def post_cmd(stop: int, reset: int, start: int): 按 停机 - 复位 - 开机 的顺序下发值为 1 的放最后 payload {cmdList: [ {attr: stop, value: stop}, {attr: reset, value: reset}, {attr: start, value: start}, ]} r requests.post(f{BASE}/device/{DEV}/command, jsonpayload, timeout3) r.raise_for_status() return r.json() # 开机先清停机位间隔 1 秒再清复位位最后置开机 post_cmd(0, 0, 0); time.sleep(1) post_cmd(0, 0, 1)这段脚本是课下自测用的赛场上直接在平台可视化页面点也可以但把请求写成脚本有个好处能精确控制 1 秒间隔也能批量重放排查“点了没反应”时到底是平台没发出去还是设备没收到。timeout3别省平台在订单执行期间响应会变慢不设超时脚本会一直挂着。对应的状态机约束是设备处于停止状态才能复位处于复位状态才能启动或停止启动状态只能接一个订单做完必须重新启动才能接下一单。写脚本批量下发前先查一次当前状态别默认它是复位态。4.5 告警规则40 度二级高温与 8 级停机告警任务 2-3 要建两条规则。第一条是温度超过 40 度触发二级高温报警这是标准的阈值规则比较符用大于而不是大于等于写错一个符号就会出现“刚好 40 度时报警”还是“41 度才报警”的差别测试用例里得专门覆盖边界值。第二条是加盖拧盖单元未完成订单且停止生产时产生 8 级、类型为“其它”的告警。这条的难点在“未完成订单且停止生产”这个复合条件——它同时依赖订单进度和设备状态两个数据源如果点位建模时没把“订单剩余数量”和“运行状态”定义成可比较的数值和枚举规则里根本选不出来。所以在 4.3 那一步做模型功能定义时就得提前想好后面要建什么规则把字段留出来。规则建完务必用一次真实停机去验证下发一个订单跑到一半手动停设备看告警有没有在规定级别上冒出来。只在页面上看着规则是“已启用”不算数。5. 避坑与排查赛场上最容易翻车的五个点下面五条都是能直接对号入座的现象—原因—解决按顺序写遇到时照单抓药就行。5.1 接线与组态类现象一智能 IO 组态里设备显示为灰色问号网络参数一栏全部不可编辑。原因通常是 GSD 文件版本和实物模块的固件版本不匹配或者导入的是另一型号的 GSD。解决方式是先看模块外壳上的订货号回参考资料文件夹找订货号完全一致的那份 GSD 重新导入找不到就换用通用 GSD但要注意通用 GSD 下部分诊断功能会失效。导入后如果还是灰色把设备从网络视图删掉重新拖一次别在原地改。现象二设备名已分配指示灯也常亮了但 PLC 侧读不到任何 IO。多半是 IO 地址段的映射没做或者映射到了 PLC 已经被占用的地址区。这种情况编译能通过下载也不报错只是数据一直是 0。解决方式是打开设备视图核对输入输出起始地址和 4.1 那张软件地址表逐个对一遍特别注意那个 I2/Q2 的偏移。对完之后在线监控一下用手挡一下传感器看 I2.1 有没有翻转没有翻转就是地址还是错的。5.2 程序与通讯类现象三RFID 程序一直停在发送/接收循环扫描周期肉眼可见地变长其他动作全部卡住。原因是状态机缺重试上限或者缺接收超时读写头没回包时程序在 2→3→2 之间无限打转。解决方式是补上retry计数器到 3 次就置错误标志退出同时在接收步骤挂一个 500 毫秒的 TON 看门狗超时按失败走。补完之后还要检查是不是标签本身不在读取范围内——瓶子放偏了几厘米读写头就是读不到程序再健壮也没用。现象四读回来的标签数据是对的但主流程拿不到M20.5一直不置位。原因通常是判结果的字节位置搞错了或者接收区没落在DB1.DBX0.0。任务书要求接收区在这个绝对地址上如果 DB 开着优化访问地址对不上程序里读的是另一块内存首字节永远不是16#C5。解决方式是检查 DB 的块属性把“优化的块访问”取消勾选重新编译下载再看一眼RFID 数据.接收[0]在线值手工触发一次读标签看它是不是变成16#C5。5.3 平台与提交类现象五可视化页面绑定完点位预览时数据不刷新但网关日志显示采集正常。原因一般是北向配置没做或者做在了南向之前平台应用层拿不到网关推送的数据也可能是可视化页面绑的是模型属性而设备实例上那个属性没被赋值。解决顺序是先确认网关南向点位在线值有变化再确认北向出口已启用最后回可视化页面重新绑定一次并保存。另外提交流程上有硬要求所有截图要放进 U 盘指定文件夹程序和答案存到“技能竞赛\竞赛编号”目录下没存到指定位置的运行记录一律不给分——我见过功能全做完、分数丢在保存路径上的。6. 二次开发把样题改造成可自测的实训工程这份样题最大的复用价值不在“照着做一遍”而在它把一条完整链路拆成了可验证的六段。想拿它做二次开发我建议按“抽骨架、换参数、加断言”三步走。抽骨架把第 3 章那个 RFID 状态机独立成一个 FB输入只留trigger、reset输出只留done、busy、error内部所有RFID 数据的引用改成接口参数。这样它就不再绑死在这套设备上任何走 TCP 定长报文的读写器都能套进去只改组帧那一段的字节布局。分拣规则同理把那个MOD 6的循环抽成一张映射表累计瓶数 n(n-1) mod 6目标区容量上限1、20、13 号平面仓63、42、32 号输送带45、64、51 号输送带4表驱动的好处是规则一变只改表不改代码。比如把周期从 6 改成 8或者把 1 号区容量从 4 改成 3都只是数据层面的调整。换参数把所有 IP、端口、DB 号、设备名集中到一个配置 DB 或一份 JSON 里程序里只引用符号。这一步做完同一套程序可以同时适用于两个单元的 PLC只是加载不同的配置。加断言这是最值得投入的一步。给状态机写几个可自动跑的测试场景——标签不在场、读写头掉线、回包首字节是16#C8、回包超时——每个场景都期望程序在规定时间内退到error而不是卡死。没有硬件也能测用一个 Python 脚本起个 TCP 服务端模拟读写头按不同分支返回不同报文PLC 侧或者上位机侧跑状态机看它是不是每次都按预期退出。这套脚本写一次后面所有改造都能复用。import socket # 模拟读写头按请求次数切换返回分支验证状态机的异常处理 MODES [b\xC5 b\x00 * 71, # 成功 b\xC8 b\x00 * 71, # 失败 None] # None 表示不回包触发超时 with socket.socket() as s: s.bind((0.0.0.0, 9000)) s.listen(1) for mode in MODES: conn, _ s.accept() conn.recv(72) # 收下 PLC 发来的 72 字节请求 if mode: conn.sendall(mode) conn.close()这个模拟器的价值在于把“读写头”这个不可控因素从测试里摘出去剩下的问题全在你自己的代码里。MODES列表顺序就是三条分支的执行顺序跑完一轮看状态机的三个出口是不是都被覆盖到。提示模拟器绑的是 9000 端口跑之前确认本机没有别的服务占着这个端口否则bind直接抛异常。从那以后我每次接手这类多单元联动的赛题或者实训台都强制先走一遍“纯网络验证 → 单点 IO 验证 → 状态机空跑 → 联机”四步宁可前面多花二十分钟也不要在四小时的最后半小时里对着一堆不确定的中间态猜是哪一层出的问题。这套顺序不新鲜但真能省下后悔药。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/4 16:39:00 · 阅读 1.2k 工业互联网集成应用：PLC与RFID标识解析及平台接入实战
简介这份 PDF 样题面向备战工业互联网集成应用赛项的高职师生也可供智能制造、工业互联网相关课程实训参考。内容围绕竞赛须知、职业素养与安全规范、竞赛任务及模块一设备安装调试展开包含加盖拧盖与智能物流单元的工作流程、RFID 读写器安装接线、设备 IP 地址分配、PLC 与 RFID 通讯编程要求以及截图提交和现场核验要点便于读者理解赛题结构、梳理任务边界与评分关注点。资源包共 1 个 PDF 文件约 360KB轻量便携适合打印或平板上查阅。已有 274 人学习可作为赛前熟悉题型、教师命题转化和实训任务拆解的参考材料。1. 从一份赛题样卷说起它其实是份没写完的需求规格书把“工业互联网集成应用”这几个字挂在嘴边的项目不少但真正能拿出完整一条“制造 互联网”链路的样本不多这份高职技能大赛样题算一个。多数人拿到 PDF 的第一反应是打印出来划重点、背流程、数分值我第一遍也是这么干的结果发现背下来的东西一到设备旁就散架——因为里面写的是任务不是实现。换个读法就不一样了把它当成甲方丢过来的需求规格说明书。加盖拧盖单元要干什么、智能物流单元按什么规则分区、平台的三种状态怎么互相约束、哪些数据必须落到指定变量和指定 DB 地址这些全是接口约束只不过没配时序图得自己补。适合两类人手里有类似工作站但程序是半成品想找一条能落地的通讯链路或者没有硬件想照着把 PLC 侧和平台侧的骨架搭出来跑通逻辑。2. 系统全景拆解两个单元、三层网络与一份 U 盘资料目录这套工作站是典型的小型离散制造产线缩微版从物料瓶投料到成品入仓全程自动中间夹着标识解析和数据上云。拆之前先把“有哪些东西”列清楚不然后面看任务书会觉得任务 1-1 到 2-3 是散的。2.1 两个单元的职责边界与物理动作链加盖拧盖单元负责“让瓶子变成合格品”。物料瓶由人放到输送带始端输送到加盖机构下方加盖定位机构先把瓶身固定死加盖机构再动作伸缩气缸推出、升降气缸下压把盖子压到瓶口完成后继续往拧盖机构送拧盖定位机构重复一遍固定动作拧盖电机带动夹爪旋转把盖拧紧。整个过程依赖六个位置信号——加盖前限、加盖后限、加盖上限、加盖下限、加盖定位后限、拧盖定位后限少一个到位信号动作链就卡死在那里不动。智能物流单元负责“把合格品按规则放好”。分拣 A 位、B 位是两条短输送带对应的推料工位搬运机构是伺服带动的三轴机构左右、前后、上下都有原点与限位负责把瓶子抓起来送进 3 号平面存储仓。容量上有硬约束1 号存储区最多 4 个成品2 号存储区最多 4 个成品3 号存储区最多 6 个成品。这个容量表在写分拣逻辑时非常关键很多人只盯着分配规则算序号忘了区域满了要挡住结果瓶子在输送带上撞成一排。分配管理有单机和联机两套规则这是容易看漏的地方。单机模式下统计进入物流单元的累计瓶数 n按 6 为周期循环n 对 6 取模后落在 1、2 的进 3 号仓落在 3、4 的进 2 号输送带落在 5、0 的进 1 号输送带。也就是 1、2 号瓶进 3 号仓3、4 号进 2 号区5、6 号进 1 号区7、8 号回到 3 号仓9、10 号回到 2 号区如此类推。联机模式则简化成全部放 1 号区1 号区满 4 个就提示人工取走。两套规则的存在意味着 PLC 里得有一个模式位来切分支否则联机跑起来会一直往三个区乱丢。投料前还有两条现场操作要求物料瓶必须贴 RFID 标签放置时别误碰输送带始端的传感器启动智能物流单元之前1、2、3 号存储区必须清空。这两条看着像废话实际是最常见的翻车源——瓶子上没标签RFID 读出来全是空程序判 16#C8 失败一直重试存储区没清空累计计数从 4 开始算第一批瓶子直接全进 2 号区。2.2 U 盘“参考资料”的目录结构决定了你少走多少弯路任务书里反复出现“见 U 盘中参考资料文件夹”这句话不是免责声明是索引。按任务 1-1 里给的路径写法参考资料的组织方式大致是这样一套结构参考资料/ ├── 01_RFID读写器/ │ ├── 读写器说明书.pdf │ ├── 通讯协议与命令字.pdf │ └── 示例报文.txt ├── 02_智能阀岛与智能IO/ │ ├── GSD文件/ # 组态用的设备描述文件 │ └── IO模块接线与地址说明.pdf ├── 03_伺服驱动器/ │ └── 参数手册.pdf ├── 04_单元参考程序/ │ ├── 加盖拧盖单元_参考程序.ap** # 已含控制逻辑与平台对接 │ └── 智能物流单元_参考程序.ap** └── 05_模块二资料/ ├── 设备属性与点位表.xlsx └── 平台操作手册.pdf这个结构的价值在于任务和资料是一一对应的做 1-1 只翻 01 和 04做 1-2 只翻 02 和 04做 1-3 要 02、03、04 三份一起看模块二只翻 05。四小时里最贵的成本是翻文件夹先把这套结构在脑子里建起来比多背两页协议有用。提示GSD 文件如果版本对不上组态里设备会显示成灰色问号网络参数一个都填不进去。动手前先确认 GSD 的版本号和实物模块外壳上的订货号一致。2.3 三层网络拓扑与 IP 地址规划整个系统的通讯是三层现场设备层PLC 与智能 IO、伺服、RFID 读写头、单元互联层两个单元 PLC 之间、PLC 与平台网关之间、平台应用层网关北向对接平台。地址规划在任务书里给得很死照着填就行别自作主张改网段。所属单元设备IP 地址备注加盖拧盖PLC192.168.1.21主站跑控制逻辑加盖拧盖智能阀岛 / 智能 IO192.168.1.22设备名 pn-dev2加盖拧盖RFID 读写头192.168.1.24端口 9000智能物流PLC192.168.1.51主站智能物流RFID 读写头192.168.1.54端口 9000平台侧工业互联网平台192.168.1.100:30000Web 入口两个单元各自一个网段前缀相同的子网中间靠交换机串起来再由其中一台 PLC 或独立网关往上走。RFID 读写头走的是以太网通讯而不是串口端口 9000 是它对外暴露的固定服务端口这一点很关键调试阶段可以用电脑直连读写头先确认 9000 端口能通再去查 PLC 侧的收发程序能把问题范围砍掉一半。常见做法是先 ping 通、再用 TCP 工具发一帧手工报文能收到回包就说明读写头和标签都没问题剩下的全是 PLC 里的程序问题。平台的三种状态约束是跨单元的停止状态下只能执行复位复位状态下才能执行停止或启动启动状态下平台只能下达一个生产订单订单执行完必须重新启动才能接下一单。这个状态机不是 PLC 单方面实现的PLC 和平台两边都得维护一份任何一边跳步平台会拒绝下发或者设备收到指令后不动作。3. 标识解析链路PLC 与 RFID 读写器的收发状态机怎么写标识解析是这套系统里真正带“互联网”味道的一段瓶子上的 RFID 标签是物理世界的身份读写器把它变成字节流PLC 把字节流塞进指定 DB平台再把 DB 里的点位采上去。链条不长但每一环都有硬性约定。3.1 读写器接线与 9000 端口背后的通讯前提接线按布局图和网络接线图走读写头的电源、网口、以及和 PLC 之间的信号线如果走硬线触发都要接对。真正容易出问题的是网络这一层——读写头出厂默认 IP 未必是 192.168.1.24得先用配置软件改成表里的地址改完再确认端口 9000 处于监听状态。调试顺序上我一般按这个次序推进每一步都能独立验证电脑改到同网段ping 192.168.1.24 通说明物理链路和 IP 配置没问题。用 TCP 客户端连 192.168.1.24:9000能建立连接说明服务在跑。手工发一帧读标签命令收到首字节 16#C5 的回包说明标签在读取范围内、协议对得上。以上三步都过了才动 PLC 程序任何一步没过先解决那一步。第四步之前的所有动作都是纯网络调试跟 PLC 程序无关。跳过前三步直接改程序最后报错时你分不清是程序写错了还是读写头根本没响应只能一遍遍瞎改。3.2 发送与接收缓冲区为什么是 72 个字节任务书里给的两个变量定义很明确RFID 数据.发送和RFID 数据.接收类型都是Array[0..71] of Byte接收区落在DB1.DBX0.0。72 个字节不是随便定的它是这套读写器一帧报文的最大长度命令头、站号、起始地址、长度、数据区、校验位全算进去定长传输比变长好处理收发两端不用协商长度直接按 72 切。// 全局数据块 DB1 中的定义非优化访问保证绝对地址可用 DATA_BLOCK RFID 数据 { S7_Optimized_Access : FALSE } VERSION : 0.1 NON_RETAIN STRUCT 发送 : Array[0..71] of Byte; // 起始地址 DB1.DBX72.0 接收 : Array[0..71] of Byte; // 任务书要求落在 DB1.DBX0.0 END_STRUCT; BEGIN END_DATA_BLOCK这里有个顺序细节任务书要求接收区在DB1.DBX0.0那就得让“接收”结构体排在“发送”前面否则偏移全错。启用“优化的块访问”后绝对地址会失效DB1.DBX0.0 这种写法编译直接报错所以这个 DB 必须关掉优化访问。很多人是从新建 DB 开始做的默认优化访问是开着的编译报错后到处找原因其实是块属性里一个勾。定长还有个附带好处接收区可以直接整块送进平台点位不用做长度判断。平台侧按byte_array、长度 72 建一个点位采上来就是一串十六进制前几个字节就是命令字和状态码。3.3 “RFID” 函数的六步状态机任务书里给了一段流程描述a 到 f 六个步骤写得很“人话”但翻译成 PLC 代码时需要落成状态机不能写成六个串联的 IF。串联 IF 的问题是每个扫描周期都会从头执行一遍发送和接收这种耗时的异步动作会被反复触发。FUNCTION_BLOCK FB_RFID_Read VAR step : Int; // 0 空闲 1 组帧 2 发送 3 判发送 4 接收 5 判结果 6 收尾 retry : Int; // 重试计数上限 3 次 sendBuf : Array[0..71] of Byte; // 与 RFID 数据.发送 同构 recvBuf : Array[0..71] of Byte; // 与 RFID 数据.接收 同构 END_VAR VAR_INPUT trigger : Bool; // M21.1 触发读取标签 reset : Bool; // 复位回到 step 0 END_VAR VAR_OUTPUT done : Bool; // M20.5 读取标签成功 busy : Bool; error : Bool; END_VAR VAR_TEMP i : Int; END_VAR BEGIN // 复位优先任何时刻拉高都回到空闲 IF reset THEN step : 0; retry : 0; busy : FALSE; error : FALSE; END_IF; // 上升沿进入trigger 为真且当前空闲 IF trigger AND NOT busy AND NOT done THEN step : 1; retry : 0; busy : TRUE; done : FALSE; error : FALSE; END_IF; CASE step OF 0: ; // 空闲什么都不做 1: // 组帧命令字 站号 起始块 读取长度 sendBuf[0] : 16#01; // 读标签命令 sendBuf[1] : 16#00; // 读写头站号按现场拨码修改 sendBuf[2] : 16#00; // 起始块地址高字节 sendBuf[3] : 16#00; // 起始块地址低字节 sendBuf[4] : 16#04; // 读取长度4 字节 EPC sendBuf[5] : 16#00; FOR #i : 6 TO 71 DO sendBuf[#i] : 16#00; // 补零到定长 72 END_FOR; RFID 数据.发送 : sendBuf; 标签读取延时 : FALSE; // M21.5 清延时标志 step : 2; 2: // 发送置发送请求等 sendDone 回来 #sendReq : TRUE; step : 3; 3: // 判发送结果 IF #sendDone THEN #sendReq : FALSE; step : 4; ELSIF #sendErr THEN #sendReq : FALSE; retry : retry 1; IF retry 3 THEN error : TRUE; busy : FALSE; step : 0; ELSE step : 2; // 回第 2 步重发 END_IF; END_IF; 4: // 接收把 72 字节回包整块写入 RFID 数据.接收 #recvReq : TRUE; IF #recvDone THEN RFID 数据.接收 : recvBuf; #recvReq : FALSE; step : 5; ELSIF #recvTimeout THEN // 看门狗超时按失败处理 #recvReq : FALSE; retry : retry 1; step : 2; END_IF; 5: // 判结果16#C5 成功16#C8 失败 IF RFID 数据.接收[0] 16#C5 THEN step : 6; ELSIF RFID 数据.接收[0] 16#C8 THEN retry : retry 1; IF retry 3 THEN error : TRUE; busy : FALSE; step : 0; ELSE step : 2; END_IF; END_IF; 6: // 收尾置成功标志与延时标志交出控制权 读取标签成功 : TRUE; // M20.5 标签读取延时 : TRUE; // M21.5 busy : FALSE; done : TRUE; step : 0; END_CASE; END_FUNCTION_BLOCK逐块说清楚。step是整段逻辑的骨架六个状态对应任务书 a 到 f任何一次跳转都必须把step显式改掉绝不靠自然顺序往下滑。retry是保命的没有它一个读不到的标签会让程序在 2→3→2 之间死循环扫描周期被撑爆其他动作全部停摆到 3 次就认输、置error退出让上游去决定是报警还是跳过这个瓶子。sendBuf和recvBuf设计成块内静态变量而不是直接读写 DB多了一层拷贝但换来的是组帧过程不受外部干扰——如果一边组帧一边有别的逻辑改RFID 数据.发送发出去的报文就是半新半旧的。组帧完一次性赋值语义干净。第 4 步的recvTimeout是看门狗读写头正常回包在几十毫秒内超过 500 毫秒基本就是掉线或标签不在场不能无限等。这个信号在块外用一个 TON 定时器做#recvReq为真时启动到时置位超时标志#recvReq变假立刻复位定时器。注意任务书里给的是“函数”FCFC 没有静态变量step和retry存不住。实际工程里我一般写成 FB 配一个背景 DB如果非要用题目给的那个 FC就把step、retry全部换成 M 区或 DB 里的静态位别写在 TEMP 里——临时变量每个扫描周期都重新分配状态机根本跑不起来。3.4 16#C5 与 16#C8判结果为什么要看首字节读写器的回包是定长 72 字节第一个字节是状态码16#C5表示本次读写成功16#C8表示失败。判结果只看RFID 数据.接收[0]不看长度、不看校验这是协议本身的设计——长度固定校验位在读写器内部已经做过一遍。这条规则有个副作用如果程序没收到完整回包接收[0]里留着的是上一帧的旧数据很可能是16#C5于是失败被误判成成功。这就是为什么第 4 步一定要有超时看门狗并且接收必须整块覆盖——RFID 数据.接收 : recvBuf这一句是整块赋值不是逐字节写只要recvDone为真72 个字节一起换掉不会出现半新半旧。读写成功之后M20.5置位这个位是跟主流程的握手信号。加盖拧盖单元的主流程在“取标签数据”节点上等这个位等到了就去读 DB 里的 EPC读完了把M20.5复位然后走下一个动作。这中间如果M21.5标签读取延时没被正确复位下一次触发会被误判成同一个标签的重复读取所以流程里第 1 步专门把M21.5清零。4. 数据采集与平台接入从智能 IO 组态到数字化建模与告警规则模块一的后两个任务和模块二本质是同一件事的两端设备侧把信号变成可寻址的地址平台侧把地址变成带语义的点位。中间任何一段接不上大屏上就是一片灰。4.1 地址分配表怎么落成真实的 IO 映射任务书里的地址表有个特别容易被忽略的细节硬件接线和软件地址不是一一对应的。加盖拧盖单元的表里硬件端子I0:0对应软件地址I2.0I0:1对应I2.1一路顺延到I1:1对应I3.1输出侧Q0:0对应Q2.0Q1:4对应Q4.4。硬件接线软件地址功能描述I0:0I2.0瓶盖料筒检测I0:1I2.1加盖位检测I0:2I2.2拧盖位检测I0:3I2.3加盖前限I0:5I2.5加盖上限I1:0I3.0拧盖定位后限Q0:0Q2.0输送带电机Q1:0Q4.0加盖伸缩气缸这个偏移不是笔误是模块化 IO 的槽位预留CPU 后面挂了通讯模块或占位模块前面的字节被占掉实际 IO 从 I2 开始。写程序时如果照着硬件端子号写I0.0编译能过、下载能跑但那个地址上没有任何物理信号表现为“程序里所有到位检测永远是 0设备一动不动的黑匣子状态”。我见过有人在这上面耗掉四十分钟最后发现是地址差了两个字节。正确做法是把这张表原样录进 PLC 的变量表用符号名编程程序里只出现加盖位检测这种名字不出现绝对地址。这样即使后面地址再变改一处变量表就行。智能物流单元的表同理X100、Y100这种写法说明那个单元的 IO 是按另一套寻址方式编的混合编程时两套地址不能互相套用。4.2 组态、网络参数、IO 地址三段配置智能阀岛/智能 IO 的接入分三段顺序不能反第一段是组态。在编程软件里导入 GSD 文件把设备拖到网络视图上跟 PLC 连到同一根总线。这一步做完设备会出现在硬件目录下但还没有名字。第二段是网络参数。给设备分配设备名pn-dev2和 IP 地址 192.168.1.22。设备名比 IP 更重要——PROFINET 靠设备名寻址名字对不上IP 填得再对也连不通。分配完名字后设备上的指示灯通常会从闪烁变成常亮这是最直观的成功信号。第三段是 IO 地址。把模块的输入输出字节映射到 PLC 的地址区也就是 4.1 那张表的来源。这一段做完编好的程序里那些符号名才有实际落点。// 用符号名访问避免绝对地址偏移带来的误判 输送带电机 : 启动 AND NOT 停止 AND NOT 急停; 加盖伸缩气缸 : 加盖位检测 AND 加盖前限 AND 加盖上限; // 拧盖动作定位到位 上限到位才允许启动电机 IF 拧盖定位后限 AND 拧盖上限 THEN 拧盖电机 : TRUE; END_IF;这段短逻辑比长代码更值得看所有条件都用符号名表达可读性直接决定四小时后你还改不改得动。急停放在输出条件里做串联是最后一道硬保护任何输出都得先过它。智能物流单元那边还多一个伺服驱动器接线按图 1-2 和图 1-4 走参数配置的重点是原点回归方式和左右、前后、上下三组限位的逻辑电平限位接反了会出现“一上电就往一个方向顶死”的经典场面。4.3 平台侧模型、设备、点位、北向的四级创建顺序平台地址是 192.168.1.100:30000登录信息在任务书里给出。模块二任务 2-1 列的六项提交内容其实是四级对象的创建顺序先建网关模型和设备模型把“加盖拧盖单元”和“智能物流单元”抽象成两类模型再给模型做功能定义也就是属性列表——瓶盖料筒检测、加盖位检测这些开关量加上累计计数、订单数量这类数值量然后基于模型创建设备实例一个模型可以建多个设备最后在网关里配 PLC 连接、子设备、点位和通讯参数导出的点位表就是南北向打通的凭证。网关导出的点位结构大致长这样字段名各平台不同但语义一致{ gateway: gw-press-01, protocol: S7, plcIp: 192.168.1.21, points: [ {name: rfid_recv, addr: DB1.DBX0.0, type: byte_array, len: 72, desc: RFID 接收缓冲区}, {name: cap_pos, addr: I2.1, type: bool, desc: 加盖位检测}, {name: conveyor, addr: Q2.0, type: bool, desc: 输送带电机} ] }byte_array这种类型在多数平台上是支持的但要注意字节序和长度导出的长度如果写成默认 8采上来的就是前 8 个字节看不到完整 EPC。北向配置是平台对上层应用暴露的出口配完之后设备监控页面才能拿到数据这一步的顺序是“先南向通、再北向配”反过来配完发现南向没通大屏上全是空值又得回头查。4.4 三指令下发与 1 秒延时生产排程的时序约束任务 2-2 的订单是 5 瓶钙片、每瓶 2 粒分三批做第一批 60%也就是 3 瓶。可视化页面上点预览、远程启动、绑定点位这些都是操作层面的真正容易翻车的是指令下发方式。任务书里写得很明确下发控制指令时一个动作要发 3 个指令比如开机要设定“停机0、复位0、开机1”值为 1 的指令放在最后三个指令之间需要延时 1 秒。这是一个典型的三段式状态复位——先把可能残留的状态位清零再置位目标状态。少发一条设备可能停在“既没停机也没开机”的中间态顺序发反先置开机再清停机设备收到开机命令后立刻又被清掉表现为按了没反应。import time, requests BASE http://192.168.1.100:30000/api/v1 DEV press_unit_01 def post_cmd(stop: int, reset: int, start: int): 按 停机 - 复位 - 开机 的顺序下发值为 1 的放最后 payload {cmdList: [ {attr: stop, value: stop}, {attr: reset, value: reset}, {attr: start, value: start}, ]} r requests.post(f{BASE}/device/{DEV}/command, jsonpayload, timeout3) r.raise_for_status() return r.json() # 开机先清停机位间隔 1 秒再清复位位最后置开机 post_cmd(0, 0, 0); time.sleep(1) post_cmd(0, 0, 1)这段脚本是课下自测用的赛场上直接在平台可视化页面点也可以但把请求写成脚本有个好处能精确控制 1 秒间隔也能批量重放排查“点了没反应”时到底是平台没发出去还是设备没收到。timeout3别省平台在订单执行期间响应会变慢不设超时脚本会一直挂着。对应的状态机约束是设备处于停止状态才能复位处于复位状态才能启动或停止启动状态只能接一个订单做完必须重新启动才能接下一单。写脚本批量下发前先查一次当前状态别默认它是复位态。4.5 告警规则40 度二级高温与 8 级停机告警任务 2-3 要建两条规则。第一条是温度超过 40 度触发二级高温报警这是标准的阈值规则比较符用大于而不是大于等于写错一个符号就会出现“刚好 40 度时报警”还是“41 度才报警”的差别测试用例里得专门覆盖边界值。第二条是加盖拧盖单元未完成订单且停止生产时产生 8 级、类型为“其它”的告警。这条的难点在“未完成订单且停止生产”这个复合条件——它同时依赖订单进度和设备状态两个数据源如果点位建模时没把“订单剩余数量”和“运行状态”定义成可比较的数值和枚举规则里根本选不出来。所以在 4.3 那一步做模型功能定义时就得提前想好后面要建什么规则把字段留出来。规则建完务必用一次真实停机去验证下发一个订单跑到一半手动停设备看告警有没有在规定级别上冒出来。只在页面上看着规则是“已启用”不算数。5. 避坑与排查赛场上最容易翻车的五个点下面五条都是能直接对号入座的现象—原因—解决按顺序写遇到时照单抓药就行。5.1 接线与组态类现象一智能 IO 组态里设备显示为灰色问号网络参数一栏全部不可编辑。原因通常是 GSD 文件版本和实物模块的固件版本不匹配或者导入的是另一型号的 GSD。解决方式是先看模块外壳上的订货号回参考资料文件夹找订货号完全一致的那份 GSD 重新导入找不到就换用通用 GSD但要注意通用 GSD 下部分诊断功能会失效。导入后如果还是灰色把设备从网络视图删掉重新拖一次别在原地改。现象二设备名已分配指示灯也常亮了但 PLC 侧读不到任何 IO。多半是 IO 地址段的映射没做或者映射到了 PLC 已经被占用的地址区。这种情况编译能通过下载也不报错只是数据一直是 0。解决方式是打开设备视图核对输入输出起始地址和 4.1 那张软件地址表逐个对一遍特别注意那个 I2/Q2 的偏移。对完之后在线监控一下用手挡一下传感器看 I2.1 有没有翻转没有翻转就是地址还是错的。5.2 程序与通讯类现象三RFID 程序一直停在发送/接收循环扫描周期肉眼可见地变长其他动作全部卡住。原因是状态机缺重试上限或者缺接收超时读写头没回包时程序在 2→3→2 之间无限打转。解决方式是补上retry计数器到 3 次就置错误标志退出同时在接收步骤挂一个 500 毫秒的 TON 看门狗超时按失败走。补完之后还要检查是不是标签本身不在读取范围内——瓶子放偏了几厘米读写头就是读不到程序再健壮也没用。现象四读回来的标签数据是对的但主流程拿不到M20.5一直不置位。原因通常是判结果的字节位置搞错了或者接收区没落在DB1.DBX0.0。任务书要求接收区在这个绝对地址上如果 DB 开着优化访问地址对不上程序里读的是另一块内存首字节永远不是16#C5。解决方式是检查 DB 的块属性把“优化的块访问”取消勾选重新编译下载再看一眼RFID 数据.接收[0]在线值手工触发一次读标签看它是不是变成16#C5。5.3 平台与提交类现象五可视化页面绑定完点位预览时数据不刷新但网关日志显示采集正常。原因一般是北向配置没做或者做在了南向之前平台应用层拿不到网关推送的数据也可能是可视化页面绑的是模型属性而设备实例上那个属性没被赋值。解决顺序是先确认网关南向点位在线值有变化再确认北向出口已启用最后回可视化页面重新绑定一次并保存。另外提交流程上有硬要求所有截图要放进 U 盘指定文件夹程序和答案存到“技能竞赛\竞赛编号”目录下没存到指定位置的运行记录一律不给分——我见过功能全做完、分数丢在保存路径上的。6. 二次开发把样题改造成可自测的实训工程这份样题最大的复用价值不在“照着做一遍”而在它把一条完整链路拆成了可验证的六段。想拿它做二次开发我建议按“抽骨架、换参数、加断言”三步走。抽骨架把第 3 章那个 RFID 状态机独立成一个 FB输入只留trigger、reset输出只留done、busy、error内部所有RFID 数据的引用改成接口参数。这样它就不再绑死在这套设备上任何走 TCP 定长报文的读写器都能套进去只改组帧那一段的字节布局。分拣规则同理把那个MOD 6的循环抽成一张映射表累计瓶数 n(n-1) mod 6目标区容量上限1、20、13 号平面仓63、42、32 号输送带45、64、51 号输送带4表驱动的好处是规则一变只改表不改代码。比如把周期从 6 改成 8或者把 1 号区容量从 4 改成 3都只是数据层面的调整。换参数把所有 IP、端口、DB 号、设备名集中到一个配置 DB 或一份 JSON 里程序里只引用符号。这一步做完同一套程序可以同时适用于两个单元的 PLC只是加载不同的配置。加断言这是最值得投入的一步。给状态机写几个可自动跑的测试场景——标签不在场、读写头掉线、回包首字节是16#C8、回包超时——每个场景都期望程序在规定时间内退到error而不是卡死。没有硬件也能测用一个 Python 脚本起个 TCP 服务端模拟读写头按不同分支返回不同报文PLC 侧或者上位机侧跑状态机看它是不是每次都按预期退出。这套脚本写一次后面所有改造都能复用。import socket # 模拟读写头按请求次数切换返回分支验证状态机的异常处理 MODES [b\xC5 b\x00 * 71, # 成功 b\xC8 b\x00 * 71, # 失败 None] # None 表示不回包触发超时 with socket.socket() as s: s.bind((0.0.0.0, 9000)) s.listen(1) for mode in MODES: conn, _ s.accept() conn.recv(72) # 收下 PLC 发来的 72 字节请求 if mode: conn.sendall(mode) conn.close()这个模拟器的价值在于把“读写头”这个不可控因素从测试里摘出去剩下的问题全在你自己的代码里。MODES列表顺序就是三条分支的执行顺序跑完一轮看状态机的三个出口是不是都被覆盖到。提示模拟器绑的是 9000 端口跑之前确认本机没有别的服务占着这个端口否则bind直接抛异常。从那以后我每次接手这类多单元联动的赛题或者实训台都强制先走一遍“纯网络验证 → 单点 IO 验证 → 状态机空跑 → 联机”四步宁可前面多花二十分钟也不要在四小时的最后半小时里对着一堆不确定的中间态猜是哪一层出的问题。这套顺序不新鲜但真能省下后悔药。希望帮到你。本文还有配套的精品资源点击获取