做电梯控制项目这些年我一直觉得西门子1200系列是个被低估的好选择。很多人一提到电梯控制第一反应是专用电梯控制板或者老派的三菱FX系列。但真正把二部、三部六层这种小型群控项目做完之后你会发现S7-1200在性价比、通信扩展和程序可维护性上反而有不少“真香”的地方。这篇文章我把二部六层、三部六层电梯的控制程序拆开来讲从调度逻辑到博途编程实现把当初跑现场踩过的坑也一并写出来给正在搞类似项目的朋友做个参考。1. 项目整体设计与选型思路1.1 六层电梯的控制需求拆解六层楼的电梯和我们平时接触的高层电梯相比层站数量不算多但控制逻辑的完整度并不低。一个标准的六层电梯控制系统需要覆盖这几个基本功能轿厢内选层登记、候梯厅上下行呼叫登记、楼层位置检测、轿厢运行方向指示、到站平层自动开门、开关门时间控制、超载检测保护以及检修、消防、锁梯等一系列安全模式。从IO点数来看六层电梯大概需要这么一组信号一层一个轿厢内选层按钮一共6个输入一层一个楼层感应开关平层感应器一共6个输入一层一个上行外呼按钮一到五层有就是5个输入一层一个下行外呼按钮二到六层有也是5个输入再加上开门按钮、关门按钮、开门限位、关门限位、超载开关、检修开关、轿厢照明接触器反馈、主接触器反馈、抱闸反馈、变频器故障、变频器运行反馈等等输入点总数大致在30到36个左右。输出侧呢就比较直接了每个楼层一个楼层显示数码管如果不做驱动板的话就需要二进制编码输出用4个点就够了上下行指示灯各1个开门接触器、关门接触器各1个主接触器控制、抱闸控制、变频器启动/停止/方向控制、蜂鸣器、照明、风扇、故障指示等等输出点的总数基本在26到30个之间。这还没算上信号灯、到站钟这类附加装置。所以我最初做二部六层方案的时候选了CPU 1214C DC/DC/DC本机自带14路数字量输入和10路数字量输出再外扩一个SM 1223数字量混合模块8入8出IO刚好够用还留了一小部分备用点。这个配置在成本上是比较舒服的也符合“够用就好的原则。1.2 二部与三部电梯的差异点在哪里很多人觉得二部六层和三部六层无非就是多一台电梯程序复制一遍就行。这个想法我一开始也有真做起来发现不是这么回事。二部电梯也就是俗称的双梯并联核心难点在于两台电梯之间要互相通信、协调响应外呼信号。简单说如果一层有人按了上行外呼系统要判断是1号梯去还是2号梯去判断依据包括两台梯当前所在楼层、运行方向、是否已经满载、距离呼叫层的远近、当前是否在响应其他外呼等等。这个过程在行业内叫“梯群调度”或者“并联调度”二部电梯通常用“先到先得顺向截梯”的思路。三部电梯则复杂一些因为调度选择从一个“二选一”变成了“三选一”而且要考虑“不扎堆”的问题。比如早晚高峰期三部梯很容易同时跑到同一个楼层区域去抢同一个外呼导致其他楼层长时间没有电梯响应。这时就需要引入分区调度或者轮值策略比如把六层分成低区1-3层和高区4-6层三部梯按照不同的基准楼层分布一台驻留一层一台驻留四层一台作为机动这样等乘客到来时响应速度明显更快。另外还有一个容易被忽略的差异点故障耦合度。二部梯如果一台坏了另一台要承担全部的外呼任务程序的冗余逻辑要能扛住这种负荷三部梯相对好一些掉一台还有另外两台顶上。但是如果三部梯之间通信断掉了整个群控会退回各自独立运行模式这时候六层楼的体验就会突然变差所以在程序里必须设计好通信超时时的降级策略。1.3 为什么选S7-1200而不是专用板或小型继电器系统我见过不少现场还在用几十个中间继电器搭出来的电梯控制柜故障率高得离谱查线能查到怀疑人生。专用电梯控制板呢功能是集成度高但程序是厂家写死的你想改个调度策略、加个楼层显示协议往往要付费定制甚至只能换板子。S7-1200的优势在于它的编程环境博途TIA Portal提供了足够的灵活性我可以把电梯的控制逻辑像写“状态机”一样清晰地组织起来而且它自带以太网口调试的时候连一台笔记本就能在线监控程序哪个信号没过来、哪个输出没导通一目了然。这在现场排查故障时效率比拿着万用表去查继电器触点高太多了。再加上S7-1200可以选配通信模块做自由串口通信电梯的楼层信息、故障代码、运行状态这些数据可以通过RS485接到后台监控、轿厢显示屏或者物业的电脑上这个后面我专门用一章来讲。2. 电梯核心调度逻辑设计2.1 呼叫登记与消号机制电梯程序里面最核心的不是“让电梯跑起来”而是“让电梯知道该去哪”。这个“知道”靠的就是呼叫登记与消号机制。内呼按钮在轿厢里乘客按了某一层的按钮如果电梯还没到那层或者已经过了那层这个指令就要保持住不能被清掉。外呼按钮在候梯厅分上行和下行的箭头按钮登记逻辑也一样等到有电梯到达该层并且方向一致时这个外呼才能消掉。在PLC程序里每个呼叫都是一个保持继电器或置位位。内呼的消号条件相对明确电梯到达目标楼层且平层完成、开门到位这时候内呼清零。外呼的消号条件稍微讲究一点比如二层有人按下行外呼电梯到达二层并且运行方向是向下开门之后外呼才可以复位。如果电梯是上行经过二层即使开门了二层下行外呼也不能消掉否则下面还有人在等结果你没停这就要出投诉了。行业里比较常见的做法是给每个外呼设置两组标志位呼叫登记标志和到达响应标志。电梯每一次经过呼叫楼层时程序根据当前运行方向判断是否响应这个外呼如果响应就置位“响应标志”然后等平层开门后同时清除“呼叫登记标志”和“响应标志”。这个流程写出来不复杂但在实际调试中非常考验细节因为方向判断和响应标志的时序错一拍就会出现“电梯到了但门不开”或者“门开了但呼叫没消”的情况。2.2 方向判断与最远端换向逻辑电梯运行方向上我见过的最容易理解的算法是“最远端换向法”。思路是这样的电梯有一个当前运行方向标志要么向上、要么向下、要么无方向空闲。电梯运行时先把当前上行方向上所有已登记的内呼和外呼楼层全部跑完直到上行方向中没有任何一个呼叫楼层在当前层之上。然后电梯自动切换到下行方向并把下行方向上所有已登记的呼叫层全部跑完。如此反复直到所有呼叫都处理完电梯进入空闲状态。举个具体例子电梯当前停在3楼方向向上。此时2楼有下行外呼、5楼有上行外呼、4楼有内呼。电梯会怎么走按照最远端换向逻辑电梯先从3楼向上到4楼响应内呼再到5楼响应上行外呼。到5楼之后程序检查上行方向楼上已经没有呼叫了于是换向下行。向下过程中经过4楼但因为4楼内呼已消不会停经过3楼没呼叫经过2楼有下行外呼而且电梯当前方向向下于是停靠开门2楼下行外呼消号。完成之后电梯再检查上下方向都没有呼叫了回到空闲状态。这个算法的好处是简单、可靠、不会漏响应缺点是不够“聪明”——在极低客流时会有不必要的来回跑动。但六层楼的场景下它的效率损耗完全可以接受。我实际做这套程序时的建议是先按最远端换向逻辑跑通整个程序后面如果确实需要优化再加入“顺向截车”和“就近分配”的优化逻辑一步步演进而不是一上来就整一个复杂的模糊算法。2.3 二部并联调度里怎么分配外呼双梯并联调度的常用策略我归纳为三种第一种是按“响应时间最短”原则分配。系统在收到某个外呼时实时计算1号梯到达该外呼楼层并完成同向停靠所需的估算时间再算2号梯的估算时间谁短谁去。这里要估算电梯的平均运行速度、加减速时间、开关门时间粗略算也行毕竟主要看相对大小关系。第二种是“轮值优先”原则。1号梯处理完当前任务后回到基站待命2号梯处理完回到另一个基站。新的外呼来了轮流分配给1号或2号梯。这样能保证两台梯的工作量大致均衡。第三种是“运行方向优先”原则。如果某台梯当前正处于上行状态恰好新外呼是上行方向的就让这台梯优先响应如果两个外呼方向不同则分别分配给不同方向的电梯。这套策略在早晚高峰特别管用。实际项目里我通常是三种组合起来用总体优先级是方向优先优先于距离优先距离优先优先于轮值优先。在PLC里实现时每收到一个新外呼就执行一次分配判断把这个外呼归给某台梯的“虚拟外呼登记区”然后该台梯把它当作自己的内呼外呼混合列表来处理。另一台梯即使物理上经过这个楼层也不会响应这个外呼——这就避免了双梯同时去抢一个呼叫的情况。2.4 三部电梯的群控策略调整三部电梯的群控逻辑我把它做成了“固定分区动态支援”的模式。固定分区把6个楼层分成3个区域1号和2号梯负责低区3号梯负责高区或者说1号梯负责1-2层2号梯负责3-4层3号梯负责5-6层。乘客在哪个区域按外呼对应的电梯优先响应。动态支援如果负责该区域的电梯处于检修、故障或者满载状态其他空闲的电梯要能接管该区域的外呼。此外三部电梯必须要有一个“基站位置管理”逻辑。我让1号梯默认停靠在1层2号梯默认停靠在3层3号梯默认停靠在6层。这样电梯分布在整个井道中无论乘客在哪层呼梯三部梯的平均响应距离都最短。当某台梯空闲时间超过设定值比如3分钟就自动慢速回到自己的基站。这里有个非常关键的点三部梯之间的外呼分配状态必须实时同步。我在程序里用S7-1200之间常见的以太网通信或者用IEC TCP通信来做数据交换每台梯定时把自己的运行状态、方向、所在楼层、已分配外呼列表广播给其他两台梯。通信周期我设为200毫秒实测下来三部六层场景完全够用。3. 西门子1200程序实现要点3.1 硬件配置与IO地址分配我用的硬件方案是两台/三台CPU 1214C DC/DC/DC每台电梯一套完整控制系统。重要的安全回路急停、门锁回路、极限开关、超载等采取硬接线方式直接串入主接触器的控制回路不依赖PLC程序。这个原则必须先立起来——PLC程序只是运行控制逻辑安全防护必须靠物理回路。我的IO分配表大致如下以单台电梯为例I0.0-I0.5六层平层感应器常开型到达楼层时闭合I0.6-I0.7、I1.0-I1.3轿厢内选层按钮1至6层I1.4-I1.61-3层上行外呼按钮I2.0-I2.24-6层上行外呼按钮6层没有上呼只用5个点这里按需求调整I2.3-I2.5等下行外呼按钮I3.0开门按钮I3.1关门按钮I3.2开门到位限位I3.3关门到位限位I3.4超载开关I3.5检修开关I3.6主接触器反馈I3.7抱闸反馈。Q0.0上行方向接触器Q0.1下行方向接触器Q0.2主接触器Q0.3抱闸接触器Q0.4开门接触器Q0.5关门接触器Q0.6运行蜂鸣器。Q1.0-Q1.3楼层显示的8421编码输出。这个表格不是唯一的但有一个原则性的经验平层感应器和门区信号尽量用一个输入模块集中接入不要东一个西一个方便调试时集中监控。平层信号是电梯定位的“眼珠子”优先级最高绝对不能和变频器输出做在同一个输出模块上避免强干扰。3.2 博途TIA Portal程序结构怎么搭S7-1200的程序我用的是模块化组织。OB1作为主循环调用各个功能块核心功能拆成FB函数块和FC函数FC100呼叫登记与消号统一处理内外呼FB200方向判断与最远端换向用带背景数据块的FB写方便记录运行状态FC300平层处理与停靠逻辑FB400开关门控制FC500楼层显示与信号灯控制FB600通信数据整理与群控分配双梯/三梯FC700故障检测与报警FB800自由串口收发处理为什么要用带背景DB的FB而不是全部用FC因为电梯程序的运行状态非常多当前是否运行、运行方向、到站停车标志、开门时间计时、呼叫列表状态等等。如果用FC这些中间变量要在OB1或者全局DB里定义变量一多监控起来非常乱。FB的好处是每个功能块自带背景数据块局部变量和运行状态都封装在DB里程序的可读性和可维护性高一个档次。3.3 平层与停靠逻辑的实现细节平层停靠是整个程序中时序要求最高的部分。六层电梯的平层感应器通常安装在井道每层楼的平层位置轿厢上的感应铁板随轿厢运动感应到对应平层开关时PLC知道轿厢正在这一层。程序里的停靠判断逻辑可以简化成一句话当电梯进入某个楼层并且该楼层的呼叫列表中有需要响应的呼叫同时电梯当前运行方向与该呼叫方向匹配就执行“减速-平层-开门”的流程。在PLC程序里我习惯用两个标志位来锁定楼层一个是“进入楼层标志”一个是“楼层有效标志”。运行过程中读到的平层感应信号先进入“进入楼层标志”并且楼层号要连续判断如果前一帧没感应到3层这一帧感应到了说明电梯刚进入3层平层区如果前一帧还在3层这一帧也在3层说明电梯停在3层或者正在缓慢通过。这两种状态要区分开否则电梯可能在某个楼层反复触发开门。实际调试中我遇到过一个问题电梯在低速爬行经过楼层平层区时平层信号抖动了两次导致程序以为电梯进了两层楼楼层显示乱跳。后来我的解决方案是加一个“信号稳定延时”平层信号持续50毫秒以上才认定为有效同时增加“同层多次触发只算一次”的防抖逻辑效果立竿见影。3.4 开关门控制与安全互锁开关门控制看起来简单做起来细节不少。我设置的核心参数有这几个开门时间默认6秒可通过轿厢内开门按钮延长到8秒。关门时间默认3秒若关门过程中有物体挡住门门区光幕/安全触板信号立即重新开门。关门超时保护如果连续关门超过15秒仍未收到关门到位信号程序判定关门异常停止关门动作并输出故障代码提示。开门继电器吸合后延时2秒才允许启动主接触器和运行接触器防止开门状态下带着门跑。安全互锁方面我的原则是“所有启动条件必须全部为真才允许输出运行”。关键条件包括关门到位信号为真、门锁回路闭合通过反馈点检测、超载信号为假、检修模式关闭、无任何故障。这里尤其要注意门锁回路的接线逻辑我建议门锁回路的反馈信号既有常开点也有常闭点同时进PLC程序里判断这两个点是否“逻辑一致”如果不一致就判定为门锁触点粘连故障停梯报警。这个做法能防住很多门锁触点老化导致的隐性故障。4. 自由串口扩展让电梯数据开口说话4.1 什么是西门子1200的自由串口通信说到“西门子1200之自由串口”这可能是不少朋友觉得最陌生的一块。通俗讲S7-1200的串口通信模块CM1241 RS232/RS485除了支持Modbus RTU这种标准协议之外还可以配置成一种叫“自由口”的模式——在这个模式下通信协议完全由用户自己定义报文的长度、帧头帧尾、校验方式、数据内容全部写在自己程序里。因为协议不受限所以叫“自由”。这个功能的典型用途包括对接第三方电梯状态显示器、LED楼层显示屏、轿厢内信息屏、后台监控主机、或者外接到物业的串口服务器。很多显示终端不支持标准的Modbus协议只支持厂家自定义的简单串口协议这时候自由口就派上用场了。在TIA Portal中S7-1200自由口通信的配置路线是在设备组态里给CM1241模块选择“Freeport”协议也就是自由口然后在程序里调用“R”接收指令和“S”发送指令对应的功能块在博途的帮助里搜RCV和XMT即可找到。接收和发送都是异步执行的也就是说程序每扫描一次只会去查询一次接收缓冲区里有没有数据、发送缓冲区是否空闲实际数据搬运是靠模块后台完成的。4.2 自由串口报文设计实战我实际做过一个轿厢内LED显示屏的对接项目要求PLC把梯号、当前楼层、运行方向和开关门状态发给屏幕。我设计的报文格式是这样的帧头2字节AA 55 数据区6字节字节梯号、楼层号、方向0停止1上行2下行、开关门状态0关门1开门、预留字节、预留字节 校验1字节所有数据区字节累加取低8位 帧尾2字节0D 0A发送周期我设为500毫秒屏幕每收到一帧有效报文就刷新一次显示。这个方案在自由口下实现非常简单PLC里建一个发送缓冲区把上述字节填充好然后调用发送指令把整个缓冲区扔出去。接收方向的设计同理比如后台电脑可以发送命令让电梯切换检修模式、锁定某个楼层或者请求当前状态。在自由口接收程序里我推荐做三层过滤第一层判断帧头是否匹配第二层判断数据长度是否在预期范围内第三层做累加和校验校验不过就丢弃整帧不做任何动作。这三层过滤做好之后通信的稳定性会非常好几乎不会出现误触发。4.3 自由串口实战中的几个坑自由口通信最常踩的坑有三个第一个坑是“接线没有共地”。RS485是差分信号理论上不依赖于地线但如果两个设备之间没有公共地信号漂移会非常明显尤其是在电机启动、变频器运行的时候通信错误率飙升。我的建议是RS485的A/B两根线要双绞屏蔽层单端接地尽量从柜内干净接地点引地线到通信设备的地端。第二个坑是“波特率不匹配”。PLC侧和终端设备侧的波特率、数据位、校验位、停止位必须完全一致否则对端收到的是乱码。常规我用9600波特率、8位数据位、无校验、1位停止位这个组合兼容性最好。第三个坑是“发送和接收不能同时写入缓冲区”。自由口模块是半双工还是全双工取决于模块型号RS485基本都是半双工RS232也常配成半双工使用。程序里必须加一个“发送忙”标志前一次发送指令还没执行完时不能再次触发发送否则数据会相互覆盖帧直接损坏。我在程序里用一个独立的“发送标志位”来锁存发送指令的完成位DONE为真时复位该标志位这样就能稳定地按周期发送数据。5. 调试与故障排查实录5.1 平层信号抖动的排查现场调试时最让我头疼的一个问题就是平层信号抖动导致楼层错乱。电梯在低速运行时经过每层楼的平层感应开关信号理论上应该是一干净利落的“上升沿-保持-下降沿”但由于安装间隙、感应铁板距离波动、变频器谐波干扰等原因实际信号往往是“毛刺”的。我排查时用的方法很简单在博途在线监控里把该平层信号的数据类型改成时间戳型变量然后让电梯以检修速度全程跑一遍记下信号的每次跳变时间点。对比后发现正常信号持续时间大约120毫秒而毛刺信号只有10到20毫秒。于是我在程序里加了一个延时判断信号必须持续30毫秒以上才被认定为有效平层信号。这个办法直接解决了90%的抖动问题。另外因为平层信号板装在井道内如果桥架上还有变频器动力线两者靠得太近的话感应开关的感应电压会受到耦合干扰。我的做法是平层信号线用屏蔽线屏蔽层在PLC侧单端接地并且尽量远离变频器输出线。5.2 双梯通信中断导致群控失效二部或三部电梯群控调试时通信中断是高频故障。我遇到过一次很典型的情况1号和2号梯的通信模块都正常唯独2号梯收不到1号梯的心跳包但1号梯能正常收到2号梯的包。排查下来发现是因为1号梯所在的控制柜和2号梯的通信模块共用一个隔离电源而1号梯的抱闸接触器动作时电源电压会产生一个比较大的跌落脉冲导致1号梯的通信模块瞬间重启。解决方法是把通信模块的供电独立出来加了一个DC-DC隔离电源模块问题就消失了。这个案例给我的教训是调试群控通信时不要只盯通信参数要关注电源质量和接地。通信模块对电源的敏感程度远高于普通PLC模块供电不稳的情况下通信异常是必然的。5.3 常见问题速查表我把调试过程中最常见的几类问题整理成一个速查表方便参考现象可能原因排查方向电梯能运行但楼层显示乱跳平层信号抖动、编码器信号接线松动检查平层信号防抖逻辑、接线压接外呼登记了但电梯不响应外呼分配逻辑错误、群控通信中断检查群控分配结果、通信心跳状态门开了关不上关门限位接触不良、光幕被遮挡查关门到位信号回路、检查门区光幕运行中突然急停门锁回路反馈丢失、超载误动作查门锁反馈点、超载开关调整自由串口收不到数据接线共地不良、波特率不一致检查RS485接线、核对通信参数双梯/三梯互相抢呼调度策略优先级没设好检查群控分配结果、分配标志位是否互斥5.4 运行试验的几个安全习惯调试电梯程序时我养成了几个固定习惯在这里重点强调一下。第一程序下载和修改之后先做全面的离线仿真再上电联调。西门子博途支持PLCSIM仿真虽然S7-1200的仿真不支持全部通信模块但主逻辑的仿真完全能做。第二联调时把检修速度设置为额定速度的30%到50%并且在井道和轿厢内安排专人看护。急停按钮的位置要在现场提前交底确保任何情况下人都能第一时间按停。第三每一次修改程序都要在程序注释里写明修改时间、修改人和修改内容。电梯程序属于特种设备相关的控制程序版本管理非常重要后期维护时没有版本记录的代码几乎没法接手。最后再分享一个我实际用下来很舒服的小技巧在S7-1200的自由口通信里发送和接收缓冲区的长度不要定得刚刚好多留几个字节的余量这样以后扩展协议内容时不用改硬件也不用改通信配置只需要在程序里调整数据区的填充内容就行。我第一版把缓冲区定义为16字节后来加了一个“运行模式”字段直接把原来的预留字节改一下含义前后不到十分钟就改完了兼容性一点没受影响。这种“预留扩展”的思路做电梯程序这种维护性要求高的项目真的很值得养成。
西门子S7-1200电梯控制：从二部三部六层群控到自由串口通信实战
做电梯控制项目这些年我一直觉得西门子1200系列是个被低估的好选择。很多人一提到电梯控制第一反应是专用电梯控制板或者老派的三菱FX系列。但真正把二部、三部六层这种小型群控项目做完之后你会发现S7-1200在性价比、通信扩展和程序可维护性上反而有不少“真香”的地方。这篇文章我把二部六层、三部六层电梯的控制程序拆开来讲从调度逻辑到博途编程实现把当初跑现场踩过的坑也一并写出来给正在搞类似项目的朋友做个参考。1. 项目整体设计与选型思路1.1 六层电梯的控制需求拆解六层楼的电梯和我们平时接触的高层电梯相比层站数量不算多但控制逻辑的完整度并不低。一个标准的六层电梯控制系统需要覆盖这几个基本功能轿厢内选层登记、候梯厅上下行呼叫登记、楼层位置检测、轿厢运行方向指示、到站平层自动开门、开关门时间控制、超载检测保护以及检修、消防、锁梯等一系列安全模式。从IO点数来看六层电梯大概需要这么一组信号一层一个轿厢内选层按钮一共6个输入一层一个楼层感应开关平层感应器一共6个输入一层一个上行外呼按钮一到五层有就是5个输入一层一个下行外呼按钮二到六层有也是5个输入再加上开门按钮、关门按钮、开门限位、关门限位、超载开关、检修开关、轿厢照明接触器反馈、主接触器反馈、抱闸反馈、变频器故障、变频器运行反馈等等输入点总数大致在30到36个左右。输出侧呢就比较直接了每个楼层一个楼层显示数码管如果不做驱动板的话就需要二进制编码输出用4个点就够了上下行指示灯各1个开门接触器、关门接触器各1个主接触器控制、抱闸控制、变频器启动/停止/方向控制、蜂鸣器、照明、风扇、故障指示等等输出点的总数基本在26到30个之间。这还没算上信号灯、到站钟这类附加装置。所以我最初做二部六层方案的时候选了CPU 1214C DC/DC/DC本机自带14路数字量输入和10路数字量输出再外扩一个SM 1223数字量混合模块8入8出IO刚好够用还留了一小部分备用点。这个配置在成本上是比较舒服的也符合“够用就好的原则。1.2 二部与三部电梯的差异点在哪里很多人觉得二部六层和三部六层无非就是多一台电梯程序复制一遍就行。这个想法我一开始也有真做起来发现不是这么回事。二部电梯也就是俗称的双梯并联核心难点在于两台电梯之间要互相通信、协调响应外呼信号。简单说如果一层有人按了上行外呼系统要判断是1号梯去还是2号梯去判断依据包括两台梯当前所在楼层、运行方向、是否已经满载、距离呼叫层的远近、当前是否在响应其他外呼等等。这个过程在行业内叫“梯群调度”或者“并联调度”二部电梯通常用“先到先得顺向截梯”的思路。三部电梯则复杂一些因为调度选择从一个“二选一”变成了“三选一”而且要考虑“不扎堆”的问题。比如早晚高峰期三部梯很容易同时跑到同一个楼层区域去抢同一个外呼导致其他楼层长时间没有电梯响应。这时就需要引入分区调度或者轮值策略比如把六层分成低区1-3层和高区4-6层三部梯按照不同的基准楼层分布一台驻留一层一台驻留四层一台作为机动这样等乘客到来时响应速度明显更快。另外还有一个容易被忽略的差异点故障耦合度。二部梯如果一台坏了另一台要承担全部的外呼任务程序的冗余逻辑要能扛住这种负荷三部梯相对好一些掉一台还有另外两台顶上。但是如果三部梯之间通信断掉了整个群控会退回各自独立运行模式这时候六层楼的体验就会突然变差所以在程序里必须设计好通信超时时的降级策略。1.3 为什么选S7-1200而不是专用板或小型继电器系统我见过不少现场还在用几十个中间继电器搭出来的电梯控制柜故障率高得离谱查线能查到怀疑人生。专用电梯控制板呢功能是集成度高但程序是厂家写死的你想改个调度策略、加个楼层显示协议往往要付费定制甚至只能换板子。S7-1200的优势在于它的编程环境博途TIA Portal提供了足够的灵活性我可以把电梯的控制逻辑像写“状态机”一样清晰地组织起来而且它自带以太网口调试的时候连一台笔记本就能在线监控程序哪个信号没过来、哪个输出没导通一目了然。这在现场排查故障时效率比拿着万用表去查继电器触点高太多了。再加上S7-1200可以选配通信模块做自由串口通信电梯的楼层信息、故障代码、运行状态这些数据可以通过RS485接到后台监控、轿厢显示屏或者物业的电脑上这个后面我专门用一章来讲。2. 电梯核心调度逻辑设计2.1 呼叫登记与消号机制电梯程序里面最核心的不是“让电梯跑起来”而是“让电梯知道该去哪”。这个“知道”靠的就是呼叫登记与消号机制。内呼按钮在轿厢里乘客按了某一层的按钮如果电梯还没到那层或者已经过了那层这个指令就要保持住不能被清掉。外呼按钮在候梯厅分上行和下行的箭头按钮登记逻辑也一样等到有电梯到达该层并且方向一致时这个外呼才能消掉。在PLC程序里每个呼叫都是一个保持继电器或置位位。内呼的消号条件相对明确电梯到达目标楼层且平层完成、开门到位这时候内呼清零。外呼的消号条件稍微讲究一点比如二层有人按下行外呼电梯到达二层并且运行方向是向下开门之后外呼才可以复位。如果电梯是上行经过二层即使开门了二层下行外呼也不能消掉否则下面还有人在等结果你没停这就要出投诉了。行业里比较常见的做法是给每个外呼设置两组标志位呼叫登记标志和到达响应标志。电梯每一次经过呼叫楼层时程序根据当前运行方向判断是否响应这个外呼如果响应就置位“响应标志”然后等平层开门后同时清除“呼叫登记标志”和“响应标志”。这个流程写出来不复杂但在实际调试中非常考验细节因为方向判断和响应标志的时序错一拍就会出现“电梯到了但门不开”或者“门开了但呼叫没消”的情况。2.2 方向判断与最远端换向逻辑电梯运行方向上我见过的最容易理解的算法是“最远端换向法”。思路是这样的电梯有一个当前运行方向标志要么向上、要么向下、要么无方向空闲。电梯运行时先把当前上行方向上所有已登记的内呼和外呼楼层全部跑完直到上行方向中没有任何一个呼叫楼层在当前层之上。然后电梯自动切换到下行方向并把下行方向上所有已登记的呼叫层全部跑完。如此反复直到所有呼叫都处理完电梯进入空闲状态。举个具体例子电梯当前停在3楼方向向上。此时2楼有下行外呼、5楼有上行外呼、4楼有内呼。电梯会怎么走按照最远端换向逻辑电梯先从3楼向上到4楼响应内呼再到5楼响应上行外呼。到5楼之后程序检查上行方向楼上已经没有呼叫了于是换向下行。向下过程中经过4楼但因为4楼内呼已消不会停经过3楼没呼叫经过2楼有下行外呼而且电梯当前方向向下于是停靠开门2楼下行外呼消号。完成之后电梯再检查上下方向都没有呼叫了回到空闲状态。这个算法的好处是简单、可靠、不会漏响应缺点是不够“聪明”——在极低客流时会有不必要的来回跑动。但六层楼的场景下它的效率损耗完全可以接受。我实际做这套程序时的建议是先按最远端换向逻辑跑通整个程序后面如果确实需要优化再加入“顺向截车”和“就近分配”的优化逻辑一步步演进而不是一上来就整一个复杂的模糊算法。2.3 二部并联调度里怎么分配外呼双梯并联调度的常用策略我归纳为三种第一种是按“响应时间最短”原则分配。系统在收到某个外呼时实时计算1号梯到达该外呼楼层并完成同向停靠所需的估算时间再算2号梯的估算时间谁短谁去。这里要估算电梯的平均运行速度、加减速时间、开关门时间粗略算也行毕竟主要看相对大小关系。第二种是“轮值优先”原则。1号梯处理完当前任务后回到基站待命2号梯处理完回到另一个基站。新的外呼来了轮流分配给1号或2号梯。这样能保证两台梯的工作量大致均衡。第三种是“运行方向优先”原则。如果某台梯当前正处于上行状态恰好新外呼是上行方向的就让这台梯优先响应如果两个外呼方向不同则分别分配给不同方向的电梯。这套策略在早晚高峰特别管用。实际项目里我通常是三种组合起来用总体优先级是方向优先优先于距离优先距离优先优先于轮值优先。在PLC里实现时每收到一个新外呼就执行一次分配判断把这个外呼归给某台梯的“虚拟外呼登记区”然后该台梯把它当作自己的内呼外呼混合列表来处理。另一台梯即使物理上经过这个楼层也不会响应这个外呼——这就避免了双梯同时去抢一个呼叫的情况。2.4 三部电梯的群控策略调整三部电梯的群控逻辑我把它做成了“固定分区动态支援”的模式。固定分区把6个楼层分成3个区域1号和2号梯负责低区3号梯负责高区或者说1号梯负责1-2层2号梯负责3-4层3号梯负责5-6层。乘客在哪个区域按外呼对应的电梯优先响应。动态支援如果负责该区域的电梯处于检修、故障或者满载状态其他空闲的电梯要能接管该区域的外呼。此外三部电梯必须要有一个“基站位置管理”逻辑。我让1号梯默认停靠在1层2号梯默认停靠在3层3号梯默认停靠在6层。这样电梯分布在整个井道中无论乘客在哪层呼梯三部梯的平均响应距离都最短。当某台梯空闲时间超过设定值比如3分钟就自动慢速回到自己的基站。这里有个非常关键的点三部梯之间的外呼分配状态必须实时同步。我在程序里用S7-1200之间常见的以太网通信或者用IEC TCP通信来做数据交换每台梯定时把自己的运行状态、方向、所在楼层、已分配外呼列表广播给其他两台梯。通信周期我设为200毫秒实测下来三部六层场景完全够用。3. 西门子1200程序实现要点3.1 硬件配置与IO地址分配我用的硬件方案是两台/三台CPU 1214C DC/DC/DC每台电梯一套完整控制系统。重要的安全回路急停、门锁回路、极限开关、超载等采取硬接线方式直接串入主接触器的控制回路不依赖PLC程序。这个原则必须先立起来——PLC程序只是运行控制逻辑安全防护必须靠物理回路。我的IO分配表大致如下以单台电梯为例I0.0-I0.5六层平层感应器常开型到达楼层时闭合I0.6-I0.7、I1.0-I1.3轿厢内选层按钮1至6层I1.4-I1.61-3层上行外呼按钮I2.0-I2.24-6层上行外呼按钮6层没有上呼只用5个点这里按需求调整I2.3-I2.5等下行外呼按钮I3.0开门按钮I3.1关门按钮I3.2开门到位限位I3.3关门到位限位I3.4超载开关I3.5检修开关I3.6主接触器反馈I3.7抱闸反馈。Q0.0上行方向接触器Q0.1下行方向接触器Q0.2主接触器Q0.3抱闸接触器Q0.4开门接触器Q0.5关门接触器Q0.6运行蜂鸣器。Q1.0-Q1.3楼层显示的8421编码输出。这个表格不是唯一的但有一个原则性的经验平层感应器和门区信号尽量用一个输入模块集中接入不要东一个西一个方便调试时集中监控。平层信号是电梯定位的“眼珠子”优先级最高绝对不能和变频器输出做在同一个输出模块上避免强干扰。3.2 博途TIA Portal程序结构怎么搭S7-1200的程序我用的是模块化组织。OB1作为主循环调用各个功能块核心功能拆成FB函数块和FC函数FC100呼叫登记与消号统一处理内外呼FB200方向判断与最远端换向用带背景数据块的FB写方便记录运行状态FC300平层处理与停靠逻辑FB400开关门控制FC500楼层显示与信号灯控制FB600通信数据整理与群控分配双梯/三梯FC700故障检测与报警FB800自由串口收发处理为什么要用带背景DB的FB而不是全部用FC因为电梯程序的运行状态非常多当前是否运行、运行方向、到站停车标志、开门时间计时、呼叫列表状态等等。如果用FC这些中间变量要在OB1或者全局DB里定义变量一多监控起来非常乱。FB的好处是每个功能块自带背景数据块局部变量和运行状态都封装在DB里程序的可读性和可维护性高一个档次。3.3 平层与停靠逻辑的实现细节平层停靠是整个程序中时序要求最高的部分。六层电梯的平层感应器通常安装在井道每层楼的平层位置轿厢上的感应铁板随轿厢运动感应到对应平层开关时PLC知道轿厢正在这一层。程序里的停靠判断逻辑可以简化成一句话当电梯进入某个楼层并且该楼层的呼叫列表中有需要响应的呼叫同时电梯当前运行方向与该呼叫方向匹配就执行“减速-平层-开门”的流程。在PLC程序里我习惯用两个标志位来锁定楼层一个是“进入楼层标志”一个是“楼层有效标志”。运行过程中读到的平层感应信号先进入“进入楼层标志”并且楼层号要连续判断如果前一帧没感应到3层这一帧感应到了说明电梯刚进入3层平层区如果前一帧还在3层这一帧也在3层说明电梯停在3层或者正在缓慢通过。这两种状态要区分开否则电梯可能在某个楼层反复触发开门。实际调试中我遇到过一个问题电梯在低速爬行经过楼层平层区时平层信号抖动了两次导致程序以为电梯进了两层楼楼层显示乱跳。后来我的解决方案是加一个“信号稳定延时”平层信号持续50毫秒以上才认定为有效同时增加“同层多次触发只算一次”的防抖逻辑效果立竿见影。3.4 开关门控制与安全互锁开关门控制看起来简单做起来细节不少。我设置的核心参数有这几个开门时间默认6秒可通过轿厢内开门按钮延长到8秒。关门时间默认3秒若关门过程中有物体挡住门门区光幕/安全触板信号立即重新开门。关门超时保护如果连续关门超过15秒仍未收到关门到位信号程序判定关门异常停止关门动作并输出故障代码提示。开门继电器吸合后延时2秒才允许启动主接触器和运行接触器防止开门状态下带着门跑。安全互锁方面我的原则是“所有启动条件必须全部为真才允许输出运行”。关键条件包括关门到位信号为真、门锁回路闭合通过反馈点检测、超载信号为假、检修模式关闭、无任何故障。这里尤其要注意门锁回路的接线逻辑我建议门锁回路的反馈信号既有常开点也有常闭点同时进PLC程序里判断这两个点是否“逻辑一致”如果不一致就判定为门锁触点粘连故障停梯报警。这个做法能防住很多门锁触点老化导致的隐性故障。4. 自由串口扩展让电梯数据开口说话4.1 什么是西门子1200的自由串口通信说到“西门子1200之自由串口”这可能是不少朋友觉得最陌生的一块。通俗讲S7-1200的串口通信模块CM1241 RS232/RS485除了支持Modbus RTU这种标准协议之外还可以配置成一种叫“自由口”的模式——在这个模式下通信协议完全由用户自己定义报文的长度、帧头帧尾、校验方式、数据内容全部写在自己程序里。因为协议不受限所以叫“自由”。这个功能的典型用途包括对接第三方电梯状态显示器、LED楼层显示屏、轿厢内信息屏、后台监控主机、或者外接到物业的串口服务器。很多显示终端不支持标准的Modbus协议只支持厂家自定义的简单串口协议这时候自由口就派上用场了。在TIA Portal中S7-1200自由口通信的配置路线是在设备组态里给CM1241模块选择“Freeport”协议也就是自由口然后在程序里调用“R”接收指令和“S”发送指令对应的功能块在博途的帮助里搜RCV和XMT即可找到。接收和发送都是异步执行的也就是说程序每扫描一次只会去查询一次接收缓冲区里有没有数据、发送缓冲区是否空闲实际数据搬运是靠模块后台完成的。4.2 自由串口报文设计实战我实际做过一个轿厢内LED显示屏的对接项目要求PLC把梯号、当前楼层、运行方向和开关门状态发给屏幕。我设计的报文格式是这样的帧头2字节AA 55 数据区6字节字节梯号、楼层号、方向0停止1上行2下行、开关门状态0关门1开门、预留字节、预留字节 校验1字节所有数据区字节累加取低8位 帧尾2字节0D 0A发送周期我设为500毫秒屏幕每收到一帧有效报文就刷新一次显示。这个方案在自由口下实现非常简单PLC里建一个发送缓冲区把上述字节填充好然后调用发送指令把整个缓冲区扔出去。接收方向的设计同理比如后台电脑可以发送命令让电梯切换检修模式、锁定某个楼层或者请求当前状态。在自由口接收程序里我推荐做三层过滤第一层判断帧头是否匹配第二层判断数据长度是否在预期范围内第三层做累加和校验校验不过就丢弃整帧不做任何动作。这三层过滤做好之后通信的稳定性会非常好几乎不会出现误触发。4.3 自由串口实战中的几个坑自由口通信最常踩的坑有三个第一个坑是“接线没有共地”。RS485是差分信号理论上不依赖于地线但如果两个设备之间没有公共地信号漂移会非常明显尤其是在电机启动、变频器运行的时候通信错误率飙升。我的建议是RS485的A/B两根线要双绞屏蔽层单端接地尽量从柜内干净接地点引地线到通信设备的地端。第二个坑是“波特率不匹配”。PLC侧和终端设备侧的波特率、数据位、校验位、停止位必须完全一致否则对端收到的是乱码。常规我用9600波特率、8位数据位、无校验、1位停止位这个组合兼容性最好。第三个坑是“发送和接收不能同时写入缓冲区”。自由口模块是半双工还是全双工取决于模块型号RS485基本都是半双工RS232也常配成半双工使用。程序里必须加一个“发送忙”标志前一次发送指令还没执行完时不能再次触发发送否则数据会相互覆盖帧直接损坏。我在程序里用一个独立的“发送标志位”来锁存发送指令的完成位DONE为真时复位该标志位这样就能稳定地按周期发送数据。5. 调试与故障排查实录5.1 平层信号抖动的排查现场调试时最让我头疼的一个问题就是平层信号抖动导致楼层错乱。电梯在低速运行时经过每层楼的平层感应开关信号理论上应该是一干净利落的“上升沿-保持-下降沿”但由于安装间隙、感应铁板距离波动、变频器谐波干扰等原因实际信号往往是“毛刺”的。我排查时用的方法很简单在博途在线监控里把该平层信号的数据类型改成时间戳型变量然后让电梯以检修速度全程跑一遍记下信号的每次跳变时间点。对比后发现正常信号持续时间大约120毫秒而毛刺信号只有10到20毫秒。于是我在程序里加了一个延时判断信号必须持续30毫秒以上才被认定为有效平层信号。这个办法直接解决了90%的抖动问题。另外因为平层信号板装在井道内如果桥架上还有变频器动力线两者靠得太近的话感应开关的感应电压会受到耦合干扰。我的做法是平层信号线用屏蔽线屏蔽层在PLC侧单端接地并且尽量远离变频器输出线。5.2 双梯通信中断导致群控失效二部或三部电梯群控调试时通信中断是高频故障。我遇到过一次很典型的情况1号和2号梯的通信模块都正常唯独2号梯收不到1号梯的心跳包但1号梯能正常收到2号梯的包。排查下来发现是因为1号梯所在的控制柜和2号梯的通信模块共用一个隔离电源而1号梯的抱闸接触器动作时电源电压会产生一个比较大的跌落脉冲导致1号梯的通信模块瞬间重启。解决方法是把通信模块的供电独立出来加了一个DC-DC隔离电源模块问题就消失了。这个案例给我的教训是调试群控通信时不要只盯通信参数要关注电源质量和接地。通信模块对电源的敏感程度远高于普通PLC模块供电不稳的情况下通信异常是必然的。5.3 常见问题速查表我把调试过程中最常见的几类问题整理成一个速查表方便参考现象可能原因排查方向电梯能运行但楼层显示乱跳平层信号抖动、编码器信号接线松动检查平层信号防抖逻辑、接线压接外呼登记了但电梯不响应外呼分配逻辑错误、群控通信中断检查群控分配结果、通信心跳状态门开了关不上关门限位接触不良、光幕被遮挡查关门到位信号回路、检查门区光幕运行中突然急停门锁回路反馈丢失、超载误动作查门锁反馈点、超载开关调整自由串口收不到数据接线共地不良、波特率不一致检查RS485接线、核对通信参数双梯/三梯互相抢呼调度策略优先级没设好检查群控分配结果、分配标志位是否互斥5.4 运行试验的几个安全习惯调试电梯程序时我养成了几个固定习惯在这里重点强调一下。第一程序下载和修改之后先做全面的离线仿真再上电联调。西门子博途支持PLCSIM仿真虽然S7-1200的仿真不支持全部通信模块但主逻辑的仿真完全能做。第二联调时把检修速度设置为额定速度的30%到50%并且在井道和轿厢内安排专人看护。急停按钮的位置要在现场提前交底确保任何情况下人都能第一时间按停。第三每一次修改程序都要在程序注释里写明修改时间、修改人和修改内容。电梯程序属于特种设备相关的控制程序版本管理非常重要后期维护时没有版本记录的代码几乎没法接手。最后再分享一个我实际用下来很舒服的小技巧在S7-1200的自由口通信里发送和接收缓冲区的长度不要定得刚刚好多留几个字节的余量这样以后扩展协议内容时不用改硬件也不用改通信配置只需要在程序里调整数据区的填充内容就行。我第一版把缓冲区定义为16字节后来加了一个“运行模式”字段直接把原来的预留字节改一下含义前后不到十分钟就改完了兼容性一点没受影响。这种“预留扩展”的思路做电梯程序这种维护性要求高的项目真的很值得养成。
