从污水处理案例读懂S7-1200：程序、通讯点表与触摸屏的工程串联

第一次拿到这套污水处理项目资料时，我印象最深的是它的完整度：S7-1200 PLC的程序、通讯点表、触摸屏画面三样齐全。大多数学习资料都是拆开的，程序归程序、图纸归图纸，能把三者串成一条线讲清楚的案例很少。而这份资料恰好把污水处理这条工艺链从头到尾演示了一遍——从进水提升到生化曝气，再到污泥回流与出水排放，每个环节都有对应的控制逻辑、通讯点位和画面操作。

这也是为什么我一直建议学PLC的人别盯着红绿灯、电机启停这类小Demo不放，找一套带通讯点表和上位机画面的中型项目去通读，收获完全不一样。你从里面能读到的不只是梯形图，而是一整套工程化的思考方式：信号从哪儿来、经过什么处理、最终怎么被操作员看到和干预。这篇文章我就以这套水处理程序为主线，把读图、读程序、读点表的顺序和思路完整拆开来讲。

1. 为什么污水项目是学PLC工程的“全要素”教材

1.1 一份完整项目资料在学什么

很多人拿到完整项目资料的第一反应是打开程序文件，从OB1开始往下读。这个习惯得改。真正的工程资料里，程序只占一部分价值，点表和触摸屏画面才是把程序“钉”在现实世界中的锚点。

这么说吧：梯形图里一个Q0.3输出，如果你不看点表，不知道它对应的是一台提升泵接触器还是一台电动阀的开阀指令，那么你只能看懂逻辑，看不透系统。反过来，你拿着点表去对照工艺流程，才能理解为什么程序里要把液位信号分组处理、为什么某些泵要设轮换周期、为什么模拟量通道要做工程量转换。

这套污水项目正好具备这些要素：

• S7-1200系列PLC程序，属于中小型项目的主流选型，性价比高，资料也多。
• 完整的通讯点表，涵盖数字量输入输出、模拟量输入输出以及Modbus/RS485仪表通讯点位。
• 触摸屏工程，操作员视角的画面组态，包括流程总览、单机控制、报警与趋势。

这三样东西合在一起，本质上就是一个微缩的工业控制系统。你把这个案例吃透，再去接触大型DCS项目或者分布式控制系统，思路是相通的。

1.2 污水工艺里的控制逻辑密度足够高

污水处理在工艺上有个特点：流程长、环节多、设备类型丰富，且控制对象既有逻辑开关量，又有需要连续调节的模拟量。这决定了它的程序不可能只是“按下启动按钮、电机转动”那么简单。

粗格栅的清污机要根据格栅前后液位差自动启停；提升泵房里的潜污泵要按集水井液位自动开泵、关泵，还要轮换运行；生化池的溶解氧要控制在一定范围，于是鼓风机的频率调节成了PID控制的典型场景；二沉池的污泥回流比要稳定，对应的回流泵又需要比例调节。更不用说加药间里的计量泵、消毒单元的紫外灯组、出水口的在线监测仪表。

这些工艺需求映射到PLC程序里，就形成了几大块固定节目：

• 液位联锁与泵阀启停逻辑
• 多泵轮换与运行时间均衡
• 模拟量采集与工程单位换算
• PID闭环调节
• 仪表通讯数据采集与断线处理

一个污水案例把这几样全包含了。相比之下，很多教材项目只覆盖了第一项，后面几项全靠自己脑补。所以我说它是“全要素”教材，一点也不夸张。

2. 读懂程序前，先把工艺流程图挂在墙上

2.1 单元工艺与控制点的一一映射

读程序最忌上来就翻OB块。我个人的习惯是先画一张工艺流程图，把每个工艺单元的设备和仪表标注出来，再拿这张图去对照程序结构。

污水处理的典型流程是：粗格栅拦截大块漂浮物，提升泵房把水抬高到后续处理单元；细格栅进一步去除细小悬浮物，曝气沉砂池去砂；然后是生化处理段，通常包含厌氧、缺氧、好氧三个区域，利用微生物降解有机物和脱氮除磷；再往后是二沉池做泥水分离，出水经消毒后排放，污泥一部分回流到生化池维持微生物浓度，剩余污泥进入储泥池外运处置。

在这个流程上，控制点分布非常清晰：

拿这张表去对照S7-1200的项目树，你会惊讶于结构高度对应：程序里的每一个功能块，几乎都能在工艺图上找到一个属于自己的位置。这就是工程化的组织方式，也是我反复强调“先把工艺图挂在墙上”的原因。

2.2 控制需求表先行，再谈编程技巧

如果把工艺图比作地图，控制需求表就是施工图。很多初学者拿到工艺图后，眼睛只盯着那些看起来“有技术含量”的部分，比如PID、通讯，却把最简单的“泵什么时候开、什么时候停”给忽略了。结果一到现场调试，问题全出在这些基础逻辑上。

我在这套水处理案例里整理过一份简化的控制需求表，拿提升泵房举例：

• 集水井液位低于0.5米：所有泵停止，防止空转。
• 液位位于0.5～1.5米：启动1号泵，达到1.5米时停泵。
• 液位位于1.5～2.5米：启动2号泵，两台泵交替运行。
• 液位超过2.5米：两台泵同时运行，提高排水能力。
• 任一泵运行时间累计超过设定值：切换备用泵，均衡磨损。

这段需求翻译成程序其实并不难，关键是你要先能把需求表写出来。许多项目出现“泵频繁启停”“两台泵同时工作后液位波动剧烈”这类问题，根本原因不是编程技巧不够，而是控制需求没有定清楚。液位死区、启停间隔、轮换周期，这些参数必须在写程序前就要有明确取值。

我见过不少人在程序里直接写死“液位大于1米开泵，小于0.8米停泵”，表面看没问题，实际运行时会发现：进水流量波动大，水泵频繁启停，接触器和电机发热严重。这是典型的控制需求考虑不周。正确做法是给每个启停条件增加持续确认时间，比如液位超过启动阈值且持续5秒才允许开泵，防止瞬时波动误触发。

3. S7-1200程序结构：先看OB再看FC，别从OB1硬啃

3.1 程序块的调度关系与命名规范

S7-1200的程序组织方式和传统S7-300/400稍有不同，但核心思路一致：OB是组织块，负责调度；FC是函数，适合做无记忆的逻辑运算；FB是函数块，带背景数据块，适合做有状态的控制逻辑；DB是数据块，存放全局数据。

这套水处理程序的块结构通常长这样：

• OB100：启动初始化，复位输出、装载默认参数。
• OB1：主循环，按顺序调用各工艺段的处理函数。
• OB35或循环中断OB：周期执行模拟量采集与PID运算。
• FC：例如FC100用于格栅控制，FC101用于提升泵控制。
• FB：例如FB110用于鼓风机频率调节，内部封装PID逻辑。
• DB：例如DB100存放模拟量实时值，DB200存放设备状态。

初学者最常犯的错误，是把所有逻辑全堆在OB1里，一个扫描周期从上到下执行几百行甚至上千行程序。这么写小Demo没问题，用到污水站这种规模的项目里，后期调试、查故障、改逻辑都会非常痛苦。

正确做法是让OB1保持精简，只做“总调度”，真正干活的是FC和FB。看一下这套程序的OB1，一般前几行就是调用格栅处理函数，接着调用提升泵处理函数、生化池处理函数，最后调用通讯数据刷写函数。每个函数内部只管自己那一块设备的逻辑，输入输出通过参数传递，数据和数据之间不互相纠缠。这种分层方式，是工程调试效率的核心保障。

3.2 模拟量工程转换：量程偏移与数字量处理

污水处理里大量信号是标准的4～20mA模拟量：液位计、压力变送器、pH计、溶解氧探头、流量计。这些信号进入S7-1200的模拟量输入模块后，会被转换成整型数字量，范围一般是0～27648。

我收到的这套案例里，工程转换逻辑写得很标准，公式是：

工程值 = (原始值 / 27648) × (量程上限 - 量程下限) + 量程下限

举个例子：一个液位计量程是0～5米，输出4～20mA。PLC采集到的原始值是13824，那么对应液位就是(13824 / 27648) × 5 = 2.5米。

看似简单的公式，在实际项目中有三个非常容易踩的坑：

第一，量程不匹配。现场液位计量程是0～5米，但程序里默认成了0～10米，结果画面显示值只有真实值的一半。这种问题点表上最容易发现——点表里标注了量程范围，写程序前必须逐个核对。

第二，信号断线判断。4～20mA在断线时会掉到0mA，对应数字量0。如果不做“信号异常”判断，程序会把断线误判为“液位为0”，然后做出错误联锁动作。规范的模拟量处理都会加一个上限上限检查、下限下限检查，比如小于500就报通道故障，不参与联锁逻辑。

第三，滤波与平滑。污水池液位波动很大，尤其是进水泵启动后，液位会在短时间内快速下降。如果直接拿原始液位做PID或者联锁判断，输出会来回震荡。实际工程中通常做一阶惯性滤波，或者用多次采样取平均值。滤波时间常数要现场调试，不是越大越好，太大了会掩盖真实液位趋势，影响泵的正常启停判断。

3.3 PID调节与鼓风机供氧逻辑

生化池溶解氧控制是污水处理自动化的重头戏。工艺要求在好氧区维持溶解氧浓度在某一个区间，比如1.5～2.5mg/L，这个控制目标通过调节鼓风机的供气量来实现。

程序里通常用PID_Compact功能块，设定值是目标溶解氧浓度，过程值是溶解氧仪表反馈值，输出是鼓风机频率指令。

PID参数整定上，污水曝气系统有一个明显的痛点：纯滞后大。从鼓风机调频到曝气头出气，再到溶解氧仪表数值变化，中间隔着一池水和几十分钟的生化反应过程。所以PID参数不能照搬教材上的经验值，比例增益要放小、积分时间要拉长，否则系统必然震荡。

我经常跟人建议，这种大滞后系统调试时先从手动模式开始：手动给一个固定频率，观察溶解氧变化速率，记录上升时间，再据此估算PID的积分时间和增益。这个案例程序里PID块带手动自动切换功能，就是给这种调试方式留入口的。

另一个容易被忽略的细节是PID输出上限。鼓风机频率指令通常在25Hz到50Hz之间运行，低于25Hz可能无法克服管路背压，高于50Hz会超出电机额定转速。程序里要限幅，还要把输出换算成变频器实际接收的模拟量信号或通讯报文格式。

4. 通讯点表：比程序还重要的图纸

4.1 点表的三层信息

点表这东西，外行看着就是一张Excel表，内行能从中读出三层信息：信号定义、PLC地址、量程与说明。

以这套水处理项目的点表为例，上边大致是这么填的：

• 信号描述：1号提升泵运行反馈
• 信号类型：DI（数字量输入）
• PLC地址：I0.0
• 现场去向：MCC柜内接触器辅助触点
• 备注：无源干接点

再看模拟量点位：

• 信号描述：生化池溶解氧
• 信号类型：AI
• PLC地址：IW64
• 量程范围：0～5mg/L
• 信号制式：4～20mA
• 对应仪表位号：DO-101

拿到点表先做什么？不是背地址，而是拿着它和工艺流程图对照。每一个工艺环节的检测仪表和控制设备，都应该能在点表里找到对应的位置。如果在某一段流程里发现了“只有设备、没有信号”的情况，那就要重点确认：是工艺设计时就没考虑自动控制，还是资料交接漏掉了。

4.2 现场仪表与PLC之间的Modbus通讯

除了硬接线的数字量与模拟量，现代污水站还有大量智能仪表通过通讯方式接入PLC。在线COD分析仪、氨氮分析仪、pH计、超声波流量计，这些仪表多数支持Modbus RTU协议。

这套案例里，PLC通过RS485口或通讯模块连接多台仪表。Modbus RTU的配置在程序里不外乎这么几点：

• 波特率：常见9600或19200，要和仪表侧一致。
• 数据格式：8个数据位、1个停止位、无校验或偶校验。
• 从站地址：每台仪表一个唯一地址，不能冲突。
• 功能码：读保持寄存器一般用功能码03。

程序上，S7-1200可以通过Modbus_Comm_Load指令配置端口，再用Modbus_Master指令轮询各从站。这套程序里比较讲究的是把通讯数据映射到独立的数据块中，比如DB300存放从各仪表读上来的原始寄存器值，DB310存放转换后的工程量值。

这里我想强调一个很多人吃过亏的点：Modbus是主从轮询机制，程序每个扫描周期只能读取有限个寄存器，如果你把全部仪表的几十个参数塞在同一个循环里，周期会被拉得很长，甚至导致通讯超时。正确做法是拆分轮询周期：实时性要求高的参数，比如溶解氧、液位，放在短周期任务里；实时性要求低的，比如COD、氨氮，放到长周期任务里。这类水处理案例里通常能看到两个独立通讯轮询函数，就是这个原因。

4.3 触摸屏变量与PLC地址的映射

触摸屏工程说到底是变量的映射问题。你画了一个液位显示框，框绑定的变量必须指向PLC里存储液位值的数据块地址；你放了一个泵启动按钮，按钮的“按下”事件必须对应PLC程序里那个泵的启动位。

这套案例的触摸屏工程里，变量映射有一个清晰的规律：画面上的显示值，直接对应PLC的DB块地址；画面上的操作按钮，对应PLC程序里的保持性位或者脉冲位；画面上的报警文本，对应PLC里的报警字或位。

举个例子，提升泵房画面上的“集水井液位”显示框，绑定的是DB100.DBD0这个实数地址，也就是程序里模拟量转换后的工程值；1号泵的“运行”指示灯，绑定的是DB200.DBX0.0，也就是泵运行反馈的中间变量。

理解了这层映射关系，再去看触摸屏和PLC程序，就不会觉得它们是两个独立的东西，本质上是同一份数据的两种展示方式。

5. 触摸屏画面的操作员思维

5.1 画面层级：总览、分系统、单设备

我在看这套水处理程序的触摸屏工程时，特别注意它的画面层级设计，这套设计思路值得单独拿出来讲。

总览画面：显示整条工艺链的简化流程图，从进水到出水，主要设备的运行状态用颜色区分，关键液位、流量、溶解氧数据全部以数值或棒图形式呈现。操作员站在画面前，五秒内能判断全厂运行是否正常。

分系统画面：点击总览上的某个单元，进入对应的分系统画面。提升泵房画面、生化池画面、加药间画面、出水监测画面等。每个画面只显示本系统的设备与仪表，并配有启停按钮、手自动切换、参数设定框。

单设备操作画面：用于特定设备的详细操作和参数设置，比如PID调节面板、泵轮换参数、计量泵频率设定。

这种三层结构的好处是信息不过载。操作员平时盯总览，出现问题迅速下钻到具体分系统，再下钻到单设备做干预。初学者在组态触摸屏时容易犯的毛病是贪多：想在一张画面上把所有信息都放进去，结果画面拥挤，现场操作员根本没法用。

5.2 报警与趋势：运维最关心的两个页面

操作员日常最依赖的其实是两个页面：报警页面和趋势页面。

报警页面在污水处理项目里作用尤其明显。污水设备二十四小时不停机，夜班人员少，异常不可能全部靠人眼发现。规范的做法是：把液位超限、泵故障、仪表断线、通讯超时、溶解氧异常等关键事件全部组态进报警系统，并区分报警等级。严重报警要声音提示和闪烁，普通报警只在列表里记录。

我在这个案例的报警画面里看到过一些值得学习的细节：报警文本写的是人话而不是代码，比如“1号提升泵故障跳闸”，而不是“MCC1-FAULT”；每条报警带时间戳，支持确认和复位操作；报警历史记录归档到触摸屏存储卡里，方便事后追溯。

趋势曲线在调试阶段的意义比运行阶段更大。通过趋势画面，你可以看到液位变化曲线、溶解氧响应曲线、泵启停状态变化。PID参数整定、轮泵周期设置是否合理，看一段时间趋势图就一目了然。触摸屏自带的趋势控件用起来很简单，关键是选对变量、设好采样周期，并保存足够长度的历史数据。

6. 调试现场真正踩过的几个坑

6.1 泵的频繁启停与轮换逻辑

调试这套提升泵程序时，我第一次写好液位联锁，全自动运行不到半小时就发现：泵启停次数异常频繁。

原因并不复杂：集水井来水波动大，液位在设定阈值附近反复穿越，程序里又没有加延时确认，导致泵一会儿开一会儿停。后来在联锁判断里增加了“持续5秒确认”逻辑，并且把启动阈值和停止阈值拉开了死区距离，问题才消失。

轮换逻辑也要注意。有些初学者把轮换写成“运行时间超过8小时就切换到另一台泵”，表面看着合理，实际运行中可能出现切换瞬间工艺水量不足或者集水井液位过高的情况。正确做法是加入条件判断：只允许在液位处于安全区间时切换泵，切换时先启动备用泵，确认运行正常后再停止原泵。这套顺序不能搞反，否则会出现两分钟真空期，池子液位猛涨。

6.2 模拟量干扰与量程错位

污水站变频器多，电缆敷设密集，模拟量信号受干扰是大概率事件。我在这类项目里处理过的典型故障是：液位信号在无波动时刻出现上下乱跳，排查后发现是液位计信号电缆与变频器输出电缆在同一个桥架里并行走线造成的。

解决办法不外乎几种：模拟量信号用屏蔽电缆且屏蔽层单端接地；信号电缆单独走桥架，与动力电缆保持距离；PLC侧加信号隔离器。这几点在图纸设计阶段就要考虑，等调试阶段再整改，成本成倍上升。

量程错位问题更要命。某台污泥浓度计的安装量程是0～10000mg/L，点表里也标了，但程序里写成了0～1000mg/L。结果就是画面显示污泥浓度永远100%超量程，加药系统拿着错误数据做比例调节，把药量调得失控。这类问题靠程序调试很难发现，必须在联动调试前把点表里的量程范围、程序里的换算参数、触摸屏里的显示范围三处逐一核对。

6.3 通讯断线时的默认值陷阱

Modbus通讯有个软故障最坑人：从站仪表掉线后，PLC读到的寄存器数据不再更新，但程序里还保留着最后一次成功读到的值。如果这段数据参与联锁控制，比如用COD读数决定是否开启排放阀，就可能造成严重事故。

规范做法是在通讯轮询里增加故障标志。某一次轮询超时或返回错误码，立刻把对应的数据有效性位清零；控制逻辑里判断该有效性位，如果无效则进入安全状态。比如仪表断线时，溶解氧PID自动切回手动模式，鼓风机频率保持当前值，同时报警提示操作员介入。故障恢复后，延时确认稳定一段时间再切换回自动模式。

这套处理思路在案例程序的通讯功能块中通常能看到雏形，但很多简化案例会省略故障恢复逻辑。我建议学习者在自己的复现练习中，一定要后补这一段，因为这才是工程应用和实验室作业的本质区别。

7. 用这份案例完成一次自我复现学习

7.1 复现三阶段：仿结构、抄逻辑、改参数

拿到一套完整案例，最高效的学习方式是分三个阶段复现。

第一阶段，按原结构把程序块全部建一遍，不做任何设计，单纯照着抄。这个阶段的核心目的是熟悉S7-1200的工程环境、块类型选择、变量表组织方式，体感上是“用自己的手打了一遍代码”。

第二阶段，把点表里的信号和程序里的地址一一对应，给自己讲清楚“为什么这个信号要放在这个数据块”“为什么这台泵用FC不用FB”。这个阶段不要只盯着梯形图，要对着工艺流程图，用嘴把整条工艺链的控制逻辑复述一遍，讲不顺的地方就是没吃透的地方。

第三阶段，修改关键参数，比如把液位死区从0.5米改成0.3米，或者把轮换周期从8小时改成12小时，然后通过仿真或现场观察效果。这一步能让你真正理解每个参数在系统里扮演的角色。改参数时留好记录，改一个测一个，别为了多改几个而忽略观察周期。

7.2 仿真环境下的验证技巧

没有实际设备的情况下，博途自带的PLCSIM可以做大部分逻辑验证。比如把液位模拟量信号做成一个缓慢变化的功能块，观察泵的启停顺序和轮换是否符合预期。

仿真验证有一个优势是现场不具备的：可以刻意制造故障。比如把某个泵的运行反馈强制断开，看程序会不会报故障；把模拟量原始值强制拉到0，看断线判断代码是否生效；把Modbus从站地址改错，看通讯轮询是否报超时。这些故障注入练习，接线现场反而没条件反复做。

7.3 从水处理案例中提炼的通用方法论

把这套水处理程序的思路抽象出来，你会发现它完全可以迁移到其他工艺场景：

分段处理：按工艺单元划分程序块，块与块之间用明确的DB地址传递数据，不交叉访问。

联锁优先：控制逻辑高优先处理安全联锁，其次是手自动切换，最后才是自动控制策略。

数据与逻辑分离：模拟量工程转换、通讯数据解析这类任务，尽量独立成函数，控制逻辑只消费处理后的数据，不直接读原始寄存器。

参数外置：死区、延时、轮换周期、PID参数全部存放在数据块里，方便调试时在线修改。培训资料和毕业设计里常见的“常数直接写在比较指令里”的做法，工程现场是大忌。

这几点方法论的价值，比记某一个指令怎么用要重要得多。指令查手册就会，工程思路必须靠完整项目来锤炼。

说实话，看完这套水处理案例，我又把调过的几个污水项目资料翻出来对比了一遍。几乎每一处看似“多余”的程序段，都能在现场找到它存在的理由。那层“原来如此”的通透感，是单纯刷视频教程完全带不来的。

最后给个建议：不管你是刚学PLC的程序员，还是做水处理工艺的技术员，都值得找一套包含点位表和画面的完整案例，从头到尾走一遍。第一次看不懂没关系，先梳流程，再对点表，最后啃程序，每看一遍都会有新收获。技术这东西，很多瓶颈不是缺资料，而是缺一份能让你把前后逻辑串起来的完整参照物。这案例，就是那份参照物。