尧图网页设计 
1. 项目整体设计与拆解1.1 赛题需求的深度解读西门子杯比赛里的电梯题目尤其是三部十层电梯这种规模放在本科组或者工程实践类赛题里都算是比较有代表性的综合任务。很多第一次接触这个题目的同学会以为电梯逻辑很简单不就是上下跑、开门关门嘛。真上手以后才会发现单台电梯的集选控制已经让人头大了三部电梯凑在一起还要考虑群控调度、互不干扰、信号分配再加上WINCC画面组态工作量直接翻倍。先说清楚题目到底考什么。三部十层电梯核心考核点基本集中在四个方面。第一是基础逻辑的完整性比如轿厢呼叫内呼和楼层召唤外呼的登记、消号、响应顺序。第二是安全保护机制像限位开关、急停、门锁反馈、上下行超时保护这些都是程序里必须处理的硬指标。第三是多梯协同能力外呼按钮只有一个每层上下行各一个三部电梯谁去响应怎么避免多梯同时涌向同一楼层这就是群控算法要解决的问题。第四是上位机可视化WINCC画面需要准确反映每部电梯的实时楼层、运行方向、开关门状态、内外呼信号和故障报警画面操作要能反过来控制下位机。我把这个题目的评分逻辑反复琢磨过。评委和裁判看重的不是你把程序跑通了就行而是程序结构是否规范、逻辑是否健壮、异常情况考虑得是否周全。比如外呼响应后轿厢已经到站开门结果外呼信号还挂在触点上这种细节错误在仿真评分里直接就丢分。再比如电梯在运行过程中有人反复按同一个楼层的内呼按钮你的消号逻辑能不能顶得住这种连续操作。这些都是平时练习中容易被忽略的盲区。1.2 系统架构与方案选型这次我用的软件环境是博途V15.1TIA Portal V15.1PLC选的是S7-1200系列具体型号CPU 1214C DC/DC/DCHMI组态用WINCC Runtime Professional。这个组合是西门子杯比赛里最常见的配置很多学校实验室的设备也按这个规格来准备。之所以选S7-1200而不是S7-1500一方面是因为赛题提供的硬件平台和仿真环境默认支持V15.1版本的S7-1200项目另一方面S7-1200的运算能力和存储容量对三部十层电梯这种规模的逻辑来说完全够用用S7-1500反而有点浪费但如果你手头只有1500的授权程序移植过去也不难只是硬件组态里的CPU型号要重新选。说一下为什么选择单CPU控制三台电梯而不是三台PLC分别控制再通讯。比赛仿真环境里三台电梯的机械模型和传感器信号是集中在一个设备上的如果拆成三套独立PLC硬件成本翻倍不说群控信号之间的交互还需要额外的通讯协议比如S7通讯或者PROFINET IOCS凭空增加通讯失败导致仿真扣分的风险。单CPU方案把三台电梯的逻辑全部放进同一个程序里共享数据块信号交互直接读写DB逻辑清晰、实时性也好这在比赛场景下是最稳的选型。顺便说一句网上有些方案是用两台S7-200 SMART配合触摸屏做的那种一般用于实验室教学演示跟西门子杯的仿真环境不匹配。比赛仿真器的IO映射、物理点表都是按博途加S7-1200来设计的你在这个框架下做项目才能拿到最真实的评分反馈。2. 三部十层电梯的核心逻辑设计2.1 集选控制模型电梯控制方式里有简易控制、并行控制和集选控制几种比赛要求的是标准的集选控制。集选控制的核心思想是电梯把运行方向确定之后就只响应这个方向的召唤和呼叫直到这个方向的所有信号全部处理完毕再改变方向。我当时给参赛学生设计了一个五段式的状态机用来描述每一部电梯的运行状态0 - 空闲待命电梯停在某一楼层门关闭 1 - 正在开门 2 - 正在关门 3 - 正在上/下运行移动中 4 - 故障/急停为什么把开门和关门也拆成独立状态因为门的状态直接关系到电梯能不能走门没关到位运行信号必须被锁死。很多初学者的程序里开门和关门只是两个辅助标志位状态一乱就出现门还开着、轿厢开始跑的严重逻辑错误。比赛调试中这种情况一旦发生仿真直接提示动作失误扣分非常狠。有了状态机之后每个状态之间的切换条件要定义清楚。比如空闲状态下收到内呼或者外呼先判断目标楼层和当前楼层的大小关系决定方向状态然后关好门、启动运行。运行状态下到达目标楼层先减速、平层检测到位后切换到开门状态。这些条件看起来简单但真要写得滴水不漏需要把边界情况都覆盖到。2.2 内外呼信号的登记与消号这是整道题里最容易写乱的地方也是我反复强调学员必须画时序图才能动手编码的部分。先说内呼轿厢呼叫。三个轿厢每个轿厢有10个楼层按钮内呼信号用数组存储就可以。我用了三个Bool数组每个数组下标1到10代表楼层FC_InCall_NoShaft[3][10]三位内呼信号哪部电梯哪个楼层被呼叫按钮按下的时候对应位置1。电梯到达该楼层并且开门到位后该位清零。这里有一个很多人踩过的坑消号时机你没选对信号消失太早乘客可能来不及进电梯信号消失太晚同一个楼层会被重复响应。正确做法是开门到位后延时1秒消号给乘客足够的反应时间同时避免门一开就消号导致信号闪烁。再说外呼楼层召唤。三层以上的楼层都有上行和下行两个召唤按钮顶层只有下行底层只有上行。外呼信号是公用的三部电梯共享同一组外呼信号。按钮按下后这个信号要分配给某一部电梯去响应但信号本身不能因为被分配就立刻消失而要等到那部电梯真的到位、开门、完成服务之后才能消号。我对外呼信号的处理策略是外呼信号存储在一个独立的数组里上行召唤数组、下行召唤数组各一个同时维护一个外呼分配表记录每个外呼信号当前被分配给哪一部电梯。这样做的最大好处是即使分配后电梯因为故障无法响应系统还能把信号重新分配不会出现外呼信号丢失导致楼层一个人在那干等的情况。2.3 方向判定与派梯策略三部十层电梯的群控策略比赛里最常用的是固定分区 顺向响应组合方案。固定分区指的是把整个楼层分成三个区间比如1到4层由1号梯主响应5到7层由2号梯主响应8到10层由3号梯主响应。顺向响应指的是外呼信号的分配优先考虑当前正在运行且方向一致的电梯。这个方案的优点是逻辑简单、代码易实现、便于调试。缺点是某些极端场景下比如1号梯故障4层有人按上行响应效率不高。不过在比赛的仿真评分中只要电梯不会长时间不响应召唤一般是不会扣分的追求完美算法反而容易把自己绕进去。分区派梯之外还需要定义一个超时无响应保护。实现方式是在每个外呼信号分配后启动一个外呼超时定时器如果在设定时间比如30秒内该电梯没有到位响应系统自动将这个外呼信号重新分配给其他符合条件的电梯。这相当于是兜底逻辑实战中我测试下来非常有效能在动态多变的仿真场景里大幅降低漏接乘客的概率。电梯运行过程中的方向保持逻辑参考的是《电梯原理与逻辑控制》教材里经典的方向优先原则电梯运行方向有了之后在这个方向的信号全部响应完之前不会因为反方向的新召唤而换向只有一个方向的信号全部清除后才执行方向的切换这个原则翻译成程序语言上行优先存在上行信号时直接保持上行状态不检查下行信号顺向响应上行途中遇到上行呼梯按就近原则接待反向呼梯上行途中遇到下行呼梯记入登记表等当前方向跑完再回头处理3. 博图V15.1程序实现细节3.1 程序结构规划写这种中等规模的PLC项目程序结构一开始就要规划好不然代码量上来之后查错查到你怀疑人生。我推荐的组织方式是把程序块按功能拆开每个FC负责一块相对独立的逻辑OB1主循环统一调用各功能块 FC1_FloorSignal_Process楼层信号采集与处理 FC2_Elevator1_Logic1号梯运行逻辑 FC3_Elevator2_Logic2号梯运行逻辑 FC4_Elevator3_Logic3号梯运行逻辑 FC5_Group_Dispatch群控调度分配 FC6_Door_Manage开关门总控制 FC7_Alarm_Check故障检测与保护 DB1_Floor_Signal_DB楼层信号变量区 DB2-4_Ele1-3_DB三台电梯运行数据块 DB5_Group_Data_DB群控与分配数据 DB6_Alarm_DB报警变量区OB1里面我习惯用先采集、再运算、后输出的顺序来调用这些块。先处理输入信号比如电梯实际楼层位置、门锁反馈、按钮信号再做核心逻辑计算最后统一输出到IO接口。这样做的好处是程序执行顺序固定变量的时序关系清楚不像有些写法在多个块里反复读写同一个变量调起来非常被动。还有一个细节值得提一下如果你用的是多实例数据块尽量把每一部电梯的变量单独放在自己的结构体里。我最初把三台电梯的变量全部堆在一个扁平DB里地址一多就开始乱后来改成结构体数组的方式分别命名比如Elevator1_DB、Elevator2_DB而不是简单叫DB3、DB4程序的逻辑关系一目了然别人接手也能快速理解每个变量的含义。3.2 核心功能块的编写要点先说楼层位置检测。电梯的楼层检测在仿真环境里通常通过模拟传感器信号实现常见做法是用一个整型变量ActualFloor存放电梯当前所在楼层再用一组限位信号负责触发楼层位置的更新。实际调试中最稳妥的方式是利用编码器或接近开关信号的上升沿来更新楼层位置而不用轮询方式扫描电平状态。我在程序里给每一部电梯都做了楼层位置更新块核心逻辑是IF 楼层N的接近开关信号 上升沿 THEN ActualFloor N END_IF这样做的好处是电梯高速通过某层的时候不会因为扫描周期的抖动丢掉楼层信息位置更新非常可靠。开关门逻辑是另一块容易踩坑的领域。门机控制至少需要三路信号开门命令、关门命令、门到位反馈。我用的控制方式是优先关模式正常情况下开门命令和关门命令互锁但一旦检测到门区内有人或光幕触发关门命令立即撤销并重新执行开门保证安全。在程序实现上就是开门命令置位后必须收到门到位信号才能进入下一步关门命令置位后门到位信号关到位生效才允许启动运行。关于运行中不响应开关门指令这一点我也加了保护。电梯速度信号有效正在运行期间任何开关门输入信号都只做寄存器登记不产生实际输出避免运行时突然开门导致的重大故障模拟判罚。3.3 关键定时器与记忆保持博途里定时器用TON延时接通非常多。我总结了几个关键场景开门到位后延时消号TON1秒关门超时保护TON10秒超时未收到关门到位则触发报警并反向开门无响应外呼重分配TON30秒启动前门锁确认TON500ms防止门锁信号刚闭合就起飞定时器的背景数据块处理上建议全部使用IEC定时器TON、TOF、TP不要用老的S5定时器S_TON、S_ODT。原因是IEC定时器在S7-1200/1500中更稳定而且定时器号的分配完全自动化不存在老式定时器号和时基的冲突问题。这一点在博途项目大、定时器多的情况下尤其实用能省掉很多编译报错的痛苦。记忆保持方面电梯的逻辑如果因为突然断电重新上电所有内呼外呼信号理论上都应该清零归位不需要掉电保存。但有一些参数建议设置为保持型比如电梯故障记录、累计运行时间、电梯分配的优先权重这些数据在上电后重新读取能帮助程序在重启后做出更合理的调度判断。保持型变量需要在DB的数据属性里勾选Retain不勾选的话默认上电清零。4. WINCC画面组态实战4.1 画面布局与整体风格设计WINCC画面做得好不好在比赛评分里占比不低。很多参赛队伍把画面拖几个方块、放几个圆形指示灯就算交差这种做法非常可惜。优秀的画面应该让裁判一眼就能看懂电梯当前的状态甚至不用看PLC运行监控就能说出每一部电梯在哪层、有没有故障。我这次做的画面整体规划如下左侧为三台电梯的井道侧面图十层楼用水平横线划分电梯轿厢用带颜色的矩形块表示实时位置通过垂直方向的动画精确显示右侧为外呼信号区每层楼的上行、下行按钮用图形化按钮实现点击画面上的按钮可以直接发送外呼信号到PLC中间区域是当前选中电梯的详细状态面板显示运行方向、当前楼层、开关门状态、内呼登记情况底部设置报警显示区故障实时滚动显示并配历史报警表格整体风格我用的是深色底、亮色元素的反差思路这样在仿真画面中更加醒目重要信息的辨识度更高。实际比赛现场会用到投影仪投屏浅色画面在亮环境下反而容易看不清深色底真的是经验之谈。4.2 变量连接与动画设置WINCC画面里的所有动态属性都依赖于变量连接。在博途V15.1的WINCC工程里HMI变量直接从PLC变量的导入表中选择连接即可。但有几个操作细节非常关键第一画面对象的属性连接要选对类型。楼层的实时位置显示我用的不是简单的字符串显示而是通过移动或状态显示来实现动画。比如轿厢矩形块它的垂直坐标属性连接到一个整型变量变量值从0到100对应井道底到顶的位置范围通过变量变化产生平滑位移效果。如果只是显示当前楼层数字那简单连ActualFloor变量就行但要做动画效果你得做数值映射。第二指示灯的颜色变化。开门状态用绿色灯、关门状态用红色灯、运行中用黄色灯每种颜色对应一个变量状态限制。用对象颜色属性选择变量然后配置颜色表。这比用脚本驱动颜色要稳定得多也方便维护。第三按钮的交互。点击外呼按钮后不但要发送置位信号还应该让按钮本身变色表示已登记直到响应完成后复位。这个联动用变量状态来驱动按钮外观就很容易做不需要额外脚本。我前后试过把置位和复位都写在按钮事件里但非常容易造成信号丢失改成PLC内部逻辑管理外呼信号HMI只做发信号和显示可靠性提升了不止一个层次。4.3 画面联动调试的现场经验画面和PLC的联合调试最常出问题的是变量地址对不上、数据类型不一致、HMI变量没有完全同步。我建议在调试前做一次全量编译和变量一致性检查只要PLC侧改动过变量必须重新编译导出变量列表然后在WINCC里做一次从PLC变量导入的完整操作。不要嫌麻烦这一步能省掉下午两个小时的无头排查。关于WINCC Professional与S7-1200的通讯方式默认走的是S7通讯协议博途组态时会自动建立连接。只要PLC和HMI的IP地址在同一网段比如PLC是192.168.0.1HMI虚拟网卡设成192.168.0.2通讯基本一次就能通。需要注意的坑是仿真环境下WINCC仿真器Simulation和PLC仿真器之间有时需要手动设置访问点否则一直显示连接失败。方法是在仿真器的在线访问点里选择S7ONLINE与真实PLC仿真保持一致。画面调试时还建议开启测试模式可以手动强制变量数值来验证画面对象的动画响应是否正确。先把PLC逻辑那边跑通再单独让画面的楼层变量手动变化看看轿厢位置对不对最后两端合起来联调效率高很多。5. 常见问题与调试经验5.1 逻辑错误类问题排查前前后后带学生调试这个题目常见的逻辑Bug主要集中在几个地方。第一个是电梯到了楼层但是不响应已经登记的内呼。这类问题的根源多半是消号条件写得太苛刻或者太宽松导致楼层到达信号与消号信号存在竞争关系。排查思路是在楼层到位信号端加延时2秒消号保证开门后才清除呼叫登记。第二个是几部电梯同时去抢一个外呼信号看起来特别滑稽1号梯往9楼跑、2号梯也往9楼跑。这就是群控分配逻辑没写好外呼信号没有正确关联到分配电梯上。解决的方法是我上文提到的分配表方案外呼信号在分配到电梯的时候其他电梯的逻辑里就应该屏蔽这个信号直到服务完成。第三个隐蔽的坑是电梯到站后立即又启动向下一个楼层跑但方向不对。这个问题一般是判断方向时获取了当前运行状态和信号优先级之后在上下行切换时没有加延时缓冲。我的经验是在电梯开门过程中如果有新的召唤先记录等待信号在关门完成后再统一做方向判断这样就能避免优先级冲突。5.2 通讯与组态问题WINCC握手错误这个热词出现在很多人的搜索结果里比赛调试现场我几乎每次都会碰到。这类问题大头是通讯超时导致的握手失败。排查顺序是先看IP是否在同一个网段再用PING工具测试物理连通性然后检查WINCC连接设置里的访问点最后重启仿真器和PLC仿真。90%的握手错误都能被这四步解决。还有一个非常常见的坑是博途版本兼容性。V15.1的项目用V16或者V17打开时会提示版本升级升级后可能部分画面对象和块属性发生变化导致运行效果和预期不一致。我的建议是比赛期间固定使用同一种版本不要混用。如果你用V15.1写好程序队友用V17改了画面最后提交的项目版本以谁的为准必须提前约定清楚。5.3 比赛调试与现场策略分享赛场上时间紧迫程序调试要讲究优先级。我整理了一套调试策略先把基础逻辑跑通即电梯本梯内呼直达、响应外呼、开关门动作正常检查安全保护逻辑急停、限位、门锁失效这类强制扣分点必须在稳定框架下验收再加入群控分配和多梯协同逻辑进行压力测试最后细化画面展示效果和交互体验每完成一步都要在仿真测试里做完整场景测试。比如1号梯在5楼上行、3号梯在8楼下行此时7楼有人按上行这种典型场景至少过三遍确保分配结果稳定。另外程序中记得写完善的中文注释。比赛有程序评分环节逻辑清晰、注释完整的程序往往会带来附加分。很多队伍的程序写完了连自己都看不懂到答辩环节被评委提问就露馅了。哪怕你只是每段逻辑前写两三行功能说明和变量含义说明观感立刻不一样。这个项目后续还可以扩展的方向不少。比如把电梯的能耗模型做进去模拟不同调度策略下的能耗差异或者加入高峰期客流模拟把固定分区改成动态分区分派再或者用SCL语言把群控算法模块化方便不同车型、不同楼层数的电梯快速复用。技术上头了还能往数据采集方向走把每台电梯的故障记录、运行时长导入数据库做预测性维护分析。我个人的体会是过了基础功能实现这一关之后把精力花在算法的稳定性和代码的可维护性上比天天纠结画面好不好看要有价值得多。这个题目作为比赛项目它的核心考验从来不是炫技而是把一个复杂的控制系统做得可靠、完整、经得起追问。 三部十层电梯PLC群控与WINCC组态实战解析
1. 项目整体设计与拆解1.1 赛题需求的深度解读西门子杯比赛里的电梯题目尤其是三部十层电梯这种规模放在本科组或者工程实践类赛题里都算是比较有代表性的综合任务。很多第一次接触这个题目的同学会以为电梯逻辑很简单不就是上下跑、开门关门嘛。真上手以后才会发现单台电梯的集选控制已经让人头大了三部电梯凑在一起还要考虑群控调度、互不干扰、信号分配再加上WINCC画面组态工作量直接翻倍。先说清楚题目到底考什么。三部十层电梯核心考核点基本集中在四个方面。第一是基础逻辑的完整性比如轿厢呼叫内呼和楼层召唤外呼的登记、消号、响应顺序。第二是安全保护机制像限位开关、急停、门锁反馈、上下行超时保护这些都是程序里必须处理的硬指标。第三是多梯协同能力外呼按钮只有一个每层上下行各一个三部电梯谁去响应怎么避免多梯同时涌向同一楼层这就是群控算法要解决的问题。第四是上位机可视化WINCC画面需要准确反映每部电梯的实时楼层、运行方向、开关门状态、内外呼信号和故障报警画面操作要能反过来控制下位机。我把这个题目的评分逻辑反复琢磨过。评委和裁判看重的不是你把程序跑通了就行而是程序结构是否规范、逻辑是否健壮、异常情况考虑得是否周全。比如外呼响应后轿厢已经到站开门结果外呼信号还挂在触点上这种细节错误在仿真评分里直接就丢分。再比如电梯在运行过程中有人反复按同一个楼层的内呼按钮你的消号逻辑能不能顶得住这种连续操作。这些都是平时练习中容易被忽略的盲区。1.2 系统架构与方案选型这次我用的软件环境是博途V15.1TIA Portal V15.1PLC选的是S7-1200系列具体型号CPU 1214C DC/DC/DCHMI组态用WINCC Runtime Professional。这个组合是西门子杯比赛里最常见的配置很多学校实验室的设备也按这个规格来准备。之所以选S7-1200而不是S7-1500一方面是因为赛题提供的硬件平台和仿真环境默认支持V15.1版本的S7-1200项目另一方面S7-1200的运算能力和存储容量对三部十层电梯这种规模的逻辑来说完全够用用S7-1500反而有点浪费但如果你手头只有1500的授权程序移植过去也不难只是硬件组态里的CPU型号要重新选。说一下为什么选择单CPU控制三台电梯而不是三台PLC分别控制再通讯。比赛仿真环境里三台电梯的机械模型和传感器信号是集中在一个设备上的如果拆成三套独立PLC硬件成本翻倍不说群控信号之间的交互还需要额外的通讯协议比如S7通讯或者PROFINET IOCS凭空增加通讯失败导致仿真扣分的风险。单CPU方案把三台电梯的逻辑全部放进同一个程序里共享数据块信号交互直接读写DB逻辑清晰、实时性也好这在比赛场景下是最稳的选型。顺便说一句网上有些方案是用两台S7-200 SMART配合触摸屏做的那种一般用于实验室教学演示跟西门子杯的仿真环境不匹配。比赛仿真器的IO映射、物理点表都是按博途加S7-1200来设计的你在这个框架下做项目才能拿到最真实的评分反馈。2. 三部十层电梯的核心逻辑设计2.1 集选控制模型电梯控制方式里有简易控制、并行控制和集选控制几种比赛要求的是标准的集选控制。集选控制的核心思想是电梯把运行方向确定之后就只响应这个方向的召唤和呼叫直到这个方向的所有信号全部处理完毕再改变方向。我当时给参赛学生设计了一个五段式的状态机用来描述每一部电梯的运行状态0 - 空闲待命电梯停在某一楼层门关闭 1 - 正在开门 2 - 正在关门 3 - 正在上/下运行移动中 4 - 故障/急停为什么把开门和关门也拆成独立状态因为门的状态直接关系到电梯能不能走门没关到位运行信号必须被锁死。很多初学者的程序里开门和关门只是两个辅助标志位状态一乱就出现门还开着、轿厢开始跑的严重逻辑错误。比赛调试中这种情况一旦发生仿真直接提示动作失误扣分非常狠。有了状态机之后每个状态之间的切换条件要定义清楚。比如空闲状态下收到内呼或者外呼先判断目标楼层和当前楼层的大小关系决定方向状态然后关好门、启动运行。运行状态下到达目标楼层先减速、平层检测到位后切换到开门状态。这些条件看起来简单但真要写得滴水不漏需要把边界情况都覆盖到。2.2 内外呼信号的登记与消号这是整道题里最容易写乱的地方也是我反复强调学员必须画时序图才能动手编码的部分。先说内呼轿厢呼叫。三个轿厢每个轿厢有10个楼层按钮内呼信号用数组存储就可以。我用了三个Bool数组每个数组下标1到10代表楼层FC_InCall_NoShaft[3][10]三位内呼信号哪部电梯哪个楼层被呼叫按钮按下的时候对应位置1。电梯到达该楼层并且开门到位后该位清零。这里有一个很多人踩过的坑消号时机你没选对信号消失太早乘客可能来不及进电梯信号消失太晚同一个楼层会被重复响应。正确做法是开门到位后延时1秒消号给乘客足够的反应时间同时避免门一开就消号导致信号闪烁。再说外呼楼层召唤。三层以上的楼层都有上行和下行两个召唤按钮顶层只有下行底层只有上行。外呼信号是公用的三部电梯共享同一组外呼信号。按钮按下后这个信号要分配给某一部电梯去响应但信号本身不能因为被分配就立刻消失而要等到那部电梯真的到位、开门、完成服务之后才能消号。我对外呼信号的处理策略是外呼信号存储在一个独立的数组里上行召唤数组、下行召唤数组各一个同时维护一个外呼分配表记录每个外呼信号当前被分配给哪一部电梯。这样做的最大好处是即使分配后电梯因为故障无法响应系统还能把信号重新分配不会出现外呼信号丢失导致楼层一个人在那干等的情况。2.3 方向判定与派梯策略三部十层电梯的群控策略比赛里最常用的是固定分区 顺向响应组合方案。固定分区指的是把整个楼层分成三个区间比如1到4层由1号梯主响应5到7层由2号梯主响应8到10层由3号梯主响应。顺向响应指的是外呼信号的分配优先考虑当前正在运行且方向一致的电梯。这个方案的优点是逻辑简单、代码易实现、便于调试。缺点是某些极端场景下比如1号梯故障4层有人按上行响应效率不高。不过在比赛的仿真评分中只要电梯不会长时间不响应召唤一般是不会扣分的追求完美算法反而容易把自己绕进去。分区派梯之外还需要定义一个超时无响应保护。实现方式是在每个外呼信号分配后启动一个外呼超时定时器如果在设定时间比如30秒内该电梯没有到位响应系统自动将这个外呼信号重新分配给其他符合条件的电梯。这相当于是兜底逻辑实战中我测试下来非常有效能在动态多变的仿真场景里大幅降低漏接乘客的概率。电梯运行过程中的方向保持逻辑参考的是《电梯原理与逻辑控制》教材里经典的方向优先原则电梯运行方向有了之后在这个方向的信号全部响应完之前不会因为反方向的新召唤而换向只有一个方向的信号全部清除后才执行方向的切换这个原则翻译成程序语言上行优先存在上行信号时直接保持上行状态不检查下行信号顺向响应上行途中遇到上行呼梯按就近原则接待反向呼梯上行途中遇到下行呼梯记入登记表等当前方向跑完再回头处理3. 博图V15.1程序实现细节3.1 程序结构规划写这种中等规模的PLC项目程序结构一开始就要规划好不然代码量上来之后查错查到你怀疑人生。我推荐的组织方式是把程序块按功能拆开每个FC负责一块相对独立的逻辑OB1主循环统一调用各功能块 FC1_FloorSignal_Process楼层信号采集与处理 FC2_Elevator1_Logic1号梯运行逻辑 FC3_Elevator2_Logic2号梯运行逻辑 FC4_Elevator3_Logic3号梯运行逻辑 FC5_Group_Dispatch群控调度分配 FC6_Door_Manage开关门总控制 FC7_Alarm_Check故障检测与保护 DB1_Floor_Signal_DB楼层信号变量区 DB2-4_Ele1-3_DB三台电梯运行数据块 DB5_Group_Data_DB群控与分配数据 DB6_Alarm_DB报警变量区OB1里面我习惯用先采集、再运算、后输出的顺序来调用这些块。先处理输入信号比如电梯实际楼层位置、门锁反馈、按钮信号再做核心逻辑计算最后统一输出到IO接口。这样做的好处是程序执行顺序固定变量的时序关系清楚不像有些写法在多个块里反复读写同一个变量调起来非常被动。还有一个细节值得提一下如果你用的是多实例数据块尽量把每一部电梯的变量单独放在自己的结构体里。我最初把三台电梯的变量全部堆在一个扁平DB里地址一多就开始乱后来改成结构体数组的方式分别命名比如Elevator1_DB、Elevator2_DB而不是简单叫DB3、DB4程序的逻辑关系一目了然别人接手也能快速理解每个变量的含义。3.2 核心功能块的编写要点先说楼层位置检测。电梯的楼层检测在仿真环境里通常通过模拟传感器信号实现常见做法是用一个整型变量ActualFloor存放电梯当前所在楼层再用一组限位信号负责触发楼层位置的更新。实际调试中最稳妥的方式是利用编码器或接近开关信号的上升沿来更新楼层位置而不用轮询方式扫描电平状态。我在程序里给每一部电梯都做了楼层位置更新块核心逻辑是IF 楼层N的接近开关信号 上升沿 THEN ActualFloor N END_IF这样做的好处是电梯高速通过某层的时候不会因为扫描周期的抖动丢掉楼层信息位置更新非常可靠。开关门逻辑是另一块容易踩坑的领域。门机控制至少需要三路信号开门命令、关门命令、门到位反馈。我用的控制方式是优先关模式正常情况下开门命令和关门命令互锁但一旦检测到门区内有人或光幕触发关门命令立即撤销并重新执行开门保证安全。在程序实现上就是开门命令置位后必须收到门到位信号才能进入下一步关门命令置位后门到位信号关到位生效才允许启动运行。关于运行中不响应开关门指令这一点我也加了保护。电梯速度信号有效正在运行期间任何开关门输入信号都只做寄存器登记不产生实际输出避免运行时突然开门导致的重大故障模拟判罚。3.3 关键定时器与记忆保持博途里定时器用TON延时接通非常多。我总结了几个关键场景开门到位后延时消号TON1秒关门超时保护TON10秒超时未收到关门到位则触发报警并反向开门无响应外呼重分配TON30秒启动前门锁确认TON500ms防止门锁信号刚闭合就起飞定时器的背景数据块处理上建议全部使用IEC定时器TON、TOF、TP不要用老的S5定时器S_TON、S_ODT。原因是IEC定时器在S7-1200/1500中更稳定而且定时器号的分配完全自动化不存在老式定时器号和时基的冲突问题。这一点在博途项目大、定时器多的情况下尤其实用能省掉很多编译报错的痛苦。记忆保持方面电梯的逻辑如果因为突然断电重新上电所有内呼外呼信号理论上都应该清零归位不需要掉电保存。但有一些参数建议设置为保持型比如电梯故障记录、累计运行时间、电梯分配的优先权重这些数据在上电后重新读取能帮助程序在重启后做出更合理的调度判断。保持型变量需要在DB的数据属性里勾选Retain不勾选的话默认上电清零。4. WINCC画面组态实战4.1 画面布局与整体风格设计WINCC画面做得好不好在比赛评分里占比不低。很多参赛队伍把画面拖几个方块、放几个圆形指示灯就算交差这种做法非常可惜。优秀的画面应该让裁判一眼就能看懂电梯当前的状态甚至不用看PLC运行监控就能说出每一部电梯在哪层、有没有故障。我这次做的画面整体规划如下左侧为三台电梯的井道侧面图十层楼用水平横线划分电梯轿厢用带颜色的矩形块表示实时位置通过垂直方向的动画精确显示右侧为外呼信号区每层楼的上行、下行按钮用图形化按钮实现点击画面上的按钮可以直接发送外呼信号到PLC中间区域是当前选中电梯的详细状态面板显示运行方向、当前楼层、开关门状态、内呼登记情况底部设置报警显示区故障实时滚动显示并配历史报警表格整体风格我用的是深色底、亮色元素的反差思路这样在仿真画面中更加醒目重要信息的辨识度更高。实际比赛现场会用到投影仪投屏浅色画面在亮环境下反而容易看不清深色底真的是经验之谈。4.2 变量连接与动画设置WINCC画面里的所有动态属性都依赖于变量连接。在博途V15.1的WINCC工程里HMI变量直接从PLC变量的导入表中选择连接即可。但有几个操作细节非常关键第一画面对象的属性连接要选对类型。楼层的实时位置显示我用的不是简单的字符串显示而是通过移动或状态显示来实现动画。比如轿厢矩形块它的垂直坐标属性连接到一个整型变量变量值从0到100对应井道底到顶的位置范围通过变量变化产生平滑位移效果。如果只是显示当前楼层数字那简单连ActualFloor变量就行但要做动画效果你得做数值映射。第二指示灯的颜色变化。开门状态用绿色灯、关门状态用红色灯、运行中用黄色灯每种颜色对应一个变量状态限制。用对象颜色属性选择变量然后配置颜色表。这比用脚本驱动颜色要稳定得多也方便维护。第三按钮的交互。点击外呼按钮后不但要发送置位信号还应该让按钮本身变色表示已登记直到响应完成后复位。这个联动用变量状态来驱动按钮外观就很容易做不需要额外脚本。我前后试过把置位和复位都写在按钮事件里但非常容易造成信号丢失改成PLC内部逻辑管理外呼信号HMI只做发信号和显示可靠性提升了不止一个层次。4.3 画面联动调试的现场经验画面和PLC的联合调试最常出问题的是变量地址对不上、数据类型不一致、HMI变量没有完全同步。我建议在调试前做一次全量编译和变量一致性检查只要PLC侧改动过变量必须重新编译导出变量列表然后在WINCC里做一次从PLC变量导入的完整操作。不要嫌麻烦这一步能省掉下午两个小时的无头排查。关于WINCC Professional与S7-1200的通讯方式默认走的是S7通讯协议博途组态时会自动建立连接。只要PLC和HMI的IP地址在同一网段比如PLC是192.168.0.1HMI虚拟网卡设成192.168.0.2通讯基本一次就能通。需要注意的坑是仿真环境下WINCC仿真器Simulation和PLC仿真器之间有时需要手动设置访问点否则一直显示连接失败。方法是在仿真器的在线访问点里选择S7ONLINE与真实PLC仿真保持一致。画面调试时还建议开启测试模式可以手动强制变量数值来验证画面对象的动画响应是否正确。先把PLC逻辑那边跑通再单独让画面的楼层变量手动变化看看轿厢位置对不对最后两端合起来联调效率高很多。5. 常见问题与调试经验5.1 逻辑错误类问题排查前前后后带学生调试这个题目常见的逻辑Bug主要集中在几个地方。第一个是电梯到了楼层但是不响应已经登记的内呼。这类问题的根源多半是消号条件写得太苛刻或者太宽松导致楼层到达信号与消号信号存在竞争关系。排查思路是在楼层到位信号端加延时2秒消号保证开门后才清除呼叫登记。第二个是几部电梯同时去抢一个外呼信号看起来特别滑稽1号梯往9楼跑、2号梯也往9楼跑。这就是群控分配逻辑没写好外呼信号没有正确关联到分配电梯上。解决的方法是我上文提到的分配表方案外呼信号在分配到电梯的时候其他电梯的逻辑里就应该屏蔽这个信号直到服务完成。第三个隐蔽的坑是电梯到站后立即又启动向下一个楼层跑但方向不对。这个问题一般是判断方向时获取了当前运行状态和信号优先级之后在上下行切换时没有加延时缓冲。我的经验是在电梯开门过程中如果有新的召唤先记录等待信号在关门完成后再统一做方向判断这样就能避免优先级冲突。5.2 通讯与组态问题WINCC握手错误这个热词出现在很多人的搜索结果里比赛调试现场我几乎每次都会碰到。这类问题大头是通讯超时导致的握手失败。排查顺序是先看IP是否在同一个网段再用PING工具测试物理连通性然后检查WINCC连接设置里的访问点最后重启仿真器和PLC仿真。90%的握手错误都能被这四步解决。还有一个非常常见的坑是博途版本兼容性。V15.1的项目用V16或者V17打开时会提示版本升级升级后可能部分画面对象和块属性发生变化导致运行效果和预期不一致。我的建议是比赛期间固定使用同一种版本不要混用。如果你用V15.1写好程序队友用V17改了画面最后提交的项目版本以谁的为准必须提前约定清楚。5.3 比赛调试与现场策略分享赛场上时间紧迫程序调试要讲究优先级。我整理了一套调试策略先把基础逻辑跑通即电梯本梯内呼直达、响应外呼、开关门动作正常检查安全保护逻辑急停、限位、门锁失效这类强制扣分点必须在稳定框架下验收再加入群控分配和多梯协同逻辑进行压力测试最后细化画面展示效果和交互体验每完成一步都要在仿真测试里做完整场景测试。比如1号梯在5楼上行、3号梯在8楼下行此时7楼有人按上行这种典型场景至少过三遍确保分配结果稳定。另外程序中记得写完善的中文注释。比赛有程序评分环节逻辑清晰、注释完整的程序往往会带来附加分。很多队伍的程序写完了连自己都看不懂到答辩环节被评委提问就露馅了。哪怕你只是每段逻辑前写两三行功能说明和变量含义说明观感立刻不一样。这个项目后续还可以扩展的方向不少。比如把电梯的能耗模型做进去模拟不同调度策略下的能耗差异或者加入高峰期客流模拟把固定分区改成动态分区分派再或者用SCL语言把群控算法模块化方便不同车型、不同楼层数的电梯快速复用。技术上头了还能往数据采集方向走把每台电梯的故障记录、运行时长导入数据库做预测性维护分析。我个人的体会是过了基础功能实现这一关之后把精力花在算法的稳定性和代码的可维护性上比天天纠结画面好不好看要有价值得多。这个题目作为比赛项目它的核心考验从来不是炫技而是把一个复杂的控制系统做得可靠、完整、经得起追问。