1. 项目整体设计与思路拆解
1.1 为什么选博途V15.1和S7-1200系列
做电梯控制这个领域的老工程师都知道，TIA Portal版本迭代快得让人头疼，从V13一路到现在的V21，每个版本都有各自的脾气。但如果你让我推荐一个最稳妥、最适合做中小型PLC项目参考设计的版本，我仍然会首选博途V15.1。V15.1不像V13/V14那样对Win10系统兼容性差，也不像V16之后的版本那样动辄占用十几个G内存、打开项目卡半天。V15.1在功能完整度、系统资源占用、硬件支持范围之间找到了一个很舒服的平衡点。
再来看硬件选型。S7-1200系列是西门子中小型PLC的主力产品，特别是1214C和1215C这两款CPU，在处理六部十层电梯这种规模的控制任务时，资源完全够用。一台电梯的逻辑控制量大概需要多少资源？我大致估算过：十层楼的厅外召唤信号最多19个（一楼只有上行、顶楼只有下行，中间楼层上下各一个），轿内楼层按钮10个，再加上开关门、平层、门区、安全回路、检修、消防等辅助信号，单梯的数字量输入点大约在40点左右，数字量输出点大约在20点左右。六个梯加起来需要240点DI、120点DO。1215C本体自带14点DI和10点DO，剩下的通过扩展SM1221/SM1222模块就能解决，成本可控，逻辑清晰。
1.2 六部十层电梯的参考程序定位
标题里最关键的是“参考程序设计方案”这七个字。很多人拿到一个程序就急着往下翻，想找到现成的梯形图直接抄，这不叫参考方案，这叫闭眼复制。真正的参考程序设计，应该是把六部十层电梯的控制逻辑抽象成一套可复用的框架：厅外召唤如何分配到具体电梯、顺向截梯怎么判断、反向截梯怎么处理、平层消除内选、端站校正楼层计数、多梯联动时的调度策略——这些核心算法搞清楚了，你换成八部十五层、五部八层，改的只是数据范围，逻辑框架完全不用动。
这个方案面向的读者，我是这样设想的：第一类是刚入行两三年、接触过博途基础操作但没完整做过电梯项目的电气工程师；第二类是在设备厂工作、需要快速搭建电梯控制样机的调试工程师；第三类是职业院校里教PLC课程的老师，可以把这套框架用在自己的教学项目中。
1.3 控制逻辑的架构拆解
六部十层和单梯十层最大的区别在于“群控”。单梯只要管自己，六梯就得管分配。厅外的上行/下行召唤信号来了之后，系统需要判断哪部电梯去响应最合理。我采用的是分区调度+最小等待时间结合的方案：六部电梯分成三组，每组两部，分别负责低层区（一层到四层）、中层区（五层到七层）、高层区（八层到十层），层区之间有交叉重叠，高峰时段可以跨区支援。这样既避免了所有电梯都涌向同一个召唤点的问题，又不会像单双层分配那样僵化——单双层在上下班高峰期经常出现某部电梯被叫到顶楼、另一部在底楼闲着的尴尬局面。
整个参考程序的PLC架构分四层：第一层是信号采集层，处理所有数字量输入和模拟量输入；第二层是运行状态层，用状态机管理每部电梯的当前状态；第三层是调度分配层，接收厅外召唤信号并分配给各梯；第四层是执行输出层，控制接触器、变频器、门机等设备。这四层在程序中解耦清晰，调试的时候可以逐层排查，不会出现牵一发动全身的情况。
2. 核心细节解析与实操要点
2.1 楼层检测和平层逻辑的设计
十层电梯的楼层检测，业界主流有两种方式：一种是纯平层开关+楼层计数，井道里每层装一个平层隔磁板，轿厢经过时平层开关动作一次，PLC计数增减；另一种是旋转编码器+绝对位置校正，编码器实时计算轿厢位置，平层开关只做减速点和停靠点的校正。
既然是参考程序，我推荐用第二种方案，原因很简单：第一种方案在平层开关间距不均匀的时候，计数的可靠性完全取决于安装精度，而旋转编码器方案抗干扰能力强得多。具体做法是：在曳引机轴端安装增量式编码器，PLC用高速计数器通道采集脉冲。电梯从首层出发时，计数器清零，每上升一层累加的脉冲数通过井道高度除以层间距计算得出。由于钢丝绳打滑、机械误差的存在，编码器计算的位置会漂移，所以必须用平层开关做硬校正——轿厢到达某层平层区时，以平层开关信号为准，把当前楼层值直接写入数据块。
这里有一个细节很多人第一次做会踩坑：编码器脉冲方向。电梯上行和下行时脉冲计数的方向相反，如果只用加法计数，下行时脉冲数会越减越乱。我的做法是在OB100初始化时将高速计数器设置为双向计数模式，通过方向信号确定加/减。SCL伪代码如下：
// 楼层计数校正逻辑（SCL） IF "HSC_Status".Direction = TRUE THEN #CurrentPulse := #CurrentPulse + 1; // 上行累加 ELSE #CurrentPulse := #CurrentPulse - 1; // 下行累减 END_IF; // 平层校正：当平层开关动作时，用当前楼层覆盖计算值 IF "IO_Inputs".LevelSwitch = TRUE THEN #CurrentFloor := #CalculatedFloor; #CurrentPulse := #FloorPulseBase[#CalculatedFloor]; END_IF;2.2 电梯运行状态机的组织方式
六部电梯每部都有七个基本状态：空闲、运行、减速、平层停靠、开门、关门、故障。参考程序中，我建议为每部电梯创建一个独立的FB（函数块），FB内部用CASE语句实现状态机跳转。这里要强调一个原则：状态机只做状态切换的判断，不直接执行输出。输出动作应该由状态本身去驱动，这样逻辑才清晰。
CASE #State OF 0: // 空闲状态 IF #CallUp OR #CallDown OR #CallCar THEN #State := 1; // 进入运行状态 END_IF; 1: // 运行状态 // 顺向截梯判断逻辑 IF #TargetFloor = #CurrentFloor THEN #State := 2; // 进入减速状态 END_IF; 2: // 减速状态 IF #LevelSwitch = TRUE THEN #State := 3; // 平层停靠 END_IF; 3: // 平层停靠 #Brake := TRUE; #State := 4; // 开门状态 4: // 开门状态 #DoorOpenCmd := TRUE; #OpenTimer(IN := TRUE, PT := T#5S); IF #OpenTimer.Q THEN #State := 5; // 关门状态 END_IF; 5: // 关门状态 // 检测门锁信号 IF #DoorLock = TRUE THEN #State := 0; // 回到空闲状态 END_IF; 6: // 故障状态 // 故障处理逻辑 END_CASE;2.3 安全回路与信号采集
电梯行业的安全标准非常严格，作为参考程序，安全逻辑绝对不能做成“意思一下”的摆设。急停按钮、限速器开关、安全钳开关、上下极限开关、断绳保护开关，这些信号必须串联接入安全继电器回路，安全继电器的常开触点再进入PLC的数字量输入。PLC程序里只负责监视安全回路状态并做出相应处理，绝对不能替代硬件安全回路。这个边界必须清晰，调试时也要提醒甲方：PLC程序只是软件层面，真正的安全保护靠硬件。
厅外召唤信号的处理也是关键。每个厅外召唤按钮按下后，信号需要保持，直到被响应并完成停靠后才能消除。如果是顺向截梯，电梯到达该层并开门后，对应的厅外召唤才清零；如果是反向截梯，需要等到电梯完成转向后再次到达该层才能清除。这个逻辑做不好，就会出现“电梯明明停过了，厅外按钮还亮着”的尴尬情况。
3. 实操过程与核心环节实现
3.1 在博途V15.1中创建项目和硬件组态
新建项目后，第一步是添加CPU。我以1215C DC/DC/DC为例，在设备视图中拖入CPU 1215C，然后根据实际硬件配置添加信号板SB1232（模拟量输出，用于变频器速度给定）和通信模块CM1241（RS485，用于和变频器Modbus通信——但现在主流变频器都支持PROFINET，建议直接用PROFINET组态更省事）。
组态时有两个小细节容易被忽略：
第一，时钟存储器字节务必开启。在CPU属性->系统和时钟存储器中勾选“启用时钟存储器字节”，默认是MB100。这个字节的各个位会输出固定频率的脉冲信号（0.5Hz、1Hz、2Hz等），门机闪烁指示灯、检修蜂鸣器都可以直接引用，省去自己写定时器的麻烦。
第二，高速计数器的组态。在CPU属性中启用HSC1作为编码器计数输入，输入类型选择“计数”，计数模式选择“双向”，参考电压根据编码器型号选择24V或5V。把方向信号也配置好——通常编码器的A/B相分别接两个输入点，通过比较A/B相相位差判断方向。硬件组态完成后，需要在PLC变量的系统常量中找到HSC1的地址（通常是ID1000），供程序中使用。
3.2 标签表和UDT数据结构的建立
六部十层的标签量很大，如果不建UDT（用户自定义数据类型），编程时会疯掉。我建了一个名为“Elevator_Data”的UDT，包含以下主要字段：
- 状态字（State_Word）：当前状态机状态
- 命令字（Cmd_Word）：启动、停止、检修、消防等命令
- 故障字（Fault_Word）：各个故障标志位
- 当前楼层（Current_Floor）
- 目标楼层（Target_Floor）
- 上下行指示（Direction_Up/Down）
- 各层内选呼叫（Call_Car_Array: Array[1..10] of Bool）
- 各层厅外上行召唤（Call_Up_Array: Array[1..9] of Bool）
- 各层厅外下行召唤（Call_Down_Array: Array[2..10] of Bool）
- 平层状态（Level_Status）
- 开关门状态（Door_Status）
- 运行速度给定值（Speed_Setpoint: Real）
创建UDT后，在全局DB中建立一个数组：Elevators: Array[1..6] of “Elevator_Data”。这样每一部电梯的数据都集中在一个DB里管理，监控调试时打开DB就能看到全部信息，非常直观。有人问为什么不用多重背景DB，我的经验是：对于参考程序，用全局DB+数组更直观，不同水平的人接手都能快速看懂，多重背景DB适合程序封装性要求更高的大型项目，调试反而不方便。
3.3 主程序OB1和循环中断的组织
OB1里调用三个主要FB：FB_IO_Scan（IO扫描与滤波）、FB_Elevator_Ctrl（六部电梯的实例调用）、FB_Dispatch_Alloc（厅外召唤分配）。OB100初始化里做数据初始化：各楼层平层脉冲基准值写入DB、所有召唤信号清零、电梯复位到首层。
这里说一个实操建议：不要把所有的厅外召唤分配逻辑都写在OB1里。我在设计参考程序时，把分配逻辑放在一个单独的FB_Dispatch_Alloc中，每50ms执行一次（通过OB32循环中断触发）。为什么不用OB1连续扫描？因为分配逻辑需要“稳定”的信号状态，连续扫描时信号抖动的瞬间可能导致重复分配——某层召唤被分配给两台电梯，造成两台电梯同时去响应。循环中断强制执行间隔，相当于加了时间滤波，稳定性好很多。
FB_Elevator_Ctrl内部采用多实例调用方式，每个电梯实例共享同一套控制逻辑，但背景数据相互独立。这里用FOR循环遍历六部电梯，每一轮的当前电梯索引作为数组下标，就能复用一套逻辑处理六台电梯。SCL伪代码如下：
FOR #i := 1 TO 6 DO #ElevatorData := "Elevators"[#i]; // 调用电梯控制FB #EleCtrl_Instance( Data := #ElevatorData, IO_In := #IO_In_Array[#i], IO_Out := #IO_Out_Array[#i] ); END_FOR;3.4 厅外召唤的分配逻辑实现
这是整个参考程序最核心的算法。当某层厅外上行召唤信号为TRUE时，系统需要从六部电梯中选一部去响应。我采用“投票打分”机制：每部电梯根据当前状态和位置计算一个分值，得分最高（或最低，根据定义）的电梯获得该召唤。
评分维度包括：电梯当前楼层与召唤楼层的距离、电梯当前运行方向是否与召唤方向一致、电梯当前是否处于故障/检修状态、电梯当前是否已有大量内选任务。距离越近加分越多、方向一致加分更多、故障检修状态直接排除。如果有两部电梯得分相同，则优先选择上一次分配次数最少的电梯，实现负载均衡。
这个打分算法用SCL写起来很简单，但需要反复推演的边界情况很多。我实测中发现最容易出错的是“空闲电梯”的处理：如果一部电梯完全空闲，它的得分是否应该比正在下行但顺路的上行电梯高？我的做法是：空闲电梯加一个较大的基础分，但如果上行电梯能在同一方向截梯，额外加分超过空闲基础分，这样效果更好。这个系数需要在现场实际调整，参考程序中我把它做成一个可调参数放在DB里，方便调试时在线修改。
4. 常见问题与排查技巧实录
4.1 博途V15.1在Win10/Win11下老是需要重启
这个问题我遇到得太多了，群里有同行新装了V15.1，打开软件后提示“需要重启计算机”，重启完还是提示，能把人逼疯。排查顺序是这样的：先看杀毒软件，西门子的License服务（Automation License Manager Service）会在启动时检查授权文件，杀毒软件拦截授权服务，就会导致异常。解决办法是把整个安装目录、授权目录加入杀毒软件白名单，然后重启服务。如果还不行，大概率是Windows Installer缓存问题，用“msiexec /unregister”和“msiexec /register”重新注册Windows Installer服务，再重启。
还有一种情况是V15.1和Office插件冲突，特别是Visio和Project的许可证服务，会抢占西门子授权服务端口。如果你电脑装了这两个软件，建议把Visio的许可证服务设为手动启动，实测能解决大部分“需要重启”的奇怪问题。
4.2 博途卸载重装时注册表残留问题
很多项目上需要把V15.1升级到V16或者V18，卸载不干净是重装失败的第一大原因。V15.1卸载后，注册表里至少残留几十个相关项，手动清理不现实。我的经验是分三步：先用控制面板正常卸载，然后下载西门子官方的Uninstall Tool（在Support网站可以找到，不需要账号），它会扫描所有西门子软件并强制清理。最后打开注册表编辑器，搜索“Siemens Automation”和“TIA Portal”两个关键字，删除残留项——注意只删和西门子相关的，别手滑删了其他软件的项。这个办法我用了很多次，重装成功率接近百分百。
4.3 博途密钥过期怎么办
打开项目提示“许可证密钥缺失或过期”是最常见的授权问题。先打开Automation License Manager（开始菜单里搜索），检查STEP 7 Professional和WinCC的许可证状态。如果显示过期，需要重新下载对应版本的许可证密钥（Sim_EKB的授权方式在工程圈里很普及，但正规渠道还是联系西门子销售申请试用授权）。有一个细节要注意：V15.1的许可证和V16不通用，如果电脑上装过多个版本，最好把旧版本的授权文件全部删除，只保留当前版本对应的，否则License Manager会混乱。
4.4 触摸屏字符串显示旧值的问题
标题热搜词里有一条“博途字符串里面的值已经为0但是触摸屏为什么还是显示原来的字符”，这个问题我详细说一下。在WinCC Comfort面板中，字符串变量的显示和普通整数/实数变量的机制不同：字符串类型在HMI中默认带有缓冲区，如果PLC端把字符串清空了，但HMI的画面帧没有主动刷新该区域，就会一直保留旧内容。解决办法有三个：一是在HMI变量属性中，把字符串变量的“采集周期”从默认的1s改为100ms，刷新频率越高越不容易缓存；二是做两个字符串变量，一个作为数据源一个作为显示缓存，PLC写入新值后先写显示缓存，清空数据源时把显示缓存也同步清空；三是如果字符串只是在报警/日志界面显示，检查该画面组件的“刷新周期”是否设置为“永久”。实测中最有效的是第二种，从逻辑上杜绝了缓存不一致的问题。
4.5 SCL中TON定时器怎么用
用SCL写TON定时器，很多人第一次会报错，因为SCL中定时器需要先声明一个TON的实例。正确写法如下：
// TON使用示例 #Open_Timer_Instance(IN := #DoorOpenCmd, // 输入条件 PT := T#5S, // 定时5秒 Q => #DoorOpenDone, // 输出 ET => #OpenTimeElapsed); // 已计时时间重点是：定时器实例必须在FB接口区或DB中声明，不能直接在OB1的临时变量区声明。因为TON需要保持状态，临时变量区每次循环后会被覆盖。常见的报错“OB的临时区不能用于存储定时器实例”就是这个原因。我在参考程序中所有定时器都在FB的Static区声明。
4.6 V16/V18有授权打不开项目的问题
最近有同行装的是V18，下载了参考程序，结果打不开——版本不兼容。TIA Portal的工程文件版本是向下不向上兼容的：V15.1的项目可以用V16/V18打开（V17以后的版本支持直接打开低版本项目，会弹出升级提示），但V18的项目V15.1打不开。如果你用的是V15.1，需要眼尖一点，下载项目前确认对方保存时是什么版本。另外，升级项目时会有个选择，是否保留原有项目版本（Multi-User模式可以在服务器上保留多版本），我建议不要盲目升级，参考程序一般是框架性的，直接在低版本里重建工程量也不大。
5. 六部十层调度策略与消防联动设计
5.1 多梯群控的分区策略
前面提到我把六部电梯分成三个区，很多同行拿到参考程序后，第一反应通常是“分区分组是不是固定的”？我给的这套参考方案做了个灵活的配置区：程序启动时读取一个配置DB（或HMI上的设置页面），可以自由选择“统一调度模式”“分区调度模式”“单双层调度模式”。不同使用场景下切换方便——写字楼早高峰适合分区，商场全天候适合统一调度，住宅小区错峰时段适合单双层。
分区分组时最需要考虑的是“跨区支援”条件：当A区两部电梯都忙碌、B区有一部空闲时，A区的召唤应该被B区电梯响应。这个功能实现起来不复杂，只需在分配打分算法中增加一个“跨区使能”标志，当某区电梯占据率超过80%时，自动把该区的召唤信号开放给相邻区域。我这里说的占据率不是真正的百分比，而是已分配任务数和内选数的加权和。这个加权值可以根据项目现场情况调整，参考程序里我初始设为“内选+外呼分配总数超过6时触发跨区支援”。
5.2 并行内选和外呼的处理逻辑
十层楼的内选和外呼，最怕的是“顺向不拦、反向盲冲”的乱逻辑。参考程序中，内选和外呼被分成三类：顺向截梯（电梯运行方向上，前方楼层有召唤）、反向截梯（电梯运行方向反方向有召唤，电梯会在完成当前方向的所有顺向任务后再转向响应）、本层外呼（电梯停在某层，该层有召唤且方向一致，直接开门）。
顺向截梯是最优先的。电梯从第3层上行，第5层有上行召唤，第7层有内选。这时电梯应该在第5层停靠开门并消除外呼，再继续上行到第7层。反向截梯放在最后处理：电梯从3层上行去7层，第2层有上行召唤，电梯到7层后会改变方向，下行到2层响应召唤。这个“先同向再反向”的顺序必须通过程序强制，否则就会出现电梯被反向召唤“拽”得来回乱跑。
5.3 消防联动和基站返回
消防信号是整个电梯控制系统中优先级最高的外部信号。参考程序中，消防信号接入PLC的数字量输入点，一旦为TRUE，所有电梯立即进入消防模式：正在运行的电梯不在当前层停靠，而是直接返回基站层（通常是一层）开门并停梯，途中忽略一切内选和外呼。电梯在消防模式下不允许自动响应任何召唤，只允许消防员通过轿内的专用开关（消防员钥匙）手动控制。
这个逻辑难在“立即返回”的路径规划：如果电梯正在上行去7层，消防信号来时电梯在第4层，程序应该让电梯在最近顺向可停层停靠后换向，还是直接继续上行到顶层再返回？按照国内规范的要求，消防返回时电梯应保持当前运行方向运行到最近层站停靠，然后换向下行回到基站。参考程序中我严格按这个规范实现，安全第一。
5.4 防捣乱与满载直驶功能
满载直驶是防止资源浪费的关键。轿厢内加装称重装置或超载开关，当载重达到额定载重的90%以上（参数可调）时，电梯自动取消所有顺向外呼响应，只保存已登记的内选。这样做有两个好处：一是减少了高峰期电梯频繁停靠的浪费，二是保护曳引机和制动器避免频繁启停。慢速满载/超载报警信号在参考程序中分别用两个DI点采集，程序里做了20ms的滤波去抖，避免瞬时波动导致误判。
防捣乱功能是针对恶意多次按键的：当电梯在某个方向运行时，如果某个内选层站被登记后超过三次重复选择（比如乘客反复按某个楼层按钮又取消），系统自动屏蔽重复内选，避免电梯被无效指令拖累。这个防捣乱逻辑很多商业电梯系统有，但参考程序中做到这个深度的不多。取值阈值我放在了DB中可调整，现场根据实际客流情况微调。
5.5 数据统计与监控接口扩展
六部十层的参考程序不需要像商业系统那样做复杂的后台管理，但预留一份数据监控接口非常有必要。我在程序里把每部电梯的运行次数、开门次数、故障次数、累计运行时间做成统计字段，通过PROFINET通信或Modbus TCP接口开放给上位机或云平台。你可以直接接个组态软件或者用简单的MQTT网关把这些数据推送到云端，做电梯健康度分析。
实际项目里，这个接口帮过我大忙——某项目甲方反馈5号梯老是无故停梯，但现场又没有报警记录，我通过历史数据看到5号梯“无故障运行次数”和实际运行记录不匹配，进一步排查发现是抱闸微动开关间隙调整不到位，偶发信号抖动导致控制器误判。有了数据统计，这种偶发问题就好定位很多。
6. 实操心得与调试建议
项目做完电气设计、程序写好，真正的战场在调试。六部十层的电梯调试，我一般会按这个顺序做：先单梯调试再群控联调，先慢车调试再快车调试，先手动运行再自动运行。
单梯调试时，重点验证楼层计数是否准确：电梯从首层开始慢车向上，每经过一个平层开关，监控DB里的当前楼层值是否递增。如果递增异常，优先检查编码器脉冲方向和平层开关信号是否抖动。这一步做好了，后面快车运行基本不会出大问题。
信号测试用强制表最快。在博途的监控表中，把每部电梯的厅外召唤、内选、平层、门锁信号一一强制置位，观察控制器的响应是否正确。重点测试以下场景：同方向召唤穿越响应、最远端反向召唤、本层外呼开门、超时关门保护（关门过程中门锁信号长时间不反馈，程序应自动开门重新关门，防止夹人事故）。
群控联调是整个项目最耗时也最容易出问题的地方。六部电梯同时运行时，大厅外呼的分配是否合理、会不会两部电梯同时响应同一个召唤、会不会出现“楼道空车跑”的现象（某电梯被分配去响应召唤，但到之前又被更近的电梯抢先了），这些都要反复试验。我的经验是准备一个20分钟的脚本：模拟上班高峰期（大量上行召唤集中在一层）、下班高峰期（大量下行召唤集中在顶层）、闲时（随机召唤）三种场景，每种场景跑两遍，记录每部电梯的响应时间和等待时间，对照评分算法参数调整。
最后想说的是，做电梯控制参考程序，核心不是把代码写对，更重要的是把边界情况想清楚。比如“电梯正在开门时被分配了新的厅外召唤”，按我的设计要等门完全关闭后才能执行新的任务；“电梯检修模式下所有召唤无效”但消防信号仍然有效，这些优先级和互锁关系看着不起眼，调试时都能让人头疼半天。
我在博途V15.1下用S7-1200写这套六部十层参考程序，前后打磨了大约一个多月，中间改过的版本不下十稿。现在拿出来重新整理这套设计方案，不是为了给一套能直接跑的程序——每个项目的井道尺寸、楼层高度、变频器型号都不一样，照抄没有意义。有价值的是一整套可复用的设计思路：状态机怎么划、数据结构怎么建、算法参数怎么调、故障怎么排查。你拿着这套思路去做五部八层、八部十二层，无非是数组维度改一下，参数重新标定一遍，核心逻辑完全不用动。这就是参考程序设计的意义所在。
