前阵子有朋友问我说准备西门子杯比赛想拿“三部十层电梯”做题目用博图TIA Portal V15.1写PLC程序再带上WinCC画面不知道从哪里下手。这个项目我比较熟悉也算得上是竞赛圈和毕业设计里的经典款了。你仔细想想三部电梯和一部电梯的差别不是简单的数量乘以3而是多了“群控调度”这层逻辑这才是比赛真正想考你的地方。再加上博图V15.1搭配WinCC做上位机监控整套下来既能体现PLC编程基本功又能展示工程组态能力对准备比赛的学生、做毕设的人或者刚进电梯行业做调试的工程师都是很值得吃透的案例。这篇文章我就按实际做项目的思路把整体框架、核心逻辑、实操步骤和常见的坑都摊开讲尽量把为什么这么做也说清楚方便你直接照着搭自己的方案。1. 整体设计思路为什么三部电梯难度上了个台阶1.1 从单梯逻辑到群控调度到底多了哪些事先说单部电梯的逻辑。正常情况下你只要处理轿厢内呼、楼层外呼、运行方向、平层、开关门这些内容。比如电梯在5楼向上走6楼有人按了上行那这趟就可以顺路停如果这时候8楼有人按下行电梯就不能立刻掉头得先把上面顺路的请求都处理完再反方向折返。这些规则用梯形图或者SCL写出来本身不算难真正麻烦的是多个请求同时到达之后“先响应谁、去哪接人”的优先级判断。到了三部电梯事情就变了。同样是某个楼层有人按了外呼程序要决定的是“让哪一部电梯去接”。这个决策如果做得不合理就会出现两部电梯同时跑过去、剩下两部在角落里闲着的情况人一多就乱套。所以在项目一开始就要定好调度策略这属于群控的核心内容。常见的做法有几种固定分区1号梯负责1到4层2号梯负责5到7层3号梯负责8到10层。优点是好写互不干扰缺点是某部电梯坏了或者某个区域人多其他梯帮不上忙。最小等待时间每次有外呼程序计算每部电梯响应这个请求大概要多久取时间最短的那部去。计算时要考虑电梯当前楼层、运行方向、是否顺路。顺向捎带在调度基础上再加一层判断如果电梯正在经过某个楼层且方向一致就顺便停一下提高效率。比赛里的三部十层电梯我最推荐“最小等待时间加顺向捎带”这个组合。固定分区虽然稳但体现不出调度算法的设计能力拿高分比较难。动态分配写起来也没那么可怕后面我会给你一个可落地的思路。1.2 为什么选博图V15.1加WinCC这对组合博图V15.1是目前市面上特别常见的版本对S7-1200和S7-1500都支持得非常好。相比老一代的Step7加WinCC flexible组合博图最大的优势就是同一个工程里同时管理PLC和HMI变量表可以共享。你在PLC里建好的变量WinCC画面直接引用不用像以前那样两边各自建变量、再手动对地址省掉了大量容易出错的工作。而且V15.1这个版本很成熟网上资料多比赛时也常见。如果你用V16或者V17打开V15.1的项目会面临升级转换的问题有时候转换到一半就报错。反过来用V15.1也打不开更高版本创建的项目版本锁死非常耽误事。我建议你在准备这台电脑的时候就统一好环境最好只装一套博图V15.1并确认WinCC组件是Professional级别因为很多基础版WinCC不支持高级画面功能做监控会很吃力。注意博图的安装路径和项目保存路径尽量不要放到中文文件夹里。我之前见过有人项目名就用“电梯比赛最终版”这种结果仿真的时候画面无响应折腾半天才发现是路径编码问题。英文路径虽然看着不亲切但能保平安。1.3 系统整体架构与I/O规划方式三部十层电梯的系统架构从底往上分三层设备层按钮、行程开关、平层感应器、变频器、接触器、指示灯这些。控制层S7-1200或者S7-1500 PLC负责所有逻辑运算和调度。监视层WinCC画面实时显示轿厢位置、方向、内呼外呼状态、故障报警。如果你是自己搭实训台没有真实电梯机械部分一般会用模型或者仿真面板来模拟。IO分配也要跟着你的实际设备来定没有统一标准。但我给你一个通用的规划参考信号类型数量范围说明轿厢内呼按钮10个/梯每层一个常用常开点外呼上行按钮9个/梯1到9层有上行10层是顶层一般没有外呼下行按钮9个/梯2到10层有下行1层是底层一般没有平层感应器10个/梯也可以用楼层编码器替代门区/门锁信号2到3个/梯开门到位、关门到位、门锁闭合变频器控制2到3个/梯上行、下行、抱闸以及速度选择每个电梯相当于一套独立子系统所以写博图项目时强烈建议把单梯逻辑封装成一个功能块FB然后3部电梯各调用一次生成3个背景数据块。这样你只维护一套程序改逻辑时不用三份都改不容易漏这也是工程上常见的标准化写法。2. 核心逻辑拆解电梯调度算法的关键细节2.1 单梯“定向”和“顺向截梯”怎么理解我先用一个例子说明方向判断的核心。假设电梯当前在6楼正在向上运行此时4楼有上行外呼9楼也有上行外呼。按“顺向优先”原则电梯应该继续向上先响应9楼等到达顶层或者没有顺路的信号之后再折返向下这时候才会响应4楼。为什么不能立刻下去接4楼因为电梯已经在上行途中如果突然反向一来机械上不允许二来会让轿厢里的乘客搞不清方向。在程序里这个判断可以用“方向锁存加请求记忆”来实现。我一般用一个数组存储所有层楼的请求比如有两个数组上行请求数组和下行请求数组再配合轿厢内呼数组。电梯运行中每次经过一层就检查当前方向上还有没有更远的请求。如果有继续走如果没有记录为“本方向无任务”然后执行反向折返。用SCL写一个简化版的方向判断大概长这样FUNCTION_BLOCK FB_Elevator VAR_INPUT iCurrentFloor : INT; // 电梯当前楼层 bUpCall : ARRAY[1..10] OF BOOL; // 各层上行外呼 bDnCall : ARRAY[1..10] OF BOOL; // 各层下行外呼 bCarCall : ARRAY[1..10] OF BOOL; // 轿厢内呼 END_VAR VAR_IN_OUT bDirectionUp : BOOL; // 当前方向TRUE为上行 bDirectionDn : BOOL; // 当前方向TRUE为下行 END_VAR VAR iNextStop : INT; i : INT; END_VAR // 假设当前向上运行先找iCurrentFloor上一层以上的最近请求 IF bDirectionUp THEN iNextStop : 0; FOR i : iCurrentFloor 1 TO 10 DO IF bCarCall[i] OR bUpCall[i] OR bDnCall[i] THEN iNextStop : i; EXIT; END_IF; END_FOR; // 如果上面没有请求说明该折返了 IF iNextStop 0 THEN bDirectionUp : FALSE; bDirectionDn : TRUE; END_IF; END_IF;这段代码不是完整的工程代码但核心思想在这里方向判断的本质就是“扫描本方向前方还有没有请求”。等你把这段逻辑封装好单梯基本上就能跑得像个正经电梯了。2.2 三部电梯请求分配固定分区还是动态计算固定分区最常见也最好调试。你把楼层按比例切开1号梯只管某几层2号梯只管另外几层。但实际比赛中电梯不可能每层使用率都一样比如写字楼中午吃饭时间大家都在按电梯去1楼固定分区的短板就出来了。所以我更建议做动态计算。思路是每来一个新外呼程序把每部电梯响应这个请求的“预估时间”算一遍选时间最短的去响应。预估时间可以简化为这几个变量相加电梯从当前楼层到达外呼楼层所需的运行时间如果电梯当前方向与外呼方向不一致加上折返时间如果电梯已经在响应另一个任务考虑它的剩余任务时间实际写SCL时我一般不会做特别复杂的路径规划因为比赛场景里所有电梯速度都一样楼层距离也一样所以“当前位置加方向”基本能代表优先级。比如1号梯在8楼往下走2号梯在1楼停着这时候5楼有人按上行1号梯顺路在5楼下方理论上它可以带但如果从等待时间看2号梯离5楼只有4层且待机状态可以立即出发那2号梯可能更快。这个决策就得让程序算出来而不是靠人拍脑袋。群控调度的分配结果还要考虑到“不能重复派梯”。当3号梯已经被派去响应5楼外呼后其他梯接收到同一层外呼信号时程序要把这个请求标记为“已分配”否则会看到两辆电梯都往5楼跑那画面就很尴尬了。2.3 开关门、平层和安全联锁别等比赛现场才想起来很多新手把电梯逻辑重点全放在“走哪层停哪层”却忽略了开关门时序。开关门其实是电梯项目里最容易扣分的部分。正常情况下电梯平层之后不是立刻开门而是先减速、确认门区信号、再发开门指令。开门到位之后开始延时延时结束自动关门。关门过程中如果光幕或者安全触板触发要立刻重新开门。安全联锁方面程序里至少要预留这些故障位急停触发检修模式超速故障门锁回路断开在程序设计时这些故障位要排在自动逻辑之前一旦触发无论当前电梯在做什么都要立即停止运行并取消所有已分配的任务。比赛时不一定所有安全信号都接真实硬件但程序结构里要有因为在答辩或者评审环节评委很爱问“你的故障处理机制是什么样的”。平层信号的处理也要讲究。有些设备用干簧管和磁铁感应机械安装有误差会有抖动。你不能检测到一次平层信号就立刻开门一般加一个20到50毫秒的延时或者滤波防止信号跳变导致电梯在没到达层楼时就开门。这个细节在仿真里看不出来但真实设备上如果不处理会出现偶发性的乱层故障。3. 博图V15.1实操项目搭建、程序编写与WinCC画面3.1 在博图里把工程骨架先立起来打开博图V15.1后建议先新建项目名字用英文然后添加一个新设备。PLC型号你可以选S7-1215C DC/DC/DC或者直接选S7-1511看你们实验室现有硬件。如果只是做比赛和仿真S7-1200完全够用价格也更友好如果以后要接WinCC Professional做较复杂的报警归档S7-1500的内存和通信能力会更强。接着在项目树里把程序结构先规划成这样OB1主程序循环调用各功能块FB_Elevator单梯控制功能块输入输出接口完全相同FB_Scheduler群控调度功能块负责外呼分配FC_FloorCalc楼层计算/编码转换功能块DB_Elevator_1、DB_Elevator_2、DB_Elevator_33个背景数据块DB_Global共享数据块存放所有外呼信号和调度结果为什么单梯逻辑要做成一个FB再实例化三次因为这样一来你调用的3个背景数据块结构完全一致WinCC画面引用变量时也能用同样的结构体路径省掉很多重复的组态工作。你如果老老实实复制三份梯形图后面想改一个逻辑得同一处错误改三遍关键比赛现场你还不一定记得把三份都改齐风险太大了。3.2 单梯FB接口设计与SCL核心实现FB_Elevator的接口设计直接决定了后面写HMI变量时顺不顺手。建议这样定FUNCTION_BLOCK FB_Elevator VAR_INPUT iFloor : INT; // 当前楼层 bCarCall : ARRAY[1..10] OF BOOL; // 轿厢内呼 bUpCall : ARRAY[1..10] OF BOOL; // 上行外呼 bDownCall : ARRAY[1..10] OF BOOL; // 下行外呼 bDoorClosed : BOOL; // 关门到位 bDoorOpened : BOOL; // 开门到位 bEmergency : BOOL; // 急停 bInspection : BOOL; // 检修 END_VAR VAR_OUTPUT bRunUp : BOOL; // 上行输出 bRunDown : BOOL; // 下行输出 bOpenDoor : BOOL; // 开门输出 bCloseDoor : BOOL; // 关门输出 iTargetFloor : INT; // 当前目标楼层 eState : INT; // 运行状态0待机 1上行 2下行 3开门 4关门 END_VAR有了这个框架你可以在SCL里写一个包含基础梯控逻辑的函数体。需要注意SCL里访问接口变量直接用名字不要用地址这样代码可读性好得多。小区里很多老工程师习惯梯形图但涉及群控调度这种带数组和循环的逻辑SCL明显更高效而且博图支持在同一个OB里混合调用LAD和SCL写成的块你不用担心不会梯形图就做不了电梯。如果坚持用梯形图也可以但我建议方向判断部分还是用SCL因为数组遍历这种事情梯形图写起来特别绕你维护一次就知道有多痛苦。3.3 WinCC画面组态过程从连接变量到动态显示WinCC这块最容易出问题的就是通信连接。在博图项目树里右键“添加新设备”选“PC系统”再选WinCC RT Professional。之后在HMI设备下找到“连接”新建一个连接通信驱动程序要选“SIMATIC S7-1200/1500”不能选老式的S7-200驱动。连接参数里的IP地址要填PLC的地址比如192.168.0.1同时PC机网卡要设置成同网段比如192.168.0.2。这里说一个最常见的问题WinCC里变量显示连接失败状态是黄色或者红色很多人就叫它“握手错误”。排查顺序我建议是这样先PING一下PLC的IP确认物理链路通不通。在博图项目树里查看PLC的“防护与安全”设置确认勾选了“允许从远程对象进行HMI访问”。再看PG/PC接口设置里访问点是否配置成S7ONLINE且对应实际网卡。最后再检查HMI连接的通信驱动选对没有。有个坑我得专门提醒有些人电脑上装了多个网卡比如无线网卡和有线网卡博图默认可能选错网卡导致PLC地址即使PING不通程序也能下载但HMI就是连不上。处理办法是在控制面板里的“设置PG/PC接口”把S7ONLINE访问点固定绑定到有线网卡。画面内容方面至少要有这几块电梯井道剖面示意图用10个楼层点位表示轿厢位置每部电梯当前楼层数值显示上行/下行状态指示箭头10层的轿厢内呼按钮1到9层上行外呼按钮2到10层下行外呼按钮开门、关门、故障报警区在WinCC里位置显示可以有两种做法。简单一点的是图形IO用不同状态的图形对应“该层是否有轿厢”这个变量复杂一点的是用“对象移动”功能把轿厢图形按照楼层数值计算纵向位移。比赛项目我建议用图形IO稳定可靠且工作量小视觉效果也不差。指示灯动态变化建议用“可见性”属性而不是不停切换画面。比如电梯上行指示你建一个上升箭头图形设置它的可见性关联到“上行运行中”变量变量为TRUE时可见为FALSE时隐藏。这样代码量少运行也流畅。3.4 下载程序与PLCSIM仿真调试如果没有真实PLC可以用博图自带的PLCSIM来仿真。在博图里选中PLC设备点“仿真”按钮然后下载程序到虚拟PLC。这里要注意PLCSIM不是一个真实的PLC所以有些通信功能特性有差异但逻辑运算和变量监控是完整的比赛前期的联调阶段够用了。WinCC的仿真运行也有两种方式。一种是把WinCC设备也设置成仿真模式然后在同一台PC上启动另一种是WinCC RT Professional直接运行。两者各有习惯但我建议在博图工程里直接启动WinCC仿真因为变量连接在组态里已经做好了不需要额外跨软件配置。调试的步骤也别乱来我习惯按这个顺序先跑单梯只启用1号梯手动给几个内呼观察它能不能正确上行、下行、开关门。再测顺向截梯让电梯向上运行途中某层有同向请求确认它能停。然后测反向记忆上行中后方出现反向请求确认电梯把任务记住等折返后再处理。最后测群控三梯分别放在不同楼层人工模拟各层外呼看调度结果是否符合你的预期。最好做一个Excel记录表把测试用例、三梯状态、外呼楼层、程序给出的派梯结果都记下来。遇到结果不合理还能回看当时三个背景数据块的数值不至于瞎猜。4. 常见问题与排查技巧实录4.1 编译报错和变量地址冲突博图项目里编译报错大多集中在接口类型不对、数组越界、背景数据块类型不匹配这几类。比如你在FB的VAR_INPUT里定义了ARRAY[1..10]但调用时填的变量却来自一个没有相同结构的UDT那编译肯定过不去。还有一个很隐蔽的问题梯形图里用了M区中间变量比如M0.0。如果工程比较大你又同时用了多个定时器和计数器M区地址很容易重复占用。排查方法就是打开博图的“交叉引用”功能输入M0.0看看在哪些地方使用了。如果发现两个功能块都在写同一个M位那逻辑就互相打架了。我自己的习惯是尽量不用M区做业务逻辑改用共享数据块DB里的静态变量。这样地址分配完全由编译器管理不会冲突HMI引用HMI变量时也更清晰。如果你实在要用M区也要在变量表里建符号名不要直接在梯形图里写裸地址不然过两天你自己都忘了M10.2是干嘛的。4.2 WinCC画面不显示或者连不上PLC“之前打开都没问题这次打开没有显示”这类问题多半是博图项目路径或者版本问题。博图对中文路径支持得不够好尤其当项目里既有WinCC又有PLC时容易在启动阶段卡住。解决办法就是把项目复制到英文路径下比如D:\Project\Elevator_3再重新打开。还有一种是压缩包解压不完全导致的。竞赛交流群里经常有人传项目如果对方打包的时候没有把生成的“文件存储”目录一起打进去你拿到手打开就会缺这少那画面空白。正确做法是使用博图的“归档”功能来打包项目而不是直接复制文件夹。另外WinCC Flexible和博图WinCC是两套东西如果你之前用的是WinCC Flexible想直接把它导入博图V15.1大概率会报版本不兼容画面迁移后各种控件丢失严重时打不开工程。这种“无显示”千万别硬试老老实实照着博图WinCC重新组态一遍时间上可能更快。4.3 电梯逻辑隐含问题信号抖动和状态竞争用PLCSIM仿真时输入信号都是手动给的不会出现抖动。但真实设备上按钮和开关触点会因为机械振动产生几毫秒到几十毫秒的误动作。比如平层信号抖动可能导致电梯在平层开门后立刻又关门或者在本层反复开关门。最简单的处理方式是在程序里加一个“信号稳定时间”判断比如连续20毫秒读到平层信号才认为有效。三台电梯同时运行时还有一个“状态竞争”问题。比如群控调度同时给2号梯和3号梯分配了同一层外呼程序在同一个扫描周期里可能先处理2号梯的分配此时外呼标记已被占用后处理的3号梯应该跳过。为了避免这种竞争群控调度的赋值和消消标记必须在同一个程序段内完成不能分开在多个OB里乱写。4.4 比赛场景的加分细节和答辩小技巧如果你想让这个项目在比赛答辩中更能打有几个细节值得加在WinCC报警画面里把故障分成“一般报警”和“严重报警”两类并加一个“故障复位”按钮故障恢复后可一键复位。群控调度策略在程序里做成可选的几种模式用HMI下拉框或者输入域切换。比如“分区模式”和“动态分配模式”平时演示时切换给评委看比讲半天算法更直观。在数据块里记录电梯的总运行次数、总开关门次数虽然比赛不强制要求但这能体现你对运维指标的考虑。答辩的时候评委最爱问一个问题“你为什么不把3号梯也派过去”这时候你如果能准确回答“因为该外呼已经被分配重复派梯会造成资源浪费和乘客混乱”会比只说“程序就是这样写的”要好得多。所以写代码的时候就要真正理解调度逻辑而不是背程序。5. 一些个人的实际体会做三部十层电梯这个项目说难不难但说简单也真不简单。我见过太多人一开始就扎进梯形图里今天写内呼明天写外呼写到一半发现结构不对又推倒重来。其实最稳的路线是先用一张纸把整个系统的IO清单和状态图画清楚把单梯逻辑调稳了再去碰群控。群控也别一上来就整最复杂的算法先把固定分区跑通再加上动态分配每一步都验证过再往下走。调试的时候尤其要有耐心不要因为PLCSIM仿真没问题就心大。仿真和实机最大的区别在于信号连续性和时间响应很多问题只有接到真实变频器、按钮、指示灯之后才会暴露。如果你们实验室有实物平台建议把“平层抖动”“光幕重开门”“检修优先”这几个测试用例优先级提上去它们才是真正区分项目和玩具程序的分界线。做完这批功能再回头看一开始的代码你就知道哪些设计是当初没想全面的了。