在CoDeSys 3.5里写程序绕不开功能块FB和程序PRG这两个核心概念。很多刚接触IEC 61131-3编程的工程师在ST语言里看到fbValve(xEnable : TRUE);这种写法很容易懵为什么不能直接写FB_Valve(xEnable : TRUE);中间非要加一个实例名这个细节恰恰是PLC程序从“小练习”走向“工程化”的分水岭。这一篇是我CoDeSys入门实战系列的第十四篇专门把FB与PRG的实例化、调用和工程实践摊开讲清楚。适用对象是已经会写基本ST、梯形图但还没搞清楚怎么组织一个完整项目的初学者也适合从传统PLC平台转CoDeSys的工程师。1. 先从IEC 61131-3的视角认识FB和PRG1.1 FB是带静态数据的“乐高积木”PRG是主控流程在CoDeSys这种基于IEC 61131-3的开发环境里程序由不同的POUProgram Organization Unit程序组织单元构成。常见的有程序PRG、功能块FB、函数FUN。FB和PRG表面上都是“一段代码”但它们在工程中的定位完全不同。功能块的核心特征是你必须先创建一个“实例”Instance然后才能调用。还记得面向对象里的“类”和“对象”吗FB就相当于类实例就是对象。FB内部可以定义自己的局部变量、常量、输入输出参数甚至可以写状态机逻辑。每次调用FB实例它都会记住上一次运行结束时留在内部变量里的数据。这个“静态记忆”是FB最重要的东西也是它和普通函数最本质的区别。程序PRG通常用来承载一个完整的控制流程。它更像是一个项目的“主循环”可以理解为一台设备的操作说明书什么条件下启动什么条件下停止遇到故障怎么处理。PRG里面可以调用FB实例也可以调用函数还可以调用其他PRG。但PRG本身要运行得先被分配到一个“任务”Task里由任务调度器按设定周期循环执行。可以说PRG是骨架FB是一块一块的肌肉两者配合项目才能立起来。这里还要提一下CoDeSys里相当常见的“功能块与程序混用”问题。很多初学者会把设备控制逻辑直接写在PRG的IF语句里这当然能跑但项目一旦超过两三百行这种写法会迅速变成一坨没法维护的面条代码。我见过有人在一个PRG里用IF套IF写了十几个设备的状态新增一个阀门就要复制几百行。正确的方向应该是PRG只做“流程编排”设备动作细节全部下沉到FB内部。1.2 为什么必须有实例化这一层很多初学者最大的疑惑是为什么要多此一举先实例化再调用直接写功能块名字不就好了答案在于PLC程序的可复用性和数据隔离。一条生产线可能有10台电机每台电机的控制逻辑完全一样正转、反转、停止、过载保护。如果你给10台电机各写一份子程序后面想改逻辑就要改10个地方漏改一个就出大事故。更好的做法是只定义一个FB_MotorCtrl功能块然后在程序里声明10个实例fbMotor1、fbMotor2……一直到fbMotor10。每个实例都有自己的内部状态比如bRunning、iCurrent互相不干扰。改逻辑时只改FB本体10个实例自动生效这就是实例化带来的最大价值。用生活类比FB是“图纸”实例是“按图纸造出来的机器”。图纸规定了机器有什么部件、怎么运转但你不可能直接开动图纸必须先把图纸变成一台具体的机器。10台电机就是10台不同的机器虽然都来自同一张图纸但每台的运行时间、电流反馈、报警计数都是独立的。没有实例化这层抽象你的程序将是一堆重复代码维护成本直接爆炸。需要注意实例名是唯一的标识命名一定要有意义。我见过有人把实例命名为fb1、fb2三个月后回去看代码完全想不起fb1到底是电机还是阀门。后面的工程实践部分我会专门给出命名规范建议。1.3 FB、功能块实例和函数调用的本质差异这里顺便把函数FUN也拎出来对比一下。函数没有内部记忆给它相同的输入参数它永远返回相同的结果而且调用时不需要实例直接用函数名加参数即可。例如iAbs : ABS(iValue);你不需要为ABS创建实例。功能块则不同它内部可以有很多局部变量这些变量在上一次调用结束后仍然保留所以同样的输入可能因为内部状态不同导致输出不同。这带来一个重要结论函数适合做纯计算比如温度换算、工程量转换功能块适合做带状态的设备控制比如电机、阀门、气缸、PID调节。PRG与FB的另一个差异在于实例化层级。PRG在任务中挂载时系统会为它创建一个唯一的实例这个实例对应整个程序运行时的全局数据区。FB实例则更灵活你可以随时在任何POU的变量区里声明。我用下面这个表格帮大家快速分辨维度函数FUN功能块FB程序PRG是否需要实例否是是由任务创建内部是否有状态记忆无有有典型用途计算、转换设备控制、协议处理、算法封装主流程、任务调度、IO映射调用方式FUN(参数)fbInstance(参数)任务调度或PRG()调用存储位置临时栈所在POU的数据区任务实例数据区这个表建议存下来以后写程序前先问自己一句我这段逻辑是需要记忆的还是纯计算需要记忆的用FB不需要的用函数而PRG只负责把整个流程串起来。2. 功能块FB实例化的三种常用姿势与细节2.1 局部变量区直接声明实例大多数场景的首选最基础、也最常用的实例化方式就是在PRG或FB本体的变量声明区里直接写PROGRAM MAIN VAR fbValve1 : FB_ValveCtrl; fbValve2 : FB_ValveCtrl; bStart : BOOL; END_VAR然后在程序主体中IF bStart THEN fbValve1(xEnable : TRUE); ELSE fbValve1(xEnable : FALSE); END_IF fbValve2(); // 假设它在内部读取输入信号这样声明出来的实例生命周期和所在POU的实例一致。如果声明在PRG Main里那它就在主程序每次扫描时被刷新如果声明在另外一个FB里那它就是这个FB内部的一个子设备跟随父级实例一起被创建和销毁。绝大多数情况下我都建议把设备实例声明在使用它的PRG或上层FB的局部变量区作用域清晰调试时也很容易从调用树里找到特征值。这里有个关键细节FB实例的输入输出接口最好通过命名实参形式调用比如fbValve1(xEnable : bStart, bAuto : bMode);。命名实参可以让你在FB接口变更时更快发现问题而且代码可读性比一股脑的顺序传参好得多。千万不要写出fbValve1(bStart, TRUE, 5);这种“顺序传参”参数一多谁也不记得第三个参数是什么意思。2.2 VAR_GLOBAL全局实例跨POU共享状态的便捷通道有时你会遇到一个需要被多个程序访问的FB实例比如一个全局的通信状态机Main程序要往里面喂指令另一个异常处理程序要读取它的故障码。这时候就可以把实例声明在全局变量列表GVL里VAR_GLOBAL fbComm : FB_ModbusRTU; END_VAR然后在任意POU中直接使用fbComm。全局实例的优点是访问方便缺点是“谁都读、谁都写”容易造成数据竞争和逻辑混乱。我在实际工程里见过很多次多个PRG同时调用同一个全局FB实例导致一个周期里FB被执行了好几遍状态机跳了好几步。所以如果你要用全局实例务必明确谁负责写、谁负责读或者用一个特定的处理PRG集中调用。全局实例适合低频、慢速的通讯、打印、数据记录不适合快速响应的伺服控制。如果你需要多个PRG共享同一个设备FB但又不想搞全局变量还有一个折中方案在上层PRG中创建实例通过接口VAR_IN_OUT或引用向下层传递。比如Program_IO创建fbMotor1把fbMotor1通过VAR_IN_OUT传给Program_Logic。这样数据归属仍然清晰又满足了跨POU访问。2.3 指针实例和动态分配用得少但必须会CoDeSys 3.5提供了有限但可用的指针操作。你可以写VAR pTimer : POINTER TO FB_Timer; END_VAR pTimer : __NEW(FB_Timer); pTimer(); __DELETE(pTimer);这样可以在运行时动态创建和销毁实例。这种能力的工程价值在哪里比如你的设备数量不固定今天接8台仪表明天换10台编译期你不想把上限定得太大就可以用动态分配。但代价也很明显你要自己管理内存忘记__DELETE会导致内存泄漏长时间运行后程序逐渐卡顿甚至崩溃。我个人的态度是普通PLC工程能不用动态分配就不用如果你真的想用务必限制实例数量上限并且添加分配/释放的日志跟踪避免线上问题无法追溯。更常用的是数组形式批量实例化。CoDeSys允许你定义一个FB实例数组VAR fbPump : ARRAY [1..8] OF FB_Pump; END_VAR FOR i : 1 TO 8 DO fbPump[i](xOn : bPumpOn[i]); END_FOR这比写8个独立实例优雅得多尤其是设备数量多、且它们的工艺参数高度相似时。不过要注意数组索引最好用1..8这类显式上下界方便遍历和做寻址也避免和0起始的C语言习惯搞混。2.4 实例化时初始化和释放的坑实例化不等于“创建完就没事了”。在PLC上电或下载程序后实例内的变量会按照声明时给定的初始值进行初始化。如果你希望某些数据在断电后还能保留就需要单独处理。CoDeSys中的保持变量可以放在VAR RETAIN区但FB实例内部的数据能不能保持取决于你如何声明实例。假如你将FB实例声明在普通VAR区它的所有内部变量在断电重启后都会被清回初始值。想让其中某个状态保持要么把这个状态提升到PRG级的Retain变量里要么就用VAR RETAIN包住这个FB实例。实际操作中CoDeSys允许直接在FB实例的声明变量区加RETAIN属性但碎片化的保持数据可能影响启动性能。这个问题没有绝对标准答案我的建议是需要保持的数据尽量集中在一个专门的数据保持FB中不要在几十个设备FB里各放一个Retain变量。删除实例也有讲究。如果你在在线模式下删除了一个实例声明系统通常要求你进行“更改下载”这时PLC会重新初始化所有非保持变量。某些情况下你想保留保持变量就需要执行“在线重置保持变量”或者只对实例进行冷启动。这个环节千万别随手点“确定”先想清楚设备现场是否允许全部状态清零。3. 程序PRG的实例化与任务分配工程落地的关键一步3.1 为什么PRG也讲究“实例化”任务配置中的实例路径很多刚从传统PLC转过来的人容易把PRG当成“程序文件”觉得在左侧设备树里新建一个PRG它就能自动跑。其实不然。在CoDeSys工程中一个PRG要真正被执行你必须把它挂到“任务配置”里并在任务下添加一个“POU调用”或“程序实例”。这一步往往被人忽略于是编译没报错下载后程序却不动作查了半天发现任务里根本没有这个PRG。在任务配置中你会看到类似这样的结构任务配置 └─ Task_IO └─ MAIN (PRG实例)这里的MAIN就是PRG Main的一个实例名默认和POU名字相同。你可以在一个任务下挂多个PRG实例也可以把同一个PRG挂到多个任务里——但后一种做法会产生不同的实例副本每个副本有各自独立的内部变量。如果你想在两个任务中共享同一个PRG的数据正确的做法不是重复挂载而是让这个PRG通过全局变量或共享FB来交换数据。理解“实例化”对PRG同样适用。新建一个PRG时它不过是一段未运行的代码只有当你把它实例化并挂上任务它才成为运行时中一个活生生的、带着状态的控制循环。实际排查“程序不动作”时我通常会按三步走先看任务配置里有没有这个PRG再看任务周期是否合理最后用在线监视看任务是否进入运行状态。大部分初学者栽在第一步检查完任务配置问题往往就水落石出。3.2 把PRG挂上任务的三种配置方式在CoDeSys 3.5中添加PRG到任务通常有三种常见操作路径。第一种是在“任务配置”左侧树中右键添加任务例如新建一个名为CyclicTask的周期任务设置周期为10ms优先级为1。然后在任务节点下右键“添加POU调用”选择你要执行的PRG比如Main。第二种是如果已经有了PRG可以直接把设备树里的PRG拖拽到任务节点上CoDeSys会自动创建调用关系。第三种方式是直接在模板默认的PLC_PRG中调用其他PRG但底层还是要有一个任务来跑PLC_PRG。我实际项目中更倾向于一个任务对应一个主程序主程序里再用FB组织功能。比如Task_Main周期5ms调用MainMain内部再调用IO_Adapter、Seq_Selector、MC_Logic等FB实例。这样任务调度一目了然也方便通过任务看门狗判断超时。任务周期设置的坑在于不是所有代码都适合放同一个周期。IO刷新可能只要2msModbus RTU通信可能要50ms如果你把它们硬塞进同一个5ms任务通信函数内部的等待时间会白白占住CPU周期。合理的做法是在任务配置里建多个任务用不同周期和优先级分别调度不同PRG/FB。3.3 主程序与子程序用调用结构组织整个项目并不一定所有PRG都要挂在任务下。CoDeSys允许一个PRG内部调用另一个PRG吗严格说你可以用SubPRG();这样的方式调用但我一般不推荐。原因有两个一是PRG本身是“任务级”的组织单元把它当作普通子程序调用会让调用层级混乱二是PRG的实例和内部状态容易被多个任务重复调用造成数据竞争。更干净的工程结构是任务 → 主PRG实例 → 若干FB实例。让主PRG负责调度让FB负责具体功能。如果实在要复用一大段流程把它封装成FB而不是PRG。比如一个标准项目的POU分布可以是这样MainPRG主任务入口调用下面几个调度FB。IO_AdapterFB负责把原始IO信号读进来映射成工艺信号。Seq_SelectorFB负责选择手动/自动/调试三种模式。FB_ValveCtrl、FB_MotorCtrl具体设备驱动。FB_ErrorLog故障记录。这样你拿到任意一个FB都能单独测试改动机器逻辑时只要找对应FB不用在几千行的PRG里翻Find。工程组织这件事真正做到后面比写逻辑本身更重要。3.4 不同PLC平台下的任务优先级与扫描周期影响CoDeSys是跨平台IDE很多国产PLC比如汇川AM、Easy系列以及国外品牌都基于它二次开发。不同PLC的实际固件对任务支持不一样有的平台支持抢占式优先级有的只是轮询调度。如果你写了一个高优先级任务里的FB去等待某个共享资源而低优先级任务正在修改这个资源轻则数据抖动重则看门狗超时。我踩过一个比较典型的坑把Modbus RTU的串口驱动放在了一个20ms的任务里同时又把HMI数据刷新放进了5ms任务。HMI任务频繁调用一个读取串口状态的FB导致串口驱动程序在还没完成上一帧接收时就被反复打断通信帧错误率飙升。后来把串口相关FB所有调用都收敛到同一个任务并把读取操作和解析操作拆成两个FB问题就消失了。所以当你用FB实例化后第一件事就是画一张“调用表”明确每个实例在哪个任务、什么周期、读写哪些全局变量。不要等到现场出了灵异问题才回来查。4. FB与PRG联合调用的工程实践从小工装项目看组织方式4.1 项目需求与POU划分说具体的。去年我做过一个小型工装设备十几台阀门、几台风机带一个Modbus RTU仪表还有一个读取PLC网口MAC地址用于设备标识的需求。如果全塞在一个PRG里状态会非常乱。我当时的划分很简单一个Main程序负责主循环一个IO_Adapter功能块负责所有数字量输入输出扫描一个FB_ValveCtrl功能块封装阀门的开阀、关阀、反馈确认、超时报警一个FB_MotorCtrl封装风机的启停和过载保护还有一个FB_ModbusRTU封装仪表读取最后写了一个临时功能块FB_GetMac用于在首次联网时读MAC地址。每个FB内部都维护自己的状态机对外只暴露必要的输入输出接口。这样分工的好处是调试时可以单独用在线监视查看每个FB内部状态哪一步动作不对一眼就能定位。4.2 用FB封装Modbus RTU读取接口的实例思路在上面的项目里FB_ModbusRTU是我刻意设计的一个多功能块。它的输入包括xRead读请求使能、uiSlaveAddr从站地址、uiRegister寄存器地址输出包括xDone、bError、aData读取数据的数组。内部维护了定时器、帧状态机和错误计数。在主程序里我这样调用fbMeter.xRead : bReadMeter; fbMeter.uiSlaveAddr : 1; fbMeter.uiRegister : 40001; fbMeter(); IF fbMeter.xDone THEN g_rMeterValue : UINT_TO_REAL(fbMeter.aData[0]); END_IF这种封装方式的精髓在于把“怎么读”藏进FB内部外面只管“什么时候读”和“读回来的数据怎么用”。即使以后从Modbus RTU换成Modbus TCP也只需要改动FB内部实现外部逻辑完全不用动。记得当时我把整个串口初始化、超时重试、CRC校验全封装在内部FB接口没变后续替换驱动时上层main代码只改了一行实例定义。4.3 在PRG中调用多个FB实例的代码框架下面给一个简化的主程序调用框架不算完整工程但能看出组织思路PROGRAM Main VAR io : IO_Adapter; fbV1 : FB_ValveCtrl; fbV2 : FB_ValveCtrl; fbM1 : FB_MotorCtrl; fbMeter : FB_ModbusRTU; fbGetMac: FB_GetMac; END_VAR PROGRAM Main // 1. 先刷新IO把物理信号读入内部 io(xScan : TRUE); // 2. 阀门控制读入来自HMI手/自动命令 fbV1(bAuto : g_bAutoMode, bCmdOpen : g_bV1Open); fbV2(bAuto : g_bAutoMode, bCmdOpen : g_bV2Open); // 3. 风机控制 fbM1(bRun : g_bFanRun); // 4. 仪表轮询每50个周期触发一次 IF g_uiPollCnt 0 THEN fbMeter(xRead : TRUE); END_IF // 5. 读取MAC只在上电初始化阶段执行一次 IF g_bFirstScan THEN fbGetMac(); g_bFirstScan : FALSE; END_IF注意几点。第一IO刷新永远放在最前因为后面的所有FB都可能依赖本次扫描最新的输入。第二同类设备FB可以并列调用但必须确保它们的内部定时器不会因为调用顺序而出现偏置问题比如两个阀门同时给开阀指令为什么一个先动作一个后动作多半是反馈延时处理不同。第三像读取MAC这种只执行一次的任务适合放在首次扫描分支里不要在循环周期里反复调用。4.4 调用链设计谁负责状态机谁负责IO映射工程实践中的一个核心问题是状态机放在哪里是放在PRG里还是放在FB里我的经验是设备级状态机放在FB里流程级状态机放在上层PRG里。所谓设备级状态机比如阀门的“开阀—等待反馈—确认到位—关阀—等待反馈—确认关闭”这些完全是设备自身的固定行为放进FB_ValveCtrl内部再合适不过。流程级状态机比如“上料—加热—保压—卸料”每一阶段要触发哪些设备FB这个属于整机工艺应该放在上层主PRG或者一个专门的流程FB里。如果把流程级状态机也塞进设备FB设备FB就要知道产线上的其他设备耦合度急剧升高复用性瓦解。我以前见过一个同事把整条线的工艺状态写进了一个名为FB_Motor的电机功能块里结果调试另一条线时只能复制粘贴改名字痛苦程度一言难尽。正确的做法是设备FB只管自己的活对外提供bRun、bReady、bError这些状态接口主程序里的流程状态机根据这些接口决定下一步发布什么指令。5. 避坑实录FB/PRG使用时常见的编译错误与排查思路5.1 编译阶段最常见的几个报错语意CoDeSys的报错信息虽然没有C#那么友好但认熟几个常见错误能省很多时间。比如你把功能块当函数调用直接写FB_ValveCtrl(...)编译器会报“预期是变量”或“未知标识符”。原因很简单功能块名不是变量只有实例名才能调用。再比如你在一个FB内部声明了另一个FB实例但两个FB文件处于不同的库命名空间可能会报“找不到POU”的错误。这时候去检查库引用是否齐全或者是否写了完整的命名空间前缀。另外一个高频错误是“实例未声明”。这通常发生在你把功能块实例藏在VAR_TEMP区里然后想在调用点使用它。CoDeSys中VAR_TEMP是临时变量区用于存放每个扫描周期都会被重新初始化的临时数据功能块实例放在里面无法保留内部状态甚至直接报错。功能块实例应该放在VAR或VAR_RETAIN区不能放在VAR_TEMP区。记住这一点能省下一个小时的排查时间。5.2 实例声明位置引发的作用域问题实例声明的位置直接决定谁能访问它。如果我在PRG Main的VAR区声明fbValve1那其他PRG直接写fbValve1肯定会报“未知标识符”因为局部实例只在本POU可见。很多初学者遇到这个报错第一反应是去查有没有拼写错误实际就是作用域没搞清楚。解决方案很简单要么把实例提到GVL要么通过接口参数传递。但接口参数传递时我用得比较多的方式是用VAR_IN_OUT将FB实例引用传进另一个FBFUNCTION_BLOCK FB_HMI_Control VAR_IN_OUT fbTarget : FB_ValveCtrl; END_VAR这样HMI控制块可以直接操作fbTarget内部接口同时数据归属还在上层。这里要注意VAR_IN_OUT传的是引用调用方必须保证实例存在且生命周期覆盖整个调用过程否则会访问到无效数据区。5.3 任务周期与FB内部定时器不一致的误解FB内部的TON、TOF等定时器其计时基准来自它所属的调用任务周期。比如你把一个FB放到10ms任务里内部定时器的解析度就是10ms放到100ms任务里解析度就是100ms。这个常识很多人会忽略结果在不同任务中调用同一个FB时出现“为什么这台设备延时异常”的问题。如果你希望延时精度和任务周期无关那就应该基于时间戳差值的算法实现或者使用系统实时时钟而不是依赖任务计数。这里还要引入一个我常给团队强调的规则每个FB内部使用的TON实例必须声明在VAR区而不是VAR_TEMP区。如果你把定时的临时实例放在VAR_TEMP里每次调用重新初始化为0定时器永远无法累计动作永远延时不了。这个错误隐蔽在在线监视里也很难发现因为从外部看你传了tPreset : T#5S进去但内部ET始终是0。此外还要注意任务周期抖动。CoDeSys可以设置固定周期但实际周期会受其他高优先级任务影响。如果你在FB里用当前时间戳做了积分周期抖动量会在积分中放大导致伺服类控制不平顺。这时候要给任务配置留出余量不要让它满负荷跑。5.4 在线修改与实例状态丢失的问题CoDeSys支持在线修改但功能块接口变更时在线下载往往会要求我们重置实例。无论提示是“重新初始化所有实例”还是“仅布局更改”你都应该先判断现场工艺能不能接受数据清零。有一次我在现场改了FB的一个输入引脚然后点了在线修改。PLC倒是没停机但所有FB内部状态全部重置了正在运行的一台设备突然重新走了一遍初始化流程。后来我在所有关键状态处理逻辑里加了“状态恢复”代码并且严格规定接口变更一律安排在计划停机窗口绝不现场随便在线改。如果你确实需要在不停机的情况下修改逻辑唯一的办法是将可变动逻辑做成参数共享的变量或配方而不是修改FB接口。FB的接口一旦发布就要当成“协议”看待不要随手改。工程上这是所有PLC工程师迟早要养成的习惯。5.5 常见故障速查表我把这些年遇到的FB/PRG相关问题整理成一个速查表方便大家直接对号入座现象可能原因解决办法编译报错“未知标识符”没写实例名直接把FB名当函数调用先声明实例再用实例名调用程序下载后不执行PRG没有挂接到任务配置在任务下添加POU调用设置周期FB内部状态每次调用都被清零实例放在了VAR_TEMP区移到VAR或VAR_RETAIN区断电重启后FB状态丢失实例不在保持变量区将需要保持的数据放到Retain区或单独保持FB同一FB的多个实例动作不一致实例间共享了全局变量检查全局变量访问尽量让逻辑只依赖实例内部数据在线修改后设备状态异常接口变更导致实例被重新初始化规划停机窗口或封装参数避免修改接口Modbus通信偶发超时多个任务中重复调用通信FB收敛调用点统一周期和优先级温度/速度模拟量波动大调用周期与采样周期不匹配让FB按固定任务周期运行采样数据加滤波这些经验不是书本上写的都是我一行一行试出来的。按着速查表排查至少能帮你省掉两三个通宵。我这里想补充一个最实在的个人体会CoDeSys项目从入门到能干活真正难的不是ST语法而是对实例化和调用关系的把握。哪怕你暂时不追求复杂的算法只要把每个设备抽象成一个FB把所有流程编排留在PRG再用合适的实例作用域把这些积木搭起来你的程序就已经超过一半的工业项目水平了。后续你还会遇到更多实际需求比如读取PLC网口MAC、分发Modbus数据、做配方管理等只要记住“先有实例再谈调用接口稳定工程才稳”这些需求都可以用同样的思路拆解。第二个小技巧是在开发阶段就把每个FB的调用点画在纸上或画在代码注释里等现场调试时你会感谢当初做笔记的自己。下一篇我准备讲讲CoDeSys里结构体与联合体在通信数据解析中的应用以及如何用它们把Modbus RTU收到的字节流优雅地映射成工艺变量。如果你在FB实例化或任务配置上还有想不通的细节欢迎在评论区留下问题我会挑典型的在下期一起展开。