前阵子一个做电梯改造的朋友问我博途V15.1环境下用1200系列做六部十层的电梯参考程序到底行不行、怎么下手这问题我太熟了这两年正好做过几个类似规模的项目。很多人一听“六部十层”先想到1500其实1200只要资源算得清、程序结构合理完全吞得下而且成本能省一截。这篇就把我推进一个六部十层项目时整理的参考设计方案摊开讲机型怎么选、I/O点数怎么估、单梯和群控怎么分工、电梯核心逻辑怎么写以及V15.1在实战中那几个绕不开的坑。1. 六部十层到底需要多大资源I/O点数与硬件选型先别急着写程序第一步是搞清楚“六部十层”这个控制对象的真实规模。六部电梯、十层楼每层有厅外召唤每部电梯有轿内召唤、平层信号、开关门机构、安全回路。这些信号先盘一遍才知道1200该选哪款CPU、要不要扩展模块、通讯怎么组。1.1 每部电梯的I/O点数逐项估算这里按常规集选控制加群控来估算每部电梯独立控制。有一点必须说清楚我习惯把安全回路和门锁回路做成硬线安全链只把安全链状态通/断这一个点给PLC不在PLC里做安全逻辑。这么做不是偷懒而是安全回路涉及安全钳、限速器、断绳开关、上下极限等硬器件用硬线串联闭锁比PLC内部连锁更可靠也符合电梯行业的常规做法。每部电梯的数字量输入DI大致如下内呼按钮十层共10点平层/门区信号确认是否在平层区用于停车和开门判断预留2点楼层编码或换速信号如果用井道开关配合旋转编码器做楼层计数预留4点开关门限位开门到位、关门到位各1点共2点安全链返回1点门锁回路返回1点超载、满载信号2点司机、直驶、消防等操作信号预留4点检修、急停2点这样合计大约28点DI。数字量输出DO相对少一些上行方向、下行方向各1点开门、关门继电器各1点抱闸控制1点到站钟、风扇、照明等辅助输出约3点合计约8点DO。按这个量级估算单部电梯大约需要28点DI和8点DO。S7-1200系列里CPU 1214C DC/DC/DC自带14点DI、10点DO单机差得远必须扩展。常规做法是加一块SM 1223数字量混合模块16点DI加16点DO这样单台CPU最多有30点DI、26点DO余量足够而且后续想加司机信号、到站钟都不怕没点。六部电梯如果每部独立一台PLC就是6台CPU 1214C加6块SM 1223。有人可能会问为什么不直接上一台1500带远程I/O成本账算下来六台1214C加扩展模块的单价相比一台带远程IO的1500方案要低不少更重要的是每部电梯独立控制单台故障只影响本梯不至于整组电梯瘫痪。对于电梯这种安全相关设备“独立性”本身就是一种可靠性的保障。这里再补充一个选型注意点CPU 1214C和1215C之间如果只是单梯控制1214C足够。1215C的优势在于本体带两个以太网口和更大的工作存储器但如果程序空间够用、通讯通过外部交换机扩展1214C完全能胜任。我见过有人不自觉得选了1215C最后资源闲置成本却上去了。记住选型别只看CPU要看“点数、程序空间、通讯连接数”三者是否匹配。1.2 六台PLC怎么组网每梯一机加以太网轮询这个规模的项目强烈推荐“每梯一机”而不是“一台CPU集中控六部梯”。原因很简单电梯调试常常要单机检修、单梯故障处理如果群控主机一重启所有电梯都失联现场维保人员会疯掉。六台1200通过工业交换机组成以太网用S7通讯交换群控数据。主从关系不用做得太重。我习惯指定1号梯做主调度负责接收厅外召唤并分配派梯结果其他梯把自身状态周期上传。主调度故障时各梯自动降级为单梯集选模式本层召唤自己响应保证乘客至少能坐某一部梯到达目标层而不是整个系统卡死。这里有一个反直觉的点很多人担心1200做群控“算不过来”实际上电梯群控的计算密集度非常低无非是几台电梯的召唤比对和派梯判断对CPU负担远小于模拟量运算或通信处理。如果程序跑得慢问题基本出在程序写得烂而不是CPU不够。1200的工作存储器对电梯程序来说也绰绰有余一个六部十层的单梯控制加群控通讯程序编译后大约50到80KB1214C有100KB工作存储器余量充足。2. 程序架构按“单梯逻辑”和“群控逻辑”分层的模块化设计程序结构是这类项目的命根子。博途里的程序规划我习惯一句话概括单梯逻辑做成一个多功能块FB群控逻辑做成一堆函数块FC和全局数据块DB。单梯逻辑和群控逻辑必须彻底分开这样单梯调试可以脱离群控独立完成群控出问题时改群控不用动电梯本体的逻辑。2.1 程序块清单与职责划分一个比较成熟的参考程序块规划大致如下表程序块类型职责OB1组织块主循环依次调用信号采集、逻辑处理、输出刷新OB100组织块启动初始化清召唤表、置检修模式、写默认参数OB35组织块固定周期中断100ms处理速度曲线与时间相关逻辑FB1_EleCtrlFB单梯核心控制块召唤登记、方向决策、开关门时序FC1_IOProcessFCI/O映射把硬件的DI/DO信号映射到符号数据区FC2_SafetyFC安全链与故障处理安全链断开、超载、检修模式等FC3_GroupCalcFC群控分配计算读取各梯状态、计算派梯结果FC4_ComS7FCS7通讯读写PUT/GET数据收发DB_GroupData全局DB群控共享数据区各梯状态、外呼列表、派梯结果DB_AlarmData全局DB故障报警与事件记录存储模块化编程的价值在维护阶段体现得淋漓尽致。举个例子现场发现关门到位信号抖动导致偶尔关门失败你只需要改FB1里的开关门时序或者改FC1里的输入滤波逻辑完全不用翻其他程序。反过来说如果几百个变量和几十个网络全堆在OB1里后期基本上谁都不敢动改一个点可能影响一片逻辑。模块化编程还有一个隐形好处方便团队分工。一个工程师写单梯逻辑另一个写群控逻辑只要提前约定好数据接口两边可以并行开发。等单梯调试完再把群控模块挂上去联调。这个工作流程放在动辄数月的电梯项目里能省下大量时间。2.2 数据区规划变量表、M区与全局DB的边界1200推荐用符号寻址。我的建议是硬件I/O单独建一张PLC变量表程序内部状态放在全局DB里M区只放临时标志位不做跨程序块的主要数据交换。这样数据位置清楚在线监控也比翻M区方便得多。群控数据区是重点。DB_GroupData里放一个结构体数组元素是“梯号索引”字段大致如下TYPE GroupStatus STRUCT ElevatorID : INT; // 梯号 CurrentFloor : INT; // 当前楼层 Direction : INT; // 0静止 1上行 -1下行 IsFault : BOOL; // 故障标志 IsFullLoad : BOOL; // 满载 InnerCall : ARRAY[1..10] OF BOOL; // 内呼登记 AssignedHall : ARRAY[1..10] OF INT; // 已分配的外呼层 ServedCall : ARRAY[1..10] OF BOOL; // 已响应的召唤标识 END_STRUCT END_TYPE这种结构的好处是无论用PUT/GET整体读写还是本地逻辑引用都很直观。另一个实践细节我给每台PLC单独建一个“本梯状态DB”比如DB_Ele1发送侧直接从本梯状态DB取数写入对方地址区域接收侧同样落在对方的DB_Ele1里各机之间的数据结构保持对齐即可。这样调试时拿在线监控看一个DB就能清楚本梯向外部广播了什么状态。3. 电梯单梯控制的核心逻辑从召唤登记到平层停车单梯逻辑是整台电梯的“脊梁”。群控算法再好最后都要落到单梯能不能把乘客送到、停得平、开得稳。这部分我挑几个关键点展开不会把整个程序贴出来但会把判断思路和容易出错的地方讲透。3.1 召唤登记、方向决策、顺路截梯召唤登记是电梯程序最基础的信息。内呼和外呼分别登记。内呼在轿厢操作盘上十层楼就是十个按钮外呼在每层厅外顶层只有下行、底层只有上行中间层通常有上行和下行两个按钮。判断一个召唤是否被响应核心是“方向加楼层加是否已分配”的组合。方向决策我参考了教科书里的集选控制逻辑但做了实用化调整。基本规则上行优先电梯当前方向为上行时只响应本层以上的内呼和外呼含当前层。下行同理只响应本层以下的方向一致的召唤。到最远目标点后转向上行过程中记录本次运行的最高目标层内呼和外呼的最高层到达后若上方无召唤且下方存在未响应的召唤则换向下行。顺路响应某一层的外呼如果方向与电梯当前运行方向一致且电梯尚未越过该层则插入响应队列。方向判断的SCL伪代码可以这样写// 电梯当前 direction: 1上行 -1下行 // hallCallDir: 某层外呼方向 1上行 -1下行 // hallCallFloor: 所在楼层 IF direction 1 THEN IF hallCallDir 1 AND hallCallFloor currentFloor THEN ADD_TO_RESPONSE_LIST(hallCallFloor); END_IF; ELSIF direction -1 THEN IF hallCallDir -1 AND hallCallFloor currentFloor THEN ADD_TO_RESPONSE_LIST(hallCallFloor); END_IF; END_IF;这里有一个容易踩的坑某一层只安装了一个召唤按钮顶层只有下行、底层只有上行。如果按“外呼方向与运行方向一致”来判断就必须用对应楼层“实际可用”的外呼方向来登记。否则程序会把底层“上行按钮”误登记成一个双向召唤导致某部电梯虽然停在底层却因为没有“下行召唤”而长期不响应。在实际工程里我对召唤列表用两层结构处理第一层是原始召唤登记按层号记录哪个方向被按了第二层是响应列表每台梯自己维护一个将要停靠的楼层集合。响应列表在运行中不断刷新到了某一层停靠开门后从响应列表里删掉该层。这样做的好处是无论内呼还是外呼最终都统一折算成“需要停靠的楼层”方向判断、顺路判断都围绕这个楼层集合展开逻辑非常干净。3.2 平层、减速、停车与开关门时序平层停车是电梯舒适性和精度的关键。常见做法是“井道平层开关加旋转编码器”双确认PLC通过编码器预判楼层位置和减速点到平层开关时做最终确认保证停车精度。程序里不要只依赖单个开关因为平层感应器受安装误差和机械抖动影响单点信号很容易造成重复停车或停车过冲。我用OB35的100ms中断做速度相关逻辑启动时给变频器方向信号和使能信号如果收到启动命令后2秒内没有速度反馈判为启动失败进故障接近减速点前给出换速信号让变频器进入减速段到平层区后门区开关确认到位再发停车和开门指令。这个“命令—反馈—确认”的链条是电梯程序里最值得花心思的部分。开关门时序也是电梯里最容易出问题的地方。常规顺序停车后确认零速先抱闸再开门具体按电梯厂家要求有的要求开门后松抱闸。开门继电器置位开门到位限位返回后切断开门输出。保持开门延时一般2到4秒SCL里用TON实现延时结束且无阻挡信号再给关门命令。关门到位限位返回后等待下一次运行指令。如果只是单纯“延时”就关门不检测光幕或安全触板关门夹人会是非常严重的事故。所以关门命令发出后如果光幕信号一直有效应延长开门时间或重新开门同时计数报警提示。这里正好说一下SCL里TON怎么用因为“博途scl中ton怎么用”这个话题被问得太高频了。在SCL里不能像LAD那样直接拖一个TON定时器块正确做法是先在FB的静态变量区或者全局DB里声明一个定时器实例比如VAR doorOpenTimer : TON_TIME; // 声明一个TON_TIME类型的定时器实例 doorOpenDone : BOOL; doorOpenValue : TIME; END_VAR然后在程序里直接调用这个实例doorOpenTimer(IN : doorIsOpen, PT : T#4S, Q doorOpenDone, ET doorOpenValue);调用时用括号传参输入是IN和PT输出是Q和ET。注意这里定时器实例不能放临时变量区因为每次扫描临时变量都会被重置定时器永远跑不起来。这个问题我见过不止一次现场查了半天最后发现就是实例放错位置了。4. 六部十层的群控分配派梯策略与故障降级单梯逻辑做好之后六部电梯怎么协同工作是这个项目真正的“区别点”。群控的本质是当一个厅外召唤到来决定把这单交给哪部电梯。群控策略太复杂反而难维护实践里我倾向于简单、稳定、可解释的规则。4.1 两套主流派梯策略对比常见的派梯策略有最小等待时间法和距离优先加顺路法。两者对比策略原理优点缺点适用场景最小等待时间法估算各梯到召唤层的预计时间楼层差×单层运行时间开关门加减速选最短高峰期客流分配均衡等待时间短需要标定运行时间参数计算稍复杂写字楼、酒店等客流集中场景距离优先加顺路法距离召唤层最近的梯优先运行方向顺路的优先实现简单、行为直观、调试容易客流集中时可能分配不均衡住宅小区、中小型楼宇六部十层如果是我做首选距离优先加顺路法再加上“满载直驶”“反向不响应”等限制。原因是参数少、现场好调业主也容易理解。派梯规则越直白出问题时越好排查。你想想如果现场投诉“等电梯时间太久”你至少能马上解释是哪部梯被派过去了、为什么派过去如果用的是复杂的模糊控制业主问起来你只能干瞪眼。具体分配逻辑可以这样写收到某层的外呼后遍历六部电梯。剔除故障、检修、满载满载时只响应内呼直驶不停的电梯。计算每部正常电梯到召唤层的楼层距离当前运行方向与召唤方向一致时距离等于召唤层与当前层的绝对差值方向相反时距离等于当前层到转向终点再加终点到召唤层的距离。选距离最小的电梯把这条外呼登记到该梯的AssignedHall列表。这个算法再简化一点也没问题。我做过一个项目只用了“召唤层和当前层绝对距离最小”加“满载排除”现场响应也完全够用。所以做群控不用贪心先把基础规则跑稳再根据实际客流逐步优化。4.2 外呼信号的接入方式集中式还是分布式六部十层的厅外召唤信号怎么接入是一个经常被想当然的问题。两种做法做法一集中式。每层厅外按钮只接一组信号线到机房柜由1号PLC的DI采集1号PLC算好派梯结果后把对应的“分配梯号”通过以太网分发到各梯PLC同时通过DO输出到各层的到站显示。优点是外呼线缆少、显示逻辑统一缺点是1号PLC故障时厅外召唤失灵所以必须保留“各梯本地检修、直驶”和“单梯集选”的降级能力。做法二分布式。每层厅外按钮的多组触点分别接到各梯PLC的DI每台PLC自己采集就近的外呼信号再通过群控数据区交换由各梯自行判断这层召唤是否由自己响应。优点是单台PLC故障不影响外呼采集缺点是接线量大、柜内跨线多现场施工容易接错。就十层六部这个规模我更推荐做法一但在柜内给每层外呼做一个小中间继电器切换当1号PLC在群控模式时外呼直接进入群控逻辑当1号PLC检修或故障时通过硬切换让各梯直接响应本层召唤。这样兼顾了集中管理的清晰性和降级的可靠性是我实测下来比较稳的结构。4.3 群控数据同步与故障降级几台1200之间的数据同步我用过PUT/GET和TSEND/TRCV两种方式。对于六部十层PUT/GET足够了编程简单不需要额外握手直接在OB1或OB35里周期性调用即可。TSEND/TRCV性能更高但程序复杂用在更大型的群控或运动控制场景更合适。轮询周期建议50到200ms。太短没必要电梯运行是秒级事件召唤信号实时性用不着毫秒级太长超过500ms会导致两台电梯同时看到同一召唤但派梯结果不一致出现“一梯已应、另一梯也去”的重复响应。我在现场习惯把群控数据交换周期设为100ms各梯状态刷新周期也是100ms实测下来召唤分配结果基本同步。故障降级必须提前设计。最简单的一句话规则群控正常时外呼由调度分配群控超时比如连续1秒收不到1号梯的群控心跳时每部电梯恢复“单梯集选模式”本层召唤自己响不再接收群控分配结果。心跳信号不用单独传放在每台PLC周期上送的状态字里就行检测方只要发现状态字不再刷新就判定失联。5. 博途V15.1在实战中的几个坑和对策说到V15.1这个版本稳定性确实一般。很多现场因为旧项目、旧授权和工程师的使用习惯仍然在用。热词里“portal v15.1老是需要重启”“博途安装删除注册表”“博途密钥过期怎么办”“博途v18有授权打不开”每一条背后都有真实故事。这块我按排查顺序讲方便你直接照着定位。5.1 “V15.1老是需要重启”的根因排查现象是打开V15.1加载项目或编译时突然提示“需要重新启动计算机”有时候重启完第一次能打开过一会儿又提示循环往复。我踩过的排查链路是这样的先排除杀毒软件和系统更新。TIA Portal安装和启动时会写系统服务、注册表项和临时目录杀毒软件拦截会触发重启提示Windows自动更新改变了某些系统组件状态也会导致这种情况。把杀毒软件对Siemens目录的实时监控排除掉暂停自动更新这是第一步。检查是否缺少.Net Framework 3.5。TIA Portal很多组件依赖它特别是WinCC和PLCSIM相关功能。控制面板里把“.NET Framework 3.5包括2.0和3.0”勾上装完再试。检查授权管理器状态。V15.1的许可证服务如果损坏软件会出现各种诡异行为包括反复要求重启。用Automation License Manager把现有授权删除后重新激活或者更新授权软件版本。最后才考虑卸载重装。如果以上都不行就卸载干净重装而且卸载必须连注册表残留一起清。第4步的“删除注册表”是很多人不敢做又必须做的。卸载完TIA Portal后清理这几个位置HKEY_LOCAL_MACHINE\SOFTWARE\Siemens、HKEY_CURRENT_USER\Software\Siemens、HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Siemens再手动删除系统盘下C:\Program Files (x86)\Siemens残留目录和%TEMP%里的Siemens临时文件。删之前一定备份注册表确认电脑里没有其他依赖Siemens组件的软件。注册表清理是最后手段不要一上来就动。5.2 授权打不开、密钥过期怎么处理“博途v18有授权打不开”“博途密钥过期怎么办”这类问题本质是授权文件和授权服务对不上。我遇到过的情况是重装系统或升级Windows后软件还在、授权没了或者几个人交替用同一台电脑有人把授权带走了回来就报密钥过期。常规处理路径打开Automation License Manager查看当前授权状态。如果显示“已过期”但实际授权是永久版多半是系统时间被改动或授权服务异常。校准系统时间重启Automation License Manager Service服务。如果是试用授权到期必须找正式授权文件不能用网上流传的“破解”手段既不稳定也可能触发西门子授权反查机制。授权文件导入后重新启动V15.1确认Software Update Manager里选“不自动更新”避免更新后授权失效。需要强调授权问题跟程序本身没关系不要为了赶进度用绕授权的方式现场调试到一半授权失效比什么都难受。5.3 项目版本升级与固件匹配V15.1的项目可以被V16及以上版本打开并自动升级但升级后的项目不能再用V15.1打开所以升级前必须备份原项目。还有一个限制项目跨大版本升级时PLC固件版本也要检查。S7-1200如果固件是4.xV15.1基本都支持如果项目里用了V15.1之后才有的指令库或功能低版本打开时会丢块或报错。我的经验做法是项目团队统一版本最好连Update补丁都统一。V15.1建议至少装到Update 3或Update 4很多莫名奇妙的编译错误、卡死、重启问题就是缺补丁导致的。如果项目要交给不同单位维护在项目说明文件里写清楚“博途V15.1 Update 4加1200固件4.4”避免后面的人踩版本坑。关于“给博途v21的软件添加mcp”这类需求本质上是向TIA Portal里添加附加组件或库。无论是Motion Control Panel还是其他选件安装前先确认软件版本与选件版本兼容。V15.1的程序升级到V21后运动控制类功能块可能需要重新选择驱动协议或重新组态不能指望“打开就全能用”。做这类六部十层项目最深的体会是程序架构永远比代码技巧重要。单梯逻辑和群控逻辑不分开后期改一个功能可能牵一发动全身V15.1的坑再多只要版本统一、补丁打齐、授权干净现场出问题的概率会降低一大半。最后分享一个小技巧调试群控时别急着上六部梯联调先把1号梯的群控功能禁用用2号梯做单梯加模拟群控数据测试数据通了再逐步加入其他梯。这样能避开很多网络配置和数据结构不一致的问题。希望这份参考方案能帮你少走点弯路。