三部六层电梯群控仿真系统：基于S7-1200与博途的完整实现

一提到电梯群控很多做PLC的朋友第一反应就是“这玩意儿不是电机正反转加个平层就完了么”。可一旦涉及三部电梯、六层楼、同时还要做仿真联动情况就完全不一样了——你不仅要处理单台电梯的上下行逻辑还要让三台电梯学会“商量着来”谁去接这个外呼、谁该让路、谁能顺路捎带这些在博图里写梯形图写到怀疑人生都很正常。这篇文章就基于西门子S7-1200 PLC和博图v15.1及以上版本把这个“三部六层电梯仿真群控联动系统”的完整设计思路、信号规划、调度算法、博图实现细节、仿真联调的坑一步步拆开讲清楚。这个项目最大的价值在于它既是毕业设计和技能竞赛里的常客也是理解分布式控制、状态机设计和多机通信的一个极好载体。三部电梯各自有独立控制器又通过上位协调逻辑形成整体这种“单梯自治群控仲裁”的结构和真实楼宇里的电梯群控系统在架构上是同构的。看懂这个后面再去接触西门子1500、威纶通触摸屏对接或者真实井道调试也就是顺理成章的事。1. 项目需求与整体方案设计思路1.1 三部六层电梯群控到底要解决什么问题先别急着打开博图我们得先把自己代入到设计者的角度。所谓“三部六层”指的是三台独立电梯服务同一座六层楼的每一层。它和单台电梯的最大区别不在电梯本身的拖动控制而在于“外呼分配”六层楼每层都有上下行召唤按钮一层只有上行六层只有下行中间层上下行都有。一名乘客在二楼按下上行按钮三台电梯理论上都能去接但实际应该由某一台去响应。究竟让哪台去这就是群控调度。如果三台电梯各自闷头跑结果就是一个外呼来了三台全往二楼赶。既浪费能源又让乘客看到三台门同时开体验极差。所以群控系统必须有一致的决策机制确保一个外呼只分配给一台最合适的电梯同时其余电梯即使经过该层默认也不停。还没完。电梯群控不只是“分配”这一锤子买卖。分配完之后电梯在运行途中还会碰到新的内呼、新的外呼这时候就要动态判断当前方向是否顺路、前方还有没有同向目标、是否应该顺路消呼。再往后三台电梯如果同时响应不同楼层的需求可能出现两台电梯在相邻楼层“互相追尾”甚至“背向运行”的尴尬局面所以还要有防碰撞和任务均衡的机制。总结一下这个系统要完成四件事单梯上下行自动运行、楼层平层与开关门、外呼的自动分配与消呼、多台电梯之间的协调避让。其中前三件事偏单梯最后一件才是真正意义上的“群控联动”。1.2 为什么选S7-1200和博图v15.1在做这类多控制器仿真项目时硬件选型我一般坚持一个原则够用、稳定、资料多。S7-1200系列在这个场景里几乎是最优解。从硬件能力上看S7-1200虽然定位是小型PLC但它的处理速度、定时器/计数器资源、以太网通信能力都足够支撑六层电梯的逻辑和一两个通信伙伴。CPU 1214C最多可以扩展8个信号模块数字量输入输出不够时可以加SM1221/SM1222也可以用信号板SB1223补充少量点。如果每部电梯单独用一台PLC控制1214C加一两块扩展模块完全能覆盖。从软件生态上看博图v15.1是我个人比较推荐的版本。原因很简单它兼容Win10 64位系统支持S7-1200从老固件到最新固件的大部分型号而且比后面的V16、V17、V18更加轻量安装包虽然也有十几个G但至少不会频繁遇到许可证冲突和组件兼容性报错。很多人一上来就装博图v21、v20结果项目没写几行先折腾了一周安装很影响心情。这个项目用v15.1起步后续需要高版本特性时再升级工程完全来得及。再说通信。博图天然支持多实例仿真也就是说可以在PLCSIM里同时模拟三台S7-1200再配合HIM仿真或者WinCC仿真一套完整的“下位机逻辑上位监控画面”全部在一台电脑上跑通。这对没有真实电梯模型的在校生或者自学党特别友好也是这个项目能够做成“纯软件仿真”的前提。1.3 系统架构怎么定三台独立控制器还是单CPU多任务这是设计的第一步也是很多新手第一反应就做错的地方。有人说“三台电梯嘛我用一台S7-1200写三个功能块在OB1里轮询调用不就行了”理论上是能跑但实际项目千万不要这么做。原因有三第一IO点数不允许。单台六层电梯的输入输出点大约在30~50个三台电梯就是90~150个。S7-1200的扩展能力再强靠一台1215C强行拉这么多点也捉襟见肘而且现场布线会非常痛苦。第二从“群控”两个字出发三台电梯在物理上就应该处于“各自独立控制、通过网络协调”的分布式结构。这和真实工程里每台电梯配一个控制柜、柜与柜之间用通讯线互联的形态完全一致。做仿真虽然不是真实设备但逻辑分层必须贴合工程习惯。第三单一CPU一旦故障三台电梯全停分布式结构下就算群控通信断开单梯还能靠本机逻辑独立运行这就是所谓的“降级运行”。电梯是特种设备安全冗余永远是第一位的。所以我的推荐方案是每台电梯独立使用一台S7-1200 CPU三台PLC通过以太网连接到同一个交换机或直接组成Profinet网络。群控决策可以放在其中一台PLC里做主机也可以单独加一台协调控制器。为了贴合大多数毕设和竞赛的配置我习惯把1号梯设为“群控主机”2号梯和3号梯通过PUT/GET或TSEND_C/TRCV_C把自身状态上报给主机主机完成外呼分配后再把目标呼梯表下发。这样三台PLC之间既有分工又有协作逻辑层次非常清晰。2. 信号定义与IO规划先把每一层的“眼睛”和“手”列清楚2.1 单部电梯需要哪些开关量信号打开博图新建项目前强烈建议先在Excel或者纸上把IO表画出来。这一步看起来琐碎但后面所有的逻辑都建立在IO分配上分配错了返工成本极高。以六层楼单梯为例基本信号可以分为四类井道位置信号六层平层开关有的方案用光电传感器也有的用磁开关、顶层上限位、底层下限位。这些信号决定了电梯“知道自己在哪里”是停层和换向的基础。呼梯信号轿厢内六层楼层按钮内呼、一层上行外呼按钮、二至五层上下行外呼按钮、六层下行外呼按钮。外呼总计10个按钮每台电梯面对的是同一组外呼按钮但硬件上通常每台电梯都接一遍或者由群控主机统一采集后分发给各梯。门系统信号开门按钮、关门按钮、开门到位限位、关门到位限位、光幕/安全触板、超载信号。这些信号负责开关门联动和防夹人保护。运行输出信号上行接触器、下行接触器、开门继电器、关门继电器、各层楼到站钟/指示灯、轿厢内楼层显示等。把上面这些汇总一下单台电梯的数字量输入通常在28~35点数字量输出在16~20点。用1214C本体14DI/10DO肯定不够所以我会选择1215C16DI/16DO再配一块SM1221数字量输入模块和一块SM1222数字量输出模块剩余量留作裕度。下面这张表是实际项目中比较常用的分配参考信号类别具体信号数量说明井道位置平层开关1~66到达某层时置位“电梯当前位置”井道位置顶层上限位、底层下限位2防冲顶、防蹲底门系统开门到位、关门到位2门动作完成确认门系统开门按钮、关门按钮2轿厢内操纵箱按钮门系统光幕、超载2安全防护外呼一层上、六层下、二至五层上下10层站召唤按钮内呼一至六层6轿厢内楼层选择按钮输出上行、下行接触器2曳引机方向控制输出开门、关门继电器2门电机控制输出层站上下行指示/轿厢显示若干状态显示输入输出信号确定后建议在博图PLC变量表里按照“地址连续、类别分组”的原则排列。比如%I0.0到%I0.7放平层开关%I1.0到%I1.7放呼梯按钮这样写梯形图时一眼就能看出当前信号属于哪类排查故障时也少翻变量表。2.2 仿真环境的“虚拟信号”怎么映射很多人做纯软件仿真时不知道这些开关量从哪里来实际上博图PLCSIM里你可以直接强制输入点的值或者在HMI画面上用按钮关联到每个输入变量。我习惯的做法是在HMI仿真画面中放三组楼层显示每组显示对应一台电梯的当前位置、运行方向、开关门状态。外呼按钮和内呼按钮在HMI画面里做成“置位按钮”按下后把对应的PLC输入点置1PLC逻辑登记呼梯后再通过输出点点亮HMI上的呼梯指示灯。平层开关不用HMI控制在程序里用一个变量“当前楼层”替代。电梯到达目标楼层时由程序置位“本层平层记忆”这个“记忆位”就相当于平层开关信号。这样做的好处是全程不需要手动模拟平层信号程序每次移动楼层时自动产生。轿厢位置可以用一个INT类型变量存储比如“轿厢楼层目标值”电梯上行时变量每层增加下行时每层减少。HMI的楼层指示直接读取这个变量即可。把物理IO转换成这种“软信号”之后整个仿真就很顺畅了。程序本身仍然可以最终映射到真实IO上只是调试阶段用变量代替了物理传感器。2.3 IO规划中的常见隐患结合我带过的几轮毕设经验IO规划阶段最容易犯三个错第一平层开关信号没有去抖。实际传感器在电梯低速运行时都可能产生抖动如果不加延时确认或滤波可能会在某一层反复触发。解决办法是在程序中给平层信号加一个50ms上下的置位延时稳定后才更新当前位置。第二门限位和门输出共用地址。有的同学为了省IO把开门输出直接当作开门到位输入来用这是绝对不行的。输出是执行机构收到的指令到位开关是执行结果的反馈两者混在一起门打不开时你根本分不清是命令没发出去还是门机械卡住了。第三外呼按钮没有“自锁”。真实电梯层站按钮按下后即使松开呼梯登记也必须保持直到电梯到达并开门后才消号。仿真中如果忘了用置位/复位保持按钮状态你会看到按钮一松手呼梯就消失了整个逻辑完全乱套。3. 群控联动的核心逻辑拆解单梯自治与多梯仲裁3.1 先造一台“懂规矩”的电梯单梯状态机群控的前提是每一台单梯能独立跑好基础逻辑。单梯逻辑说白了就是一套状态机空闲、上行、下行、平层停靠、开门、关门。状态之间靠“登记的任务”和“当前位置”来驱动转换。我在博图里通常用一个DB结构体来保存单梯的运行状态字段大概是这样TYPE ELEVATOR_STATE : STRUCT pos : INT; // 当前楼层位置1~6 dir : INT; // 方向标志0空闲1上行2下行 running : BOOL; // 运行中 doorOpen : BOOL; // 门开状态 cabCalls : ARRAY[1..6] OF BOOL; // 内呼登记表 hallUp : ARRAY[1..6] OF BOOL; // 各层上行外呼 hallDown : ARRAY[1..6] OF BOOL; // 各层下行外呼 targetFloor : INT; // 当前目标楼层 isSelected : BOOL; // 是否被群控分配了任务 END_STRUCT END_TYPE有了这个结构体单梯的逻辑就可以概括成下面几条规则无任务时电梯停在最近停靠层并开门待命方向标志置0。有内呼或分配给本梯的外呼时根据当前楼层和目标楼层决定方向。电梯运行过程中每到达一层平层位置扫描该层是否存在“同向呼梯”如果有则停梯、平层、开门。同一个方向的呼梯全部消完之前不响应反方向呼梯。也就是说电梯不会一边上行一边往下跑必须等上行的任务清完再进入下行方向响应下边的呼梯。这就是常说的“顺向截梯”和“反向不响应”原则。电梯行业有一句俗话叫“电梯不回头”本质上就是用这条原则换取了运行效率和运行安全。3.2 群控分配策略三种常用选梯方法对比单梯逻辑跑通之后群控的核心就是“当新的外呼出现时谁去接”。这一步也常被叫做“派梯”。常见的派梯策略有“固定分区”“最短距离”“顺路捎带优先”三种各有优缺。固定分区最简单把楼层分成三段1、2楼归1号梯3、4楼归2号梯5、6楼归3号梯。优点是不需要计算逻辑稳定缺点是电梯使用不平衡高峰期可能一部累死两部闲死。仿真演示效果也一般。最短距离策略当新外呼产生时计算三部电梯当前位置到呼梯楼层的距离谁近谁去。这个策略理解起来容易实际效果也不错但有一个问题——如果一台电梯正在向上运行且已经过了2楼你在2楼按了上行它虽然刚去过2楼实际上也已经“错过”了并不适合折返。所以单纯按“绝对距离”选梯会出现电梯反复折返的尴尬。顺路捎带优先策略这是我认为最适合这个仿真项目也最接近真实商用电梯的算法。它的核心思想是首先看有没有电梯正在向呼梯楼层方向运行并且还未经过该层如果它的运行方向与呼梯方向一致这趟活优先派给它因为“顺路”如果没有顺路的再从空闲电梯和反方向电梯里选择一个综合代价最小的。综合代价的计算可以用一个简单的评分函数评分 当前楼层到呼梯楼层的距离 方向惩罚顺路0空闲1反方向2 任务数量惩罚本梯已有任务数 × 1.5得分最低的电梯获得该外呼。这个评分过程用SCL写起来很顺手在博图里做成一个FC函数输入三部电梯的状态输出一个INT类型编号。所有外呼登记到群控主机后由这个评分函数统一仲裁然后把目标楼层写入选中的电梯任务表。3.3 多梯让行与防重复响应分配完了还不算完群控里最考验细节的是“呼梯消号”的时机。以二层上行按钮为例如果1号梯被分配去接这个呼梯那么2号和3号梯即使途经2楼也不能再响应这个呼梯。同时电梯抵达二层并开门后二层上行的按钮灯要熄灭意味着这个呼梯被真正“消掉”。在程序设计上我建议用一个单独的DB保存“群控总呼梯表”包括六层上行和六层下行一共10个外呼记录。每台电梯的内部任务表只保存“分配给我”的那部分呼梯。单梯执行完任务后需要回头清掉自己在群控总呼梯表里对应项目的占用标志。这样就避免了多台电梯同时抢一个呼梯的问题。另外一个比较隐蔽的问题是“两台电梯同时响应相邻楼层”。比如1号梯在3楼上行2号梯在4楼上行这时5楼有了新呼梯评分函数可能同时选中两台。为了防重复可以在分配后给选中电梯置一个“分配锁定”的时间窗口单位是秒级在这段时间内其他电梯即便评分更低也不得抢占。这个锁通过定时器自动复位窗口结束再释放。3.4 安全联动与异常降级群控联动不只有效率逻辑还有安全逻辑哪怕在仿真项目里也要体现出来。我至少会加以下几道防线防冲顶/防蹲底当电梯到达顶层或底层时强制清除上升或下降方向任务方向标志翻转响应反向呼梯。这个保护独立于群控逻辑在单梯内部完成。开门超时保护电梯停靠开门后如果在设定时间内无人操作自动关门继续执行后续任务如果持续有光幕信号阻断关门超过一定次数后开门等待并报警。超载不进群控如果电梯超载该梯对外广播的“可响应任务”标志置0群控主机分配时直接跳过它。通信故障降级当从梯与主机的通信中断时从梯不再理会群控分配而是按照“本梯外呼优先、顺路响应”的规则自行运行。这一点在真实工程中非常关键是电梯不会因为群控故障全部“罢工”的兜底方案。4. 博图v15.1中的工程实现细节分块编程与关键代码4.1 程序架构怎么搭FC、FB、DB各司其职在博图里写电梯群控这种逻辑量比较大的程序千万不要把所有代码都堆在OB1里面。OB1只应该做框架调用真正的功能逻辑按模块拆分到FC或FB里。推荐的程序结构是这样的OB1主循环依次调用“群控分配FC”“单梯运行FB”“门控制FC”“通信FC”并周期性刷新显示缓冲DB。FB1“单梯运行控制”每台电梯实例化一份背景DB负责本机的方向判断、呼梯扫描、平层停车、消号逻辑。FC1“派梯评分计算”从群控DB读取三部电梯状态计算评分并输出选梯编号。FC2“呼梯广播处理”接收从梯上传的状态更新群控总表。FC3“通信处理”通过PUT/GET或TSEND_C/TRCV_C完成三台PLC之间的数据交换。全局DBDB_Group总呼梯表、DB_Status三部电梯状态镜像、DB_DisplayHMI显示缓冲。这样拆分的核心好处是每个模块可以单独调试。先调单梯再把三部单梯丢到群控环境里调分配出问题时定位非常快。4.2 内呼登记、顺向消呼的关键SCL片段我习惯优先用SCL写核心算法因为电梯调度的条件分支很多梯形图写几十个网络自己看着都晕。SCL里几条关键的逻辑可以这么写首先内呼登记逻辑。每个楼层按钮按下时把对应位的cabCalls数组元素置TRUE。外呼也一样但外呼要区分上下行方向// 内呼登记 IF HMI_Button_Cab1 THEN #elev.cabCalls[1] : TRUE; END_IF; // 外呼登记以上行呼梯为例 IF HMI_Button_HallUp2 THEN #group.hallUp[2] : TRUE; FC_Dispatch.execute(); // 触发群控分配 END_IF;其次是运行方向决策。一个比较稳妥的做法是用“最远目标优先”的原则电梯向上运行时把本梯所有内呼和外呼中大于当前楼层的最大楼层作为“上行的最终目标”只有当最终目标清完之后方向才翻转为下行。代码可以简化为// 查找最大上行目标 #maxUpTarget : #elev.pos; FOR #i : #elev.pos TO 6 BY 1 DO IF (#elev.cabCalls[#i] OR #elev.hallUp[#i] OR #elev.hallDown[#i]) THEN #maxUpTarget : #i; END_IF; END_FOR; // 如果当前位置同层有呼梯则停车消号 IF (#elev.cabCalls[#elev.pos] OR #elev.hallUp[#elev.pos] OR #elev.hallDown[#elev.pos]) AND #elev.running THEN // 停止并平层 #elev.dir : 0; END_IF;顺向消呼的根本原则是电梯在某层停靠后清除该层与本方向一致的呼梯。上行时清hallUp下行时清hallDown内呼无论方向都清。如果该层同时存在反向呼梯比如2楼的电梯正在上行但乘客在2楼按了下行这时电梯不停要等下行阶段再处理避免上行途中掉头。4.3 群控分配FC的实现思路派梯评分FC是整个系统中代码量不多但逻辑最值得推敲的地方。我的做法是写一个循环依次扫描三台电梯的状态代入评分公式保留最小评分和对应编号#bestScore : 999; #bestElevator : 0; FOR #k : 1 TO 3 BY 1 DO CASE #group.elevState[#k].dir OF 0: #dirPenalty : 1; // 空闲 1: IF #callDir 1 AND #group.elevState[#k].pos #callFloor THEN #dirPenalty : 0; // 同向顺路 ELSE #dirPenalty : 2; END_IF; 2: IF #callDir 2 AND #group.elevState[#k].pos #callFloor THEN #dirPenalty : 0; ELSE #dirPenalty : 2; END_IF; END_CASE; #distance : ABS(#group.elevState[#k].pos - #callFloor); #taskNum : FN_CountTasks(#k); // 统计该梯任务数 #score : #distance #dirPenalty * 1.0 INT_TO_REAL(#taskNum) * 1.5; IF #score #bestScore THEN #bestScore : #score; #bestElevator : #k; END_IF; END_FOR;这段代码里距离的单位是楼层惩罚系数和任务数量系数可以按仿真效果调整。系数太小分配偏向距离近的电梯系数太大又可能导致电梯永远闲着。实测下来“距离权重1、方向惩罚2、任务惩罚1.5”是一个比较均衡的配置仿真时乘客等待时间不会有明显波动。还有一个细节分配完成后立即在群控总呼梯表里置位“已分配”并把目标楼层写入选中的电梯任务表。这个操作要放在同一个扫描周期内完成避免中间插入新的呼梯导致重复分配。4.4 三台S7-1200之间的通信组态三台PLC的通信我建议直接用S7-1200自带的PUT/GET指令它简单可靠不需要额外配置连接管理。在博图组态时需要在“设备和网络”中把三台PLC都加入同一个Profinet网络并且给每台PLC设置不同IP比如192.168.0.1/2/3。主机读取从机状态时用PUT/GET的“读取”功能把从机DB里的状态字段读回主机的镜像DB主机向从机下发任务时用“写入”功能把任务表写到从机的对应DB。这里有一个新手很容易踩的坑S7-1200作为服务器默认是不允许远程PUT/GET的必须在CPU属性里勾选“允许来自远程对象的PUT/GET通信访问”否则指令报错或者数据全是0。通信数据块建议单独建立不要直接读整个运行DB。例如每台从机只暴露一个“通信接口DB”内部包含当前位置、方向、任务数、故障标志主机只允许读写这个接口DB。这样既保证了安全性也避免了通信数据量过大造成以太网带宽浪费。5. 仿真实战与常见问题排查从PLCSIM到HIM联调5.1 建一个能“看得见”的HMI仿真画面调试群控逻辑光靠变量表强制信号是盯不住的。博图里HMI仿真可以非常直观地展示轿厢位置、呼梯状态、电梯方向建议在画面上做这样几个部分每台电梯一条纵向轨道六层楼各放一个楼层指示块电梯轿厢用方块表示随“当前位置”变量动态移动。HMI里可以通过“移动”动画关联PLC变量不用额外写逻辑。每层楼外呼按钮做成按钮控件按下就把PLC外呼输入位置1电梯响应后消号通过输出点把按钮背景色变暗。轿厢内呼按钮同样关联内呼输入点。门状态用两个圆或者色块联动开门到位/关门到位变量。加一排“群控状态”文本区显示当前哪个外呼由哪台电梯响应方便观察分配算法是否正确。HMI的画面要在博图里选择“仿真”运行方式然后点击启动仿真按钮。它会自动连接当前正在运行的PLCSIM实例。如果PLC不是运行状态HMI界面连接会一直显示红色所以顺序一定要“先启动PLCSIM并下载程序、再启动HMI仿真”。5.2 常见问题速查表HMI按钮无反应、数据不同步等我把实际调试中遇到频率最高的问题整理成了一张排查表照着查基本能解决大半问题现象可能原因排查与解决HMI按钮按下PLC输入点无变化HMI连接未建立或PLCSIM未启动先确认PLCSIM和HMI运行系统都在运行查看HMI下方状态栏是否绿色连接PLC输入点有变化但程序没动作按钮变量地址和IO地址不对应打开变量表核对HMI连接变量的绝对地址别用符号名互相猜电梯总在一个楼层不停触发平层平层信号没有去抖扫描周期内反复置位给平层信号加延时确认或改为“楼层位置变化”沿触发外呼消不掉按钮一直亮电梯停层后没有清除群控总呼梯表里对应项检查消呼逻辑是否同时清了单梯任务表和群控总表三台电梯都去响应同一个外呼分配结果没有锁定或从梯没有执行任务表加上“分配锁定”每台电梯运行时只扫描本机任务表通信数据全是0对方PLC未允许PUT/GET远程访问勾选CPU属性中的远程访问权限并检查通信DB地址映射下载程序时提示固件不兼容博图版本和PLC实际固件版本不一致在设备组态中把CPU固件版本改为真实PLC固件版本或升级固件博图v17以上打开v15.1工程出现标签丢失高版本升级工程导致部分变量映射变化升级前备份工程升级后重新编译并核对变量表5.3 仿真模型与真实设备差异要心里有数最后得泼一盆冷水这个仿真系统跑得再顺和真实电梯还是有明显差异的。仿真最大的简化在于它没有真正的电机调速、没有物理层的光幕信号、没有井道传感器时序。你在博图仿真里写“电梯从1楼直接跳到6楼”不违反任何规则但真实电梯的曳引机加减速、平层精度、门机动作时间都会影响群控调度的“时序”。所以仿真项目重在验证“逻辑正确性”而不是“物理可行性”。如果你后续要把这套逻辑迁移到真实设备至少要补三件事把轿厢位置变量改为编码器脉冲或旋转编码器换算值而不是简单的楼层整数。给运行方向接触器加互锁下行时即使程序出错也不能同时闭合上行接触器。加入平层精调逻辑低速爬行到位后采用平层开关确认而不是预设楼层数直接停车。5.4 关于版本兼容与工程迁移的建议经常有人私信问我“我电脑里装的是博图v18能不能打开这个v15.1工程”答案是可以博图工程基本都支持向上兼容v18可以打开并升级v15.1的项目。但升级后你会发现部分HMI画面控件样式、动画关联方式可能发生变化极个别变量映射需要重新拖拽。所以如果你自己是初学者我建议“老师或网上下载的工程是什么版本就用什么版本打开”不要一边学PLC一边和软件兼容性较劲。反过来想从高版本降到低版本是不可能的。高版本博图项目无法用低版本软件打开这也是很多人在网上下载到v20/v21工程后找不到能打开软件的直接原因。我的建议先装v15.1把逻辑学会需要时再装一个高版本作为对照不要盲目追求新版本。5.5 仿真联调的“最后一公里”心得整个项目做到最后阶段我自己习惯做一套完整的“脚本级联调”流程先在HMI里按下三层上行按钮观察哪台电梯响应等待这台电梯到达三层并开门后立刻在三层按下下行按钮看它能否在关门后自动切换方向继续下楼两分钟后在五层按上行按钮观察群控是否会把这单生意分配给另一台闲着电梯而不是让刚才那台跑回头路。这套操作看似简单但实际上把顺向捎带、反向不响应、空闲分配、任务均衡全部覆盖了一遍。我在跑这套测试的时候还喜欢用博图的变量监控表开着计算器看评分结果。每次分配后对比实际选择的电梯和理论评分最小电梯是否一致不一致就暂停程序查逻辑一致就继续跑下一轮。群里调群控速度最快的办法不是闷头看代码而是“脚本制造工况评分结果对照”一分钟能找出三四个逻辑漏洞。再说一个小技巧群控主机程序里加一个“手动锁梯”标志变量可以在HMI上随意锁定某一台电梯不让它参与派梯。这样做验收演示时特别有用可以表演“一台检修时另外两台自动顶上”的降级运行场景这种细节往往就是评分老师最看重的实际工程思维。最后补充一句我个人的习惯所有通信数据块里的变量命名尽量带上“_Comm”后缀比如Elevator1_Pos_Comm。这样无论多久以后翻工程打开DB就能一眼分辨哪些是本地运行变量、哪些是网络交换变量不依赖注释也能理清关系。这个小习惯在多人协作时尤其能救命因为我见过太多学长交接工程时面对满屏“DB1.DBW12”无从下手的表情。这次的项目做到这里回头看其实最难的部分并不在PLC指令本身而在于你有没有能力把“三部电梯应该如何协同”这个问题拆成“单梯状态机群控评分函数通信接口”三个清晰的层次。只要这个框架搭对了后面所有代码都只是填肉而已。真到了现场调试那天你会感谢自己当初在仿真阶段把每一个呼梯、每一次消号、每一回分配都看得那么仔细。