基于SCL For循环的电梯楼层优先级调度实现与HMI联动

这些年做西门子S7-1200/1500项目我最大的体会是凡是遇到“一堆条件同时进来必须按优先级挑一个执行”的逻辑就用SCL写For循环去扫基本都能把程序写得又短又清楚。这次要聊的电梯楼层优先级调度就是最典型的一个例子。16层楼轿厢里的选层按钮、每层厅外的上召和下召再加上消防强制返回基站这种特殊请求信号量不算大但互相之间的优先级关系特别绕。如果全用梯形图去堆程序写出来跟蜘蛛网一样改一个条件就可能牵一发动全身。用SCL的For循环把每一层当成数组里的一个元素对整个请求表扫描打分最后挑出得分最高的楼层整个调度逻辑就变成了一段能读懂的文本代码。这篇文章我把自己从需求拆解、调度算法设计、TIA Portal实际编程再到触摸屏联动演示的完整过程都放进来。适合正在学SCL、想用结构化文本做复杂逻辑的同行也适合被类似“排号叫号”逻辑困扰、想换个思路写程序的朋友。文章不是教科书式的语法罗列而是从真实项目视角出发讲清楚每一步为什么这么做。1. 电梯调度问题的本质为什么For循环是最优解1.1 请求类型与数据结构把物理按钮映射成数组电梯调度在软件层面其实不复杂难点在于它同时存在多个“请求源”。以16层住宅楼为例电梯要处理的请求至少分成四类轿厢内选层指令乘客在轿厢里按的楼层按钮这种指令一旦登记在到达前一直有效。厅外上召某层有人在等电梯并且要上行按下行方向箭头里的“上”按钮。厅外下召某层有人要下行按下“下”按钮。特殊/紧急请求消防返回基站、地震管制返回等需要无条件抢占最高优先级。这四类信号如果用梯形图表达最常见做法是给每层每个方向建一个中间继电器然后用一大堆常开常闭触点去互锁。楼层少还勉强能看一旦楼层超过8、10层触点组合就非常难看。改一个楼层需求要翻好几页程序。换成SCL思路以后我第一件事永远是画数据结构不急着写代码。16层楼那就建三个长度为16的布尔数组内部呼叫数组、上召数组、下召数组。数组下标就是楼层号数组元素是TRUE就代表该楼层有一个等待中的呼叫。紧急请求特殊一点用一整个BOOL加一个INT记录紧急楼层。这种“楼层当数组下标、按钮状态当数组元素”的做法是后面所有For循环逻辑的地基。数组天然支持循环遍历写一行循环体就能覆盖16个楼层的检查这就是结构化文本相对梯形图的本质优势——用数据组织代替触点堆叠。1.2 梯形图也能做但为什么我坚持用SCL有工程师会问梯形图用比较器也能实现同样的功能为什么要换成SCL我给你讲个实际场景。梯形图做优先级比较通常需要两两比较的逻辑链呼叫A和呼叫B比较胜者再和呼叫C比较一层层嵌套下去。楼层多了以后这个树状结构会非常庞大。更麻烦的是当优先级规则调整时——比如原来“同方向顺路优先”后来改成“附近楼层优先”——电气工程师就要在几百个触点里去找到底哪一条线路决定优先级改完还要担心影响旁边其他逻辑。SCL的For循环完全绕开这个问题。优先级规则不是靠触点串联实现的而是靠“打分公式”实现的。规则变了改几行赋值语句就行。而且For循环天然可读从第1层循环到第16层每一层的呼叫做加法、比较大小逻辑一目了然。1.3 SCL语言在逻辑密集型控制里的优势与局限SCL在很多自动化工程师眼里“偏软件”初期确实要适应。它的优势非常明显数组、循环、数学运算、字符串处理都很顺手适合做算法类控制逻辑。代码即注释只要变量命名规范半年后回看还能读懂。便于团队协作和版本管理改动可以用文本对比工具看差异。但它也有短板。首先是电气专业背景的同事接受度低现场维护时不一定人人都会看ST文本。其次是SCL调试时不能像梯形图那样在触点上一眼看出导通状态必须靠监控变量。所以我的建议是你可以在一个项目里混合使用LAD和SCL。设备级逻辑、安全回路互锁这类“看趋势”的逻辑继续用梯形图而调度算法、数据处理、通讯解析这类“靠逻辑”的代码坚决用SCL。2. SCL For循环的调度原语从扫描到打分2.1 For循环语法和执行模型理解这几条就够了TIA Portal里的SCL For循环基本格式就是FOR #i : 1 TO 16 BY 1 DO // 循环体 END_FOR;几个关键点必须先搞清楚循环变量必须是整数型INT、DINT不能用REAL。BY后面的步长可以省略默认是1反向循环写BY -1。PLC里的For循环是在同一个扫描周期内全部执行完的不是分多个周期慢慢跑。这个理解和单片机里的循环完全一致所以循环次数过大时要注意扫描周期时间。循环中如果出现数组越界或者除数为零会直接触发OB的停止或诊断事件不是跳过出错那一下那么简单。正因为For循环在一个周期内执行完它特别适合做“扫描类”任务数据整理、请求登记、优先级裁决。电梯16层才循环16次扫描周期影响微乎其微。2.2 方向扫描先确定电梯“顺不顺路”写电梯调度第一步不是直接挑一个最近楼层而是先明确电梯此时的运行方向。电梯方向分三种上行、下行、静止。方向会影响哪些呼叫“值得登记”电梯正在上行时优先响应当前楼层以上、且是“上行方向”的呼叫下行呼叫通常不顺路我们可以取消或者放到反向扫描里。电梯正在下行时同理优先处理当前楼层以下的下行相关呼叫。电梯静止时哪个方向都可以但要考虑启动后的新方向。用SCL表达这个扫描逻辑可以写一个简单的“顺路检测”片段// 只扫描当前方向上方的楼层 FOR #i : Elevator_Data.CurrentFloor 1 TO Elevator_Data.MaxFloor BY 1 DO IF Elevator_Data.CallUp[#i] OR Elevator_Data.CallInternal[#i] THEN #nextFloor : #i; EXIT; // 向上扫到第一个请求就停就是最顺路的 END_IF; END_FOR;这种“带方向扫第一个”的算法用于单台电梯的顺路截梯场景非常实用。EXIT在这里起到了“提前跳出循环”的作用避免继续扫后面楼层节省不必要的计算。2.3 优先级打分模型把规则变成公式不过实际项目往往不只是“顺路第一”。优先级的判定还要把呼叫类型和距离综合起来。简单的“方向扫描加EXIT”不能满足所有场景。我会做一层“打分模型”给每个待选楼层算一个分数分数最高的楼层就是下一个目标。打分模型我通常这么设计影响因子权重值设计理由轿厢内呼30乘客已经在轿厢里响应优先级高于厅外召唤厅外召唤与方向匹配20顺路方向上的外呼优先级稍低与当前运行方向一致100电梯尽量保持一个方向走完避免频繁换向与当前运行方向相反-100反向请求在正常扫描阶段不做考虑楼层距离每层 -5同等条件下越近越优先这套权重不是拍脑袋定的。“方向权重±100”的作用是让“同方向”请求在分数上形成压倒性优势“内呼30 vs 外呼20”保证同层同时有内呼和顺路外呼时先完成轿厢内任务“距离-5”则是为了让同一方向上的近端楼层比远端楼层更容易被选中。2.4 CONTINUE和EXIT循环控制不是花架子很多初学者看FOR循环只用“干跑”不知道CONTINUE和EXIT在SCL里有多有用。CONTINUE跳过当前这个循环变量的剩余循环体直接进入下一轮。在电梯扫描里如果某层楼完全没有任何有效呼叫继续计算这层的分数就是浪费。用CONTINUE快进跳过。EXIT终止整个循环。方向扫描时找到第一个同方向楼层就可以立刻退出不需要再看更高楼层了。在完备的打分模型里因为要遍历所有楼层选出最高分EXIT用得少但如果你写的调度策略是“当前方向顺路优先扫到就决定”那EXIT就是性能利器。两种循环控制结合使用能让程序在“全覆盖打分”和“单方向快扫”之间灵活切换。3. TIA Portal中实现电梯调度FB块可运行代码逐段拆解3.1 先建数据蓝图全局DB设计正式写代码前我在项目里会先建一个全局DB专门用来存放电梯的请求和状态。这个DB既是PLC程序的数据中枢也是后面触摸屏联动读取和写入的“共同语言”。推荐字段大致如下全局DB: Elevator_Data - MaxFloor : INT // 总楼层数默认16 - CurrentFloor : INT // 当前楼层 - Direction : INT // 1上行-1下行0静止 - IsMoving : BOOL // 运行标志 - DoorOpen : BOOL // 门区标志 - CallInternal : ARRAY[1..16] OF BOOL // 轿内选层请求 - CallUp : ARRAY[1..16] OF BOOL // 上召请求 - CallDown : ARRAY[1..16] OF BOOL // 下召请求 - EmergencyActive : BOOL // 消防/紧急返回激活 - EmergencyFloor : INT // 紧急返回的目标楼层如1层 - TargetFloor : INT // 调度选出的目标楼层 - BestScore : INT // 调试用显示最高分 - bHmiEnable : BOOL // 触摸屏上的“允许自动调度”总开关这里有个细节CallInternal/CallUp/CallDown直接用数组触摸屏和HMI都可以按数组方式访问不需要额外做数据搬运。如果你的HMI不支持直接读写PLC侧的优化DB数组后面我会讲到怎么处理。3.2 FB接口设计把变化隔离在接口层电梯调度我习惯用FB写不写FC。原因很简单FB自带背景DB可以在背景DB里保存计时器实例和中间状态多次调用时互不干扰。接口我设计得尽量清爽FUNCTION_BLOCK FB_ElevatorCtrl VAR_INPUT bEnable : BOOL; // 调度使能 bSimMode : BOOL; // 演示模式用内部定时器模拟电梯移动 END_VAR VAR // 循环扫描临时变量 i : INT; callWeight : INT; dirWeight : INT; distance : INT; score : INT; bestScore : INT; bestFloor : INT; hasCall : BOOL; // 演示运动用定时器 simTimer : TON; doorTimer : TON; END_VAR接口只留两个输入bEnable总使能开关bSimMode演示模式开关。实际项目里输入还可以增加当前楼层位置反馈、门区信号、上下限位、变频器运行反馈等。但核心调度算法的内部变量不需要暴露到接口层这样以后换IO点只改调用处不碰FB内部逻辑。3.3 核心调度代码For循环扫描加打分这一段是整个调度块的核心我一行行拆开讲。// ---------- 调度主逻辑 ---------- IF NOT #bEnable THEN RETURN; END_IF; // 1. 紧急请求绝对优先 IF Elevator_Data.EmergencyActive THEN Elevator_Data.TargetFloor : Elevator_Data.EmergencyFloor; Elevator_Data.Direction : 0; Elevator_Data.IsMoving : FALSE; RETURN; END_IF;紧急请求强制优先这是电梯行业里的硬规矩。消防时电梯必须停到指定层并开门任何正常调度请求都靠边站。这段代码放在调度开头就是为了保证不管前面扫描结果如何紧急状态下都只有一个目标。// 2. 电梯静止且没有目标时执行一次全楼层扫描 IF NOT Elevator_Data.IsMoving AND Elevator_Data.TargetFloor 0 THEN #bestScore : -32767; #bestFloor : 0; #hasCall : FALSE; FOR #i : 1 TO Elevator_Data.MaxFloor BY 1 DO // 2.1 汇总该楼层呼叫权重 #callWeight : 0; IF Elevator_Data.CallInternal[#i] THEN #callWeight : #callWeight 30; END_IF; IF Elevator_Data.CallUp[#i] AND Elevator_Data.Direction 0 THEN #callWeight : #callWeight 20; END_IF; IF Elevator_Data.CallDown[#i] AND Elevator_Data.Direction 0 THEN #callWeight : #callWeight 20; END_IF; IF #callWeight 0 THEN CONTINUE; END_IF; #hasCall : TRUE; // 2.2 方向权重 IF Elevator_Data.Direction 0 OR (Elevator_Data.Direction 1 AND #i Elevator_Data.CurrentFloor) OR (Elevator_Data.Direction -1 AND #i Elevator_Data.CurrentFloor) THEN #dirWeight : 100; ELSE #dirWeight : -100; END_IF; // 2.3 距离权重 #distance : ABS(#i - Elevator_Data.CurrentFloor); #score : #callWeight #dirWeight - #distance * 5; // 2.4 记录最高分 IF #score #bestScore THEN #bestScore : #score; #bestFloor : #i; END_IF; END_FOR; // 3. 有请求就派梯 IF #hasCall THEN Elevator_Data.TargetFloor : #bestFloor; Elevator_Data.BestScore : #bestScore; IF #bestFloor Elevator_Data.CurrentFloor THEN Elevator_Data.Direction : 1; ELSIF #bestFloor Elevator_Data.CurrentFloor THEN Elevator_Data.Direction : -1; END_IF; Elevator_Data.IsMoving : TRUE; END_IF; END_IF;这段代码最核心的思路就是把“哪个楼层该去”这道选择题变成“给每个楼层算一道分”的数学题。callWeight处理呼叫类型dirWeight处理方向distance处理远近三者加权以后取最高分。For循环在这里不是简单遍历而是充当了一个全楼层“评委”。需要注意的是IF NOT IsMoving AND TargetFloor 0这个外层的条件。也就是说只有当电梯停车到位、并且当前没有既定目标时才重新扫描派梯。这样设计是为了避免电梯运行途中反复修改目标楼层造成“截梯抖动”。3.4 演示运动模拟与到站清呼逻辑真梯项目里电梯的移动由变频器和编码器反馈控制这一段的实现方式完全不同。但为了触摸屏联动演示我们需要在PLC内部模拟“电梯正在移动”的效果。最简单的做法就是加一个1秒的定时器每隔1秒把CurrentFloor向TargetFloor方向走一层。// ---------- 演示模式运动模拟 ---------- IF #bSimMode AND Elevator_Data.IsMoving THEN IF Elevator_Data.CurrentFloor Elevator_Data.TargetFloor THEN #simTimer(IN : TRUE, PT : T#1S); IF #simTimer.Q THEN #simTimer(IN : FALSE); Elevator_Data.CurrentFloor : Elevator_Data.CurrentFloor Elevator_Data.Direction; END_IF; ELSE // 到达目标楼层清呼、开门、复位 #simTimer(IN : FALSE); Elevator_Data.IsMoving : FALSE; Elevator_Data.CallInternal[Elevator_Data.TargetFloor] : FALSE; Elevator_Data.CallUp[Elevator_Data.TargetFloor] : FALSE; Elevator_Data.CallDown[Elevator_Data.TargetFloor] : FALSE; Elevator_Data.DoorOpen : TRUE; #doorTimer(IN : TRUE, PT : T#2S); IF #doorTimer.Q THEN #doorTimer(IN : FALSE); Elevator_Data.DoorOpen : FALSE; Elevator_Data.TargetFloor : 0; END_IF; END_IF; END_IF;这段代码在真实项目里不会这么写但在演示和调试阶段非常实用。它让我不依赖真实变频器就能把整个调度流程“跑起来”触摸屏上的楼层数字会自己动肉眼就能验证调度是否正确。这里还有一个关键细节清呼。电梯到站后必须把该楼层对应的内部呼叫、上召、下召复位掉否则请求会一直存在电梯会在同一层反复开门。复位要结合当前方向和请求类型比如电梯上行到达5层那么5层的上召可以清但5层的下召必须保留留给电梯换向下行时响应。3.5 边界情况首尾楼层、同层呼叫与换向边界处理是电梯调度最容易翻车的地方。我列几个典型场景电梯在1层所有请求都在1层。这时候distance0目标就是当前层应该直接开门清呼不能出现“电梯试图下楼”的荒谬动作。电梯在最高层16层向上运行此时如果16层有上召因为16层已经是顶层上召按钮通常物理上就不会安装。但程序要做好防护CallUp[16]即便为TRUE也应该忽略因为不可能向上走了。电梯从6层上行去8层途中有人在7层按了下召。7层是下行方向按正常调度“反方向-100分”会被忽略但当电梯运行到8层、清呼完成之后如果7层下召仍然有效就应该在下一轮扫描中进入下行队列。这些边界条件不是锦上添花而是决定程序能不能长期稳定运行的关键。我在真实项目里见过太多因为边界处理不够导致电梯到了顶层还继续往上走或者到站后不消号重新跑一次的情况。4. 触摸屏联动演示MTP/KTP系列HMI工程配置4.1 屏与PLC的数据交换机制电梯调度做完了不能总靠在编程软件里监控DB看数据。触摸屏联动是项目验收时最直观的部分。西门子触摸屏和PLC在TIA Portal里属于同一个工程体系组态思路本质上就是“建立变量连接、把PLC里的变量拖到画面上”。KTP系列面向Basic Panel直接在TIA Portal WinCC V16/V17里组态。MTP1000这类Unified面板需要使用WinCC Unified整体思路一致但工程文件和画面模型有差异。下面以KTP700为例说具体操作如果你用的是MTP系列把“HMI变量表”和“画面编辑器”的位置换一下就可以。触摸屏和PLC之间走Profinet或者PROFIBUS通讯HMI通过变量通道读取/写入PLC的DB、M区、I/O区。关键点在于HMI变量必须和PLC变量建立一一对应关系。最省事的方式是在HMI变量表里直接添加PLC变量的路径例如PLC变量: Elevator_Data.CurrentFloor HMI变量: Elev_CurrentFloor这样读写关系就绑定了画面上的显示组件指向HMI变量即可。4.2 创建电梯状态显示画面工程里新建一个HMI画面名称建议叫“电梯调度演示”。画面大致分四个区域顶部状态区显示当前楼层、目标楼层、运行方向、门状态。中部竖井模拟区用16个指示灯代表1到16层当前楼层那一个亮起。左侧轿内选层区16个按钮模拟轿厢内按楼层。右侧厅外召唤区每层两个按钮分别代表上召和下召首层只有上召顶层只有下召。当前楼层的显示是最容易的直接拖一个IO域或者文本域关联Elev_CurrentFloor。为了更直观我还习惯在竖井模拟区放16个圆角矩形每个都用一个“可见性”动画透明度由“当前楼层是否等于该层号”决定这样屏幕上就能看到一个小光点随着电梯升降移动。这个“可见性动画”的做法比用多层子画面切换更稳定而且几乎不消耗HMI性能。16个图形控件每个都关联一个公式Elev_CurrentFloor 1、Elev_CurrentFloor 2……实话说组态时工作量稍微大一点但运行效果非常直观。4.3 内部呼叫与外部召唤的触摸输入设计轿内选层按钮组态时可以批量实现。在KTP画面的按钮属性里事件页签选择“单击”动作功能选择“SetBit”变量指向Elevator_Data.CallInternal[1]到CallInternal[16]。每个按钮配一个指示灯指示灯用“位可见性”关联对应的请求位这样按下去以后按钮会高亮或者变色表示该楼层呼叫已被登记。厅外召唤按钮也类似但变量分别指向CallUp[1..16]和CallDown[1..16]。这里注意一个细节按钮的“按下”动作和“释放”动作不要都写变量操作否则可能产生重复置位或抖动。我只在“按下”事件里做置位释放事件不做操作这样最干净。如果你嫌16个按钮一个个组态太累可以使用TIA Portal的“变量批量创建”功能。先在HMI变量表中建一个变量数组或者按命名规则批量生成变量再把按钮的“数组元素索引”绑定到变量数组的下标上。但这个操作稍微绕一点新手建议还是规规矩矩复制粘贴十分钟就能点完。4.4 优化DB、绝对寻址与HMI常见连接问题这里分享一个实战中容易踩的坑S7-1200/1500默认使用优化DB访问也就是变量没有固定偏移地址只有符号名。传统HMI组态里有些老版本WinCC或者第三方屏要求你填绝对地址比如DB1.DBW0这时候优化DB会显示离线或者在线监控时看不见数据。解决方法是二选一在DB属性中取消勾选“优化的块访问”改成标准访问。但这样会失去符号寻址的便利而且一部分高级语法特性可能受影响。如果是KTP/MP系列和TIA Portal同版本保留优化DB即可HMI变量里直接拖拽PLC变量路径不需要也不应该手动填绝对地址。如果你的屏幕比较老或者第三方屏那就要把数据单独做一份“非优化DB”用于HMI交互PLC内部跑调度就用优化DB。两块区域之间用MOVE指令同步这种隔离方案是工程界最稳妥的做法。触摸屏连不上时优先检查三件事IP地址是否同一网段PLC与HMI是否都处于RUN状态HMI变量是否指向了正确的PLC连接和DB。别小看这三件事我调试时遇到的触摸屏问题八成都是IP冲突或者变量路径指错了。5. 调试验证与实战踩坑文档里不会写的事5.1 用PLCSIM验证For循环调度逻辑TIA Portal的PLCSIM可以完美仿真S7-1200/1500所以电梯调度逻辑在没接真实硬件之前就能验证。我推荐的做法是在项目里建一个全局DB专门用来“注入测试请求”比如手动置位几个呼叫位然后观察TargetFloor和Direction的变化。具体步骤把程序下载到PLCSIMCPU切到RUN-P。打开“监控与强制表”把Elevator_Data.CallInternal[5]强制为TRUE。观察调度结果此时CurrentFloor1、Direction0、TargetFloor应该自动变成5。再把CallUp[3]也置TRUE观察在电梯未动之前TargetFloor是否会从5变成3。第4步是个有趣的测试当前电梯静止在1层内呼去5层同时3层有人上召。按“方向权重”模型两个请求都是同方向但3层距离近得分更高所以调度会优先选择3层顺路接上3层乘客再去5层。这就是典型的“顺路截梯”逻辑验证。5.2 常见错误一数组下标越界与扫描周期For循环最常见的故障是数组越界。比如你把MaxFloor从16改成24但数组定义还是ARRAY[1..16]For循环运行时第17次访问就直接报错CPU进入停机状态。TIA Portal对这类错误诊断比较明确但预防更重要数组维度和循环边界要来自同一个地方。另一个容易被忽略的问题是For循环会占用扫描周期时间。电梯楼层16层循环体就扫16次CPU负荷完全在可接受范围内。但如果你把同样的套路用在“遍历几百个配方参数”上每次扫描周期多出几毫秒对高速设备来说就是事故。遇到大数据量遍历时可以考虑分周期扫描或者把For循环改写成“一次周期只处理几个元素”的节流逻辑。5.3 常见错误二FB背景DB的实例选择使用FB必然涉及背景DB。电梯调度如果只有一栋楼一台电梯那单实例FB就够了。但如果项目是双电梯并联你要么新建两个FB实例分别挂两个背景DB要么在FB里用多重背景的方式管理。多重背景的好处是背景DB集中成一个方便整体上传下载缺点是变量路径会多一层程序阅读稍难。我给的建议是单梯项目用单实例双梯并联动不动就上多重背景。但不管哪种方式背景DB的变量要命名清晰别出现Instance_Data_1这种没有业务含义的名字。调度块就是Elev_Ctrl_Left、Elev_Ctrl_Right一眼就分得清。5.4 从演示到真梯安全功能绝不放进For循环最后必须强调一点本文展示的调度逻辑属于功能控制层负责“该去哪一层”。但真实电梯项目里安全功能——比如门锁回路、超速保护、上下限位、轿厢安全钳动作——绝对不能放在调度逻辑里用软件判断了事。这些必须通过独立的安全回路、安全PLC、安全继电器去实现。我在演示项目里可以把DoorOpen直接放进DB里随便置位但在真实项目中门状态信号来自门锁继电器回路PLC逻辑只能读取不能绕过安全硬件直接控制。写调度程序时务必将“舒适/效率控制”和“安全保护”分开。这既是行业规范也是职业底线。还有一个经验逻辑写完以后至少要在PLCSIM上跑一整天的随机呼叫测试让脚本随机置位各种呼叫组合确认电梯在任何情况下都不会出现“上着上着突然换向下行”“到站不开门”“请求永远消不掉”这类问题。很多随机组合是手测很难覆盖到的自动化压力测试才是验证调度算法可靠性的正路。这个习惯我几乎在每个调度类项目里都会用效果远好于人工一个个按钮去点。