六层电梯控制系统：MCGS触摸屏与三菱PLC串口通信实战

1. 项目背景与核心需求

六层电梯控制系统属于工业自动化领域的典型应用场景，相比常见的四层电梯，六层结构在逻辑复杂度上呈几何级数增长。我这次选用的是MCGS7.7触摸屏作为人机交互界面，搭配三菱FX3U PLC作为控制核心的方案组合，这个搭配在中小型工业控制项目中非常常见。

核心需求可以拆解为三个层面：

• 基础功能：完成六层楼宇的轿厢召唤、楼层显示、开关门控制等标准电梯功能
• 安全逻辑：实现超载报警、紧急制动、故障自检等安全机制
• 交互体验：通过触摸屏实现状态监控、参数设置和故障记录查询

这套系统的特殊之处在于采用了RS485串口通信（COM4口）进行设备互联，而不是更常见的以太网通信。串口通信在抗干扰性和传输距离上有独特优势，但配置复杂度也更高，这也是后续遇到各种"坑"的主要原因。

2. 硬件架构与通信配置

2.1 设备选型考量

选择MCGS7.7触摸屏主要基于三个因素：

1. 性价比：相比西门子等国际品牌，国产MCGS在功能满足需求的前提下价格优势明显
2. 协议兼容：原生支持三菱PLC的通信协议，省去协议转换的麻烦
3. 开发环境：配套的组态软件对中文支持良好，控件库包含现成的电梯元素

三菱FX3U PLC的选型则看重其：

• 128点的I/O容量足够覆盖六层电梯的输入输出需求
• 内置RS485接口可直接使用，无需额外通信模块
• 运动控制指令集便于实现轿厢的加减速曲线控制

2.2 通信参数配置详解

通信配置是本次项目的第一个"深坑"。两个设备通过COM4口连接时，必须保证以下参数完全一致：

实际调试中发现几个关键点：

1. MCGS的通信参数设置藏在两个地方：设备窗口属性页和通道连接配置，容易遗漏
2. FX3U的通信参数需要通过GX Works2软件写入，断电重启后才生效
3. 通信线建议采用双绞屏蔽线，单端接地（PLC侧），线长不超过15米

重要提示：当通信不稳定时，建议先用串口调试助手单独测试PLC的通信响应，排除硬件问题后再排查软件配置。

3. PLC程序逻辑设计

3.1 楼层控制状态机

六层电梯的核心是一个七状态的状态机（包含待机状态），用SFC语言实现最为清晰。每个楼层对应一个状态步，转移条件包括：

• 上升过程：S10→S11→S12→S13→S14→S15
• 下降过程：S15→S14→S13→S12→S11→S10
• 转移条件：当前楼层外呼信号+轿厢位置判断

关键程序段示例：

ladder复制LD M10    // 1楼上呼信号
AND X0    // 轿厢在1楼位置
SET S10   // 进入1楼服务状态

3.2 呼叫登记与消号逻辑

呼叫信号处理需要实现：

1. 上下行分向登记（D10-D15寄存器记录上呼，D20-D25记录下呼）
2. 轿厢内选层登记（D30-D35寄存器）
3. 消号时机判断（到达目标楼层+开门完成信号）

这里容易出问题的点是消号延迟处理，正确的做法是：

ladder复制LD X10           // 开门到位信号
AND T0 K50       // 延时5秒
RST D10          // 清除1楼上呼登记

3.3 安全保护程序块

包含三个关键保护机制：

1. 超载检测：通过称重传感器X20触发Y10报警输出
2. 急停回路：直接切断主接触器控制回路（独立于PLC）
3. 故障自锁：任何异常触发M100自保持，需手动复位

4. 触摸屏界面开发要点

4.1 通信变量映射

MCGS中需要建立与PLC的变量对应关系，主要数据类型包括：

4.2 动态元素设计

几个关键界面元素的实现技巧：

1. 轿厢位置动画：用垂直移动动画绑定D100值
2. 楼层指示灯：使用多状态图形元件关联Y11-Y16输出
3. 参数设置：通过数值输入框修改D200-D215寄存器

实测发现：动画刷新率建议设为200ms，过快的刷新会导致通信负荷过大

4.3 故障记录功能

利用MCGS的历史数据存储功能实现：

1. 创建报警事件：当M100=1时记录当前时间和状态
2. 设置循环存储：保留最近100条记录
3. 添加查询界面：按日期筛选显示

5. 联调问题排查实录

5.1 通信故障类

现象1：触摸屏显示"设备无响应"

• 检查步骤：
  1. 确认PLC电源和RUN指示灯状态
  2. 用万用表测量RS485线路A/B间电压（正常应有2-5V波动）
  3. 检查GX Works2中的通信参数设置
• 解决方案：发现停止位设置不一致，修改后通信恢复

现象2：数据偶尔跳变

• 可能原因：
  1. 接地不良引入干扰
  2. 终端电阻未配置（在最后一台设备加120Ω电阻）
  3. 波特率过高导致误码
• 最终措施：降低波特率至9600，增加磁环滤波

5.2 逻辑错误类

案例1：电梯反向截车异常

• 现象：下行过程中响应了上呼信号
• 排查：发现状态转移条件缺少方向判断
• 修复：增加方向标志位判断

ladder复制LD M10       // 1楼上呼
AND M50      // 当前下行标志
ANI X0       // 不在1楼
OUT S10      // 允许响应

案例2：楼层显示抖动

• 原因：轿厢位置检测光电开关(X0-X5)存在机械振动
• 改进：在PLC程序增加50ms滤波定时器

ladder复制LD X0
OUT T10 K5   // 5ms滤波
LDI T10
OUT Y10      // 稳定后输出

5.3 性能优化建议

1. 通信优化：

   • 将频繁更新的变量（如轿厢位置）单独分组轮询
   • 不常用的参数（如故障记录）设置为手动读取

2. PLC程序优化：

   • 用ZRST指令批量复位呼叫寄存器
   • 上升沿触发替代持续扫描

3. 触摸屏优化：

   • 减少同时运行的动画数量
   • 将静态画面与动态数据分页显示

6. 关键经验总结

经过两周的调试，这套系统最终实现了稳定运行。几个值得记录的经验：

1. 通信配置必须"三对照"：

   • PLC程序中的参数设置
   • 触摸屏通信配置
   • 物理线路实际连接方式

2. 状态机设计建议：

   • 每个状态步设置唯一入口和出口
   • 增加超时保护转移条件
   • 重要状态变化记录到D寄存器便于监控

3. 调试技巧：

   • 先用LED灯模拟输出信号
   • 利用GX Works2的在线监控功能
   • 关键变量在触摸屏上做临时显示框

4. 维护建议：

   • 定期备份PLC程序和HMI工程
   • 保留完整的IO分配表和变量说明
   • 设置维护密码防止误操作

这套方案虽然用的是基础款设备，但通过合理的程序设计，完全能够满足六层电梯的控制需求。最大的收获是深刻理解了串口通信的细节把控有多么重要，任何一个参数不匹配都可能导致整个系统瘫痪。下次如果再遇到类似项目，我会优先考虑以下改进点：

• 增加通信心跳检测机制
• 采用MODBUS协议替代原生协议
• 预留10%的IO余量以备后期扩展