★ FEATURED ARTICLE 做自动化这些年电梯控制系统一直是我心中最适合练手的完整项目。它不像流水线那样只有顺序动作也不像过程控制那样依赖复杂回路电梯把传感器、执行机构、逻辑判断、人机交互全部揉在一起而且安全要求极高。这篇博文我就拿西门子S7-1200 PLC搭配KTP1200触摸屏完整梳理一套电梯控制系统的实现过程包括硬件选型、IO分配、程序架构、HMI画面设计、通信联调以及我在调试中踩过的坑。不管你是刚接触PLC的在校学生还是准备转行工控的电气工程师这套方案都能给你一个从零到一的完整参照。先说清楚这套系统能做什么模拟一台五层电梯的全部核心功能——内外召唤、轿厢移动、平层停车、开关门控制、楼层显示、方向指示、超载报警、消防迫降。S7-1200负责逻辑运算和输出执行KTP1200触摸屏作为操作员面板既能实时监控电梯状态也能手动切换检修模式。两者通过Profinet工业以太网通信数据交换实时性完全够用。相比传统的继电器控制这套方案的优点是逻辑修改方便、故障诊断直观、扩展能力强而且整套系统的成本在工控项目里属于非常友好的一档特别适合入门到进阶的过渡阶段。1. 系统整体设计与硬件选型思路1.1 电梯控制系统到底在控制什么很多初学者拿到电梯项目第一反应是“控制电机转”其实这个理解不完整。电梯控制的本质是状态机管理什么时候允许运行、往哪个方向运行、到达哪一层停、停稳之后门怎么开、开门多久后自动关这一连串动作必须严格按顺序执行而且每个状态切换都要有传感器信号作为依据。以五层电梯为例核心输入信号包括每层楼的上行召唤按钮、下行召唤按钮、轿厢内的楼层选层按钮、每层的平层感应器、轿厢门开关限位、门锁反馈、超载开关、检修开关。核心输出信号包括上下行接触器、开关门继电器、楼层数码管显示、方向指示灯、蜂鸣器。这样一列项目边界就清楚了PLC要做的不是“让电梯动”而是“根据所有输入条件安全地决定每一步动作”。硬件选型上我用了S7-1200 CPU 1214C DC/DC/DC这款自带14路数字量输入、10路数字量输出对五层电梯来说IO数量紧巴巴但够用。如果楼层数超过八层建议直接上1215C或者加装SM1223扩展模块否则IO地址编号会非常痛苦。触摸屏用KTP1200 Basic PN12寸屏足够把楼层状态、报警列表、参数设置放在同一画面里配合Profinet接口和PLC直连省去额外的通信模块。1.2 为什么选Profinet而不是硬接线这里要给新手解释一个概念PLC和触摸屏之间交换数据有两种主流方式。一种是触摸屏直接通过I/O地址读PLC的输入输出点另一种是建立共享数据块触摸屏读写数据块里的变量。前者简单但浪费点表而且要操作中间变量很麻烦。后者灵活程序里把状态整理到DB块屏上只管读写DB结构清晰得多。S7-1200和KTP1200同属西门子博途平台Profinet通信是天生自带的不需要额外组态GSD文件只要在博途里把两个设备的IP地址配到同一网段连上网线就能通信。我用的是PLC作为Profinet控制器、触摸屏作为智能设备的方式连接建立后触摸屏能直接访问PLC的DB块、位存储区和定时器值。实测下来通信稳定性和响应速度完全没问题电梯这种毫秒级响应的控制系统用Profinet绰绰有余。1.3 电气设计的几个关键细节控制柜里除了PLC还需要配断路器、24V开关电源、继电器、接触器、接线端子排。有几个地方特别提醒输入信号线务必用24V直流不能和220V动力线走同一个线槽否则干扰大到传感器乱跳输出到接触器线圈的PLC信号先经过中间继电器隔离再驱动接触器别拿PLC输出点直接接接触器线圈电流冲击很容易烧点电机主回路必须有独立的短路保护和热过载保护这是安全底线。电梯的平层感应器我用的接近开关每层楼装两个一个负责平层停靠一个负责减速。有人会问为什么不直接用一个因为电梯到达目标楼层前需要提前减速如果只有一个感应器PLC在收到信号的瞬间就必须同时完成减速和停车机械冲击非常大。两个感应器一高一低先触发减速信号再触发停车信号体感就舒服多了。2. PLC程序设计的核心逻辑与实操要点2.1 程序架构别再全部堆在OB1里我见过很多初学者写PLC程序一个OB1从头写到底几百个网络连在一起出问题的时候查得想哭。电梯控制这种多状态项目正确做法是分层组织程序。我的习惯是OB1里只放五个块FC_Init初始化、FC_Call召唤登记、FC_Direction方向判断、FC_Move运行控制、FC_Door门控制每个块用函数FC封装自己带接口变量将来维护单独看某一块就行。这种模块化思路的好处在调试阶段体现得最明显。比如门关不上直接打开FC_Door看门限位信号和门锁反馈比如电梯不响应召唤去FC_Call查登记标志位有没有置上。不用像排查意大利面条一样从头捋到尾。博途里FC的临时变量放在Temp区接口变量放在Input/Output/InOut区写代码时注意变量作用域细节不展开但初学者往往在这里栽跟头赋值给一个Temp变量后发现程序一扫描完就丢数据回头查一下是不是该用Static。2.2 召唤登记与楼层请求的SCL实现召唤登记是电梯逻辑的第一个环节。每层楼的外呼按钮按下后对应标志位置1直到电梯到达该层并完成响应后复位。内选按钮同理区别在于内外呼在方向优先级上处理方式不同。这个逻辑用梯形图写需要十几个网络用SCL写就是几行循环所以我强烈建议在博途里混用编程语言逻辑判断部分用SCL顺序控制部分用梯形图。这里给一段我在项目里实际改过的SCL示意代码逻辑是遍历楼层生成请求汇总#req : 0; FOR #i : 1 TO 5 DO IF #innerCall[#i] OR #upCall[#i] OR #downCall[#i] THEN #req : #req #i; END_IF; END_FOR;这个片段虽然简单但体现了一个思路把五层楼的召唤信号汇总成一个请求值方便后续判断电梯应该去哪一层。实际项目里还要加防抖、去重复触发、按钮指示灯反馈等功能但核心骨架就是这个。SCL的好处是处理数组和循环非常方便五层楼可能感受不深将来做二十层楼的时候你就知道这玩意儿有多省事。2.3 方向判断电梯最容易被绕晕的逻辑电梯方向判断是整套程序里最容易出bug的地方。基本规则是如果电梯当前向上运行那么只响应上方的内选请求和上行的外呼请求下行外呼不做响应先继续向上把上方任务做完再做下行的。这就是典型的“顺向截梯”原则。如果电梯在3楼4楼有人按了下行5楼有人按了上行电梯应该先去5楼再去4楼而不是调头往下跑。具体实现我用了比较法遍历所有请求楼层找出高于当前楼层的最近请求和低于当前楼层的最近请求。当前方向是上行时优先选高于当前楼层的楼层如果没有才切换下行。运行过程中每次到达楼层都要刷新方向指示不能等到所有请求处理完才换向。这个逻辑用梯形图写就是一大串比较指令嵌套用SCL就清爽很多。注意方向判断和换向延时要同时做。电梯到达顶层或底层必须强制换向这个优先级最高不能靠算法自动判断因为边界条件下请求楼层的比较结果可能不直观。我习惯在FC_Direction里先用顶层底层限位信号强制确定方向再执行正常逻辑。2.4 开关门控制与安全互锁门控制系统是电梯安全的核心。我的实现方式是电梯处于停车且平层状态下才允许开门开门到位限位触发后才允许关门关门到位后门锁接通电梯才允许启动。这几个条件必须环环相扣任何一个环节不满足电梯都不能移动。PLC程序里用中间标志位表示“门锁接通”启动条件里必须有这个标志位为1。这里还涉及一个安全继电器的问题很多项目会在PLC之外单独加安全回路门锁信号直接串在安全回路上PLC只负责逻辑判断。我的建议是电气和程序双重保护都做即便PLC程序出错硬件安全回路也能强制切断主接触器。安全无小事电梯这种载人设备尤其如此程序写得再漂亮硬件安全兜底也不能含糊。开门时间也值得讲一下开门到位后开始计时默认8秒自动关门。如果光幕检测到有乘客正在进出计时复位重新开始。这个功能在程序里实现很简单一个定时器加一个光幕输入信号就行但实际体验提升非常明显。我见过一些项目图省事不做光幕信号接入乘客带着行李进出电梯经常被夹投诉率很高。2.5 平层减速与停车的时序控制电梯快接近目标楼层时要减速到平层位置要停车这两个动作由两个感应器配合完成。我用的方案是目标楼层的第一感应器减速感应器触发后输出方向接触器断开同时输出低速接触器第二感应器平层感应器触发后完全断开输出并启动抱闸。这样电梯在低速状态下滑行一小段平层体感上基本感觉不到顿挫。这个时序在程序里必须处理干净不然容易出拖泥带水的情况。我习惯用M区标志位记录当前运行状态0表示静止、1表示减速、2表示平层。状态跳转严格按照感应器信号来不用定时器猜位置。定时器只用来做超时保护比如运行了10秒还没收到平层信号直接强制停车报警这在调试阶段能救你很多次。3. KTP1200触摸屏组态与画面设计3.1 HMI的基本框架不是把按钮怼上去就行KTP1200组态在博途的WinCC里完成。我见过太多人把触摸屏做成一个按钮一个功能的大杂烩操作员用起来一脸懵。正确的做法是把画面分成几个功能区监控区、操作区、报警区、参数区。我的画面结构是主画面放楼层状态模拟图楼宇剖面加轿厢位置动态移动、运行方向指示、门状态指示、内外呼按钮实时状态操作画面放权限开关、手动/自动切换、单层调试按钮报警画面放实时报警列表包括超载、门故障、平层故障、通信故障参数画面放开门延时时间、运行速度档位、楼层名称文本。这样操作员日常看主画面就够了出问题再进报警画面查原因。主画面的提升技巧是让轿厢位置随PLC里的楼层数据动态变化。我在PLC里维护一个整数变量CurFloor触摸屏上画五层楼的标识再在每层楼位置放一个显示元素通过变量比较控制可见性。比如变量CurFloor等于33楼的轿厢标志就可见其他楼层不可见。这种效果看着高级实际上就是几个可见性动画组态成本很低。3.2 变量连接与数据块规划触摸屏和PLC通信的基础是变量。我在PLC里专门建了一个DB块叫HMI_Data里面把所有需要触摸屏访问的数据集中存放当前楼层、运行方向、门状态、内呼请求数组、外呼请求数组、故障代码、手动操作命令。这样做的原因是程序里访问DB块比直接访问I/O点更规范而且HMI一次性读取整个DB块的效率比分散读I/O点高得多。变量命名也要养成好习惯别用Tag_1、Tag_2这种。我的命名规则是“类型_描述_用途”比如CurFloor_Int、DoorState_Bool、UpCall_Array。触摸屏组态的时候直接拖变量就能对应上省去大量连线核对时间。博途还支持PLC变量直接发布到HMI就不用两边重复建变量了这个功能一定要用起来能少掉一半重复工作量。3.3 报警组态与操作记录KTP1200的报警功能很多人没充分利用。我在PLC程序里把故障按级别编码一般故障超载、门超时显示提示类报警严重故障平层丢失、运行超时显示急停类报警。每个报警关联一个文本和一段建议操作操作员看到报警后不用翻图纸也能知道怎么处理。报警信息通过PLC里自定义的故障字传递故障字里面每一位代表一种故障PLC程序中发生故障就置位复位按钮做解锁功能。触摸屏按字读取并映射到报警文本这个方案比每个故障单独建一个报警变量省变量也方便做历史记录。KTP1200自带报警缓冲区可以记录最近几百条报警发生时间和复位时间排查偶发故障时特别有用建议开启这个功能。3.4 手动检修模式的设计逻辑自动模式之外一定要留一个手动检修模式这是调试阶段最重要的工具。检修模式下触摸屏显示四方向按钮和开关门按钮操作员点住按钮电梯就动松开就停。检修速度由变频器点动端子控制不走正常逻辑。这个模式的意义在于程序逻辑出问题时可以通过手动模式先把电梯开到平层位置再切回自动模式继续排查不至于让电梯卡在两个楼层之间别人进不去也出不来。手动模式和自动模式的切换必须做安全互锁切到检修模式时自动模式的所有输出指令全部清零防止输出残留在自动和手动切换的瞬间造成误动作。我在程序里用一个模式标志位区分每个输出点的驱动条件是“模式标志位 AND 对应模式逻辑”从结构上避免输出交叉。4. 通信配置与整机联调全流程4.1 IP分配与Profinet组态S7-1200和KTP1200之间走Profinet第一步是给两个设备分配IP地址。我的习惯是把PLC设成192.168.0.1触摸屏设成192.168.0.2子网掩码统一255.255.255.0。如果现场还有其他设备IP规划就要提前做表格避免冲突。博途里组态Profinet网络时把HMI从硬件目录拖到网络视图连接到PLC的Profinet接口上即可系统会自动建立连接。下载程序的时候有个坑值得提一下PLC和HMI的下载顺序有讲究。我一般先下载PLC程序确认PLC运行正常后再下载HMI项目。如果先下载HMIHMI在线找设备时PLC处于停止状态通信建立会失败虽然不耽误后续操作但白白浪费时间排查。另外HMI的项目下载要走网线组态前先看好电脑网口和两个设备的IP在同一网段否则连不上设备也不知道原因。4.2 从模拟调试到现场调试的步骤调试策略很重要我的习惯是先模拟后实机。模拟阶段用博途的仿真功能或者干脆在程序里写一个测试段用触摸按钮模拟传感器信号。把电梯逻辑跑通一遍确认所有状态跳转都符合预期后再接真实I/O。现场调试我严格按这个顺序走第一步只通电不使能输出检查所有输入信号是否被PLC正确采集这一步能发现接线错误和传感器类型选错的大多数问题第二步手动模式点动确认接触器和电机方向是否正确方向反了就把电机相序调过来第三步空载自动跑不载人从一层到五层反复跑观察平层精度和门控制时序最后才是负载测试按额定载重逐步加码。4.3 联调中的常见问题与排查技巧联调阶段最容易出的问题我整理了一个排查表都是实际遇到过的现象可能原因排查方法触摸屏花屏或不亮IP不在同网段 / 项目版本不匹配检查设备IP用Ping命令测通确认HMI项目版本和固件匹配电梯不动但无报警门锁信号没接通查看输入表中门锁位是否有信号检查门锁继电器和接线减速信号没反应感应器位置安装偏移用万用表测感应器输出调整安装支架位置并固定平层精度差减速触发点太晚或太早调整减速感应器的安装高度观察实际停车位置触摸屏按钮点了没效果HMI变量连接丢失检查HMI变量是否映射到DB块正确偏移地址通信间歇性中断网线接触不良 / 变频器干扰更换屏蔽网线检查线缆和接地情况变频器动力线与通信线分离还有一个调试神技分享给大家博途的在线监视功能边运行边看程序里的变量变化。电梯跑动过程中把FC_Direction打开盯着方向判断变量的跳变能直观看到电梯在哪一步出现逻辑错误。这个功能比任何仿真都实用因为它是真实I/O状态下的实时数据。4.4 数据记录与偶发故障追踪电梯这类设备最怕是偶发故障十次运行九次好一次出问题。排查这种问题靠眼睛盯是不行的必须靠数据记录。S7-1200有内置的Diagnostic Buffer程序里也可以自己写数据记录功能。我的做法是在电梯每次完成一个运行周期时把关键数据请求楼层、当前楼层、方向、门状态、故障字追加写入PLC的保持性存储区触摸屏上做一页曲线/表格显示。有了运行记录偶发故障就变成了可追溯的问题。比如某次故障前故障字的某一位先跳了一下就能顺着时间戳定位到对应的传感器或接触器。我还试过在程序里加定时采集每200毫秒把状态存入数组故障发生后再把这些数组上传到触摸屏显示。虽然是笨办法但在排查现场疑难问题时效率非常高。5. 经验心得与扩展方向整个项目做下来我最大的体会是电梯控制系统的难点不在单个功能而在多个功能叠加后的状态冲突管理。比如内外呼同时到达、乘客在关门瞬间按了开门按钮、超载信号和门锁信号同时触发——这些边界情况才是程序质量的分水岭。新手写电梯程序最容易忽略的就是边界条件和互锁关系的穷举上电调试时各种稀奇古怪的现象基本都是这些边角逻辑没处理好引起的。再分享几个具体的经验。第一无条件给所有输出做安全互锁哪怕你认为某个输出不可能同时动作也把互锁加上成本很低但心里踏实。第二声音报警一定要做蜂鸣器比屏幕提示更能引起操作员注意电梯困人的时候外面的人听到蜂鸣器就知道出事了。第三楼层计数不要单独依赖感应器我在程序里用感应器加方向信号联合判断楼层变化感应器在楼层交界处抖动干扰时也不容易误计数。第四硬件选型时留好备用IO和备用扩展槽位项目交付后提出新增功能是常态没留余地就得改柜子非常狼狈。这个项目的扩展空间也很大。比如在此基础上加入变频器Profinet通信直接通过PLC写速度给定和读取电流反馈替代接触器控制的硬启停方案加入远程监控模块通过4G网关把电梯状态传到云端平台或者把单梯控制扩展成两梯联动需要增加群控调度算法——这些都是从这套基础系统出发能自然延伸出来的进阶方向。对于想往工业物联网方向发展的朋友把PLC数据往云上打就是很好的下一个练手项目。最后补充一个我踩过的坑触摸屏画面设计别一味追求炫酷动画和图片太多会拖慢HMI的刷新速度真实项目里操作员对响应速度的敏感度远超对视觉效果的敏感度。KTP1200性能足够用但也别把CPU时间浪费在无意义的动画上。保持界面简洁、信息层次清晰、操作路径短才是工业HMI设计的正道。
阅读完成 · 觉得有帮助？
