第一次接触天塔之光实验时,我被这个看似简单却暗藏玄机的流水灯控制需求难住了。实验要求实现一组LED灯(L1-L8)按照特定规律循环点亮:从单灯流动到多灯组合,再到对称闪烁,最后全灯齐亮。这种非线性的亮灯模式,如果用传统继电器逻辑硬接线,估计要堆满整个控制柜。
在S7-200 SMART PLC上实现这个功能,本质上是要解决状态存储和状态转移两个核心问题。实验手册给出的SHRB移位寄存器方案,就像用传送带运送货物——把所有灯的状态排成一列,通过移位操作让状态依次传递。而我尝试的顺序功能图方案,则更像地铁换乘——每个站点(步)有明确的进出规则,通过置位/复位指令切换不同路线。
两种方案在硬件接线完全一致(I0.0启动开关,Q0.0-Q0.7对应L1-L8输出)的情况下,编程思维却截然不同。这让我想起刚入行时老师傅说的话:"PLC编程没有标准答案,只有更适合当前场景的解决方案。"
SHRB指令的全称是Shift Register Bit,它操作起来就像老式电影院的票务系统。假设有16个连续座位(M10.1-M11.7),每次有新观众(DATA端的M10.0状态)入场,所有观众就集体向右挪一个座位(N=+16),最右边的观众(M12.0)会被挤出去(存入SM1.1溢出位)。
在实际程序中,这个"座位调整"由定时器T37每500ms触发一次。移位后的座位状态直接对应输出点:当M10.1=1时点亮L1(Q0.0),M10.2=1时点亮L2(Q0.1),以此类推。这种映射关系使得灯效变化完全由移位寄存器内容决定。
实验手册的梯形图程序虽然简洁(仅用15个网络段),但调试时遇到了两个典型问题:
移位寄存器的优势在于资源占用少(仅需1个定时器和16个位存储器),但代价是程序可读性差——就像用摩斯电码写操作手册,虽然简洁但需要反复查译码表。
我的顺序功能图方案采用了更符合人类思维的设计方法。首先将整个灯效循环分解为20个独立步骤(Step0-Step19),每个步骤相当于地铁的一站:
code复制Step0(初始站)→[启动按钮按下]→Step1(L1亮)→[定时0.5s]→Step2(L1+L2亮)→...
每个步骤用M0.0-M1.3共20个位存储器标记,步骤间的转换条件就是定时器触点。在梯形图中,这转化为20个置位/复位电路块。例如Step1到Step2的转换:
ladder复制Network 1
LD T37 // 定时器触点
S M0.2,1 // 置位Step2
R M0.1,1 // 复位Step1
输出控制则采用"多站并联"设计。比如L2(Q0.1)在Step2、Step6、Step14等多个步骤都需要点亮,就直接用这些步的标记位并联驱动:
ladder复制Network 15
LD M0.2 // Step2标记
O M0.6 // 或Step6标记
O M1.4 // 或Step14标记
= Q0.1 // 输出到L2
在真实PLC上运行两种方案时,我用监控表记录了关键指标:
| 对比项 | SHRB方案 | 顺序功能图方案 |
|---|---|---|
| 程序容量 | 2.5KB | 4.8KB |
| 扫描周期 | 0.8ms | 1.6ms |
| 位存储器用量 | 16位 | 32位 |
| 定时器用量 | 1个 | 20个 |
| 仿真兼容性 | 不支持 | 完全支持 |
| 故障诊断难度 | 高(需查映射) | 低(步骤明确) |
虽然顺序功能图方案资源消耗更大,但在可维护性上优势明显。有次需要修改Step7的灯效组合,我只需调整对应步的输出逻辑,完全不影响其他步骤——这就像修改地铁某站点的出口指示牌,不会改变整条线路的运行。
经过多次实验验证,我认为SHRB移位寄存器特别适合以下场景:
有个实战技巧:在移位寄存器前增加数据校验网络。比如在M10.0输入前加入:
ladder复制Network X
LD SM0.1 // 首次扫描
MOVB 16#55, MB10 // 初始化寄存器为01010101
这样可以避免上电时寄存器全零导致灯效异常。
对于天塔之光这类非连续变化的控制需求,顺序功能图展现出更强适应性:
我在汽车生产线改造中就深有体会:当客户临时增加"急停后恢复"功能时,用顺序功能图只需在对应步骤插入恢复逻辑,而移位寄存器方案几乎要推倒重来。
深入测试发现SHRB有些手册没明说的特性:
ladder复制Network Y
LD M0.0
SHRB M20.0, +8 // 控制L1-L4
SHRB M30.0, -8 // 控制L5-L8反向移动
为避免步数过多导致程序臃肿,我总结了几条优化经验:
最实用的当属状态快照功能:在关键步骤将MW0状态存入保持型寄存器,设备断电重启后可恢复运行状态。这在大楼灯光控制系统中特别实用。