企业官网建设流程全解析

做PLC毕业设计或者工程实践，最怕遇到一类题目：看着名字就头疼，比如这个“三部十层群控电梯”。单说一部十层的电梯，梯形图已经够绕了，现在要三部电梯并在一起联动，很多人的第一反应是“这咋做”。但这个题目放在毕业设计里其实是个非常经典的综合性课题，硬件上覆盖传感器、变频器、触摸屏，软件上牵涉逻辑控制、通讯、调度算法，做完一遍，等于把PLC最核心的应用场景都练了一遍。我前前后后带过不少学生做这个题目，也亲手调过类似的系统，今天就把这套从设计到交付的完整思路拆开讲一讲。

这套设计到底是解决什么问题的？先说清楚。三部电梯如果各干各的，最直接的场景是：你在10楼按了下行，结果三部电梯里只有一台停在1楼往上走，眼睁睁看着需要等半天；或者三部电梯同时冲向同一个呼梯楼层，另外两层的外呼反而没人接。群控电梯要解决的就是这种“资源重复消耗”和“响应不及时”的问题——通过统一调度，让三部电梯像一支有编队的车队，谁的路径最优谁去接客，顺路的捎上，不顺路的避开。从硬件角度看，群控系统比单梯多的是一个“大脑”的决策层，其余传感器、执行机构都类似；从软件角度看，难点全在调度策略的落地。

这篇内容适合谁看？正在写PLC方向毕业设计的学生，尤其是选题是电梯、立体车库、物流分拣这类多站点系统的；做非标设备想引入多机协同控制的工程师；以及想搞懂“电梯群控到底怎么控制”的自动化爱好者。下文会覆盖硬件选型、I/O分配、调度策略、程序设计、调试经验、报告整理和答辩准备，全是实际做过的东西，直接拿去就能用。

1. 三部十层群控的设计难点：不只是三部电梯放一起

很多人以为群控就是把三台单梯程序复制三遍，再连几根通讯线。这是最大的误解。三部十层群控真正的难点在于：电梯之间需要“商量着干活”，而PLC的编程模式天生是“各管各的”，要让三个控制器协同决策，必须从架构层面重新设计。

1.1 单梯控制与群控的思维转变

一部单梯控制，核心是“轿厢在哪儿、谁按了键、往哪走、到站停”。程序里只要考虑自身的运行状态：运行方向、当前位置、内呼楼层列表、外呼请求。哪怕是十层楼，也只是多几个点位，逻辑本质不变，无非是“顺向截梯”的判断复杂了一些。

群控就不一样了。当超过一台电梯同时响应一个外呼时，系统必须回答三个问题：

• 哪个外呼指令分配给哪部电梯？
• 分配之后，其他电梯还里要不要响应这个楼层？
• 电梯运行途中出现新外呼，如何处理？

这三个问题单靠梯形图里的自锁互锁解决不了，需要引入“调度算法”这个抽象层。换句话说，群控系统在基础逻辑之外，必须有一段能够根据所有电梯的实时位置、方向、任务列表来计算“综合代价”的程序。这已经超出了传统PLC“顺序控制”的思维，更接近一个小型决策系统。

1.2 群控系统的核心组成

一套完整的三部十层群控电梯，从系统层面拆解包含以下几大块：

实际设计里，群控决策可以放在一台“主PLC”，其他两台作为“副梯”向主PLC汇报状态并接收指令；也可以用三台PLC通过网络互相广播数据，各自运行相同的调度运算逻辑。对于毕设题目，前者结构更清晰，程序调试也更方便，后者的健壮性更好（主PLC挂了其他梯还能独立运行），但调试难度高不少。

2. 硬件选型与I/O分配：这套配置是怎么定下来的

群控电梯的I/O点数远超单梯，选型之前必须把每个输入输出算清楚，否则PLC点数不够，后期加扩展模块会非常被动。这也是答辩时老师最爱问的环节，你答不出“为什么选这个CPU、为什么点位刚好够”就会露怯。

2.1 PLC型号与扩展策略

三部十层电梯，每部电梯自身需要处理的信号大约是：

• 输入：十层楼每层平层传感器（10个，可用井道隔磁板+干簧管，也可用编码器模拟）、上下限位（各1个）、轿厢内呼按钮（10个）、开关门到位信号（2个）、门锁回路（1个）、超载信号（1个）、安全回路（1个）、检修/消防信号（1个备用），合计约28~30个输入。
• 输出：上行接触器/变频器方向（2个）、抱闸控制（1个）、开门/关门继电器（2个）、楼层指示（约4位译码，可用数码管驱动模块减少点数）、方向灯、蜂鸣器等，合计约12~15个输出。

单部电梯稳定起见需要40~48个I/O点。如果选小型PLC（如西门子SR30/SR40、三菱FX3U-48M），单机正好。但群控还需要处理全楼的外呼按钮：每层上行和下行按钮（除首层只有上行、顶层只有下行外，10层楼合计20个按钮）、每层上下行指示灯（20个输出）。这些在每部电梯内部再单独占用I/O就不合适了，一般做法是：外呼信号接入群控主站PLC，主站通过通讯把分配结果下发到对应电梯的PLC。

所以硬件方案一般有两种：

方案A：三台小型PLC做轿厢控制 + 一台PLC做群控主站

• 优点：分工清晰，群控逻辑独立，报告好写，调试好定位。
• 缺点：四台PLC造价高，通讯数据量稍大。

方案B：三台PLC通过RS485/以太网互联，互为群控节点，外呼分散接入各部PLC

• 优点：省一台主机，结构更像真实商用群控系统。
• 缺点：调度算法要在每台PLC里重复写，若采用“令牌轮询”或“优先级竞争”机制，逻辑复杂度明显上升，对新手不友好。

毕设我推荐方案A，工程上常见、框图好画、答辩好讲。选型上可以用西门子S7-200 SMART（SR40）做轿厢控制，再配一台SR20做群控主站；或者全部用三菱FX3U系列，通过485BD板做N:N网络。如果实验室条件只能用一台PLC，那就只能做“三梯逻辑集中式”，也就是用一台大点数PLC同时处理三部电梯的所有输入输出和调度，这在验证算法上没问题，但物理布线上会非常复杂，用来交毕设课题尚可，实际工程意义不大。

2.2 I/O点数细算与实际分配

以方案A为例，四台PLC的点位分配我一般建议这样：

• 群控主站PLC：接入全楼20个外呼按钮（输入）、20个外呼指示灯（输出），再兼做触摸屏的数据代理，剩余空间做调度计算。20入/20出，选40点以内的主机足够。
• 1#/2#/3#轿厢控制PLC：每台处理轿厢内呼、传感器、门控等，约30入/14出，选40~60点主机。

这里有个经验：不要在选型时把点数卡得刚刚好，一定要留10%~15%的备用量。实际调试中经常会出现“这个信号单独接个继电器”“那个传感器需要复用一个点”的情况，留着余量，后期就不用改柜子。

另一个很容易忽略的是输入端的滤波时间。电梯里按钮、继电器触点抖动严重，PLC输入端的滤波时间要适当调大（比如10ms~20ms），否则外呼信号会被误触发。这点在写参数配置时一定要写进报告里，属于细节就能看出你做了真东西。

2.3 传感器与执行机构的选择

电梯的位置检测是整套系统里最重要的硬件环节。“十层”意味着需要精确知道轿厢在哪一层。常见方案有三种：

1. 井道磁开关+隔磁板：每层装一套隔磁开关，轿厢上的遮磁板插入时输出信号。可靠、便宜、调试直观，毕设最爱用。
2. 旋转编码器+楼层计数：通过电机转数推算轿厢位置，接线简单但存在累计误差，必须用平层开关校正。
3. 绝对值编码器：精度高、无需校正，但成本高。

毕设建议选方案1，必要时加编码器做平层前的减速判断（高速区减速、低速区找平层），这个搭配还能在报告里多写一个“变频多段调速/模拟量调速”的亮点。

变频器选型上，10层电梯用2.2kW~5.5kW的VVVF变频器即可，重点是要支持外部端子控制和多段速/模拟量给定。我见过不少同学买廉价的变频器，结果不支持外部端子控制，程序写好了却驱动不了电机，只能干瞪眼。还是那句话——硬件选型前先查手册，确认功能端子，再决定型号。

3. 电梯群控调度策略：不只是“谁近谁去”

群控的核心不是电梯本身能跑，而是“谁来接这个外呼”。调度策略决定系统的效率，也是论文里最能体现专业深度的章节。网上能查到很多花哨的算法，但毕设里要兼顾可实现性和论文可解释性。

3.1 五种常见的调度策略对比

真实群控系统里的调度算法很多，结合毕设的可行性，我整理过这张表：

毕设最推荐的是“综合代价评估法”：每当一个外呼按钮被按下，群控主站就计算三台电梯的“代价函数”，取最小值对应的电梯去响应。代价函数不复杂：

代价 = 距离权重 × |呼梯楼层 - 电梯当前楼层| - 方向一致加分（顺向给负值，反向给正值） + 当前任务数 × 任务量权重 + 电梯忙闲状态修正

举个例子：5楼按下行，1#梯在8楼正在下行（顺向，且5楼在它的下行路径上），2#梯在2楼正在上行（反向顺路性差），3#梯在5楼正在下行（顺向且最近），那么3#梯会得到最小的代价，系统就会把5楼下行外呼分配给3#梯。这个逻辑不需要复杂的模糊神经网络，用PLC的算术指令就能算出来，而且运行速度快。

3.2 如何用PLC实现代价计算

在梯形图里做“减法+乘法+比较”是完全可以的。把每部电梯的当前位置、方向、任务数放在数据寄存器里，触发外呼时执行一段计算程序，最后把三个代价结果做比较，最小值对应的电梯触发“接受任务”标志。

这里有几个工程上的技巧：

• 方向一致的量化：不要用简单的“1或0”，要用偏移值。比如顺向且该楼层在电梯路径上，代价-5；顺向但电梯已经过了该楼层要折返，代价+3；反向，代价+5。量化后，算法会非常接近人类的直觉判断。
• 防止某部电梯被“过度偏爱”：如果简单地选最小值，会出现某一部电梯永远被派去接客，另外两部闲着。修正方式是给代价函数加一个“任务数”因子：电梯当前已经登记的内呼越多，代价越大，这样系统会自动把任务分摊到空闲梯上。
• 掉电后的任务保持：电梯一旦运行中停电，再上电时外呼和内呼记忆要能恢复。PLC的掉电保持寄存器（如三菱的锁存区D、西门子的保持性DB）必须用起来，否则一断电客户全跑了。

3.3 调度策略的边界情况

任何调度算法都会有边界情况，这是答辩老师最喜欢追问的。比较常见的有几个：

• 高峰方向一致（上班同向上行）：假设10楼集中上行的早高峰，三部电梯都在响应上行，但10楼的外呼是永远没人接。处理办法是设置“电梯到达最高层后自动改为上行方向”，或者在代价计算中对“方向任务”加全程顺路判断。
• 外呼已被响应但电梯满载：电梯称重信号一旦触发，该梯自动屏蔽新外呼，已经分配的任务保留但不再接新客。等满载解除后再开放。
• 外呼取消/人为误触：长时间没人响应时（比如5分钟），系统要自动清掉无效外呼信号，防止恶意占用。

这些边界在报告里每写一条，答辩就能多答一个问题。写代码的时候注意留出空余的定时器做这些逻辑，不要只做主干程序反复演示“正常情况”。

4. 程序结构怎么搭：模块化是多人协作和后期调试的命根子

三台电梯的程序如果全部塞在一个ORG或者一个主程序里，几千条指令读起来简直是一种折磨。我坚持要求把程序按功能模块拆分，这个习惯在任何PLC平台上都是通用的，只是不同平台的“块”叫法不同（西门子叫FC/FB、三菱叫子程序）。

4.1 单梯内部程序的分层

单梯控制程序我通常分成四层：

第一层：信号预处理。把物理输入（按钮、传感器、门区信号）统一做滤波、取沿、复位处理，生成内部使用的“软继电器”或“标志位”。比如外呼按钮按下一次，生成一个“登记信号”，松开后登记保持，只有电梯到达该楼层才清除。这一层能大幅减少主逻辑里对物理输入的重复引用。

第二层：轿厢运行控制。核心是“自动定向”和“顺向截梯”逻辑：

• 定向规则：电梯在停止状态时，按“内呼优先于外呼”“上行外呼优先于下行外呼”等规则判断运行方向。
• 顺向截梯：电梯向上运行时，只响应“上行外呼”和“内呼”，当前楼层以上的信号；向下运行时只响应下行信号。这是电梯运行的基本礼仪，程序里用两层比较指令即可实现。

第三层：平层与开关门控制。当电梯进入目标楼层时，先减速到爬行速度，平层传感器动作后停梯、开门、限时后关门。这套时序用状态机+定时器实现，我最常踩的坑是开门延时的时序和门锁信号的配合：门锁没闭合就启动电机，是事故隐患，程序里必须把“门锁OK”串进启动回路。

第四层：通讯与状态上报。把本梯的当前位置、运行方向、任务数、忙闲状态打包发送到群控主站，同时接收主站下发的“外呼分配任务”。S7-200 SMART之间的通讯可用GET/PUT或Modbus TCP；三菱可用N:N网络，非常成熟。

4.2 群控主站的调度程序

群控主站的程序可以看作一个循环：

1. 扫描外呼信号，若有新外呼则登记；
2. 遍历三台电梯的状态数据，计算每个外呼对应的三台电梯的代价函数；
3. 选取代价最小的电梯，下发分配指令；
4. 同时点亮该层外呼指示灯（表示已经有人接单了）；
5. 若该电梯到达外呼楼层，清除对应登记和指示灯。

主站的扫描周期很短，干扰不大，但要注意：下发指令和状态反馈之间有时序差。比如电梯刚接收任务，但位置还没更新，这时候又来一个外呼，可能会重复分配。解决办法是维护一张“任务分配表”，每部电梯分配了哪些外呼，在清除之前不再参与新的代价计算。

4.3 程序注释和数据区规划

写群控项目，数据区规划比代码本身更重要。三台梯各自的状态字、外呼分配字、故障代码字全部用命名地址或符号表管起来。我见过有同学用裸地址堆了3000行梯形图，调试的时候连“这个位是干嘛的”都要从头查。符号表的成本很低，收益却很高，尤其是有万字报告要写的时候——直接导出一份I/O表和符号表，报告内容瞬间充实一半。

5. 调试阶段的坑与心得：实验室里不跑的坑，现场都会加倍还回来

程序写完只是第一步，能稳定跑完几千次呼梯不出错，才算合格。群控电梯的调试要分阶段走，不能用“一次性连线全上电”的方式，冒进只会让故障点淹没在信号堆里。

5.1 先单梯点动，再双梯联动，最后三梯群控

我先说一套自己总结的调试顺序，基本屡试不爽：

1. 单梯空载点动：断开变频器输出，手动操作接触器，验证电机转向、抱闸时序、限位动作。这个阶段能查出大量接线错误。
2. 单梯自动运行：接上变频器，不按外呼，只用内呼测试自动定向、平层停靠、开关门时序。多跑几轮，尤其是2楼和9楼这种中段楼层，平层稳定性最容易出问题。
3. 双梯联动外呼测试：临时关闭第三部梯，让两梯按群控策略跑外呼。重点观察外呼分配是否合理，会不会出现两梯同时响应一个外呼的情况。
4. 三梯群控压力测试：全部启用，人为快速按压不同楼层的外呼按钮，模拟多任务并发，观察调度策略是否卡死、是否有外呼长期无人接。

调到这里最常出问题的几个点，我挨个说一下：

• 触点竞争：两台电梯同时到达同层，同时向主站报告“到达”，主站清除外呼时可能出现信号竞争。解法是主站收到第一台到达信号就立即清除外呼并锁定分配表，其他梯的到达信号不再处理。
• 行程开关的机械抖动：电梯平层时速度很低，但机械振动大，隔磁板插入深度不够会导致平层信号“闪断”。程序里要加30ms~50ms的滤波，或者往传感器安装位置上多垫几块垫片，双管齐下。
• 门机限位与关门到位信号不匹配：很多学生以为关门到位等于门锁闭合，实际上门锁回路里还有一道安全触点。调试时我要求眼看门确实关严了，测试门锁信号才导通，否则电梯启动瞬间触点打火，非常危险。

5.2 常见故障的排查路径

调试记录表里我通常列这么几行“症状——排查方向”，分享在这里：

这些排查路径都要写进报告的“调试与故障分析”里，这就是老师眼里“有工程实践”的直接证据。

5.3 触摸屏监控与演示的重要性

毕设答辩最怕“只看见一台PLC在那闪灯”，老师体会不到整个系统的逻辑。建议在触摸屏上做一个简化的监控界面：显示三台电梯的实时楼层、方向、外呼登记状态、当前调度分配结果，甚至可以用动画模拟轿厢移动。

组态软件（MCGS、威纶通）都内置了电梯模型或者可以自己画图。用变量导通的方式，把轿厢图标绑定到楼层变量上，运行时就能看到三台梯的动态位置。这一项会在答辩现场直接把“群控效果”可视化，比任何口头描述都有说服力。

6. 交付物整理：源文件、万字报告和讲解视频怎么准备

标题里提到“设计源文件+万字报告+讲解”，这三样恰恰也是毕设答辩的交付物核心。我见过太多程序写得还行、交付物一塌糊涂的学生，最后论文被批“深度不够”。下面把每样东西的整理思路捋一遍。

6.1 设计源文件怎么组织

源文件的组织逻辑不是把所有文件丢到一个文件夹里，而是按系统结构分层：

• 01_单梯控制/1#梯程序、2#梯程序、3#梯程序
• 02_群控主站/主站程序
• 03_触摸屏工程/HMI画面与变量表
• 04_硬件图纸/I/O分配表、接线图、柜内布局图
• 05_仿真素材/仿真模型、演示视频

每份PLC程序不能光有源文件，还要附一份“程序结构说明.md”——讲清楚每个子程序块的功能、使用的寄存器段、注意事项。这个文件夹结构既是交付给老师看的，也是自己复盘时最省心的一手资料。

关于仿真：很多平台都支持PLC仿真运行，比如西门子PLCSIM。但群控电梯的传感器信号模拟比较复杂，最好用带I/O仿真功能的工具（比如博途的PLCSIM Advanced、ProSim等），或者直接用触摸屏做信号注入。如果实在没有硬件条件，就把程序逻辑用“软元件强制置位”的方式逐段验证，把验证结果截图留存，也能说明程序正确性。

6.2 万字报告的结构与撰写重心

报告的章节结构不要按教程上的“绪论-综述-硬件-软件-总结”硬凑，建议按工程逻辑组织：

1. 需求分析：为什么要群控？三部电梯独立运行会有什么问题？列出功能需求和非功能需求。
2. 总体设计：系统架构图、群控策略的选择理由、硬件总体配置。
3. 硬件详细设计：PLC选型计算（I/O点数表、扩展模块选型）、传感器选型与安装布置、电机与变频器参数匹配。
4. 软件详细设计：程序总体流程图、I/O地址分配表、每个功能模块的设计说明（内呼登记、外呼分配、方向判断、平层开关门、群控代价计算）、关键程序段截屏与逐行说明。
5. 系统调试：调试环境、分阶段调试记录、故障案例与解决过程、最终运行数据。
6. 结论与改进：系统的不足、可优化的方向（比如引入乘客流量预测、高峰期策略切换、远程监控）。

关键要写细的是“软件详细设计”和“系统调试”两章，里面多放程序段截图、时序图（用文字描述即可，不要用mermaid）、I/O分配表，这些比写一堆“智能”和“可靠”的空话强得多。

6.3 讲解视频和答辩讲解的准备

讲解视频的长度建议控制在8~12分钟，按“系统演示——调度策略演示——故障演示”三幕走：

• 第一幕：展示三部电梯的独立运行，说明单梯控制的关键逻辑。
• 第二幕：人为制造多外呼，展示群控调度策略如何分配任务，强调“最近+方向一致+任务均衡”的实际效果。
• 第三幕：人为造一个故障（比如某部梯检修开关打开），演示它自动退出群控、其他两梯接替任务的过程。

答辩PPT的结构跟报告走，单页不要堆文字。最关键的几张图：系统总体架构图、I/O分配总表、调度算法流程图（画成静态框图）、程序模块结构图。答辩老师大概率会问“为什么选用这种调度策略，和最短距离法比有什么优劣”“某一部电梯故障时群控系统怎么应对”“你如何验证程序的正确性”这几个问题，看完我这篇文章，应该都有答案了。

7. 从毕设到工程实践：做完这个项目，你真正掌握了什么

每次带完这类“三部群控电梯”的项目，我都喜欢在结束前和学生聊一个话题：这个题目除了交一份毕设，到底给了你什么。

我觉得至少有三样东西是实打实的：

第一，多目标协调的程序设计思维。PLC程序和普通的单片机的程序不同，它要求时序确定、状态可穷举、异常可恢复。而群控电梯又多了一个“多机协同”的维度，你要学会把决策逻辑从控制逻辑里剥离出来，让系统具备“在不确定场景下做出相对优选择”的能力。这套思维用在工作上，就是自动控制工程师最核心的竞争力。

第二，调试方法论。没有人写一遍程序就能完美运行。分阶段测试、从单点控制到系统联调、用数据找问题的习惯，这才是本行业真正的入门门槛。写完这个项目，至少你遇到“系统不动作”时，会先看输入信号捕获，再看中间继电器状态，再看输出是否发出——而不是一上去就怀疑PLC坏了。

第三，文档与表达的框架感。万字报告不是字数的堆砌，而是你整个设计过程的文字复现。能把自己的设计决策讲清楚、把遇到和解决的问题说得有条有理，这种表达能力在一些人眼中比会写两段梯形图还值钱。

电梯是一个跟生命安全强相关的行业，你在实验环境里可以随意调试，但到了真实项目里，一个平层信号的抖动都可能导致停层不准甚至安全事故。这个题目教你的绝不只是几段PLC程序，而是一种对待控制系统的态度——敬畏信号、敬畏时序、敬畏异常。

最后提醒一点：如果你准备用这篇文章帮助自己完成类似的毕设课题，硬件条件允许的情况下，一定要亲手接线、亲手调参、亲手把电梯跑起来。设计源文件和报告回答的是“他杀”，触摸屏和实物演示回答的是“他动起来了”——真正答辩时，老师眼里有光的那一刻，往往不是看到你文档里的漂亮框图，而是看到你的电梯在模拟井道里平稳停在了目标楼层。

祝你顺利。