2020年西门子智能制造挑战赛我选的赛题是“6部10层电梯程序以太网通信”。拿到题目我第一反应是单梯控制根本不难难的是6部电梯在以太网环境下的协同。每台PLC既要管好自己轿厢的启停、开关门还要实时知道另外5台梯的位置、方向、呼梯状态然后把外面的楼层呼叫分给最合适的电梯。这篇文章不写参赛报告那种套话我就按实际做项目的顺序把赛题拆解、通信方案、单梯逻辑、群控调度、调试踩坑完整讲一遍给正在准备类似比赛或者做电梯群控项目的朋友做个参考。1. 赛题拆解6部10层电梯真正考的是“群控”和“通信”1.1 先看清这个项目的基本盘电梯控制本身是PLC课程的经典案例。10层楼内呼按钮10个外呼按钮18个1层只有上呼、10层只有下呼中间层上下呼各一个轿厢上行/下行、开关门、平层定位、限位保护再加一个方向指示灯和楼层显示。这些功能单拎出来用梯形图写一个功能块就能完成。但赛题把规模扩到了6部。这就带来两个质变输入输出点爆炸单梯的内外呼、限位、门锁、平层信号加起来接近50个点6部就是300个点左右。如果用一台PLC硬撑CPU型号、扩展模块、接线量都会被拉得很难受。控制逻辑从“单机顺序控制”变成“多人协作调度”外面一个人按了5楼上呼究竟派哪台梯去这不再是一台电梯自己内部的任务记录而是要在6台电梯之间找一个“最合适”的响应者。我当时选择的架构是每部电梯对应一台S7-1200 PLC6台PLC通过工业以太网互联另配一台触摸屏作为监控中心。这样每台PLC的I/O点数保持在单梯规模程序完全复用通信则用西门子S7协议解决。1.2 比赛模型的运行方式和I/O信号特点西门子这类比赛电梯通常不是真的现场搭一台建筑而是有专门的电梯仿真模型或者虚拟调试环境。模型上每个楼层有呼梯按钮和指示灯轿厢位置通过限位开关/接近开关反馈给PLC甚至有的模型直接用数码管显示楼层。一个很容易被新手忽略的点是模型的“时间加速”。为了在几分钟内演示出电梯调度效果模型的楼层移动速度比真实电梯快很多有时候1秒现实时间就对应1层楼。这导致PLC程序里的定时器逻辑、通信刷新周期都要重新校准不能照搬真实电梯项目里的时间常数。后面我会专门讲这个坑。I/O信号上要注意的是模型上的外呼按钮一般不是自锁型按下瞬间给出一个脉冲程序里必须要做“呼梯记忆”把这次呼梯请求存起来等电梯去响应。内呼按钮同理。如果不做记忆等电梯走到那层按钮早已释放直接就漏掉了。2. 网络架构6台PLC如何用以太网“互相说话”2.1 为什么选S7通信而不是PROFINET或RS485多电梯并联通信有几种路线。RS485串行通信要自己定义轮询机制、处理报文和校验还要处理多主站冲突比赛周期里光调通信就耗掉大半时间。而西门子的S7通信是PLC和PLC之间最经典的点对点协议TIA博图里组态两个CPU之间的S7连接然后调用PUT/GET指令就能把数据写进对方的DB块简单粗暴。PROFINET理论上也能做但PROFINET更适合IO设备、实时运动控制的场景用来做PLC之间的数据交换反而复杂还要考虑RT/IRT的实时性设置。比赛环境里的6台PLC都是平等的控制站不是主从的IO设备所以我最终选了S7单边通信PUT/GET。这里我踩过的第一个坑是S7-1200的DB默认是“优化访问”模式这种DB块在S7通信里无法读出。想把DB给伙伴PLC读必须右键DB属性勾掉“优化块访问”否则通信建了也读不到数据。很多人的程序逻辑没问题卡就卡在这。2.2 通信数据块设计先定“聊天协议”再写代码多PLC通信最容易犯的错是程序写完了才开始想“我要传哪些数据”。正确做法是先定义好公共数据块相当于几个人聊天前先约定话术。我把公共数据块分成6个区域每个区域对应一台电梯每台PLC只负责写自己的区域、读其他5个区域。区域里放的关键状态字段字段数据类型说明CurrentFloorINT当前楼层DirectionINT0停止1上行2下行RunModeBOOL运行中/空闲DoorOpenBOOL门状态IDoorReq[1..10]BOOL数组轿厢内呼记录HallCallUp[1..9]BOOL数组各层上呼记录HallCallDown[2..10]BOOL数组各层下呼记录TargetFloorINT当前目标楼层IsAvailableBOOL是否可被分配新任务这个结构里有几个细节Direction用INT而不是BOOL是为了后续写群控算法时可以直接用数值比较内外呼分开记录内呼是轿厢内乘客选的楼层外呼是楼道上的人按的按钮两类请求在调度里优先级完全不同TargetFloor保存当前轿厢正在执行的目标防止群控算法给同一台梯重复指派两个不同方向的楼层。通信代码里每个周期做一次PUT和一次GET把自己区域写到伙伴对应区域同时读回对方的区域。因为6台PLC都要互相交换数据最朴素的写法是每台PLC写5条PUT、5条GET。但这样程序块比较多我后来在OB30100ms循环中断里统一调用通信指令避免通信在普通OB1里被扫描周期的不稳定影响。2.3 IP规划与通信参数设置IP规划一定要提前定。我用的是192.168.0.11到192.168.0.16子网掩码255.255.255.0。每台PLC除了IP还要设置好设备名称。S7连接要指定伙伴的IP、机架号0和插槽号按CPU实际插槽填S7-1200一般是1。在TIA博图的网络视图中最省事的办法是先拖出6个S7-1200 CPU在“连接”表里手动添加“S7连接”每个连接选择本地ID和伙伴ID然后勾选“允许从远程伙伴访问”。程序里PUT/GET块的参数里要把通信的DB编号、远程地址和长度写清楚。S7通信单次传输有长度限制如果后续数据量超出一条DB区域拆成多条PUT/GET指令来传。还有一个与通信强相关的细节通信质量的监控。我建议在公共DB里放一个“通信心跳”字段每台PLC把自己的一段计数值周期性写入其他PLC如果发现某台电梯的心跳值长时间不变就在HMI上弹一个“通信中断”提示否则比赛中出现过一次电梯不响应调度全场没人知道是哪台梯的通信断了排查起来特别痛苦。3. 单梯控制把一台电梯做成可靠的状态机3.1 电梯状态机的搭建思路单梯控制我用的是一个标准的状态机IDLE电梯静止等待内呼或分配到的外呼RUN_UP上行中持续判断是否在目标层停靠RUN_DOWN下行中DOOR_OPEN平层后开门DOOR_CLOSE关门FAULT急停或故障禁止运行方向判定是单梯逻辑里最关键的一环。比赛模型里没有轿厢内载荷传感器所以方向优先级很纯粹电梯处于IDLE时如果有内呼先响应如果没有内呼再找外呼所有请求都在当前楼层上方就上行都在下方就下行上下都有先走当前运行方向没有运行方向时以第一个登记的请求方向为准。这里要给个具体例子。1号梯停在4层当前无请求。此时2层有人按了下呼去1层方向5层有人按了上呼。电梯应该先往哪走我当时的规则是先看内呼再看外呼的响应价值。2层下呼和5层上呼都是新请求没有顺路关系那就固定选“最早登记的请求”。如果两个请求几乎同时到达选离当前层近的。这种策略虽然不保证全局最优但能保证行为可预期比赛时不容易出幺蛾子。3.2 平层、限位与门锁互锁电梯模型中平层信号通常来自每层的限位开关。程序里需要检测“上一层限位触发”到“下一层限位触发”的过程来更新当前楼层。要注意的是模型运行时电梯在两层限位之间的时间可能短得可怜如果扫描周期过长楼层号会跳变甚至漏掉。所以我在OB1里加了一个高速计数累加逻辑每当检测到某个限位信号的上升沿就更新当前楼层号并同时清除该层对应的内呼记录和外呼记录。这比每个扫描周期去轮询“当前层在哪”可靠得多。门锁互锁这块必须从严。不管比赛怎么宽松只要门没有完全关好电梯就不能启动如果电梯在运行中门锁信号突然断开必须立即紧急停止不能有任何例外。我在FAULT分支里把所有输出全部清零同时把HMI上的故障状态置位等手动复位后才允许重新投入运行。往上层和下层极限位置还要加上失速保护模型虽然不会真的冲顶但程序里该有的边界必须写全。3.3 呼梯记忆与重复登记的处理模型上的按钮是瞬时电平所以每个呼梯信号都要做上升沿检测置位记忆。我单独做了两个功能块一个处理内呼一个处理外呼。内呼只有轿厢内的10个按钮外呼则要跟群控调度配合。单梯自己记忆呼梯是一回事群控系统里外呼的归属是另一回事。比如5楼的上呼被分配给了3号梯那这个呼梯信号应该由3号梯的程序登记而不是所有电梯都登记。我在群控逻辑里加了“呼梯归属标志”数组某个外呼一旦被分配给某台梯其他电梯就不会再响应它直到3号梯完成该层的停靠才把标志清掉。这样避免了外面按一下6台电梯同时在5楼排队停靠的尴尬局面。4. 群控调度让6台梯学会分工合作4.1 从“区域划分”到“代价函数”最简单的6梯调度策略是按楼层分区比如1号梯管1~2层2号梯管3~4层……但真实情况是早上高峰时大家都从1楼往上走管高层的电梯闲死管低层的电梯忙死。比赛也一样固定分区非常容易在演示时露出短板。我采用的是动态代价函数法。每次有新的外呼产生时群控程序遍历6台电梯为每台梯计算一个“响应代价”选代价最小的去响应。代价函数不追求理论最优但要能反映“哪台梯去更合理”代价 距离惩罚 方向惩罚 任务量惩罚 顺路奖励距离惩罚就是 |当前楼层 - 呼梯楼层|方向惩罚用来处理“电梯正在往上跑而请求在下面”这种情况。具体地如果呼梯楼层不在电梯当前运行方向的前方代价加50如果呼梯方向与电梯当前运行方向不一致代价加80这个数值远大于普通楼层差基本上可以避免派一台正在上行的电梯去下面接人。任务量惩罚统计这台梯当前已经登记的内呼和外呼数量每多一个任务加10这样不会让某台梯攒一堆任务而旁边电梯空着。顺路奖励则是如果呼梯楼层正好在电梯的前进路径上且方向一致减15。可以用SCL在功能块里这样实现FOR #i : 1 TO 6 DO #tempCost : ABS(#CurrentFloor[#i] - #CallFloor) * 1; // 方向惩罚 IF #CallFloor #CurrentFloor[#i] AND #Direction[#i] 1 THEN #tempCost : #tempCost 50; END_IF; IF #CallFloor #CurrentFloor[#i] AND #Direction[#i] 2 THEN #tempCost : #tempCost 50; END_IF; // 方向一致性 IF (#CallDir 1 AND #Direction[#i] 1) OR (#CallDir 2 AND #Direction[#i] 2) THEN #tempCost : #tempCost - 15; END_IF; // 任务量惩罚 #tempCost : #tempCost #TaskCount[#i] * 10; IF #tempCost #minCost THEN #minCost : #tempCost; #chosen : #i; END_IF; END_FOR;这里有一个必须注意的点调度计算必须用通信数据块里的“伙伴状态”而不是本机自己的引脚。也就是说所有电梯的实时状态先通过PUT/GET刷新到公共区域群控程序在读完公共区域之后再做决策。如果直接拿本地变量做调度等于只用了一台PLC的信息群控就失去了意义。4.2 顺路捎带与防震荡机制比赛中比较秀的操作是“顺路捎带”。电梯上行经过5楼时如果此时5楼刚好有人按了上呼而电梯的目的地在5楼以上那就应该让电梯在5楼停一下把人带上。捎带的判断规则是呼梯楼层在当前运行方向上呼梯方向与电梯运行方向相同电梯当前目标楼层与呼梯楼层位置关系一致上行时目标在呼梯楼层上方该呼梯当前还没有被分配给其他电梯。满足这4条电梯到那层就正常平层、开门顺路完成外呼。这个逻辑让整体效率提升非常明显演示时基本看不到电梯“明明经过却不接人”的情况。比捎带更难处理的是防震荡。所谓震荡就是5楼上呼刚分配给1号梯1号梯正往上赶此时4楼又有人按了上呼代价函数算出来2号梯更近如果系统立刻把4楼的呼梯也派给2号梯没问题。但如果算法写得激进连5楼的呼梯都可能被重新计算、改派给2号梯那1号梯刚跑到一半就被“取消任务”所有电梯都处于“算了半天又重新算”的状态现场看起来就是6台梯来回折腾、没有一台果断去接人。我的解决方法是给每个外呼加一个**“已分配锁”**。一个外呼一旦被分配给某台电梯就置位对应的归属标志其他电梯看见该标志后直接在调度时跳过这个呼梯。只有被分配的电梯真正到达该层、开门、再关门之后才把归属标志清除。这样即使后续出现了更近的电梯呼梯归属也不会随意变动保证了系统行为的稳定。4.3 同向响应、反向等待与策略边界还有一种常见场景一台电梯正上行去接7楼的请求此时4楼有人按了上呼4楼也在上行路径上那这单应该明确响应。但如果4楼按的是下呼电梯当前上行此时让电梯在4楼停一下就不划算——因为电梯上去之后还得掉头下来等于多跑一趟。对于这种“方向相反”的呼梯我的策略是不捎带、不分配把它留到电梯完成当前任务、进入IDLE状态后再重新参与分配。也就是说群控调度只负责把请求分派给“当前空闲或顺路”的电梯反向请求一律交由下一轮决策。这样做的好处是避免了电梯为了一个反向呼梯频繁换向导致上方的乘客等得更久。调度策略里还必须防两个边界情况一是同一时刻多个外呼同时到达程序里要按楼层顺序或按呼梯时间顺序逐条处理不能漏二是6台电梯都在忙时新呼梯计算出来的代价都是“前方无顺路”此时策略很简单挑任务量最少的电梯硬塞给它让它跑完当前任务后再去接。比赛模型规模下总能等到某台梯空闲不用额外做复杂的排队系统。5. 调试与仿真最容易翻车的几个环节5.1 PLCSIM多PLC联调时的连接问题比赛前如果只能在软件里验证就会碰到PLCSIM的“多实例”问题。TIA博图可以同时打开多个PLCSIM实例但每个实例下载时要对应好CPU型号和IP地址。稍不留神6台CPU全部下载到同一个仿真实例上后下载的覆盖先下载的通信连接直接失败。我的建议是在TIA项目里建立6个不同的S7-1200站点每个站点单独命名下载时通过“目标设备”下拉框明确选中对应PLC。同时仿真环境下S7通信的连接状态不一定稳定可以在程序里检查系统诊断缓冲区或者用“通信状态字”来判断连接是否建立。如果发现PUT/GET一直报错优先排查三点伙伴IP是否填对、伙伴DB是否关闭了优化访问、连接表里的机架/插槽是否正确。另外如果现场只有一套真实CPU但题目要求演示6部电梯那就不必死磕“6台真实PLC”。可以在单台PLC里建6个电梯FB实例用6组不同的背景DB承载状态再用内部共享DB模拟“以太网数据交换”的效果。这种方式对内存要求不高对于验证群控算法完全够用现场效果也不差。5.2 博图防火墙与连接下载连接真实PLC时电脑和PLC之间明明网线都通但TIA就是扫描不到设备十有八九是Windows防火墙拦了。需要把TIA相关的端口放行或者临时关闭防火墙。如果你用的是虚拟机跑博图网络模式要选“桥接”不能选NAT否则虚拟机里的IP跟PLC不在同一网段。这里我想强调一个更隐蔽的坑电脑上多块网卡可能导致地址幻觉。比如电脑连了WiFi又插了网线连PLC博图在扫描时可能把请求发到错误的网卡上。最简单粗暴的解决方法是拔掉所有不相关的网络连接只保留一条到PLC的物理链路然后给这块网卡设一个和PLC同网段的IP。不要图省事让系统自动获取IP比赛现场没有DHCP服务器自动获取的地址多半跟PLC对不上。5.3 HMI监控把6台梯的状态全摊在桌面上群控调试没有HMI几乎寸步难行。你需要一眼看到6台电梯都在哪个楼层、什么方向、有没有门锁故障、每个外呼是否分配到了正确电梯。我用西门子精智面板做了几个页面每页显示3台电梯的状态灯和楼层数还有一个总览页显示6个电梯的实时位置和方向箭头。如果直接用威纶通触摸屏它有导入S7-1200变量标签的功能可以把TIA里的PLC变量表直接导入避免手工输入地址出错。但要注意触摸屏和PLC的通信类型要选对比如“Siemens S7-1200”还是“Siemens TCP/IP”选错会显示通信超时。调试时我把所有关键变量集中到一个HMI页面上包括公共区域的每个外呼归属标志、每台电梯的目标楼层、当前方向、门状态。这样跑一段演示程序就能看出调度算法在某个特定呼梯组合下是不是卡住了、或者两台梯同时抢一个呼梯。问题定位速度比对着PLC在线变量监视快很多。5.4 时间加速模式下的调度抖动前面提过比赛模型一般有加速比楼层切换很快。这带来一个群控特有的问题如果电梯正在快速上行过程中群控算法还在反复读取它的“当前楼层”作为计算依据代价函数的结果会随位置变化而跳动。比如呼梯在5楼1号梯正在从4楼往5楼加速跑这时候2号梯从3楼出发代价函数可能一会儿觉得1号梯近一会儿觉得2号梯近。如果不做任何锁定系统可能会在几秒内连续切换响应电梯最终1号梯收到“去5楼”指令刚启动又被2号梯“抢单”现场非常难看。我的处理办法是调度决策的启动条件必须是“电梯处于IDLE状态”或“外呼方向与电梯运行方向一致且位置在前进路径上”一旦决策完成就写死归属标志不再计算该呼梯的二次分配。这样即使模型跑得再快也不会频繁改主意。同时把通信刷新周期设为固定的100ms尽量让6台PLC看到的其他电梯状态是同一时间切片。6. 复盘与经验什么样的思路能笑到最后6.1 先做一部梯再做六部梯比赛时间非常紧张最忌讳一上来就写群控。我的实施顺序是先搭好一台电梯的所有I/O映射调通单梯的呼梯记忆、方向判定、平层停靠、开关门。单梯稳定运行后复制出6个FB实例验证6套背景DB是否独立。再搭通信层先让两台PLC通过PUT/GET互相传一个字节通了以后再扩展成6台。最后才写群控调度算法用HMI观察运行效果。这个顺序的价值在于每一层功能都有明确的验证点。如果群控调度出问题你至少可以确定是调度逻辑的锅还是底层通信或单梯逻辑的锅。我曾经见过有队伍先把群控算法全都写好最后单梯无法稳定平层整个演示直接崩掉。6.2 数据流和“不信任”原则6台PLC互相通信时千万别默认对方传来的数据都是合理的。我在调度里对所有伙伴状态做了限幅楼层数值必须在1到10之间方向值必须在0到2之间如果收到非法数据就按无效处理。这样哪怕某台PLC程序跑飞了其他电梯也不会因为这个异常数据做出离谱的调度动作。还有一个安全边界群控调度不能凌驾于单梯安全逻辑之上。比如某个外呼被分配给一台正在故障中的电梯群控算法应该在检查“IsAvailable”标志时直接跳过它绝不能让故障电梯被激活去响应呼梯。安全互锁的优先级永远是门锁 限位 故障 单梯方向逻辑 群控调度。6.3 给后来者的一点建议比赛里“稳定”比“聪明”更值钱。一个简单可靠、所有呼梯组合都能正确响应的群控策略远比一个理论上效率极高但可能在边界条件卡死的复杂算法更受评委认可。我当时在算法里预留了很多调试变量比如每台电梯的当前代价、每个外呼的归属状态全部同步显示在HMI上这对现场答辩太有帮助了——评委问“你这个决策依据是什么”直接指着屏幕说就行。另外做好备份管理。TIA博图项目在比赛期间会频繁修改我每天结束前会把项目另存为带日期的版本。有一次调群控参数把通信DB改乱了回退到前一天版本直接恢复省了大量重写的时间。如果你准备参加类似赛事我建议多花时间在异常情况测试上全楼层同时呼梯会怎样所有电梯同时接到内呼会怎样某台电梯通信中断会怎样把这些边界情况跑一遍你的程序才能在演示时真的稳住。群控电梯最有意思的不是某台梯的启停而是整套系统在乱七八糟的呼梯组合下依然能冷静、有序地把任务收敛完——这个感觉值得你在比赛现场亲身体会一次。