1. 为什么用三层电梯练手一个能打通PLC全流程的经典项目做工控这行久了你会发现一个规律越是看起来简单的设备越能把PLC编程的基本功练扎实。红绿灯程序练的是纯时序逻辑抢答器练的是组合逻辑而三层电梯恰好站在一个更复杂的位置上——它同时包含了时序逻辑、状态判断、互锁保护、现场信号采集和上位机展示几乎把日常非标设备里能用到的PLC编程套路都覆盖了一遍。我第一次带徒弟做这个项目时就跟他说别小看这三层楼把这套逻辑吃透了后续去做六层、八层的电梯或者物流分拣线的呼叫调度思路是同一个。三层的意义在于层数少却结构完整——有上行有下行有内呼有外呼有平层有开关门所有核心要素都齐了调试复杂度又在可控范围内。这个项目的第二个价值在于从PLC逻辑到组态仿真这条完整链路。很多人写PLC程序能跑但一接上位机组态就卡壳——不是通讯参数不会配就是变量地址对不上再要么就是仿真运行时发现PLC侧状态刷新跟不上画面操作。这些问题在书本上不会碰到只有把一个真实的小系统完整地做一遍才知道各个环节是怎么咬合的。本文适合三类人一是PLC入门后想做点像样小项目的初学者二是电气工程师想熟悉组态软件与PLC联动调试的流程三是做非标设备调试的朋友可以从中借鉴状态机编程和互锁设计的思路。我会把硬件选型、IO分配、梯形图分块逻辑、组态画面搭建和实测踩坑完整串起来讲。2. 动手前先想清楚电梯控制逻辑到底在干什么很多初学者的第一个误区是一上来就写梯形图结果写到一半发现控制逻辑是拧巴的。电梯这个玩意儿本质是一个按状态转移运行的调度系统而不是简单的一堆启保停电路堆在一起。2.1 电梯的状态机本质不止是电机正反转拆解一下电梯的基本动作有人在3楼按了外呼下行按钮电梯如果在1楼就需要判断应该上行还是下行运行到3楼后要减速停车检测到平层信号后开门乘客进入按下内呼按钮比如要去1楼关门电梯再下行到1楼平层、开门、下人。把这个过程抽象一下电梯其实存在这样几个状态空闲待机、上行运行、下行运行、减速停车、开门、关门。任意时刻电梯只能处于其中一个状态状态之间的转换由呼叫请求当前位置运行方向共同决定。这就是教科书里讲的有限状态机思路。实际写程序时我习惯把状态机映射成PLC内部的一组M继电器或者一个整型寄存器比如M0空闲、M1上行、M2下行、M3开门保持。每个扫描周期里先判断当前状态再检查转移条件是否满足满足则复位当前状态、置位下一个状态。这种写法有个好处程序结构清晰不会出现输出条件互相打架的隐性逻辑错误。2.2 两个核心矛盾方向判定与呼叫保持三层电梯看似简单但有两个隐藏的难点。第一个是运行方向的判定。这是一个PLC程序里非常容易写乱的地方。教科书里常用的思路是先判断有没有上行呼叫且电梯当前位置在该呼叫楼层之下如果有则电梯应当上行。下行逻辑同理。听起来简单实际操作时会碰到一个细节如果电梯在2楼正在上行此时1楼有人按下行外呼电梯到达3楼后没有更新呼叫它要不要转头下去现实的电梯策略是先响应完当前方向上的所有呼叫再响应反方向的呼叫。这叫做顺向截梯。三层电梯虽然不需要处理那么复杂的顺向调度但方向判定逻辑建议从开始就按这个思路写后续扩展多层时改动最小。第二个是呼叫信号的保持。外呼按钮和楼层内呼按钮按下后如果电梯还没到这个请求必须一直记住不能因为按钮松开就丢。所以PLC程序里通常用置位/复位指令来处理呼叫登记按钮按下→置位对应的呼叫位电梯到达该楼层完成开门动作→复位对应的呼叫位。这就是呼叫登记的思路。2.3 安全永远是第一优先级门锁与上下行互锁电梯不是玩具即便只是三层楼的教学模型安全逻辑也不能省。两个最基本的保护必须写进去门锁保护电梯运行前必须确认所有厅门、轿厢门已关好。工程上常把门锁信号串联成一个回路厅门锁、轿门锁全部闭合才导通接入PLC的一个输入点。程序里如果门锁信号不成立运行输出必须被强制切断。上下行接触器互锁上行接触器和下行接触器在硬件回路上要互锁即常闭触点串联到对方线圈回路PLC程序里输出时也要做软件互锁——同时只能有一个方向的输出为ON。这是考试和现场检查都会盯的点你永远不希望出现上下两个接触器同时吸合的情况。另一件容易被忽略的事是平层与减速的关系。实际电梯会在楼层附近设置减速信号换速感应器PLC检测到换速信号后先切断高速运行输出切换为低速爬行再检测到平层信号后停车。三层电梯实训模型通常不需要区分高速/低速但逻辑上要有运行到位后停止的准确判定否则很容易冲过楼层。这一点在后面梯形图实现时会详细讲。3. PLC选型与IO分配把15个输入输出点安排明白3.1 选型思路入门项目不必追求高端IO点数先算清三层电梯按最简方案配置输入输出大致如下。输入信号约10点1/2/3楼外呼上行按钮1楼不需要上行所以实际是2楼、3楼上行2点1/2楼外呼下行按钮3楼不需要下行所以实际是1楼、2楼下行2点轿厢内呼1/2/3楼按钮3点1/2/3楼平层感应信号3点也可以用接近开关或干簧管门锁/开门到位信号1点关门到位信号1点如果门机需要单独控制输出信号约6点上行运行输出1点下行运行输出1点开门输出1点关门输出1点楼层指示/到站提示可用7段数码管或者简单指示灯至少1~3点合计约16点输入、6点输出我习惯在选型时把输入做成12~14点、输出做成8点左右留一点余量方便调试时临时加信号。西门子S7-200 SMART的SR2012输入8输出继电器输出就是很合适的入门方案性价比高配合STEP 7-Micro/WIN SMART编程软件做组态仿真时走S7协议或Modbus TCP都方便。三菱FX3U系列也可以输入继电器X、输出继电器Y的分配方式直观很多技校教材都用它。汇川、信捷这些国产PLC现在也做得不错尤其是信捷的XC系列配自家的组态软件XCPPro学习和调试成本更低。这个项目选PLC时有一点要提醒一定要选带网口的型号。组态仿真最常用的通讯方式就是以太网如果用老款只有串口的PLC比如S7-200 CN的PPI口连组态软件时还得加USB转485的线调试效率低不少而且通讯参数的坑会多到你怀疑人生。3.2 一张IO分配表解决90%的接线混乱不管用哪家PLC我强烈建议在动手写程序前先做一张IO分配表。这张表不仅是接线图纸的根据也是组态画面变量登记的底稿。下面是我做三层电梯项目时常用的一张表点位PLC地址信号说明传感器/按钮安装位置备注输入I0.01楼平层感应1楼平层开关常开到位闭合输入I0.12楼平层感应2楼平层开关常开到位闭合输入I0.23楼平层感应3楼平层开关常开到位闭合输入I0.31楼下行外呼1楼厅外按钮置位登记到达后复位输入I0.42楼下行外呼2楼厅外按钮置位登记到达后复位输入I0.52楼上行外呼2楼厅外按钮置位登记到达后复位输入I0.63楼上行外呼3楼厅外按钮置位登记到达后复位输入I0.7轿厢内呼1楼轿内按钮置位登记到达后复位输入I1.0轿厢内呼2楼轿内按钮置位登记到达后复位输入I1.1轿厢内呼3楼轿内按钮置位登记到达后复位输入I1.2门锁闭合信号各门锁串联回路运行必要条件输出Q0.0上行运行上行接触器线圈与Q0.1软件互锁输出Q0.1下行运行下行接触器线圈与Q0.0软件互锁输出Q0.2开门输出开门接触器线圈开门到位后停止输出Q0.3关门输出关门接触器线圈关门到位后停止输出Q0.4电梯运行指示蜂鸣器/指示灯可接楼层数码管登记地址的时候要特别注意一点平层感应信号的触发方式。现实里平层开关一般用常开型如干簧管电梯轿厢上的隔磁板插入时触点闭合组态仿真里模拟这个信号时通常用按钮或者组态画面里的轿厢位置动画联动这一点到第5章组态部分再展开。3.3 程序中必备的辅助继电器规划先规划好IO再规划内部软元件。我把整个程序里用到的内部继电器按功能分组这样写梯形图时思路不乱呼叫登记区M0.0~M0.6对应7个呼叫输入4个外呼3个内呼每个输入按钮接一个置位线圈对应的复位条件放在程序后段。楼层状态区M1.0~M1.2表示电梯当前所在楼层由平层感应信号触发更新。也可以用寄存器直接存楼层号但三个M继电器按位表示更直观组态读取也简单。状态标志区M2.0空闲待机、M2.1上行运行、M2.2下行运行、M2.3开门、M2.4关门用一个字节寄存器里的位来标识当前状态。运行条件区M3.0上行请求汇总有任一上层呼叫、M3.1下行请求汇总、M3.2本层呼叫。这样规划之后后面写梯形图相当于往这些规划好的格里填逻辑程序结构会非常清晰比想到哪写到哪强太多。4. 梯形图逻辑分块实现呼叫登记、方向判定与运行控制写PLC程序最忌讳的就是把所有逻辑堆在一个网络里。拿到IO分配表和内部软元件规划后我会把程序分成几个功能块按顺序排列初始化块 → 呼叫登记块 → 楼层检测块 → 方向判定块 → 运行输出块 → 开关门控制块 → 复位与互锁块。每块负责一件事出了问题也好定位。4.1 呼叫登记与清除置位和复位之间的逻辑闭环呼叫登记块是所有后续逻辑的输入源。以2楼上行外呼I0.5为例梯形图可以这样写Network 1 // 外呼上行登记 LD I0.5 // 2楼上行按钮按下 S M0.1, 1 // 置位2楼上行呼叫登记位 Network 2 // 2楼上行登记复位 LD M1.1 // 电梯当前在2楼平层感应 A M2.3 // 且电梯处于开门状态 A I1.2 // 且门锁闭合/开门到位说明电梯确实在执行开门动作 R M0.1, 1 // 复位2楼上行呼叫登记位这里有一个细节值得说明复位呼叫位的条件不能只看电梯当前在该楼层必须加上电梯已经具备开门条件这个约束。原因是电梯可能在运行中瞬间经过2楼比如从1楼去3楼时路过2楼不停如果只按平层信号复位呼叫就会被路过误清除。加开门条件后只有电梯真正在该楼层停下来开过门呼叫才被清除这更接近真实电梯的行为。实测中这也是初学者最容易犯的逻辑错误之一。内呼登记逻辑与外呼完全一致只是复位条件里多了一个前提乘客按下内呼按钮的楼层就是目标楼层所以只要电梯到达该楼层并开门就必须清除对应的内呼位不需要额外考虑运行方向。4.2 方向判定先响应同向呼叫再考虑反向方向判定是整个程序里最考验逻辑思维能力的一部分。我用的是一种简单又稳妥的实现方式上行运行条件Q0.0输出条件电梯处于运行允许状态门锁闭合、无故障且存在任意一个高于当前楼层的有效呼叫且当前没有更高楼层的呼叫需要下行响应或者说同向优先具体梯形图判断时我习惯按楼层展开而不是按呼叫类型展开。比如当前电梯在1楼上行条件简化为2楼或3楼有任何呼叫登记不管外呼还是内呼电梯就发出上行运行信号。当前在2楼时只有当3楼有呼叫登记才上行当前在3楼时上行条件必然不成立。下行运行条件对称处理电梯在3楼时1楼或2楼有任何呼叫就下行在2楼时只有1楼有呼叫才下行在1楼时下行条件不成立。写到这里有一个非常关键的点必须展开讲运行方向输出不等于电机一直转。Q0.0得电推动电梯上行但当电梯到达目标楼层、平层感应信号到来时必须先切断运行输出再执行开门动作。如果你把上行运行等同于上行接触器一直吸合电梯就会冲过平层位置这在实训台上一眼就能看出来在实际井道里叫蹲底或冲顶是重大事故隐患。所以我在运行输出块里做了这样的约束上行运行输出 上行方向判定条件 AND NOT 当前楼层平层信号 AND NOT 开门状态 AND NOT 关门动作中。留平层信号这个闸门是为了确保电梯到位时绝对不带着动力继续走。下面这段是方向输出的梯形图范例Network 3 // 上行运行输出 LD M3.0 // 有上行请求 A I1.2 // 门锁闭合 AN I0.0 // 不在1楼平层 AN I0.1 // 不在2楼平层 AN I0.2 // 不在3楼平层 AN M2.3 // 不在开门状态 AN M2.4 // 不在关门状态 AN Q0.1 // 与下行输出互锁 Q0.0 // 输出上行这里把不在1/2/3楼平层全部串联逻辑上等价于电梯处于楼层之间的位置但实际项目中更推荐用一个中间继电器M2.5来表示电梯运行中既可以当状态标志也可以减少梯形图中串联触点的数量。4.3 开关门逻辑到位信号与定时器配合电梯到达目标楼层后PLC程序自动进入开门流程。开关门控制我一般用定时器实现自动关门开门输出得电后开始计时开门持续时间到比如设定5秒自动转为关门输出关门输出得电后如果检测到关门到位信号或者开门按钮被再次按下立即停止关门并重新开门。这里需要引入一个小的防夹逻辑关门过程中如果门锁回路断开了表示有人在厅门口阻挡程序强制转为开门并延时后再尝试关门。在实训模型上可以用一个常闭按钮模拟这个信号。虽然三层教学项目没有实际安全触板但把这段逻辑写进去能培养良好的安全编程习惯。开门输出与运行输出之间也要做硬件级的动作互斥。运行的时候门必须锁死开门的时候运行输出必须为零这两个动作在现实中不可能同时发生。我在程序中用了一个简单可靠的做法把Q0.0、Q0.1的输出回路都用门锁信号和开门动作信号做串联切断从逻辑上保证运行与开关门绝对互斥。4.4 楼层计数与位置显示收到平层信号后程序要更新当前楼层状态。这里有一个常见的实现技巧不要用累加计数的方式跟踪楼层因为一旦发生溜车或信号干扰计数就会错位后续所有判断全乱套。正确的做法是以平层感应信号为准直接锁存当前楼层。梯形图实现很简单I0.0接通时把M1.0置位、M1.1和M1.2复位I0.1接通时把M1.1置位、其余复位I0.2接通时同理。这样当前楼层永远等于最后一次平层信号所在的楼层不受运行次数和方向影响。这段逻辑虽然不起眼但恰恰是程序可靠性的基石。楼层显示的输出可以直接用Q点驱动数码管也可以用组态画面的文本动画来做。组态仿真时我习惯把M1.0~M1.2三个位在画面里做成电梯当前位置的颜色变化比数码管更直观。5. 组态仿真把程序搬到屏幕上让电梯动起来PLC程序写完下一步就是组态仿真。这个环节最大的作用是在不上电、不接线的情况下验证程序逻辑是否正确。做组态仿真时有个原则需要先说明——组态画面里的轿厢运动本质上是根据PLC反馈的楼层信号来做位置映射而不是组态软件自己模拟电梯运行。搞清楚这个关系后面调试才不至于混淆。5.1 通讯配置选对协议地址映射一个都不能错我以西门子S7-200 SMART配合组态王/WinCC为例讲通讯配置。第一件事是确认PLC侧已经开启了允许远程访问以太网端口IP设置好比如192.168.1.10电脑网卡IP设在同一个网段比如192.168.1.2然后用PING命令确认能通。组态软件里新建设备时会让你选择驱动类型S7-200 SMART对应的驱动通常是S7-TCP西门子以太网协议通讯参数里要填PLC的IP地址、机架号和槽号。这里有个实操经验很多初学者按旧版S7-300的默认参数机架0、槽2去填结果连不上换成S7-200 SMART专用的机架0、槽1就好了原因是S7-200 SMART的通讯数据块映射位置与300不同。变量连接是组态里最容易出错的一环。组态软件的变量要和PLC里的IO地址一一对应组态变量名PLC地址数据类型用途Up_Request_3FM0.6位3楼上行外呼登记In_Call_1FM0.5位轿厢内呼1楼Floor_1M1.0位1楼平层状态Door_OpenQ0.2位开门输出Up_RunQ0.0位上行运行Current_Floor通过三个位组合整型/枚举画面楼层显示接线组态时有一个特别常见的坑PLC的I点作为输入在组态画面里做按钮来触发这一般是做不到的。组态软件可以读I点状态但如果你想把画面上的开关按钮直接写到PLC的I点大部分组态软件并不支持或者需要特殊驱动因为I点的物理属性决定了它只能被外部硬件驱动。正确的做法是画面上所有可操作的按钮全部对应PLC内部的M继电器或V寄存器按钮按下时把对应的M位置位。我把这种做法叫虚拟输入镜像——用M点模拟I点的功能程序里读取的是M点实际接线按钮时再把I点与M点做一次并联映射。这样同一个PLC程序既能接实体按钮也能被组态画面控制两不耽误。5.2 画面设计轿厢动画、指示灯、楼层显示画面布局我通常分成三个区域左边是井道立面图画一个细长矩形代表楼层1楼、2楼、3楼分别标出平层位置每层放一个指示灯绿色平层指示灯。轿厢用一个矩形色块表示它的垂直位置由当前楼层变量驱动。组态软件里这个位移可以用垂直移动动画连接把轿厢图元的移动值绑定到Current_Floor变量1楼对应位置0、2楼对应位置50、3楼对应位置100单位是像素或者组态的百分比。中间是操作面板放外呼按钮2楼上行、2楼下行、3楼上行、1楼下行每个按钮旁边放一个指示灯显示呼叫登记状态对应M0.x再放轿厢内呼按钮1楼、2楼、3楼和对应的内呼指示灯对应M0.5、M1.0等。右边是状态指示区显示电梯当前状态上行/下行/停止/开门/关门可以用不同颜色的文字或指示灯表示。轿厢位移动画有一个注意点组态画面中需要实时读PLC的楼层状态位以及运行输出位如果只有楼层信号画面只能显示当前位置在几楼轿厢是瞬间跳变的缺少电梯爬楼的中间过程观感很生硬。改进方法是在组态软件里用脚本比如组态王的事件命令语言、WinCC的C脚本读取运行方向信号然后以一定的时间间隔把轿厢图元往目标楼层方向移动若干像素走到对应楼层位置后停止。这样模拟出来的加减速爬楼过程非常接近实物效果。这个脚本本质上就是用组态软件模拟电梯的中间运动过程而PLC本身只输出方向和楼层状态。模块分工明确调试时思路不会乱。5.3 仿真联调的步骤与验证清单联调时我习惯按下面的顺序走确认PLC程序与组态通讯正常组态软件里做一个心跳变量比如PLC里M2.7每秒翻转一次画面显示该变量的状态如果画面上的心跳在闪说明通讯链路没问题。验证外呼登记在画面上点击3楼上行外呼按钮PLC侧对应M0.6置位外呼指示灯常亮。验证方向与运行电梯在1楼存在3楼呼叫观察PLC输出Q0.0置位画面上轿厢开始上行方向指示灯显示上行。验证平层停车轿厢移动到3楼位置组态脚本模拟到位PLC收到平层信号后复位运行输出Q0.0断开M2.3置位进入开门状态。验证呼叫复位开门动作执行后外呼登记位复位指示灯熄灭内呼登记同理。验证互锁在电梯运行中手动置位下行输出条件观察Q0.0是否因为互锁条件而保持为OFF。整个联调过程建议按功能逐条过的方式做记录哪一步没通过就回头查程序逻辑。组态仿真阶段的bug90%集中在变量地址映射错误和呼叫复位条件不完整这两类不需要过度怀疑通讯问题。6. 实测中的主要坑信号抖动、双层呼叫与组态卡顿下面这些都是我在调试三层电梯仿真系统时真实遇到并花时间解决过的问题属于那种文档里不写、但跑一遍必踩的坑。6.1 平层信号的抖动与误触发平层感应开关如果用的是机械式限位开关或者干簧管在电梯慢速爬行时开关刚接触的瞬间会产生抖动PLC一个扫描周期可能读到多次通断变化。如果程序直接把平层信号用于楼层锁存轻微抖动会导致楼层状态反复跳变。解决思路在程序里加入去抖延迟平层信号接通后延时50ms再更新楼层标志可以使用定时器实现。或者在组态画面里把平层信号的触发做成手动点头方式比如按一下画面按钮模拟轿厢到达避免信号毛刺干扰验证结果。6.2 2楼的双向外呼同向优先如何落地2楼比较特殊它同时有上行外呼按钮和下行外呼按钮。实际场景是电梯从3楼向下运行经过2楼如果此时2楼的上行外呼被按下电梯应不应该停按同向优先原则电梯正在下行只响应2楼的下行外呼不应该被上行外呼截停。程序中这一条必须明确正在下行时2楼上行外呼登记不参与本次运行的目标判定。梯形图里做这个逻辑时我的做法是Network 4 // 下行运行条件 LD M3.1 // 有下行请求1楼下行或2楼下行 A I1.2 // 门锁闭合 AN I0.0 AN I0.1 AN I0.2 AN M2.3 AN M2.4 AN Q0.0 Q0.1关键在于当电梯下行经过2楼时如果只有2楼上行外呼被登记M0.11M3.1不会增加一个斜体条件去判定它因为M3.1汇总的是下行方向的呼叫2楼上行外呼不在其中。这样电梯就会直接越过2楼继续下行到1楼。等到1楼完成向下方向的响应后程序回到空闲状态再重新检测M0.1电梯才会变为上行。这个先顺向、后反向的行为逻辑做完之后用组态仿真验证一次就非常清晰。6.3 组态画面操作与PLC扫描周期的配合问题组态软件的画面按钮按下时实际是往PLC里写一个M点的值然后等待PLC程序响应后又复位。这个过程有时间差组态软件一个按钮动作可能持续几百毫秒而PLC扫描周期可能是几十毫秒。如果按钮置位和程序复位之间出现竞争可能发生这种情况——画面按钮把M0.6置成1电梯程序开始响应但此时用户觉得按钮卡了又点了一下M0.6再次被置位。结果就是呼叫登记位反复横跳画面上的指示灯闪烁。我的处理办法是在组态脚本里给按钮做防重复触发按钮按下后立即把自身置为不可用Disable等PLC侧返回该呼叫登记位的状态为ON、且确认电梯已经开始响应即运行输出或开门输出已动作后再恢复按钮可用。这个交互逻辑虽然只是教学项目但对理解上位机与PLC的交互时序非常有帮助。6.4 仿真通过后上实物前必须查的三个硬件点如果条件允许仿真验证完整后会建议去实物实训台或真实设备上再做一遍。从仿真切到实物有三个地方必须重新检查外部按钮的接线常开/常闭软件里默认按钮接常开实物接线时如果有人接成常闭程序逻辑全反。接触器互锁触点是否真实接入了线圈回路即使程序里做了软件互锁硬件回路也必须再串一组互锁触点这是安全冗余的基本原则不能省。平层开关的安装位置实物的平层开关装在轿厢上隔磁板装在井道里两者相对位置决定了停靠精度。程序逻辑没问题但停车位置偏上或偏下往往都是机械安装问题不要急着调程序。7. 项目后续可以怎么扩展给想继续深化的人几条路三层电梯整套做完并且仿真通过后这个项目其实已经具备了很好的扩展基础。我个人建议按下面几个方向继续深化难度循序渐进每一步都能学到新东西。第一加楼层数。把三层扩展到五层、六层甚至八层时你会发现外呼登记、内呼登记的逻辑虽然看起来只是多了几路但方向判定的复杂度显著上升——中间楼层既有上行外呼又有下行外呼同样方向优先和顺向截梯的实现会变得更加关键。这时可以考虑引入运行方向标志的独立管理用一个M位表示当前是上行趋势还是下行趋势每层楼的呼叫在判断时先按趋势方向过滤再按楼层关系比较。这类思路去面试时讲出来比只说我做过三层电梯要有说服力得多。第二接入更真实的调度策略。现实中电梯除了顺向截梯还有最远方向反向折返满载直驶防捣乱呼叫等调度策略。虽然三层模型很难完全复现这些策略但可以在方向上做简化版的全域扫描调度PLC每隔一段时间扫描一次所有登记状态找出当前方向上最远的呼叫楼层作为目标楼层。这个逻辑做好了再去接触真正电梯控制系统里的调度模块底层思路是相通的。第三把组态换成真实触摸屏。很多实训项目做完组态仿真后下一步是接一块真正的HMI触摸屏比如昆仑通态、威纶通、西门子Smart Line。触摸屏通过串口或以太网直接连PLC画面里的按钮、指示灯、轿厢动画全部重新做一遍。这一步能让你理解上位机组态和HMI画面在通讯与变量绑定上的差异实际做工控项目时二者经常互相切换。第四尝试加入变频器控制。三层电梯教学模型如果用异步电机加变频器驱动程序里需要增加多段速控制启动时高速运行、接近目标楼层时切换中速、平层前切换到低速爬行。三菱、西门子、汇川的变频器都有多段速输入端子PLC用两个或三个输出点组合出不同的速度段。这个扩展会把整个项目从逻辑控制拉升到逻辑传动的层面涉及到的知识量翻倍含金量也翻倍。第四点我自己在带新人时很推荐因为变频器的加减速时间、多段速信号延迟和启停防溜车这些问题都是实际设备上天天会遇到的事。第五用高级语言做一套数据采集。基于OPC UA或Modbus TCP协议用Python、C#或Node-RED把PLC里的运行状态实时读出来比方说当前楼层、运行方向、呼叫登记情况、累计运行次数。可以存进数据库做简单分析也可以搭配Web页面做一个电梯运行监控仪表盘。这一步把工控系统向工业物联网方向延伸了一步也是近年来面试中很常见的加分点。8. 写在最后的几点个人体会做这个三层电梯项目我自己收获最大的反而不是电梯本身而是养成了一套从需求到拆分到编码到验证的工程习惯。很多本科毕业或者自学PLC的朋友容易犯一个毛病拿到项目就开始写梯形图边写边想写完就下载到PLC里试出了问题再回头一个个网络地找。这种盲目调试的方式在小程序里还能凑合一旦程序超过两三百个网络就会把自己绕进去。我现在的做法是严格执行前面讲的顺序先列IO表再规划内部软元件然后分块写逻辑每写完一块就注释清楚最后用组态仿真把每条功能路径过一遍。看着多花了一点时间实际上省下的调试时间是这个时间的好几倍。尤其是做组态联动时变量名规范统一会带来极大的便利——我遇到不少同行在组态软件里用的变量名和PLC程序里的注释对不上一查变量映射就得来回翻两套文档非常痛苦。再分享一个小技巧组态仿真的联调阶段把PLC的扫描周期故意调慢一点比如人为在程序中加延时更容易观察信号变化的先后顺序。正常设备的扫描周期是几十毫秒肉眼根本跟不上信号谁先谁后根本看不出来。把关键动作之间加上500毫秒的延时你就能在画面上清楚看到外呼置位→方向输出→运行中→平层→开门→呼叫复位这个完整链条是否按预期顺序进行。这个习惯帮我抓出过好几次逻辑顺序错误。如果你是初学者建议按照这篇文章的顺序走一遍完整流程。如果你已经做过类似项目可以重点看看第6章那几个坑和后面的扩展方向或许能带给你一些新的切入点。设备无论大小底层逻辑和方法论是通用贯通的三层电梯的功夫练好了后面换其他设备上手会顺很多。 三层电梯PLC控制全流程：从IO分配、梯形图到组态仿真
1. 为什么用三层电梯练手一个能打通PLC全流程的经典项目做工控这行久了你会发现一个规律越是看起来简单的设备越能把PLC编程的基本功练扎实。红绿灯程序练的是纯时序逻辑抢答器练的是组合逻辑而三层电梯恰好站在一个更复杂的位置上——它同时包含了时序逻辑、状态判断、互锁保护、现场信号采集和上位机展示几乎把日常非标设备里能用到的PLC编程套路都覆盖了一遍。我第一次带徒弟做这个项目时就跟他说别小看这三层楼把这套逻辑吃透了后续去做六层、八层的电梯或者物流分拣线的呼叫调度思路是同一个。三层的意义在于层数少却结构完整——有上行有下行有内呼有外呼有平层有开关门所有核心要素都齐了调试复杂度又在可控范围内。这个项目的第二个价值在于从PLC逻辑到组态仿真这条完整链路。很多人写PLC程序能跑但一接上位机组态就卡壳——不是通讯参数不会配就是变量地址对不上再要么就是仿真运行时发现PLC侧状态刷新跟不上画面操作。这些问题在书本上不会碰到只有把一个真实的小系统完整地做一遍才知道各个环节是怎么咬合的。本文适合三类人一是PLC入门后想做点像样小项目的初学者二是电气工程师想熟悉组态软件与PLC联动调试的流程三是做非标设备调试的朋友可以从中借鉴状态机编程和互锁设计的思路。我会把硬件选型、IO分配、梯形图分块逻辑、组态画面搭建和实测踩坑完整串起来讲。2. 动手前先想清楚电梯控制逻辑到底在干什么很多初学者的第一个误区是一上来就写梯形图结果写到一半发现控制逻辑是拧巴的。电梯这个玩意儿本质是一个按状态转移运行的调度系统而不是简单的一堆启保停电路堆在一起。2.1 电梯的状态机本质不止是电机正反转拆解一下电梯的基本动作有人在3楼按了外呼下行按钮电梯如果在1楼就需要判断应该上行还是下行运行到3楼后要减速停车检测到平层信号后开门乘客进入按下内呼按钮比如要去1楼关门电梯再下行到1楼平层、开门、下人。把这个过程抽象一下电梯其实存在这样几个状态空闲待机、上行运行、下行运行、减速停车、开门、关门。任意时刻电梯只能处于其中一个状态状态之间的转换由呼叫请求当前位置运行方向共同决定。这就是教科书里讲的有限状态机思路。实际写程序时我习惯把状态机映射成PLC内部的一组M继电器或者一个整型寄存器比如M0空闲、M1上行、M2下行、M3开门保持。每个扫描周期里先判断当前状态再检查转移条件是否满足满足则复位当前状态、置位下一个状态。这种写法有个好处程序结构清晰不会出现输出条件互相打架的隐性逻辑错误。2.2 两个核心矛盾方向判定与呼叫保持三层电梯看似简单但有两个隐藏的难点。第一个是运行方向的判定。这是一个PLC程序里非常容易写乱的地方。教科书里常用的思路是先判断有没有上行呼叫且电梯当前位置在该呼叫楼层之下如果有则电梯应当上行。下行逻辑同理。听起来简单实际操作时会碰到一个细节如果电梯在2楼正在上行此时1楼有人按下行外呼电梯到达3楼后没有更新呼叫它要不要转头下去现实的电梯策略是先响应完当前方向上的所有呼叫再响应反方向的呼叫。这叫做顺向截梯。三层电梯虽然不需要处理那么复杂的顺向调度但方向判定逻辑建议从开始就按这个思路写后续扩展多层时改动最小。第二个是呼叫信号的保持。外呼按钮和楼层内呼按钮按下后如果电梯还没到这个请求必须一直记住不能因为按钮松开就丢。所以PLC程序里通常用置位/复位指令来处理呼叫登记按钮按下→置位对应的呼叫位电梯到达该楼层完成开门动作→复位对应的呼叫位。这就是呼叫登记的思路。2.3 安全永远是第一优先级门锁与上下行互锁电梯不是玩具即便只是三层楼的教学模型安全逻辑也不能省。两个最基本的保护必须写进去门锁保护电梯运行前必须确认所有厅门、轿厢门已关好。工程上常把门锁信号串联成一个回路厅门锁、轿门锁全部闭合才导通接入PLC的一个输入点。程序里如果门锁信号不成立运行输出必须被强制切断。上下行接触器互锁上行接触器和下行接触器在硬件回路上要互锁即常闭触点串联到对方线圈回路PLC程序里输出时也要做软件互锁——同时只能有一个方向的输出为ON。这是考试和现场检查都会盯的点你永远不希望出现上下两个接触器同时吸合的情况。另一件容易被忽略的事是平层与减速的关系。实际电梯会在楼层附近设置减速信号换速感应器PLC检测到换速信号后先切断高速运行输出切换为低速爬行再检测到平层信号后停车。三层电梯实训模型通常不需要区分高速/低速但逻辑上要有运行到位后停止的准确判定否则很容易冲过楼层。这一点在后面梯形图实现时会详细讲。3. PLC选型与IO分配把15个输入输出点安排明白3.1 选型思路入门项目不必追求高端IO点数先算清三层电梯按最简方案配置输入输出大致如下。输入信号约10点1/2/3楼外呼上行按钮1楼不需要上行所以实际是2楼、3楼上行2点1/2楼外呼下行按钮3楼不需要下行所以实际是1楼、2楼下行2点轿厢内呼1/2/3楼按钮3点1/2/3楼平层感应信号3点也可以用接近开关或干簧管门锁/开门到位信号1点关门到位信号1点如果门机需要单独控制输出信号约6点上行运行输出1点下行运行输出1点开门输出1点关门输出1点楼层指示/到站提示可用7段数码管或者简单指示灯至少1~3点合计约16点输入、6点输出我习惯在选型时把输入做成12~14点、输出做成8点左右留一点余量方便调试时临时加信号。西门子S7-200 SMART的SR2012输入8输出继电器输出就是很合适的入门方案性价比高配合STEP 7-Micro/WIN SMART编程软件做组态仿真时走S7协议或Modbus TCP都方便。三菱FX3U系列也可以输入继电器X、输出继电器Y的分配方式直观很多技校教材都用它。汇川、信捷这些国产PLC现在也做得不错尤其是信捷的XC系列配自家的组态软件XCPPro学习和调试成本更低。这个项目选PLC时有一点要提醒一定要选带网口的型号。组态仿真最常用的通讯方式就是以太网如果用老款只有串口的PLC比如S7-200 CN的PPI口连组态软件时还得加USB转485的线调试效率低不少而且通讯参数的坑会多到你怀疑人生。3.2 一张IO分配表解决90%的接线混乱不管用哪家PLC我强烈建议在动手写程序前先做一张IO分配表。这张表不仅是接线图纸的根据也是组态画面变量登记的底稿。下面是我做三层电梯项目时常用的一张表点位PLC地址信号说明传感器/按钮安装位置备注输入I0.01楼平层感应1楼平层开关常开到位闭合输入I0.12楼平层感应2楼平层开关常开到位闭合输入I0.23楼平层感应3楼平层开关常开到位闭合输入I0.31楼下行外呼1楼厅外按钮置位登记到达后复位输入I0.42楼下行外呼2楼厅外按钮置位登记到达后复位输入I0.52楼上行外呼2楼厅外按钮置位登记到达后复位输入I0.63楼上行外呼3楼厅外按钮置位登记到达后复位输入I0.7轿厢内呼1楼轿内按钮置位登记到达后复位输入I1.0轿厢内呼2楼轿内按钮置位登记到达后复位输入I1.1轿厢内呼3楼轿内按钮置位登记到达后复位输入I1.2门锁闭合信号各门锁串联回路运行必要条件输出Q0.0上行运行上行接触器线圈与Q0.1软件互锁输出Q0.1下行运行下行接触器线圈与Q0.0软件互锁输出Q0.2开门输出开门接触器线圈开门到位后停止输出Q0.3关门输出关门接触器线圈关门到位后停止输出Q0.4电梯运行指示蜂鸣器/指示灯可接楼层数码管登记地址的时候要特别注意一点平层感应信号的触发方式。现实里平层开关一般用常开型如干簧管电梯轿厢上的隔磁板插入时触点闭合组态仿真里模拟这个信号时通常用按钮或者组态画面里的轿厢位置动画联动这一点到第5章组态部分再展开。3.3 程序中必备的辅助继电器规划先规划好IO再规划内部软元件。我把整个程序里用到的内部继电器按功能分组这样写梯形图时思路不乱呼叫登记区M0.0~M0.6对应7个呼叫输入4个外呼3个内呼每个输入按钮接一个置位线圈对应的复位条件放在程序后段。楼层状态区M1.0~M1.2表示电梯当前所在楼层由平层感应信号触发更新。也可以用寄存器直接存楼层号但三个M继电器按位表示更直观组态读取也简单。状态标志区M2.0空闲待机、M2.1上行运行、M2.2下行运行、M2.3开门、M2.4关门用一个字节寄存器里的位来标识当前状态。运行条件区M3.0上行请求汇总有任一上层呼叫、M3.1下行请求汇总、M3.2本层呼叫。这样规划之后后面写梯形图相当于往这些规划好的格里填逻辑程序结构会非常清晰比想到哪写到哪强太多。4. 梯形图逻辑分块实现呼叫登记、方向判定与运行控制写PLC程序最忌讳的就是把所有逻辑堆在一个网络里。拿到IO分配表和内部软元件规划后我会把程序分成几个功能块按顺序排列初始化块 → 呼叫登记块 → 楼层检测块 → 方向判定块 → 运行输出块 → 开关门控制块 → 复位与互锁块。每块负责一件事出了问题也好定位。4.1 呼叫登记与清除置位和复位之间的逻辑闭环呼叫登记块是所有后续逻辑的输入源。以2楼上行外呼I0.5为例梯形图可以这样写Network 1 // 外呼上行登记 LD I0.5 // 2楼上行按钮按下 S M0.1, 1 // 置位2楼上行呼叫登记位 Network 2 // 2楼上行登记复位 LD M1.1 // 电梯当前在2楼平层感应 A M2.3 // 且电梯处于开门状态 A I1.2 // 且门锁闭合/开门到位说明电梯确实在执行开门动作 R M0.1, 1 // 复位2楼上行呼叫登记位这里有一个细节值得说明复位呼叫位的条件不能只看电梯当前在该楼层必须加上电梯已经具备开门条件这个约束。原因是电梯可能在运行中瞬间经过2楼比如从1楼去3楼时路过2楼不停如果只按平层信号复位呼叫就会被路过误清除。加开门条件后只有电梯真正在该楼层停下来开过门呼叫才被清除这更接近真实电梯的行为。实测中这也是初学者最容易犯的逻辑错误之一。内呼登记逻辑与外呼完全一致只是复位条件里多了一个前提乘客按下内呼按钮的楼层就是目标楼层所以只要电梯到达该楼层并开门就必须清除对应的内呼位不需要额外考虑运行方向。4.2 方向判定先响应同向呼叫再考虑反向方向判定是整个程序里最考验逻辑思维能力的一部分。我用的是一种简单又稳妥的实现方式上行运行条件Q0.0输出条件电梯处于运行允许状态门锁闭合、无故障且存在任意一个高于当前楼层的有效呼叫且当前没有更高楼层的呼叫需要下行响应或者说同向优先具体梯形图判断时我习惯按楼层展开而不是按呼叫类型展开。比如当前电梯在1楼上行条件简化为2楼或3楼有任何呼叫登记不管外呼还是内呼电梯就发出上行运行信号。当前在2楼时只有当3楼有呼叫登记才上行当前在3楼时上行条件必然不成立。下行运行条件对称处理电梯在3楼时1楼或2楼有任何呼叫就下行在2楼时只有1楼有呼叫才下行在1楼时下行条件不成立。写到这里有一个非常关键的点必须展开讲运行方向输出不等于电机一直转。Q0.0得电推动电梯上行但当电梯到达目标楼层、平层感应信号到来时必须先切断运行输出再执行开门动作。如果你把上行运行等同于上行接触器一直吸合电梯就会冲过平层位置这在实训台上一眼就能看出来在实际井道里叫蹲底或冲顶是重大事故隐患。所以我在运行输出块里做了这样的约束上行运行输出 上行方向判定条件 AND NOT 当前楼层平层信号 AND NOT 开门状态 AND NOT 关门动作中。留平层信号这个闸门是为了确保电梯到位时绝对不带着动力继续走。下面这段是方向输出的梯形图范例Network 3 // 上行运行输出 LD M3.0 // 有上行请求 A I1.2 // 门锁闭合 AN I0.0 // 不在1楼平层 AN I0.1 // 不在2楼平层 AN I0.2 // 不在3楼平层 AN M2.3 // 不在开门状态 AN M2.4 // 不在关门状态 AN Q0.1 // 与下行输出互锁 Q0.0 // 输出上行这里把不在1/2/3楼平层全部串联逻辑上等价于电梯处于楼层之间的位置但实际项目中更推荐用一个中间继电器M2.5来表示电梯运行中既可以当状态标志也可以减少梯形图中串联触点的数量。4.3 开关门逻辑到位信号与定时器配合电梯到达目标楼层后PLC程序自动进入开门流程。开关门控制我一般用定时器实现自动关门开门输出得电后开始计时开门持续时间到比如设定5秒自动转为关门输出关门输出得电后如果检测到关门到位信号或者开门按钮被再次按下立即停止关门并重新开门。这里需要引入一个小的防夹逻辑关门过程中如果门锁回路断开了表示有人在厅门口阻挡程序强制转为开门并延时后再尝试关门。在实训模型上可以用一个常闭按钮模拟这个信号。虽然三层教学项目没有实际安全触板但把这段逻辑写进去能培养良好的安全编程习惯。开门输出与运行输出之间也要做硬件级的动作互斥。运行的时候门必须锁死开门的时候运行输出必须为零这两个动作在现实中不可能同时发生。我在程序中用了一个简单可靠的做法把Q0.0、Q0.1的输出回路都用门锁信号和开门动作信号做串联切断从逻辑上保证运行与开关门绝对互斥。4.4 楼层计数与位置显示收到平层信号后程序要更新当前楼层状态。这里有一个常见的实现技巧不要用累加计数的方式跟踪楼层因为一旦发生溜车或信号干扰计数就会错位后续所有判断全乱套。正确的做法是以平层感应信号为准直接锁存当前楼层。梯形图实现很简单I0.0接通时把M1.0置位、M1.1和M1.2复位I0.1接通时把M1.1置位、其余复位I0.2接通时同理。这样当前楼层永远等于最后一次平层信号所在的楼层不受运行次数和方向影响。这段逻辑虽然不起眼但恰恰是程序可靠性的基石。楼层显示的输出可以直接用Q点驱动数码管也可以用组态画面的文本动画来做。组态仿真时我习惯把M1.0~M1.2三个位在画面里做成电梯当前位置的颜色变化比数码管更直观。5. 组态仿真把程序搬到屏幕上让电梯动起来PLC程序写完下一步就是组态仿真。这个环节最大的作用是在不上电、不接线的情况下验证程序逻辑是否正确。做组态仿真时有个原则需要先说明——组态画面里的轿厢运动本质上是根据PLC反馈的楼层信号来做位置映射而不是组态软件自己模拟电梯运行。搞清楚这个关系后面调试才不至于混淆。5.1 通讯配置选对协议地址映射一个都不能错我以西门子S7-200 SMART配合组态王/WinCC为例讲通讯配置。第一件事是确认PLC侧已经开启了允许远程访问以太网端口IP设置好比如192.168.1.10电脑网卡IP设在同一个网段比如192.168.1.2然后用PING命令确认能通。组态软件里新建设备时会让你选择驱动类型S7-200 SMART对应的驱动通常是S7-TCP西门子以太网协议通讯参数里要填PLC的IP地址、机架号和槽号。这里有个实操经验很多初学者按旧版S7-300的默认参数机架0、槽2去填结果连不上换成S7-200 SMART专用的机架0、槽1就好了原因是S7-200 SMART的通讯数据块映射位置与300不同。变量连接是组态里最容易出错的一环。组态软件的变量要和PLC里的IO地址一一对应组态变量名PLC地址数据类型用途Up_Request_3FM0.6位3楼上行外呼登记In_Call_1FM0.5位轿厢内呼1楼Floor_1M1.0位1楼平层状态Door_OpenQ0.2位开门输出Up_RunQ0.0位上行运行Current_Floor通过三个位组合整型/枚举画面楼层显示接线组态时有一个特别常见的坑PLC的I点作为输入在组态画面里做按钮来触发这一般是做不到的。组态软件可以读I点状态但如果你想把画面上的开关按钮直接写到PLC的I点大部分组态软件并不支持或者需要特殊驱动因为I点的物理属性决定了它只能被外部硬件驱动。正确的做法是画面上所有可操作的按钮全部对应PLC内部的M继电器或V寄存器按钮按下时把对应的M位置位。我把这种做法叫虚拟输入镜像——用M点模拟I点的功能程序里读取的是M点实际接线按钮时再把I点与M点做一次并联映射。这样同一个PLC程序既能接实体按钮也能被组态画面控制两不耽误。5.2 画面设计轿厢动画、指示灯、楼层显示画面布局我通常分成三个区域左边是井道立面图画一个细长矩形代表楼层1楼、2楼、3楼分别标出平层位置每层放一个指示灯绿色平层指示灯。轿厢用一个矩形色块表示它的垂直位置由当前楼层变量驱动。组态软件里这个位移可以用垂直移动动画连接把轿厢图元的移动值绑定到Current_Floor变量1楼对应位置0、2楼对应位置50、3楼对应位置100单位是像素或者组态的百分比。中间是操作面板放外呼按钮2楼上行、2楼下行、3楼上行、1楼下行每个按钮旁边放一个指示灯显示呼叫登记状态对应M0.x再放轿厢内呼按钮1楼、2楼、3楼和对应的内呼指示灯对应M0.5、M1.0等。右边是状态指示区显示电梯当前状态上行/下行/停止/开门/关门可以用不同颜色的文字或指示灯表示。轿厢位移动画有一个注意点组态画面中需要实时读PLC的楼层状态位以及运行输出位如果只有楼层信号画面只能显示当前位置在几楼轿厢是瞬间跳变的缺少电梯爬楼的中间过程观感很生硬。改进方法是在组态软件里用脚本比如组态王的事件命令语言、WinCC的C脚本读取运行方向信号然后以一定的时间间隔把轿厢图元往目标楼层方向移动若干像素走到对应楼层位置后停止。这样模拟出来的加减速爬楼过程非常接近实物效果。这个脚本本质上就是用组态软件模拟电梯的中间运动过程而PLC本身只输出方向和楼层状态。模块分工明确调试时思路不会乱。5.3 仿真联调的步骤与验证清单联调时我习惯按下面的顺序走确认PLC程序与组态通讯正常组态软件里做一个心跳变量比如PLC里M2.7每秒翻转一次画面显示该变量的状态如果画面上的心跳在闪说明通讯链路没问题。验证外呼登记在画面上点击3楼上行外呼按钮PLC侧对应M0.6置位外呼指示灯常亮。验证方向与运行电梯在1楼存在3楼呼叫观察PLC输出Q0.0置位画面上轿厢开始上行方向指示灯显示上行。验证平层停车轿厢移动到3楼位置组态脚本模拟到位PLC收到平层信号后复位运行输出Q0.0断开M2.3置位进入开门状态。验证呼叫复位开门动作执行后外呼登记位复位指示灯熄灭内呼登记同理。验证互锁在电梯运行中手动置位下行输出条件观察Q0.0是否因为互锁条件而保持为OFF。整个联调过程建议按功能逐条过的方式做记录哪一步没通过就回头查程序逻辑。组态仿真阶段的bug90%集中在变量地址映射错误和呼叫复位条件不完整这两类不需要过度怀疑通讯问题。6. 实测中的主要坑信号抖动、双层呼叫与组态卡顿下面这些都是我在调试三层电梯仿真系统时真实遇到并花时间解决过的问题属于那种文档里不写、但跑一遍必踩的坑。6.1 平层信号的抖动与误触发平层感应开关如果用的是机械式限位开关或者干簧管在电梯慢速爬行时开关刚接触的瞬间会产生抖动PLC一个扫描周期可能读到多次通断变化。如果程序直接把平层信号用于楼层锁存轻微抖动会导致楼层状态反复跳变。解决思路在程序里加入去抖延迟平层信号接通后延时50ms再更新楼层标志可以使用定时器实现。或者在组态画面里把平层信号的触发做成手动点头方式比如按一下画面按钮模拟轿厢到达避免信号毛刺干扰验证结果。6.2 2楼的双向外呼同向优先如何落地2楼比较特殊它同时有上行外呼按钮和下行外呼按钮。实际场景是电梯从3楼向下运行经过2楼如果此时2楼的上行外呼被按下电梯应不应该停按同向优先原则电梯正在下行只响应2楼的下行外呼不应该被上行外呼截停。程序中这一条必须明确正在下行时2楼上行外呼登记不参与本次运行的目标判定。梯形图里做这个逻辑时我的做法是Network 4 // 下行运行条件 LD M3.1 // 有下行请求1楼下行或2楼下行 A I1.2 // 门锁闭合 AN I0.0 AN I0.1 AN I0.2 AN M2.3 AN M2.4 AN Q0.0 Q0.1关键在于当电梯下行经过2楼时如果只有2楼上行外呼被登记M0.11M3.1不会增加一个斜体条件去判定它因为M3.1汇总的是下行方向的呼叫2楼上行外呼不在其中。这样电梯就会直接越过2楼继续下行到1楼。等到1楼完成向下方向的响应后程序回到空闲状态再重新检测M0.1电梯才会变为上行。这个先顺向、后反向的行为逻辑做完之后用组态仿真验证一次就非常清晰。6.3 组态画面操作与PLC扫描周期的配合问题组态软件的画面按钮按下时实际是往PLC里写一个M点的值然后等待PLC程序响应后又复位。这个过程有时间差组态软件一个按钮动作可能持续几百毫秒而PLC扫描周期可能是几十毫秒。如果按钮置位和程序复位之间出现竞争可能发生这种情况——画面按钮把M0.6置成1电梯程序开始响应但此时用户觉得按钮卡了又点了一下M0.6再次被置位。结果就是呼叫登记位反复横跳画面上的指示灯闪烁。我的处理办法是在组态脚本里给按钮做防重复触发按钮按下后立即把自身置为不可用Disable等PLC侧返回该呼叫登记位的状态为ON、且确认电梯已经开始响应即运行输出或开门输出已动作后再恢复按钮可用。这个交互逻辑虽然只是教学项目但对理解上位机与PLC的交互时序非常有帮助。6.4 仿真通过后上实物前必须查的三个硬件点如果条件允许仿真验证完整后会建议去实物实训台或真实设备上再做一遍。从仿真切到实物有三个地方必须重新检查外部按钮的接线常开/常闭软件里默认按钮接常开实物接线时如果有人接成常闭程序逻辑全反。接触器互锁触点是否真实接入了线圈回路即使程序里做了软件互锁硬件回路也必须再串一组互锁触点这是安全冗余的基本原则不能省。平层开关的安装位置实物的平层开关装在轿厢上隔磁板装在井道里两者相对位置决定了停靠精度。程序逻辑没问题但停车位置偏上或偏下往往都是机械安装问题不要急着调程序。7. 项目后续可以怎么扩展给想继续深化的人几条路三层电梯整套做完并且仿真通过后这个项目其实已经具备了很好的扩展基础。我个人建议按下面几个方向继续深化难度循序渐进每一步都能学到新东西。第一加楼层数。把三层扩展到五层、六层甚至八层时你会发现外呼登记、内呼登记的逻辑虽然看起来只是多了几路但方向判定的复杂度显著上升——中间楼层既有上行外呼又有下行外呼同样方向优先和顺向截梯的实现会变得更加关键。这时可以考虑引入运行方向标志的独立管理用一个M位表示当前是上行趋势还是下行趋势每层楼的呼叫在判断时先按趋势方向过滤再按楼层关系比较。这类思路去面试时讲出来比只说我做过三层电梯要有说服力得多。第二接入更真实的调度策略。现实中电梯除了顺向截梯还有最远方向反向折返满载直驶防捣乱呼叫等调度策略。虽然三层模型很难完全复现这些策略但可以在方向上做简化版的全域扫描调度PLC每隔一段时间扫描一次所有登记状态找出当前方向上最远的呼叫楼层作为目标楼层。这个逻辑做好了再去接触真正电梯控制系统里的调度模块底层思路是相通的。第三把组态换成真实触摸屏。很多实训项目做完组态仿真后下一步是接一块真正的HMI触摸屏比如昆仑通态、威纶通、西门子Smart Line。触摸屏通过串口或以太网直接连PLC画面里的按钮、指示灯、轿厢动画全部重新做一遍。这一步能让你理解上位机组态和HMI画面在通讯与变量绑定上的差异实际做工控项目时二者经常互相切换。第四尝试加入变频器控制。三层电梯教学模型如果用异步电机加变频器驱动程序里需要增加多段速控制启动时高速运行、接近目标楼层时切换中速、平层前切换到低速爬行。三菱、西门子、汇川的变频器都有多段速输入端子PLC用两个或三个输出点组合出不同的速度段。这个扩展会把整个项目从逻辑控制拉升到逻辑传动的层面涉及到的知识量翻倍含金量也翻倍。第四点我自己在带新人时很推荐因为变频器的加减速时间、多段速信号延迟和启停防溜车这些问题都是实际设备上天天会遇到的事。第五用高级语言做一套数据采集。基于OPC UA或Modbus TCP协议用Python、C#或Node-RED把PLC里的运行状态实时读出来比方说当前楼层、运行方向、呼叫登记情况、累计运行次数。可以存进数据库做简单分析也可以搭配Web页面做一个电梯运行监控仪表盘。这一步把工控系统向工业物联网方向延伸了一步也是近年来面试中很常见的加分点。8. 写在最后的几点个人体会做这个三层电梯项目我自己收获最大的反而不是电梯本身而是养成了一套从需求到拆分到编码到验证的工程习惯。很多本科毕业或者自学PLC的朋友容易犯一个毛病拿到项目就开始写梯形图边写边想写完就下载到PLC里试出了问题再回头一个个网络地找。这种盲目调试的方式在小程序里还能凑合一旦程序超过两三百个网络就会把自己绕进去。我现在的做法是严格执行前面讲的顺序先列IO表再规划内部软元件然后分块写逻辑每写完一块就注释清楚最后用组态仿真把每条功能路径过一遍。看着多花了一点时间实际上省下的调试时间是这个时间的好几倍。尤其是做组态联动时变量名规范统一会带来极大的便利——我遇到不少同行在组态软件里用的变量名和PLC程序里的注释对不上一查变量映射就得来回翻两套文档非常痛苦。再分享一个小技巧组态仿真的联调阶段把PLC的扫描周期故意调慢一点比如人为在程序中加延时更容易观察信号变化的先后顺序。正常设备的扫描周期是几十毫秒肉眼根本跟不上信号谁先谁后根本看不出来。把关键动作之间加上500毫秒的延时你就能在画面上清楚看到外呼置位→方向输出→运行中→平层→开门→呼叫复位这个完整链条是否按预期顺序进行。这个习惯帮我抓出过好几次逻辑顺序错误。如果你是初学者建议按照这篇文章的顺序走一遍完整流程。如果你已经做过类似项目可以重点看看第6章那几个坑和后面的扩展方向或许能带给你一些新的切入点。设备无论大小底层逻辑和方法论是通用贯通的三层电梯的功夫练好了后面换其他设备上手会顺很多。