基于S7-1200的PLC流水灯控制系统设计与仿真全解析

《可编程控制器原理与应用》这门课到了综合实验阶段，题目一般都会开放好几组，我抽到的是那个看起来人畜无害的“基于S7-1200的PLC流水灯控制系统设计与仿真”。当时第一反应和大多数人一样：流水灯？这不是网上随便一搜就有梯形图的题目吗？可真到自己从选型、建项目、写逻辑到仿真验证完整走一遍，才发现搜到的那些案例基本都是“结果导向”——给你最终的梯形图和一段说明，却没人告诉你为什么要用移位寄存器而不是计数器，也没人提醒你仿真环境里的时间基准和实物接线差多远。这篇文章就把我做这次综合实验的完整过程摊开讲，从硬件选型、TIA Portal组态，到三种可以互相替换的实现思路，再到PLCSIM仿真验证，最后是调试过程中踩过的几个典型坑。

如果你正准备做同类课程设计，可以直接照着后面的章节操作；如果你是已经入行的工程师想回看顺序控制的基础，这里也有几段可以复用到其他项目上的编程模板。需要说明的是，文中提到的所有参数和调试现象，来自课程实验环境下某一批次S7-1200的典型表现，不同固件版本和软件版本会有细微差异，具体数值要以你的实际环境为准。

1. 实验定位：流水灯为什么能撑起一次综合实践

1.1 一个“小题目”覆盖了PLC课程的大部分主线

流水灯控制系统的本质，是让一组数字量输出按照时间顺序依次导通和断开。这个逻辑单看每一步都很基础，但组合起来却触及了PLC编程里最核心的几块内容：定时器（决定每一步的持续时间）、计数器或移位指令（决定状态如何前进）、位逻辑组合（启动、停止、复位、方向切换）、以及循环扫描机制对状态的影响。换句话说，这个项目相当于把课程前面所有散装知识点一次性串起来。

在验收标准里，通常除了“灯能按顺序亮灭”之外，还会追加几个要求：可以随时暂停、可以调整流动方向、可以改变流动速度、按下复位后回到初始状态。这些追加条件让原本单调的8位循环变成了一个需要考虑状态边界的小型系统。

1.2 为什么选S7-1200而不是更老的平台

选S7-1200作为实验平台，最直接的现实原因当然是课程资源——设备就在实验室里。但从工程角度看，这个选择也很合理。S7-1200是西门子小型PLC里的主流型号，它和更早期的S7-200相比，编程环境换成了TIA Portal（博途），指令体系采用IEC标准，数据类型更强，集成了以太网口，仿真工具PLCSIM也足够成熟。对一个课程综合实验来说，它既不会因为平台太老而脱离实际，也不会因为功能太复杂而让入门者迷失。

更重要的是，S7-1200在小型自动化项目里大量使用。流水灯实验里写出来的时间序列控制逻辑，换一个应用场景就是流水线上的工位节拍控制、分拣机构的顺序动作、或是一台小型设备的上电自检流程。在实验里打下的基础，能直接迁移到工程现场。

1.3 实验验收时到底在看什么

我的体会是，只看“灯亮不亮”是最低标准，真正拉开差距的集中在三件事：第一，程序结构是否清晰——是用一个OB1里堆所有逻辑，还是合理拆分函数块；第二，有没有考虑状态的异常恢复——比如运行途中突然断电再上电，程序是停在某个中间状态还是能回到初始状态；第三，仿真或实物演示时，能不能针对某个现象现场解释原因。这三点分别对应了可维护性、可靠性和对原理的理解深度，也是这篇博文后面会反复强调的线索。

2. 硬件选型与仿真路线：从CPU型号到IO分配

2.1 CPU和信号板怎么选

针对流水灯这种规模的实验，CPU选S7-1200系列里的1214C DC/DC/DC就足够。这个型号自带14路数字量输入和10路数字量输出，集成以太网口，本身也带2路模拟量输入。如果实验室配的是1212C甚至1211C，数字量点数少一些，但应对8个灯和几个按钮依然没有问题，程序逻辑完全一致，区别只在地址范围和CPU的存储区大小。

有的同学会纠结要不要额外加一块数字量扩展模块SM1223之类。以这个实验的IO规模，完全不需要。自带IO足够覆盖，加了模块反而会引入地址分配上的额外注意力负担。真正需要额外配置的不是扩展模块，而是一个能输出24V直流电的开关电源，因为S7-1200的24V电源输入和传感器输入回路共用，灯组和按钮的供电都要从同一路24V取。我实验时用的是实验室配好的开关电源，如果你自己搭台架，这一步别漏。

2.2 IO表设计里的一个关键决定

做综合实验第一步不是写程序，而是先把IO地址定清楚。我的分配表如下：

当时的程序里还用到一组内部变量M0.0到M0.7作为灯状态的中间镜像，这一步是刻意的。为什么不让Q0.0到Q0.7直接参与移位运算？因为输出映像区的主要职能是驱动外部设备，把它当作“运算内存”用虽然可行，但在程序可读性和后续扩展上都会留下隐患。用一个内部字节MB0保存状态位，再把MB0的8个位分别传到Q0.0~Q0.7，逻辑会更清晰。后面加方向切换、暂停功能时，只需要改中间变量而不必动输出区。

2.3 用仿真为主的方案如何保证实验效果

这次综合实验安排的侧重点是“设计与仿真”，因此没有把实物的物理继电器和灯组作为硬性要求。好处是每个人都能独立拥有一套完整环境，不会因为设备占用等问题互相等待；挑战在于仿真环境下，外部按钮和灯的逻辑关系需要通过监控表、强制变量等方式模拟，这对理解PLC的扫描机制反而提出了更高要求。

PLCSIM不仅能模拟CPU运行，还能模拟程序中的保持性数据区、定时器、计数器等内部资源。对流水灯系统来说，仿真时需要注意的一点是：真实按钮在物理世界的动作是异步的，而仿真里的强制变量通常会在下一个扫描周期立即生效。做实验演示时，我会把按钮的“按下”操作拆成两步——先置位变量，再触发一个延时观察，这样才能比较接近真实按钮的边沿行为。

3. TIA Portal组态：决定体验好坏的三个关键细节

3.1 新建项目与设备组态的完整流程

软件方面我用的是TIA Portal V16，系统版本不同界面可能有差异，但流程主干一样：新建项目，添加设备，选择具体CPU型号和固件版本，然后进入设备视图确认IO地址。

添加设备后有个容易忽略的步骤：检查CPU的“设备组态”中，数字量输入是否有输入滤波器设置，数字量输出是否有针对负载类型的配置。流水灯实验的负载是LED灯组或继电器，默认的参数几乎都能直接满足，真正要留意的是IO的“地址起始偏移”。有些固件版本默认从I0.0和Q0.0开始，地址直观；但如果组态时被改过起始地址，程序里写的I0.0可能实际对应硬件上不同的端子，仿真时不明显，接实物时就是灾难。做仿真实验时也建议在组态页看一眼I/Q地址分布，确认预期中的地址没有被偏移。

3.2 一个符号地址引发的偏移问题

这次实验里我踩过的一个真实小坑，和变量命名有关。TIA Portal里可以在PLC变量表中定义符号名，比如“启动”“停止”“灯1”。流程上，这时要把“灯1”的绝对地址定义为Q0.0，“灯2”对应Q0.1，以此类推。

我当时为了方便，在某个全局数据块里也定义了一个字节数组“LightState[0..7]”，打算用它来暂存灯状态。问题是，PLC变量表中的Q0.0是输出地址，而DB里的LightState是内存地址，两者在程序里如果同名，阅读时会非常混乱。最终我统一了命名：所有输出相关变量不带前缀，内部中间变量统一加“_M”后缀。别小看这个习惯，后面做程序检查时，仅仅靠变量名就能立刻判断信号来自外部还是内部。

3.3 仿真模式的准备工作

组态完成后，在点击启动仿真之前有几个前置动作：把程序块编译通过、确保没有访问越界的DB地址、UI界面上勾选“允许仿真”。在TIA Portal中，点击“启动仿真”按钮后，软件会提示创建一个新的仿真实例，此时需要选择“加载项目”的方式，通常选择“从设备组态加载”。加载完成后，把CPU切到RUN模式。

这里有一个仿真特有的坑：PLCSIM里的RUN模式不会自动运行到“首次扫描标志”的等效状态。我的程序里有一段首次扫描时执行的初始化逻辑——把MB0初始化为1。但仿真器在下载完成并切换RUN的过程中，首次扫描标志位FirstScan在部分情况下不会像真实CPU那样可靠触发，导致流水灯状态一开始有可能全灭，需要手动按一次复位按钮才能进入流动。这不是逻辑问题，而是仿真模型的边界行为。对实验演示来说，最好的应对方式是在程序里同时提供“上电复位定时器”逻辑：用一个200ms的上电延时后强制置位初始状态，这样在仿真和实物环境下行为一致。

4. 核心逻辑拆解：三种可复用的实现思路

4.1 移位循环法：最经典的顺序控制思维

流水灯最经典的实现方式，是把一组二进制位按时间节拍移位。我用内部字节MB0作为状态位，程序里定义了一个循环周期定时器，每500ms（或根据速度开关选择250ms）产生一个节拍脉冲。

按照从左到右的流动方向，初始状态MB0 = 1，即M0.0为TRUE，对应第一个灯亮。每个节拍到来时，先把状态字节左移一位，再把最高位移出来的位回填到最低位，这样“1”就在8个位之间循环流动。用SCL表示一个片段：

// 节拍定时器，脉冲周期由速度开关决定 IF "速度选择" THEN #cycleTime := T#250MS; ELSE #cycleTime := T#500MS; END_IF; // 定时器调用 #flowTimer(IN := NOT #flowTimer.Q, PT := #cycleTime); IF #flowTimer.Q THEN #M_lightByte := SHL_BYTE(IN := #M_lightByte, N := 1); // 最高位M0.7回填到最低位，形成循环 IF #M_lightByte.7 THEN #M_lightByte.0 := TRUE; END_IF; // 或者把最高位的值保存后回填 END_IF; // 输出映射 Q0.0 := #M_lightByte.0; Q0.1 := #M_lightByte.1; Q0.2 := #M_lightByte.2; Q0.3 := #M_lightByte.3; Q0.4 := #M_lightByte.4; Q0.5 := #M_lightByte.5; Q0.6 := #M_lightByte.6; Q0.7 := #M_lightByte.7;

这段代码的思路是：用一个字节存放“当前哪个灯亮”的状态，然后用定时器驱动它移动。至于方向切换，只需在移位方向上下文章——向右移就用SHR_BYTE，并且把最低位移出的位回填到最高位。

4.2 计数器加CASE分支：最直观的状态机

如果你觉得移位指令对初学者有点抽象，可以换一种思路：既然流水灯只有8个状态，那就定义一个0到7的整数计数器，让它按节拍递增，再根据计数器的值直接去点亮对应输出。这在本质上是把“连续移位”换成“离散状态选择”，逻辑上更加直白。

// 计数器递增，范围0~7 IF #flowTimer.Q THEN #step := #step + 1; IF #step >= 8 THEN #step := 0; END_IF; END_IF; CASE #step OF 0: Q0.0 := TRUE; Q0.1 := FALSE; Q0.2 := FALSE; Q0.3 := FALSE; Q0.4 := FALSE; Q0.5 := FALSE; Q0.6 := FALSE; Q0.7 := FALSE; 1: Q0.0 := FALSE; Q0.1 := TRUE; Q0.2 := FALSE; Q0.3 := FALSE; Q0.4 := FALSE; Q0.5 := FALSE; Q0.6 := FALSE; Q0.7 := FALSE; // 其余case类似，不再逐一列出 7: Q0.0 := FALSE; Q0.1 := FALSE; Q0.2 := FALSE; Q0.3 := FALSE; Q0.4 := FALSE; Q0.5 := FALSE; Q0.6 := FALSE; Q0.7 := TRUE; END_CASE;

计数器法的优势在于：状态值本身就是一个变量，你可以把它发送到HMI上显示“当前亮到第几个灯”，也可以在此基础上做更多条件判断，比如“从状态3开始变为反向”。它的缺点是当状态数量变大时，比如20个站点的顺序控制，逐一写CASE分支会显得冗长。但在流水灯这个规模下，两种方法半斤八两，选择哪个更多取决于你希望演示哪种编程风格。

4.3 定时器配合比较器：不用移位也不用CASE

第三种方法相对冷门，但扩展性强：把节点计数器的值和一个字节做比较，每个输出位的置位条件等于“计数器当前值等于该位编号”。例如在梯形图里，就是多个比较指令并联。写成SCL就成了循环判断：

FOR #i := 0 TO 7 DO // 将Q输出按位映射，这里用QRY的按位置位方式 IF #step = #i THEN // 置位第i个输出 Q0_7_array[#i] := TRUE; ELSE Q0_7_array[#i] := FALSE; END_IF; END_FOR;

这种方法的特点是把“状态编号”和“物理输出”之间的映射关系集中到一个循环里，后续如果想把某个灯位换成双色灯、或者把灯位对应到不同的物理设备，只需要改映射那一小段。实验报告里讨论三种方法的优劣时，这种“数据映射与状态推进分离”的思想反而是加分的点。

4.4 三种方法如何取舍

我自己在实验里最终选用了“移位循环法+计数器法”双版本：主程序用计时器驱动移位字节，另写了一个用于演示的计数器版本作为备用。这么做不是为了炫技，而是两种方式对应了两种调试思路——在仿真里观察字节的二进制变化，直观的是移位法；而需要确切知道当前是第几个状态时，计数器法更友好。

对比下来，可以给出一张简单对照表：

5. 仿真验证的完整闭环：从强制变量到时序观察

5.1 PLCSIM里的启动操作与信号模拟

编译无误后，点击TIA Portal工具栏上的仿真按钮，PLCSIM窗口会弹出并显示一个模拟CPU面板。下载项目后把CPU切到RUN，此刻程序已经实际运行在仿真环境里。接下来需要验证外部信号：启动按钮对应的I0.0，在PLCSIM里打开“监控表”，把I0.0置为TRUE，观察程序中的Q输出是否开始动作。

这里建议用“监控表+程序状态”两个窗口同时看。程序编辑器里，在线状态下，接通状态以彩色连线表示，这比只盯监控表更容易理解数据流。流水灯跑起来后，就是在监控表里依次观察MB0的值，按二进制解读，正常情况下应看到00000001、00000010、00000100……最后回到00000001。

5.2 把验证点设计成一张清单

仿真不只是“让它跑起来”，我习惯把验证点列成清单，逐条打勾。这次流水灯实验的验证点包括：

1. 启动后第一个灯常亮，500ms后第二个灯亮并伴随第一个灯熄灭。
2. 方向切换开关置ON后，流动方向立即反向，状态值从递增变为递减。
3. 速度开关置ON后，状态跳变周期由500ms切换为250ms，且无需停止系统。
4. 按下停止按钮，所有灯灭，但内部状态保持；再次按下启动，从停止时那个状态继续流动，而不是从头开始。
5. 按下复位按钮，系统无论处在哪个状态，都回到第一个灯亮的状态。

其中第4点比较容易被忽视。有些同学把停止按钮直接串联在定时器使能前面，导致停止后整个状态字节也被清零，再次启动时从初始状态开始。若验收要求不严格，这样也能过；但更符合“停止保存状态”的设计是：停止时只是断开定时器继续工作的条件，并不清除状态字节。这个行为差异在实验答辩时经常被追问。

5.3 仿真和实物实验的差异要心里有数

PLCSIM能做到的，是完整模拟CPU内部程序的执行；做不到的，是模拟外部接线和传感器反馈回路。对流水灯实验来说，输出动作本身在仿真里能看到线圈的通断状态，但“灯真的亮了”这种物理现象只能靠脑补。另外，仿真环境下定时器的时间基准与CPU实物几乎完全一致，因此500ms的节拍在仿真里和实物上一样。但在某些虚似机环境下，如果TIA Portal软件本身运行卡顿，在线监控的画面刷新可能受影响，让你误以为程序运行变慢了——那通常是显示问题而不是逻辑问题。

6. 调试过程中三个典型的坑和对应的排查思路

6.1 定时器编号冲突：复位不掉的老大难

在S7-1200里，定时器不再是老式S7-200里的有限编号方式，而是由系统自动分配背景数据块。但如果你在程序里手动创建了多个定时器，并且把它们的背景DB变量搞混——比如把两个定时器共用了同一个背景ID——就会出现“一个定时器触发，另一个也跟着触发”的现象。

我当时把节拍定时器和停止延时的定时器都定义在一个函数块内，修改其中一个定时器的参数时，TIA Portal提示“DB号码不一致”，排查才发现是复制粘贴定时器块时，系统保留了同一个背景DB引用。解决方式很简单：在程序左侧的“程序资源”里重新生成定时器实例，让每个定时器拥有独立的背景数据块。这种事在仿真实例里极少暴露问题，但接实物时如果出现定时时间完全混乱，可以先查这一项。

6.2 扫描周期导致的状态跳变

流水灯实验中有一个理论但实际会碰到的现象：在单个扫描周期内，状态字节的移位、回填、输出映射如果分处在不同的网络里，并且中间夹杂着其他逻辑，可能在一个扫描周期里出现“移位后又立即被某个条件改写”的中间状态。

我在第一次仿真时发现，Q0.0不会按照预期在一个节拍内熄灭，而是延迟了大约一个扫描周期。原因是输出映射指令放在移位指令所在网络的后面，而中间恰好插入了一个“复位按钮是否按下”的判断，这个判断在某次扫描执行时把状态字节清零了。排查思路是：把按钮复位逻辑改成上升沿触发，而不是电平触发。复位按钮用R_TRIG上升沿触发器处理之后，状态字节只会在按下瞬间被清零，不会再持续覆盖移位结果。

6.3 仿真时间不是问题，但操作时间会误导你

还有一类坑来自操作者而不是PLC。在PLCSIM里强制I0.0为TRUE时，如果你在监控表里同时强制了多个变量，并且手动点击了“立即全部更新”，强制值的生效时机可能与预期不同。我调试方向切换时，把I0.3强制为TRUE后，流动方向没有立刻反转，而是要等到下一个定时器触发才变。这在逻辑上是合理的——方向反不反转需要等状态推进到下一次移位才体现——但如果你在演示时不了解这一点，第一反应往往是“程序写错了”。

应对方法是把操作节奏放慢：强制完方向开关后，等一个节拍周期再观察结果，不要连续快速改动多个输入。仿真中的强制变量本质上是在模拟外部信号的持续状态，它不能替代“在正确的时间点给出正确的信号”这一工程习惯。

6.4 关于在线监控表的一个小技巧

如果想让演示效果更贴近实物，可以把PLC变量表中的Q0.0~Q0.7建到一个监控组里，显示类型选“位”，排序方式按地址顺序。这样在PLCSIM运行时，能看到一行8个位像跑马灯一样切换，展示效果比逐个查看字节更直观。这个小细节，做答辩演示时很加分。

收尾：这个实验做完之后我留下的两个习惯

第一个习惯是，凡是涉及顺序控制的程序，无论多简单，我都会把它拆成“状态推进”和“输出映射”两部分。流水灯里这个拆法可能显得小题大做，但到了二三十个工位的节拍控制场景，这种分层的可维护性优势会非常明显。第二个习惯是，仿真通过不等于现场可靠，凡是涉及定时器、边界状态、手动干预的逻辑，都要额外列出“如果这里被人突然按了一下会怎样”的检查项。流水灯实验本身就是一次很小的演练，但它把这两个习惯深深地刻进了我的调试流程里。后面每当我看到一个循环输送、顺序启停的设备，脑子里浮现的还是这几个Q点在监控表里依次跳动的画面。