简介这是一份面向电气自动化、楼宇智能化及电梯控制教学场景的PDF文档系统讲解电梯控制流程图的核心知识点。内容涵盖电梯上下行流程、外呼响应流程、开关门控制流程三大模块并给出最远反向呼梯响应、平层开关门延时等关键逻辑说明可直接用于课程设计、毕业设计或电梯控制原理自学。文档共1个PDF文件压缩包整体仅363KB清晰完整、支持编辑与打印。目前已有489人学习下载适合控制类专业学生、电梯维保人员及嵌入式开发者用作方案参考。文档以流程图加文字说明的形式呈现可帮助读者快速理解电梯调度与楼层选择机制并掌握PLC/单片机实现电梯控制时的逻辑分支设计思路。 收到一份《电梯控制流程图.pdf》是什么体验我在自动化项目里接过不少这样的文件第一眼觉得图挺规整矩形框、菱形判断、几个箭头层级也清楚。可真正到了写控制程序的时候问题全冒出来了——门明明关着为什么流程图上没画“关门途中有人挡门”这条线电梯在3楼往上跑5楼有人按了向下7楼也有人按了向下到底该听谁的流程图里一个“判断是否有召唤”的菱形背后其实是整整一套调度算法。这篇文章想跟你聊透电梯控制流程图它到底画什么、核心逻辑怎么组织、从图到代码怎么落地以及在真实项目里最容易画错、想漏的地方。内容偏向控制逻辑设计适合做PLC、嵌入式控制的工程师正在做毕业设计或竞赛的学生以及需要跟研发对齐需求的产品经理。1. 先搞明白电梯控制流程图到底在画什么1.1 一份流程图背后牵着的四大子系统电梯控制流程图不是凭空画的它是对一套实时控制系统的抽象描述。很多初学者一上来就找“电梯控制流程图模板”结果套了一个不完整的图越改越乱。要画对图你得先知道电梯控制到底分哪几块召唤与输入系统轿厢内选层按钮也就是内呼、每层上下行按钮外呼、轿厢内开关门按钮、超载开关、消防钥匙开关等。这是流程图的“事件来源”。位置与测速系统各楼层的平层感应器、门区开关、减速点限位、曳引机编码器、上下端站限位。流程图里的“是否到达目标楼层”“是否开始减速”全靠这些信号做判断依据。驱动与执行系统曳引机正转向上、反转向下、变频调速、抱闸、开门机、门锁回路。这是流程图的“动作出口”。安全与保护系统急停回路、安全钳信号、限速器信号、超载、断电平层、消防联动等。它们的特点是“随时可能触发”而且一旦触发必须接管控制权。在画流程图的时候不需要把四套系统的每个信号都变成图上的一个节点。图要表达的是逻辑关系哪些输入条件组合起来触发什么状态变化最终输出什么动作。信号采集和硬件细节可以放到另一个层面的“接线图”或“变量表”里去管。我见过最典型的错误就是把传感器信号、按钮扫描、电机动作全都画到一张图里结果一张A3纸不够用缩印之后字都看不清审图的人根本没法给出有效意见。1.2 电梯控制为什么天生适合用“状态机”来组织电梯控制和普通顺序控制最大的不同在于召唤事件是异步到达的。你没法预知下一秒有人按几楼也没法让乘客“排队等待”到一个合适的时机再按按钮。电梯必须随时响应、随时决策而且决策还要连贯——不能因为中途来了个新召唤就把当前运行方向改掉那样电梯会在楼里来回抖。这就是典型的离散事件系统。对付这种系统最合适的就是状态机模型任意时刻电梯必然处于且只处于一个状态某个事件发生之后根据当前状态和事件类型迁移到下一个状态。流程图本质上就是状态机的可视化表达菱形判断是事件条件箭头是迁移方向矩形是迁移过程中执行的动作。用个生活类比电梯像一个银行柜台多个队伍各楼层召唤同时排着柜员轿厢一次只能服务一个方向处理完当前方向的任务之后才换队列。流程图就是把这个“服务规则”写下来让程序员和调试人员看着同一份规则干活。理解了这一层你再看任何一张电梯控制流程图都会觉得它不过是在回答三个问题现在在哪个状态发生了什么事件下一步去哪个状态2. 拆开电梯的决策脑状态、召唤与方向算法2.1 六个基础状态与它们之间的切换条件状态是电梯控制流程图的骨架。无论图多复杂基本都能归纳为六个基础状态我用表格列出来方便对照状态含义进入条件离开条件待机停在某层无召唤门保持关闭初始化完成或完成一次运行后无新召唤出现新的有效召唤开门门正在打开到站平层或待机时收到召唤需要开门开门到位信号有效开门保持门打开等待乘客进出开门到位延时结束或收到关门指令关门门正在关闭延时结束或乘客按关门键门锁接通或触发防夹运行轿厢正在上行或下行门已完全关闭且门锁接通到达目标楼层并完成平层故障/紧急急停、超载、消防等异常状态任意状态下收到故障信号故障消除且完成复位流程这里有个设计取舍要讲清楚运行状态要不要拆成“上行运行”和“下行运行”两个状态拆的好处是流程图里能少一个方向变量看起来直白坏处是几乎所有涉及运行的判断都要写两份图会膨胀一倍。我自己的做法是保留一个运行状态另外单独维护一个方向变量向上/向下/无这样主流程只需要一套运行逻辑方向只参与“到站判断”和“方向决策”这两个环节。实际项目里这两种画法都有人用但如果你画的是单台电梯的完整控制图我建议用后者扩展性明显更好。2.2 内呼、外呼怎么合并成一张召唤表召唤是电梯的“任务来源”但内呼和外呼的逻辑含义不一样处理方式也因此不同。内呼是乘客在轿厢里选的目标楼层意味着“无论电梯现在往哪个方向走只要这个楼层出现在前方路径上就必须停靠”。外呼是乘客在楼层上按的分成上行和下行两种它表达的是“我希望电梯往这个方向来”。实际工程里一般不会为内呼、外呼分别维护两套复杂的决策逻辑而是统一登记到一张按楼层索引的召唤表里每条记录带方向属性。比如楼层内呼标志上行外呼下行外呼5F0107F0012F101内呼置位时方向栏可以不区分因为它不参与方向决策只参与“是否停靠”的判断外呼则必须区分上下行因为它是方向决策的直接输入。这里的核心规则是内呼可以拦停任何方向经过的电梯而外呼只能拦停沿对应方向经过的电梯。比如电梯正在下行经过5楼时5楼的内呼可以把它拦停但5楼的上行外呼不能把它拦停因为电梯下行时停靠5楼乘客是要上楼的方向和客流不一致停开门不仅低效还会让乘客产生困惑。2.3 顺向优先与最远端反向调度算法的核心单台电梯的调度核心就一句话顺向截梯反向到最远端再换向。听起来简单实际画起来很多人就乱了。举个例子电梯当前在3楼正在向上运行。此时5楼有人按了上行外呼7楼有人按了下行外呼2楼有人按了下行外呼。电梯的决策过程是这样的当前方向是上行优先响应上行路径上的顺向召唤。5楼的上行外呼是顺向的所以电梯继续上行到5楼停靠、开门。停靠5楼并重新检查当前方向上行上已经没有其他顺向召唤了但7楼还有一个下行外呼。这个召唤虽然在反方向但它位于电梯当前所在位置的上方。按“最远端反向”规则电梯继续上行到7楼随后换向为下行在7楼停靠并开门响应这个下行召唤。换向后下行方向有2楼的下行外呼于是电梯一路下行到2楼停靠、开门。至此召唤表清空电梯在2楼进入待机关门。很多新手在这里犯的错是以为电梯到5楼后应该立刻掉头向下结果7楼的下行召唤永远等不到电梯。记住了反向召唤只有在“当前方向无顺向任务且该反向召唤位于电梯继续前行的路径上”时才通过“继续前行到最远端再换向”的方式响应。这个规则保证了电梯不会在运行方向上反复横跳乘客等待时间也不会因为换向而无限拉长。流程图里方向决策必须画成一个专门的判断环节把它放在“每次停靠开门之后”和“从待机启动之前”这两个位置其他位置不应出现方向重算。3. 动手画图从顶层主流程到子流程的拆分规范3.1 顶层主流程的骨架与循环方式电梯控制流程图最忌讳“一张图画到底”。正确做法是分两层顶层主流程只画状态骨架具体动作全部用“预定义处理”节点指向子流程。你可以把顶层主流程想象成电视剧的目录页每个章节对应一集具体剧情在那一集里演。顶层主流程的骨架一般长这样LOOP: 扫描内呼、外呼按钮更新召唤表 检查安全回路急停、超载、消防等 若安全异常 → 进入故障子流程跳过本轮 CASE 当前状态: 待机: 召唤表为空 → 保持待机 召唤表非空 → 确定方向进入关门随后运行 运行: 到达当前方向的顺向目标楼层 → 减速、平层、停车进入开门 未到目标楼层 → 继续运行同时接收新召唤 开门保持: 延时未到 → 保持 延时到或收到关门指令 → 进入关门 关门: 门锁未接通 → 继续关门检测防夹 门锁接通 → 进入运行 故障: 执行故障子流程等待复位 END CASE END LOOP顶层主流程只回答“现在处于什么状态、下一步去哪个状态”不回答“门怎么开、力矩怎么设”这类细节。这样做的好处是哪怕电梯有几十个输入信号主流程的核心循环也能控制在二十行以内。审图的人拿到PDF先看主流程五分钟就能理解整个电梯的行为框架然后再按编号去翻子流程效率高得多。3.2 必拆的三个子流程门、平层、安全主流程里最典型的预定义处理节点有三个门控子流程、平层子流程、安全与故障子流程。这三个子流程几乎每台电梯都要画而且它们各自都有“一个环节内多个分支子流程”的情况正好借此说清楚子流程怎么展示。门控子流程里从“关门”状态出发至少要分出三个分支一是正常关门到位进入运行二是关门途中检测到光幕或安全触板信号重新打开门三是关门过程超过规定时间仍未到位输出关门超时报警。这个子流程单独画一页编号SP-01主流程里只需要一个“门控”节点旁边标注“见SP-01”。子流程页内部如果有多个分支建议用编号B1、B2、B3标在分支线上并在页脚配一个分支说明表审图的人不用反复比对就能看懂每个分支触发的条件和动作。平层子流程解决的是“电梯怎么准停”的问题运行过程中先经过减速点从高速切换成低速爬行平层感应器产生触发信号后控制抱闸动作完成停车最后还要用门区信号确认轿厢确实停在了可开门的安全区域内。有的系统把平层和开门之间的逻辑做成联锁平层信号没到位即便门区信号到位也不允许开门这个联锁条件建议在平层子流程末尾明确画出来。安全与故障子流程是把急停、超载、消防、断电平层等所有异常情况集中到一张“优先级表”里处理。为什么要把它们集中画因为如果每一种异常都画进主流程主流程里的判断线会多到没法看。集中处理之后主流程只需要保留一个“安全回路是否正常”的判断入口具体异常类型和处置动作全部下沉到子流程。3.3 图元、泳道与绘图工具的选择画电梯控制流程图图元规范很重要。流程图形状代表的意思虽然各工具大同小异但团队内部最好统一不然换个人读图就容易产生歧义。我常用的约定是这样图元形状含义起止圆角矩形/胶囊流程开始、结束处理矩形执行一个动作或赋值判断菱形条件分支至少两个出口输入输出平行四边形读传感器信号、写控制输出预定义处理左右带竖线的矩形引用某个子流程文档矩形下边波浪线生成记录、告警或报表还有一个容易被忽视的技巧用泳道。电梯控制涉及“轿厢侧信号”“控制板逻辑”“曳引机与门机执行”三个不同角色用三条泳道把它们分开每个图元放进对应的泳道读者一眼就能看出信号从哪来、动作由谁执行。比如“召唤按钮扫描”放在轿厢侧泳道“方向决策”放在控制板泳道“变频器启动”放在执行泳道整个系统的信号流向非常清晰。工具方面我试过Visio、ProcessOn、draw.io、PlantUML。Visio适合企业环境模板多但收费ProcessOn在线协作方便适合多人评审draw.io免费且支持离线最推荐日常用PlantUML适合习惯用文本描述流程图的工程师改起来快但画复杂分支时不如鼠标工具直观。无论选哪款最后输出PDF交付时记得把“图例”放在第一页或末页PDF是给人审的没有图例的流程图在会议桌上会被反复问同一个问题“这个双竖线框是什么”4. 流程图里最容易被画错的三类边界场景4.1 关门中途重新开门防夹时序怎么表达这是我在评审图纸时见过最多的问题。很多入门版本的流程图把关门画成一条直线关门 → 门锁接通 → 运行。但真实电梯在关门过程中随时可能有人伸手挡门光幕和门缘安全触板会给出防夹信号。正确的画法是从“关门”状态拉出一条分支条件是“收到防夹信号”目标状态是“重新开门”。光是加这条分支还不够这里有个实测中踩过坑的细节防夹触发后不能直接让流程跳回“开门到位”而是要回到“开门”状态的起点重新执行一次完整的开门动作。有工程师图省事把防夹分支直接指向“开门保持”结果门还没开到一半防夹信号消失流程又跑到关门门就在中间来回抖动乘客看了都害怕。门机是带速度曲线控制的开门动作没走完就反向关门还容易造成门机过流报警。另外光幕连续触发多次比如一直有人进出电梯要有“关门超时报警”和“强制关门”机制。这部分逻辑建议放在门控子流程里用计数变量实现连续触发N次后降低关门速度并鸣响提示音而不是无限期地重新开门否则高峰期轿厢门永远关不上整个电梯就瘫痪了。4.2 消防与急停为什么必须做成“打断”而不是“分支”电梯运行中急停和消防这类信号与正常流程的关系不是普通的“分支”关系而是“打断”关系。打个比方正常流程是一篇正在播放的电影消防信号不是电影里的一个新剧情而是断电——整个播放活动都要暂停换到备用频道。反映到流程图里安全事件检查必须放在主循环的最开头而且状态优先级最高。任何状态下收到急停信号都要立刻停止运行、保持抱闸进入故障处理收到消防联动信号则要取消全部召唤登记把电梯直接开到指定层通常是首层或避难层开门并停用正常运行功能。如果把消防逻辑画成运行状态下的一个普通分支那就意味着你必须在待机、开门、关门、运行所有状态里各画一条消防判断线不仅图面冗余还容易漏掉某个状态造成“电梯在关门时收到消防信号却不响应”的致命漏洞。所以我的建议是在顶层主流程的LOOP开头专门放一个“安全事件检查”的预定义处理节点所有异常统一在这里拦截。图面上看是一个简单的节点实际上它承担了中断控制器的作用。这样画图面干净逻辑上也安全。4.3 运行途中新来的召唤同向插入与反向挂起电梯运行过程中召唤表不是静止的。3楼往上走5楼刚有人按了上行这个新召唤要不要在这次行程里响应当然要而且要在5楼停。这就是“同向插入”新召唤与当前运行方向一致且位于当前楼层前方应该立刻把该楼层加入当前行程的停靠列表。但如果是反向召唤就要挂起。比如电梯刚过3楼正在上行此时2楼有人按了上行外呼——这个召唤虽然方向是上行但楼层在电梯身后。电梯不能回头只能把这个召唤登记进召唤表等当前上行方向的全部任务完成后换向下行时再顺路处理它。很多流程图只画了“启动前扫描召唤”和“停靠后清召唤”漏掉了“运行中实时接收新召唤”这条路径。结果就是程序按图写好之后实测发现电梯经过5楼时明明5楼有人按了上行电梯却视而不见因为扫描召唤的代码只在停车后才执行。正确做法是在主循环的运行状态里每个扫描周期都刷新召唤表并持续判断“前方是否有新增的同向召唤”。流程图里的表现就是在“运行”状态框旁边多画一个实时判断分支指向“有顺向新召唤则更新停靠列表”。5. 把流程图翻译成控制代码一次完整映射5.1 状态变量、召唤表和流程节点的对应关系流程图不是交完就完的文档它最终要变成PLC程序或者嵌入式代码。翻译的第一步是把图上的概念映射到代码的数据结构上。“状态”对应一个枚举变量“方向”对应一个方向变量召唤表用标志数组或位图表示每个判断菱形对应代码里的if或switch分支。我习惯用C风格伪代码来做这个映射结构大致如下typedef enum { IDLE, OPENING, DOOR_HOLD, CLOSING, RUNNING, FAULT } ElvState; typedef enum { DIR_NONE 0, DIR_UP 1, DIR_DOWN 2 } ElvDir; uint8_t callCar[16]; // 轿厢内呼 uint8_t callUp[16]; // 各层上行外呼 uint8_t callDown[16]; // 各层下行外呼 ElvState state IDLE; ElvDir dir DIR_NONE; int curFloor 1;这样一张表的映射图就可以严格对应到流程图的每一个节点流程图里的“待机”就是枚举值IDLE“是否有本层召唤”就是callCar[curFloor] || callUp[curFloor] || callDown[curFloor]的判断“顺向扫描”就是遍历数组找下一个非零位。图和代码一一对应之后调试时拿着PDF就能定位到具体代码行沟通成本降一大截。5.2 主状态机的代码实现把流程图里的主循环写成代码核心是switch-case结构。每个case对应一个状态每个case内部用条件判断完成状态迁移结构如下void main_loop(void) { scan_calls(); // 扫描按钮更新召唤表 if (safety_fault()) { // 安全事件检查对应主循环开头节点 state FAULT; return; } switch (state) { case IDLE: if (has_any_call()) { dir decide_direction(); // 方向决策菱形 state CLOSING; // 进入关门 } break; case RUNNING: if (is_next_target(curFloor, dir)) { level_and_stop(); // 平层子流程 clear_current_call(curFloor, dir); // 清除已服务召唤 state OPENING; } // 实时处理同向新召唤单周期内刷新停靠列表 refresh_stop_list(dir); break; case DOOR_HOLD: if (hold_timer_expired() || close_btn_pressed()) state CLOSING; break; case CLOSING: if (door_locked()) state RUNNING; else if (obstacle_detected()) state OPENING; // 防夹重新开门 break; default: break; } }这里有两个在代码里容易出错、但流程图里看得清清楚楚的点。第一is_next_target必须同时考虑“楼层是否有召唤”和“方向是否顺向”不能光判断楼层。第二clear_current_call清除召唤时如果该楼层既有内呼又有外呼不能全部清掉外呼要区分方向清除否则会出现“电梯已经停过5楼了5楼的下行外呼还在”这种残留。写代码前先把这些细节在流程图和召唤表设计里定清楚写的时候就不会犹豫。5.3 从仿真到实测的验证清单流程图和代码都完成之后真正的考验才开始。我建议按下面这份清单逐项验证每项都能对应到流程图里的某条路径单层直驶1楼到3楼直接响应3楼内呼中途不停。多层连续同向3楼内呼、5楼内呼、7楼内呼依次置位电梯逐层停靠。同向插入上行途中新增前方同向外呼必须立刻加入停靠列表。反向挂起上行途中新增后方外呼本次不响应换向后响应。关门防夹关门过程中触发光幕门重新完全打开且没有抖动。超载保护超载信号有效时电梯不能关门启动蜂鸣器报警。急停/消防任意状态触发在待机、运行、开门、关门各状态下分别测试电梯行为符合故障子流程定义。断电恢复运行中断电恢复后电梯不丢层自动低速找平层并复位。这些测试项不是我想出来的而是每张流程图评审时大家反复问的问题积累下来的。仿真阶段可以用PLC编程软件或嵌入式模拟器跑逻辑重点看状态迁移是否符合流程图现场测试阶段则要拿着流程图逐条打勾任何一条对不上都要先改图再改代码而不是直接改代码绕过图中逻辑。图和程序不一致是后期维护最大的坑。6. 最后分享几条我在现场攒下的经验电梯控制流程图这个事画到后面拼的不是工具熟练度而是对边界场景的理解。我自己走过不少弯路印象最深的一条是画图时千万别一上来就想穷举所有情况那样只会把自己困在分支的海洋里。正确顺序是先画通一条“一切正常”的主线从待机到运行到开门再回到待机确保主线能闭环跑通然后把异常分支一条一条“挂”上去每挂一条就问自己一个问题这个分支在哪个状态可能发生发生后要去哪个状态有没有和已有分支冲突另一条经验是流程图是团队沟通的公约数控制在三级以内就够了。超过三层说明你把硬件细节或管理流程混进了控制逻辑该拆出去就拆出去。PDF交付的时候记得标注版本号和日期后期程序迭代一次图就要同步更新一次否则半年后你看着旧图调试新程序那种痛苦谁经历谁知道。还有一个小技巧特别想分享在子流程分支比较多的页面上用“分支编号分支说明表”的方式组织比每根线上写一长串文字清晰得多。分支说明表里写清楚触发条件、执行动作、下一节点审图的人不用眯着眼看线条交叉会议室里少吵一半的架。这些习惯看起来不起眼但一套成熟的控制系统流程图靠的就是这些细节才能在交付之后继续被维护、被复用。本文还有配套的精品资源点击获取