企业官网建设流程全解析

简介：本资源为2021年西门子PLC技能竞赛官方赛题——“三部十层PLC程序”的完整工程文件包，面向工业自动化专业学生、PLC初学者及备赛技术人员，聚焦梯形图逻辑设计、S7-1500系统架构分层控制与TIA Portal工程实践能力提升。压缩包共130个文件，含11个XML项目配置、12个PNG界面截图、7个PDL人机交互页面、11个RPL运行日志及多个BAK/CFG/DB等核心工程备份与数据库文件，全面覆盖输入处理、十层逻辑运算、输出执行三大功能模块，体现典型电梯控制系统分层建模思路。资源大小63.54MB，结构完整、命名规范，可直接导入TIA Portal V15.1运行调试，附带工程配置说明与版本标识（如ap15_1、LT_21_07_21_10_27_30.bak），便于理解赛题实现路径与备份机制。已有2808人学习下载，是掌握西门子PLC模块化编程、工程管理及多层逻辑优化的优质实操范例。

1. 项目背景与核心价值

最近在整理硬盘时，翻到了一个尘封已久的项目文件夹，名字就叫“2021年西门子PLC比赛三部十层PLC程序”。点开一看，里面是当年参加一个行业技能竞赛时，针对一个模拟“三部十层电梯群控系统”编写的全套西门子S7-1200 PLC程序。这个项目虽然过去几年了，但里面涉及的编程思路、结构化设计、故障处理逻辑，尤其是多PLC之间的协同与通信，到现在看依然非常经典和实用。很多刚接触中大型项目或者对西门子PLC结构化编程感到困惑的朋友，常常会问我有没有好的学习案例，我觉得这个比赛程序就是一个绝佳的“麻雀虽小，五脏俱全”的范本。

这个程序要解决的问题很明确：模拟一个拥有三台独立电梯（A梯、B梯、C梯）的十层大楼，实现高效的群控调度。目标不仅仅是让每台电梯能独立响应本梯的召唤按钮，更重要的是要让三台电梯作为一个整体，智能响应大楼各层的公共厅外召唤信号。比如，你在5楼按了上行按钮，系统需要判断哪台电梯正处于空闲、哪台电梯顺路、哪台电梯响应最快，然后将这个召唤任务分配给最合适的那台电梯去执行。这背后涉及到单部电梯的完整运行逻辑、多部电梯之间的数据交换与协调算法，以及如何用西门子博途（TIA Portal）软件进行清晰、可维护的结构化编程。

对于PLC学习者而言，单纯看手册或简单例程，往往难以理解大型程序是如何组织起来的。这个比赛程序恰好展示了如何将一个复杂的控制系统，分解成若干个功能明确的块（Function Block, FB），如何规划数据块（DB），如何设计高效的通信机制。无论你是想深入理解西门子PLC的SCL结构化文本编程、学习模块化设计思想，还是想搞懂S7-1200之间通过S7通信或开放式用户通信（如TCP）交换数据的实际做法，这个项目都能给你带来很多启发。接下来，我就把这个程序的“里里外外”拆解一遍，分享当时的设计思路、关键代码以及踩过的一些坑。

2. 系统整体架构与设计思路拆解

面对“三部十层电梯群控”这样一个命题，第一步不是打开博途软件直接写梯形图，而是进行顶层设计。我们需要把整个控制系统抽象成几个核心的组成部分，并确定它们之间的信息流。

2.1 硬件与网络拓扑规划

当时的比赛指定了控制器为西门子S7-1200系列（具体型号为CPU 1214C），这意味着我们需要用三台物理PLC来分别控制三部电梯。当然，在实际教学中或资源有限时，也可以用一台PLC通过仿真或多实例方式来模拟，但比赛为了考察分布式控制能力，采用了真实的多PLC方案。

网络架构是第一个关键点。三台PLC需要实时交换数据，例如各自的当前位置、运行方向、目标楼层列表、负载状态以及各楼层的厅外召唤信号。我们选择了最稳定和常见的方案：西门子内部的S7通信。通过PROFINET网络，将三台S7-1200 PLC组态在同一个项目中，利用“组态连接”功能建立S7连接。这种通信方式编程简单，只需在两端调用PUT和GET指令，即可读写对方PLC的数据块，可靠性高，特别适合这种中小规模、确定性要求强的数据交换。

每台PLC的本地I/O负责连接本梯的核心设备：包括轿厢内的楼层按钮（10个）、开关门按钮、报警按钮，以及井道内的楼层平层信号传感器（通常为磁簧管或光电开关）、上下行限位开关、门机控制输出（开门、关门）、曳引机控制输出（上行、下行、速度），还有轿厢的载重检测信号。厅外召唤按钮（每层楼的上、下行按钮，共18个）的输入信号，则需要分配给三台PLC中的某一台来集中采集，或者更合理的做法是，通过分布式I/O（如ET200SP）采集后，由主控PLC通过通信广播给所有电梯PLC。在我们的比赛方案中，为了简化硬件和突出逻辑，采用了“厅外召唤信号由1号PLC（A梯）集中采集，然后通过通信广播给B梯和C梯PLC”的设计。

2.2 软件结构与模块化设计

在博途软件中，我们坚决采用了结构化编程的方法，这是管理复杂逻辑的基石。整个程序被划分为多个层级分明的块：

1. 组织块（OB）：这是PLC的“入口”。OB1（主循环）负责调用所有其他功能块；OB100（启动）用于初始化变量；OB82（诊断错误）用于记录硬件故障。我们还使用了OB30等循环中断组织块，用于执行需要精确周期调用的任务，比如电梯的精确平层控制算法。

2. 功能块（FB）与背景数据块（Instance DB）：这是程序的核心。我们为每部电梯创建了一个主要的控制功能块，例如FB_ElevatorControl。这个FB内部封装了一部电梯所有的状态机、逻辑判断和控制输出。每部电梯（A, B, C）都对应这个FB的一个背景数据块（如DB_Elevator_A）。这意味着，FB_ElevatorControl的代码只有一份，但三台电梯各自拥有独立的数据存储空间，互不干扰。这是面向对象思想在PLC编程中的体现，极大地提高了代码的复用性和可维护性。

3. 功能（FC）：用于编写纯功能的、无记忆的例程。例如，FC_CalculateDistance用于计算电梯当前位置与目标楼层的距离；FC_AssignCall实现了核心的群控调度算法，根据一定的策略（如最小等待时间、顺向响应等）将厅外召唤分配给最合适的电梯。

4. 数据块（DB）：用于存储全局或共享数据。我们创建了几个关键的全局数据块：

   • DB_GlobalSignals：存储所有厅外召唤按钮的状态（10层 x 2方向 = 20个布尔量）、系统总急停状态等。
   • DB_Communication：定义了用于三台PLC之间通信的数据结构。例如，每个电梯PLC都把自己当前的位置、方向、状态（空闲/运行/故障）、目标楼层列表写入这个DB的特定区域，同时从这个DB读取其他两台电梯的对应信息。DB_Communication在1号PLC（主站）上创建，并通过S7通信被2号和3号PLC读写。
   • 每个电梯FB的背景DB（DB_Elevator_A/B/C）则包含了该电梯所有的内部状态变量，如当前楼层、运行方向、门状态、内召登记列表、已分配的厅外召列表等。

5. 用户自定义数据类型（UDT）：为了管理复杂的数据结构，我们定义了UDT_ElevatorStatus这样的类型，里面包含了位置、方向、速度、负载等成员。这样，在DB或FB接口中，直接声明一个UDT_ElevatorStatus类型的变量即可，使程序更加清晰。

程序执行流程可以概括为：上电后，各PLC在OB100中初始化自身状态和通信参数。在OB1的每个扫描周期中，每台PLC首先读取本地输入（本梯内召、平层信号等），然后通过S7通信读取DB_Communication，获取最新的厅外召唤信号和其他电梯的状态。接着，调用FB_ElevatorControl，该FB根据当前状态、内召、外召以及其他电梯的状态，执行逻辑判断，更新自身的状态和目标列表，并控制电机和门机动作。最后，将自身最新的状态数据写入DB_Communication，供其他PLC读取。群控调度算法FC_AssignCall会在主PLC（或每台PLC独立计算）中周期性执行，根据全局信息刷新厅外召唤的分配关系。

3. 核心功能块详解与编程要点

理解了整体架构，我们深入到最核心的FB_ElevatorControl功能块内部。这个FB本质上是一个复杂的状态机。电梯的行为可以归纳为几个典型状态：空闲、开门、关门、加速运行、匀速运行、减速运行、精确平层、故障等。

3.1 状态机设计与实现

我们在FB内部定义了一个E_State的枚举型变量，列出所有可能的状态。状态转移的条件是编程的关键。

// SCL 语言示例 - 状态枚举和部分转移逻辑 TYPE E_State : ( Idle : // 空闲 DoorOpening : // 开门中 DoorOpen : // 门已开 DoorClosing : // 关门中 Accelerating : // 加速 Running : // 匀速运行 Decelerating : // 减速 Leveling : // 精确平层 Fault : // 故障 ); END_TYPE // 在FB内部 #currentState : E_State; #targetFloor : INT; #doorTimer : TON; // 开门保持定时器 CASE #currentState OF E_State.Idle: // 检查是否有内召或已分配的外召 IF #hasPendingCall THEN // 确定运行方向，切换到关门状态 #currentState := E_State.DoorClosing; #doorTimer(IN:=FALSE); // 复位开门计时 END_IF; E_State.DoorOpen: // 门完全打开后启动开门保持计时 #doorTimer(IN:=TRUE, PT:=T#5S); // 保持开门5秒 IF #doorTimer.Q THEN // 时间到，无人操作，自动关门 #currentState := E_State.DoorClosing; ELSIF #doorCloseButton OR #safetyEdgeObstacle THEN // 按下关门按钮或安全触板被触发，立即关门 #currentState := E_State.DoorClosing; END_IF; E_State.Running: // 实时监测当前位置与目标楼层的距离 #distance := ABS(#currentFloor - #targetFloor); IF #distance <= #decelerationStartDistance THEN // 到达减速点，切换到减速状态 #currentState := E_State.Decelerating; // 触发减速曲线输出 ELSIF #currentFloor == #nextTargetFloor THEN // 直接到达目标层（短距离），切换到平层状态 #currentState := E_State.Leveling; END_IF; // ... 其他状态转移 END_CASE;

注意：状态机的设计要保证完备性和确定性。每个状态下都要考虑所有可能的输入事件，并明确转移到哪个状态。避免出现“状态孤岛”或未定义的状态转移。使用CASE语句比一堆IF-ELSEIF更清晰。

3.2 召唤登记与定向逻辑

这是电梯逻辑的“大脑”。我们需要管理两个列表：内召登记列表和外召分配列表。在FB内部，我们通常用数组InternalCall[1..10]和AssignedExternalCall[1..10, Up/Down]来表示。

当轿厢内按下“5楼”按钮，程序需要将InternalCall[5]置位。当厅外5楼上行按钮被按下，并且群控算法将该召唤分配给了本梯，则AssignedExternalCall[5, Up]被置位。

定向逻辑的核心是判断电梯当前应该向上还是向下运行。一个经典的算法是“扫描方向优先”：

1. 电梯有一个当前运行方向（向上、向下、停止）。
2. 在运行方向上，检查所有已登记的、且楼层号大于（向上时）或小于（向下时）当前位置的召唤。这些是“顺向召唤”。
3. 如果存在顺向召唤，则保持原方向，前往最近的一个顺向召唤楼层。
4. 如果顺向召唤全部完成，则检查反方向是否有召唤。如果有，则改变方向；如果没有，则进入空闲状态。

这个逻辑需要仔细处理，特别是在电梯处于空闲状态收到第一个召唤时，需要根据召唤楼层与当前位置的关系来初始确定方向。

// 简化版的方向判断函数 (FC) FUNCTION DetermineDirection : INT // 返回 1:上, -1:下, 0:停 VAR_INPUT currentFloor : INT; currentDir : INT; // 当前方向 internalCallArray : ARRAY[1..10] OF BOOL; externalCallArray : ARRAY[1..10, 1..2] OF BOOL; // 1:Up, 2:Down END_VAR VAR_TEMP i : INT; hasCallAbove, hasCallBelow : BOOL; END_VAR hasCallAbove := FALSE; hasCallBelow := FALSE; // 检查所有召唤 FOR i := 1 TO 10 DO IF internalCallArray[i] OR externalCallArray[i, 1] OR externalCallArray[i, 2] THEN IF i > currentFloor THEN hasCallAbove := TRUE; END_IF; IF i < currentFloor THEN hasCallBelow := TRUE; END_IF; END_IF; END_FOR; // 逻辑判断 IF currentDir == 1 THEN // 当前向上 IF hasCallAbove THEN RETURN 1; // 继续向上 ELSIF hasCallBelow THEN RETURN -1; // 反向向下 ELSE RETURN 0; // 停止 END_IF; ELSIF currentDir == -1 THEN // 当前向下 IF hasCallBelow THEN RETURN -1; // 继续向下 ELSIF hasCallAbove THEN RETURN 1; // 反向向上 ELSE RETURN 0; // 停止 END_IF; ELSE // 当前停止 IF hasCallAbove AND NOT hasCallBelow THEN RETURN 1; ELSIF hasCallBelow AND NOT hasCallAbove THEN RETURN -1; ELSIF hasCallAbove AND hasCallBelow THEN // 上下都有召唤，可优化（如响应更近的） RETURN (ABS(currentFloor - NearestCallAbove) <= ABS(currentFloor - NearestCallBelow)) ? 1 : -1; ELSE RETURN 0; END_IF; END_IF;

3.3 群控调度算法实现

群控算法是项目的精华，它决定了系统的整体效率。我们当时实现了一个相对实用但不算最复杂的算法，主要基于最小响应时间预估。

算法在FC_AssignCall中实现，周期性地（例如每100ms）执行一次。其基本步骤如下：

1. 获取全局状态：读取DB_Communication中三部电梯的当前位置、方向、状态（运行/空闲）、当前目标楼层以及各自的召唤列表。
2. 遍历未响应的厅外召唤：检查DB_GlobalSignals中所有被按下但尚未被分配给任何电梯的厅外召唤按钮。
3. 为每个召唤计算候选电梯的响应时间：对于每一个未分配召唤（例如，5楼上行），分别计算三部电梯如果响应该召唤，预计需要花费的时间。
   • 预估时间= 电梯完成当前所有已登记任务所需时间 + 从最后一个任务楼层移动到该召唤楼层的时间。
   • 电梯的“任务”包括其内召、已分配的外召。需要模拟电梯按当前方向和逻辑依次服务这些任务的过程，才能估算出“完成当前任务所需时间”。这是一个简化的模拟计算。
   • 如果电梯当前方向与召唤方向不顺路（例如电梯在上行，召唤在下方且方向为上，其实召唤方向与电梯运行方向相反），则响应时间会加上一个“反向代价”（因为电梯需要先完成当前方向所有任务，再反向运行）。
4. 分配决策：选择预估响应时间最短的那台电梯，将这个召唤标记为分配给它。将分配结果写入该电梯在DB_Communication中的“已分配外召列表”区域。
5. 重分配检查（可选高级功能）：当某台电梯因故障或长时间等待（如门被阻挡）时，算法可以将其负载的任务重新分配给其他电梯。

这个算法在FC中实现时，计算量需要控制。我们做了一些简化，例如，电梯运行时间简化为“楼层差 × 每层运行时间 + 停靠时间（固定值）”。在实际比赛中，这个算法的效率是重要的评分点。

实操心得：在编写群控算法时，一定要在程序中加入详细的调试输出。例如，将每台电梯对每个召唤的预估时间、最终的分配决策，都写入一个专门的调试数据块。这样在连接PLC在线调试时，可以通过监控表清楚地看到算法的“思考过程”，对于排查逻辑错误至关重要。否则，面对不合理的电梯调度行为，你很难定位是数据采集错了、通信延迟了，还是算法计算逻辑有bug。

4. 通信配置与数据同步实战

多PLC项目的成败，一半在于通信。我们采用S7通信，以下是具体的配置和编程步骤。

4.1 博途中的网络组态

1. 在博途项目视图的“网络视图”中，添加三台S7-1200 PLC设备（例如CPU 1214C）。
2. 为它们分配不同的IP地址，例如：PLC_A: 192.168.0.10， PLC_B: 192.168.0.11， PLC_C: 192.168.0.12。确保它们在同一个子网（如255.255.255.0）。
3. 建立S7连接：从PLC_A的PROFINET接口，拖拽出一条线，连接到PLC_B的接口。在弹出的“创建新连接”对话框中，选择连接类型为“S7连接”。重复此步骤，建立PLC_A到PLC_C的连接。这样，PLC_A就作为“客户端/主动方”，可以主动向B和C读写数据。如果需要B和C之间也通信，或者需要双向主动读写，则需要建立更多的连接。
4. 在连接属性中，可以设置“主动建立连接”的伙伴为PLC_A，并记下每个连接的“本地ID”（一个16进制的数字，如W#16#100），这个ID在编程调用通信指令时会用到。

4.2 PUT/GET指令编程

在PLC_A（主站）的程序中，我们需要周期性地向B和C发送数据（写入），并从B和C读取数据。

• 向PLC_B发送数据（PUT）：在OB1中调用PUT指令。其参数配置如下：

  • REQ: 使用一个始终为TRUE的位（如M0.0）或一个时钟脉冲（如M0.5，用时钟存储器位生成）来触发每个周期都发送。
  • ID: 填写网络组态中建立的A到B连接的本地ID，例如W#16#100。
  • ADDR_1: 指向PLC_A本地要发送的数据区，例如P#DB200.DBX0.0 BYTE 20，表示从DB200的0.0字节开始，共20个字节。
  • SD_1: 与ADDR_1相同，例如P#DB200.DBX0.0 BYTE 20。
  • ADDR_2: 指定PLC_B中接收数据的区域，例如P#DB300.DBX0.0 BYTE 20。这个地址必须是PLC_B中实际存在的、并且可写的区域，通常是在PLC_B中创建好的一个DB（如DB_Comm_From_A），并确保其属性中“优化的块访问”被取消勾选（这样才有固定的绝对地址）。
  • DONE/ERROR/STATUS: 连接输出管脚，用于监控通信状态，可以连接到不同的M位或DB变量以便监控。

• 从PLC_B读取数据（GET）：同样在OB1中调用GET指令。

  • ID: 同样是A到B连接的本地ID。
  • ADDR_1: 指定要读取的PLC_B中的数据区，例如P#DB301.DBX0.0 BYTE 20。
  • RD_1: 指向PLC_A本地接收数据的区域，例如P#DB201.DBX0.0 BYTE 20。

PLC_B和PLC_C作为“服务器/被动方”，不需要调用PUT/GET指令。它们只需要创建好对应的DB（如DB_Comm_From_A,DB_Comm_To_A），并确保数据在这些DB中被正确更新即可。PLC_A会主动来读写。

数据同步策略：为了减少通信量并保证关键数据的实时性，我们定义了固定的通信数据结构。例如，一个20字节的数据包，前4个字节是电梯A的状态（包括当前位置、方向、状态字），接着是10个字节的内召列表（每个位代表一个楼层），最后6个字节是已分配的外召列表。PLC_A在每次扫描周期末尾，将本机的这些数据打包写入DB200，然后PUT指令会将其发送到B和C的对应DB。同时，PLC_A也用GET指令将B和C的对应数据读回到自己的DB201和DB202。这样，每台PLC都拥有其他两台电梯数据的“镜像”。

关键注意事项：S7通信的PUT/GET是异步指令，执行需要时间。REQ信号的触发频率不能高于通信处理的速度，否则会导致指令排队和通信错误。通常用一个几赫兹的脉冲（如100ms）来触发就足够了。务必监控ERROR和STATUS位，并在程序中做好错误处理，例如通信失败时，电梯可以降级为单梯独立运行模式，避免因通信故障导致整个系统瘫痪。

5. 调试技巧与常见问题排查

编写完程序只是第一步，现场调试才是“大考”。以下是一些从该项目中总结出的宝贵经验。

5.1 模拟调试与PLCSIM Advanced

在连接真实硬件前，强烈建议使用西门子的PLCSIM Advanced进行仿真。它可以仿真多台S7-1200/1500 PLC，并支持它们之间的网络通信（包括S7通信），这对于调试多PLC程序是无价之宝。

1. 创建仿真实例：在博途的“在线访问”中，为项目中的三台PLC分别创建PLCSIM Advanced仿真实例。
2. 下载硬件配置和程序：分别将硬件配置和程序下载到对应的仿真PLC中。
3. 使用仿真表（Simulation Table）：这是最强大的工具。你可以创建一个仿真表，为三台PLC的输入点（I）、中间变量（M）、数据块（DB）变量强制赋值或监控。例如，你可以手动“按下”某个楼层的厅外召唤按钮（强制DB_GlobalSignals.ExternalCall_5_Up为TRUE），然后观察三台PLC的内部状态变化、通信数据交换以及最终的电梯调度决策。
4. 跟踪程序流：结合博途的“监控”和“断点”功能，单步执行程序，查看状态机的转移是否按预期进行，变量值的变化是否正确。

5.2 在线监控与变量表

连接真实PLC后，变量表（Watch Table）是你的主要眼睛。

1. 结构化监控：不要把所有变量扔进一个表。建议创建多个变量表，如“电梯A状态”、“电梯B状态”、“通信数据区”、“厅外召唤”、“调试信息”等。这样逻辑清晰，便于快速定位问题。
2. 使用“修改值”功能进行测试：在安全的前提下，可以通过变量表直接修改DB中的值来模拟输入信号。例如，将DB_Elevator_A.CurrentFloor从3直接改为5，来测试电梯的平层和开门逻辑。
3. 监控通信状态字：将每个PUT/GET指令的STATUS字添加到变量表。正常通信时，STATUS会有一个固定的值（如16#7000）。如果出现错误，STATUS值会变化，根据这个错误代码去查询西门子手册，能快速定位是连接配置错误、地址错误还是网络问题。

5.3 常见问题与解决方案速查表

5.4 安全与故障处理逻辑

一个健壮的程序必须包含故障处理。我们在项目中实现了以下几层保护：

1. 硬件故障检测：通过OB82诊断中断，记录模块缺失、短路等故障，并触发系统进入安全状态（电梯就近停靠、开门）。
2. 软件看门狗：在OB1中设置一个周期性复位的“生命信号”（如M100.0），在OB30（一个固定周期，如100ms的中断）中检查这个信号。如果OB1因故卡死，生命信号无法更新，OB30会检测到超时，从而触发故障处理程序。
3. 运行超时保护：电梯在“运行”状态下，如果持续一段时间（如超过到达相邻楼层最大可能时间的两倍）仍未收到下一个平层信号，则判断为“卡梯”或故障，立即停止电机，尝试开门并报警。
4. 通信超时处理：在读取其他电梯状态的逻辑中，加入时间戳判断。如果某个电梯的数据超过一定时间（如2秒）没有更新，则认为与该电梯通信中断。群控算法将不再考虑该电梯，并将其未完成的任务重新分配给其他正常电梯。

回过头看这个2021年的比赛项目，它不仅仅是一套可运行的PLC代码，更是一个完整的中型工业控制系统开发范本。它强迫你从硬件选型、网络规划、软件架构、算法实现，一直考虑到调试、故障处理和安全。即使你未来面对的不是电梯，而是立体仓库、流水线或者复杂的物料输送系统，这套结构化设计、模块化编程、通信协同和状态机控制的思路都是完全相通的。

对于想提升西门子PLC编程水平的朋友，我的建议是：不要只停留在看，一定要动手复现。你可以先用PLCSIM Advanced仿真单部电梯，把状态机、召唤逻辑调通。然后尝试增加第二部电梯，自己设计一个简单的通信数据结构和调度规则。这个过程里遇到的每一个报错、每一个逻辑漏洞，都是最宝贵的经验。当你最终能让三台“虚拟电梯”在你的程序指挥下，有条不紊地接送“虚拟乘客”时，你对PLC编程的理解一定会上升到一个新的层次。

本文还有配套的精品资源，点击获取