企业官网建设流程全解析

做这套5层电梯控制系统，其实起因很朴素：学校实训室需要一套能稳定演示电梯运行逻辑的微型装置，而我又想完整跑一遍 Omron 欧姆龙 PLC 和 MCGS 组态从选型、接线到联调刷机的全流程。项目做完后回头看，真正有门槛的并不是梯形图本身，而是控制策略的梳理和 PLC 与触摸屏之间的数据映射。这篇文章就把我从需求拆解、硬件选型、程序框架、组态画面到调试排错的过程全部摊开来讲，给准备做 PLC 毕设、课程设计，或第一次接触 PLC + 触摸屏组态的同行一个可以直接参考的完整案例。

1. 项目需求拆解与方案选型

1.1 5层电梯控制到底要解决哪些问题

电梯控制系统听起来简单，无非是“按一下呼叫，然后电梯过去开门、关门、继续跑”，但真把它拆成 PLC 能识别的逻辑，就会发现它至少包含五个子问题。

第一是位置检测。电梯怎么知道自己现在在哪一层？常见方案是在每层平层位置装一个接近开关或者光电传感器，轿厢上的挡片触发哪一层的开关，PLC 就知道当前楼层。第二是呼叫登记。轿厢内选层按钮、各楼层厅外上/下呼梯按钮，按下之后必须“记住”这个需求，不是按完就丢，这就是呼叫寄存。第三是方向决策。同一时间可能有多个楼层在呼梯，电梯是往上走还是往下走，目标楼层选哪个，需要一套明确的规则。第四是平层停车与开关门。到目标楼层后要减速、停稳、开门、延时关门，还要保证门没关好时绝对不能启动。第五是状态指示。当前楼层、运行方向、开门状态这些信息要能显示出来，方便操作员和维护人员观察。

这套 5 层电梯系统，我的设计目标是把它做成一个“行为接近真实电梯”的教学模型：单部电梯，5 层站，内外呼齐全，有运行方向逻辑，有平层停车，有开关门互锁，还能通过触摸屏实时监视和下发指令。至于群控、消防联动、困人救援这些高级功能，暂时不纳入。

1.2 为什么用 Omron PLC + MCGS 组态，而不选其他方案

很多人会问：电梯控制用单片机不行吗？用继电器行不行？PLC 是不是贵了点？我的观点是，如果目标是“做一个能稳定运行的工业级控制模型”，PLC + 组态是目前性价比最高、最接近真实项目的组合。

单片机方案最大的问题是可靠性。电梯这种涉及安全互锁的设备，程序跑飞、I/O 抖动、抗干扰差都是不可接受的。PLC 的扫描机制、硬件看门狗和成熟的输入滤波，天然适合这类逻辑密集的场合。继电器方案虽然在简单电梯中可以工作，但 5 层电梯的呼叫寄存、方向判断、顺向截车逻辑，继电器柜会复杂到令人崩溃，改一个逻辑就要重新接线。PLC 的方案则把这些逻辑全部放进程序里，调整策略不碰硬件，项目后期维护友好。

选择 Omron，一方面是因为 Omron 的 CP1E 系列在小型 PLC 里性价比很突出，自带高速计数、丰富的定时器/计数器，指令系统清晰，CX-Programmer 编程软件上手快；另一方面，Omron 的 Host Link 通信协议在 MCGS 组态软件里有现成驱动，不需要自己写报文，能省下大量调试时间。MCGS 嵌入版组态软件则负责“让数据可见”：做一个触摸屏监控界面，电梯位置、呼梯状态、运行方向一目了然，人机交互比单纯的指示灯加按钮舒服太多。

2. 硬件选型与电气接线要点

2.1 PLC、触摸屏、传感器选型与基本参数

这套系统我用的是 Omron CP1E-N40DR-A，40 点 PLC，24 点输入、16 点继电器输出。选继电器输出而非晶体管输出，是因为电梯模型里有接触器、继电器线圈，继电器输出可以直接驱动中小负载，不用额外加中间继电器转接，教学演示更直接。触摸屏选了 MCGS TPC1062Ti，10.2 寸，串口和以太网口都有，后续想改成网络版也方便。

位置传感器选 NPN 常开型电感式接近开关，工作电压 DC24V，检测距离 4mm 左右。每层装一个，共 5 个，安装在井道对应楼层平层位置。轿厢侧焊接一块金属挡片，当挡片进入传感器检测范围时，对应输入点导通。按钮和指示灯全部选 DC24V 自复位式，内呼 5 个、外呼 8 个、开门/关门按钮各 1 个。电机驱动部分，我用了两台小功率直流减速电机分别模拟曳引电机和开关门电机，PLC 通过继电器控制电机正反转。曳引电机上加装了一个上限位开关和下限位开关作为硬件极限保护，防止程序逻辑出错时冲顶或蹲底。

下面是实际用到的 I/O 分配表，这张表在项目一开始就必须定死，后面写程序、做组态都围绕它展开：

这组 I/O 点数刚好在 CP1E-N40 的范围内，不需要扩展模块，硬件成本可控。如果你选的是 Omron CP1H 或 NJ 系列，地址会略有变化，但逻辑思路完全一样。

2.2 主回路与控制回路接线思路

教学模型的接线不需要照搬真实电梯的主回路，但控制逻辑和安全互锁一定要保留。我的做法是：PLC 输出 100.00 控制上行接触器，100.01 控制下行接触器，两个接触器的常闭触点相互串联在对方线圈回路里，形成硬件互锁。这个互锁极其重要，即使程序里写错，上下行接触器也绝不会同时吸合，否则曳引电机可能直接短路烧毁。

门电机控制同理，开门和关门继电器输出 100.02、100.03，两个方向互锁。门开到位和门关到位限位开关接入 PLC 输入，程序里只有检测到“门关到位”后才能允许启动电梯电机。实际接线时，NPN 传感器输入端要接 PLC 输入公共端 DC24V 的负极，PLC 输出端线圈负载的一端接输出公共端，另一端接负载后再回到开关电源负极，接线前一定要确认 PLC 输入点是漏型还是源型，别接反。

2.3 接线实操中的防坑细节

第一次接线最容易踩的坑有三个。

第一，传感器线序。NPN 接近开关一般是棕（电源正）、蓝（电源负）、黑（信号输出）三根线，信号线接 PLC 输入点。如果接了 PNP 型传感器，输出高电平，和 PLC 漏型输入不匹配，会一直不动作或者损坏输入点。

第二，按钮抖动。机械按钮按下和松开的瞬间，触点会产生毫秒级的抖动，PLC 扫描周期本身可以滤掉一部分，但我在程序里仍然用了 10ms 左右的延时滤波，防止呼叫信号误触发。

第三，公共端接线混乱。Omron CP1E 的输入公共端和输出公共端是分开的，不要把 DC24V 电源的负极同时接到输入公共端和输出公共端后还不加核对。输出公共端根据继电器输出类型接相应电源，接错轻则点不亮，重则烧板子。

3. PLC 控制程序设计与核心逻辑实现

3.1 数据区规划与符号表设计

写梯形图之前，我先做了一张数据区分配表。这一步很多人会跳过，直接开始写触点线圈，做到后面逻辑越堆越乱。我的习惯是先把所有“记忆状态”规划好，用符号表起好名字，梯形图里只调用符号，不直接写裸地址。

内呼记忆放在 H0 区，H0.00 到 H0.04 分别对应 1 至 5 层的内呼信号。外呼记忆放在 H1 区，H1.00 到 H1.07 分别对应 1 层上行、2 层上行、2 层下行、3 层上行、3 层下行、4 层上行、4 层下行、5 层下行。选择 H 区而不是普通 W 区，是因为 H 区在断电后依然保持，程序跑飞或意外断电后呼梯信息不会丢失，这也是真实电梯的基本要求。当前楼层、运行方向、目标楼层这些“实时计算数据”放在 D 区，比如 D100 存放当前楼层，D101 存放运行方向（0 停止、1 上行、2 下行），D102 存放当前目标楼层。

D120 和 D121 用作 MCGS 组态的映射寄存器。D120 的低 5 位对应内呼状态，D121 的低 8 位对应外呼状态，PLC 每扫描周期把 H 区呼叫状态镜像到 D120/D121。这样触摸屏读取时只读 D 区字变量，比直接读 H 区位变量稳定得多，也避免了 Host Link 通信中对位地址格式的争议。

3.2 电梯运行控制逻辑的梯形图思路

整个程序的核心，我拆成了四个功能块：楼层检测与当前楼层更新、呼叫登记与保持、方向判断与目标楼层决策、平层停车与开关门控制。

楼层检测比较简单。5 个平层开关分别接入输入点，当某一层开关导通时，用比较指令把 D100 更新成对应楼层号。为了防止轿厢停在两层之间时平层信号不稳定，我加了一个 50ms 的输入滤波，确认信号持续有效后才更新楼层。

呼叫登记逻辑是经典的置位复位电路。每个内呼按钮或外呼按钮的上升沿，把对应 H 区位置位，当电梯到达该层并完成开门后，再对该位复位。这里要注意，外呼是分方向的。2 层既有上行外呼又有下行外呼，两个按钮必须分开登记、分开清除，不能图省事合并成一个“2 层有人呼叫”。如果合并了，电梯上行时在 2 层停了，实际上那个人想去 1 层，就会白白浪费一次运行。

方向判断是整个程序中最值得反复推敲的地方。我采用的是“顺向截车、最远反向”原则：

• 电梯当前静止时，从当前楼层向上找最近的呼叫层，找到则方向设为上行；向上找不到，再从当前楼层向下找最近的呼叫层，找到则方向设为下行。
• 电梯上行期间，优先响应当前层以上的所有呼叫，包括上行外呼和内呼。如果上行到某一层时，当前层有同向呼叫或内呼，就执行平层停车。上行过程中如果上方已经没有呼叫，但下方还有呼叫，则在完成当前层任务后换向，开始下行。
• 下行逻辑与上行完全对称。

这个逻辑用梯形图实现时，我没有逐个楼层写死比较，而是用了一个循环扫描的思路。D110 到 D114 这 5 个寄存器分别对应 1 至 5 层“是否有任何有效呼叫”的标志位，程序每 100ms 扫描一次，结合当前楼层 D100 和方向 D101，把“下一个要停的楼层”写进 D102。这样四层、五层、十层电梯，程序结构都一样，只是数据寄存器数量增加而已。

下面给出方向判断的简化伪代码，帮助理解梯形图的思路：

IF D101 = 0 THEN // 静止状态 FOR floor = D100+1 TO 5 IF D110+floor 有呼叫 THEN D102 = floor D101 = 1 EXIT END_IF END_FOR IF D101 = 0 THEN FOR floor = D100-1 TO 1 IF D110+floor 有呼叫 THEN D102 = floor D101 = 2 EXIT END_IF END_FOR END_IF END_IF

真实梯形图里，我会用多个比较指令判断 D110 到 D114 的位状态，也可以用传送指令把呼叫层数直接传给 D102。这个逻辑不追求最简，但求可读性和可维护性。

3.3 关键程序段讲解与参数计算

平层停车判断是很容易犯错的地方。我的规则是：电梯上行时，只有目标楼层和当前楼层相等，或者当前层存在同向呼叫（上行外呼或内呼）且当前层号大于等于目标楼层时，才停车。听起来绕，实际翻译成梯形图就是一组比较与位检测的串联。

停车后的开门逻辑，我也做了延时参数化。D130 存放开门延时时间，单位 0.1 秒，默认值 30，也就是开门后 3 秒自动关门。D131 存放关门超时时间，默认值 10，关门动作持续 1 秒没到位，就报警并停止关门，防止门卡住后电机一直堵转。这两个参数我特意放到数据寄存器里，而不是把定时器号写死在程序里，这样调试时可以在线修改，不重新下装程序。

电机启动时，还要考虑启动瞬间的电流和机械冲击。我在程序里加了 0.3 秒的启动保持时间，确保门关到位、接触器吸合稳定后才正式进入方向运行判断。停车时则先断方向输出，再延时 0.5 秒才输出开门信号，模拟电梯完全停稳后再开门的动作。这些延时不是随便拍的，需要根据电机的机械响应时间调整。我在调试时发现 0.3 秒启动保持太短，接触器还没完全吸合电梯就开始判断位置，会出现瞬间抖动；后来调成 0.5 秒才稳定。

安全互锁方面，梯形图里必须做到：

• 上行输出和下行输出互锁，梯形图中两个线圈串联对方的常闭触点。
• 开门输出和运行输出互锁，运行状态下开门输出强制断开。
• 急停/极限保护开关输入为 ON 时，不管程序状态如何，切断所有电机输出，只保留蜂鸣器报警。

4. MCGS 组态画面搭建与通信配置

4.1 组态工程搭建与设备通信配置

MCGS 组态分为“设备窗口、实时数据库、用户窗口、运行策略”几个核心部分。设备窗口负责和 PLC 通信，实时数据库存放变量，用户窗口画界面，运行策略处理脚本逻辑。我的建议是严格按照这个顺序搭工程，先把设备通信搞定，再画画面，否则画面做得再漂亮，变量连不上也是白搭。

打开 MCGS 嵌入版组态软件，新建工程后选择触摸屏型号 TPC1062Ti。进入设备窗口，先从设备工具箱添加“通用串口父设备”，再添加“欧姆龙 Host Link”子设备。Host Link 通信参数要和 PLC 侧保持一致，我设的是波特率 9600，数据位 7，偶校验，停止位 2，PLC 站号 0。这里有个容易忽略的点：PLC 本体默认的通信口可能是外设口，而不是 RS232C 串口，必须在 CX-Programmer 的 PLC 系统设定里把外设口/串口工作模式改成 Host Link，否则触摸屏发指令 PLC 不会回应。

设备属性里，我添加了如下通道：

• D100 只读，对应实时数据库变量“当前楼层”
• D101 只读，对应“运行方向”
• D120 只读，对应“内呼状态字”
• D121 只读，对应“外呼状态字”
• D140 只写，对应 MCGS 按钮面板的“呼梯请求”，PLC 侧每 100ms 读取一次

D140 这个写通道是触摸屏主动向 PLC 发送指令的入口。比如触摸屏界面上按了“3 层内呼”按钮，脚本就把 D140 写成 3，PLC 检测到 D140 数值变化后，自动置位 H0.02 并清零 D140。这里不直接让触摸屏去写 H 区位变量，而是通过一个请求寄存器中转，调试时只要盯住 D140 就能知道触摸屏到底有没有把指令发出来，非常方便。

4.2 变量连接与画面对象设计

实时数据库里，我建立了“当前楼层”“运行方向”“内呼状态字”“外呼状态字”“呼梯请求”“开门状态”“关门状态”等变量。这些变量全部绑定到设备通道上，PLC 一扫描，触摸屏上的数值就会刷新。

用户窗口我画了两个页面，一个叫“主监控”，一个叫“运行数据”。主监控页面参考真实电梯的“轿厢位置示意图”：竖着画 5 条水平线代表楼层，每条线旁边放一个楼层号标签。轿厢用一个矩形图元表示，但在 MCGS 里做连续的“平滑移动”比较麻烦，我采用的技巧是画 5 个轿厢矩形，分别设置“可见度”动画，表达式分别是“当前楼层=1”、“当前楼层=2”……这样电梯到哪一层，就显示哪一层的轿厢图形，效果直观，组态工作量也小。

运行方向箭头用两个箭头标签做可见度切换。上行时显示向上箭头，下行时显示向下箭头，停止时两个箭头都隐藏。每层的外呼按钮和内呼按钮都是真实按钮对象，按下后执行脚本，把楼层编号写入 D140 请求寄存器。门区状态用两个指示灯：开门灯和一个关门灯，分别连接门开到位和门关到位的位状态。

这里要注意，MCGS 脚本中访问设备通道时，最好用“设备通道名”而不是直接写地址，这样后期改 PLC 地址不会影响画面脚本。我的按钮脚本大致是：

!SetDevice(设备0, 呼梯请求, 3)

含义是把设备 0 的“呼梯请求”通道写入数值 3。因为 PLC 侧会把这个请求值转换成对应的楼层呼梯置位，所以触摸屏脚本里不需要关心 H 区地址，把逻辑闭环放在 PLC 端，维护更清晰。

4.3 报警与数据记录功能

除了实时监控，MCGS 的数据记录和报警功能特别好用。我在工程里建立了一个“运行记录”数据对象，把当前楼层、运行方向、呼梯请求每隔 1 秒写入历史数据库。调试时打开历史的曲线，能很清楚地看到电梯从 1 层到 5 层的完整动作序列，比对着指示灯猜靠谱得多。

报警这块，我做了两个触发条件：一是关门超时，也就是开关门到位后 10 秒内没能关到位，报警弹窗；二是急停按钮被按下，报警并记录时间。报警显示控件放在“运行数据”页面，方便现场维护人员直接查看。

5. 系统联调、故障排查与常见问题

5.1 通信连不上的排查思路

这是整个项目里我耗时最多的一关。PLC 程序已经能通过 CX-Programmer 在线监控了，但 MCGS 触摸屏始终显示“设备连接失败”。我排查的顺序是这样的：

第一查通讯参数。CX-Programmer 在线监控的是 USB 口，而触摸屏走的是 RS232 串口，两个口不是一回事。要在 PLC 系统设定里确认串口的工作模式是 Host Link，并且波特率、奇偶校验、停止位和 MCGS 设备配置完全一致。这里最容易踩的坑是通讯参数默认值不一致，PLC 那边默认可能是 9600 8 N 1，MCGS 驱动默认是 9600 7 E 2，改到一致才能通。

第二查接线和地电位。触摸屏的 COM 口和 PLC 串口之间是交叉线还是直连线，不能凭感觉。一般 PLC 串口和触摸屏都是 DTE 设备，需要 2-3、3-2、5-5 交叉连接。如果接成直连，通信肯定失败。另外两台设备最好共地，否则串口通信会偶发丢数据。

第三查站号。Omron Host Link 协议的指令帧里带有 PLC 单元号，MCGS 驱动里默认单元号是 0，PLC 实际站号如果是 1，必须改一致。站号对不上，PLC 会对指令不响应。

如果以上都排查了还连不上，把触摸屏改到“在线调试”状态，看设备通道的读取数值是否变化。我遇到过一种诡异情况，USB 转串口线供电不足，导致触摸屏偶尔能找到设备但数据全部为 0，换一根带磁环的线就解决了。

5.2 电梯运行逻辑异常的经典问题

通信通了之后，真正磨人的是逻辑类问题。我记录了几个典型故障，这里直接列成表，方便以后复现排查。

其中我印象最深的是“呼叫消不掉”的问题。2 层外呼按钮按下后，电梯确实到 2 层停了，门也开了，但关门后外呼指示灯仍然亮着，电梯又跑了一圈才消除。原因是我当时复位外呼时，只清除了“2 层下行呼叫”这一个位，没有清除“2 层上行呼叫”。实际电梯里，如果轿厢是上行方向到达 2 层，并且用户按的是下行外呼，那么电梯在 2 层停车让用户进入之后，用户进入轿厢还会按目的楼层，此时“2 层下行呼叫”已经不再有意义，必须立即清除。这个细节才是电梯控制逻辑的灵魂，比单纯写几十个触点难得多。

5.3 一个 PLC 接两个触摸屏的扩展问题

项目做完后，有同学问能不能用一块 CP1E 同时带两块 MCGS 触摸屏。答案是可以，但要看通信方式。如果两块屏都通过串口 Host Link 和 PLC 相连，当成两个 Host Link 主站，串口一主一从的协议就不允许两个主站同时挂一条总线，通信会互相干扰。稳妥的做法是 PLC 换成带以太网口的机型，或者加一个以太网模块，两块屏都走 TCP/IP 通道，分别作为独立客户端访问 PLC。用 MCGS 的话，设备窗口里选择“以太网父设备”和对应的欧姆龙 TCP 驱动，IP 地址和端口配置好，两块屏可以同时监控。这个思路同样适用于以后想接上位机组态软件或者数据采集服务器的场景，提前把 PLC 的通信接口留足，能省很多事。

6. 项目复盘与下一步可做的扩展

6.1 整个调试过程中最值得记住的三件事

这个项目让我最受益的，不是最后跑通了，而是中途反复折腾时沉淀下来的三条经验。

第一，I/O 表和地址分配表一定要在动手前定死。我在项目刚开始时想着“边写程序边改地址”，结果程序写了三分之一，发现外呼地址分配不合理，前前后后改了一个晚上。定死之后，接线、程序、组态三件事各自并行推进互不干扰，效率翻倍。

第二，梯形图里尽量用“符号”和“状态寄存器”，不要到处裸写触点。我所有楼层呼叫状态都集中映射到 D120/D121，好处是组态和上位机读取数据时只面对两个字变量，不需要理解几十个位地址。后面扩展触摸屏功能时，我就靠这两个字变量做页面逻辑，少走了很多弯路。

第三，安全逻辑宁可冗余也不要精简。上行和下行接触器互锁、门联锁、急停切断，任何一个都别省。教学模型可以允许性能差一点、响应慢一点，但不能出现上下行同时吸合或者门没关好电梯就走的危险情况。这是做自动化设备最基本的底线。

6.2 后续功能扩展：变频器、物联网和数字孪生

这套系统目前用的是直流电机直接正反转，控制逻辑和真实电梯已经非常接近了。如果想进一步贴近工业现场，下一步我建议把电机驱动换成变频器，PLC 输出运行方向和速度给定信号，变频器驱动三相异步电机，这样能实现加减速平滑，还能通过模拟量给定多段速，更接近真实电梯的运行曲线。

另一个我打算做的扩展是加装 OPC UA 服务。Omron 较新的 NJ 系列 PLC 自带 OPC UA Server，CP1E 可以通过串口网关或者上位机中转，把当前楼层、运行方向、呼梯状态这些数据发布出去。配合物联网网关，就能在电脑端做一个 Web 组态界面，远程查看电梯状态和统计运行次数。这类需求在非标设备的远程运维场景里非常常见，会了这套电梯项目，再做其他设备的 Web 组态监控，思路几乎可以平移。

回想这套系统第一次正常把轿厢从 1 层送到 5 层时，我在触摸屏前反复点了几次才确认不是偶发。这个项目最大的收获不是写了几百行梯形图，而是逼着我把“电梯会怎么动”这个问题拆成了一个个可检测、可控制的状态机。后面你如果遇到类似的物流分拣、立体车库、小型升降机项目，这套框架完全可以平移过去，通用的不是代码，而是把复杂动作拆成“位置检测、请求登记、方向决策、安全互锁”这套设计方法。