企业官网建设流程全解析

很多刚入行自动化或者从其它行业转来做水处理的工程师，都会有一个共同的困惑：PLC的Demo程序看了不少，指令也都会用，但一拿到真实项目就不知道从哪里下手。梯形图能看懂，但不知道为什么要这样分段；变量表能填，但不知道点表背后的信号逻辑。我前阵子整理了一套某市政污水厂的完整程序包，包含S7-1200的PLC程序、通讯点表、触摸屏组态工程，反复翻了几遍之后最大的感受是：这确实是学习污水处理最合适的一套入门到进阶的实战样本，因为它不是教学示例，而是一个能跑现场的真实项目。

这套程序的价值不在于用了多高级的指令，而在于它完整展示了从工艺逻辑到设备控制、从通讯协议到上位机交互的整个链路。我今天就把这套程序里最值得研究的几个部分拆开来讲，包括为什么S7-1200在这种中小型污水站项目里这么常见、程序怎么分层才便于维护、通讯点表到底怎么读、触摸屏组态和PLC变量是怎么联动的，以及拿到类似项目源码后应该用什么顺序去消化它。

1. 污水处理不是想象中那么复杂：先把工艺和控制对象理清楚

我见过不少人拿到程序包之后直接打开OB1开始看梯形图，结果看了两个小时脑袋还是乱的。这是典型的思路问题。污水处理的PLC程序，本质上就是一整套"根据液位、时间、流量等信号，去启停泵和阀、控制鼓风机和加药泵"的逻辑。如果你不了解背后的工艺顺序，程序就是在看天书。

1.1 这套项目里共有的几段核心工艺

以这套1200程序对应的工艺为例，典型的生活污水或工业废水处理会分成这么几个环节：

• 预处理段：粗格栅、提升泵房、细格栅、沉砂池。作用是把大颗粒杂物和砂石去掉，保护后面的设备。控制上主要是格栅的自动清污、提升泵的轮换运行。
• 生化处理段：这是最核心的部分，常见的是AAO工艺（厌氧-缺氧-好氧）或者SBR、氧化沟等。控制上涉及曝气风机、回流泵、污泥回流、加药除磷等。
• 深度处理段：加药混凝、沉淀、过滤或者膜处理。主要控制加药泵和排泥阀。
• 污泥处理段：污泥浓缩脱水，控制脱水机、加药装置和污泥泵。

这套程序在结构上并没有把上面所有环节都塞进一个PLC里，但它把泵、阀、风机的控制方式展示得特别清楚。我建议你拿到程序后第一件事不是看代码，而是把工艺流程图（P&ID或者简单的水量流向图）找出来，对照程序里的每个FC或FB去理解"这一块逻辑管的是哪台设备、服务哪个工艺目的"。

1.2 PLC在这个项目里的控制边界

值得注意的一个点是，这套项目里的S7-1200承担的是电控层核心的角色，但并没有去做闭环曝气控制之类的复杂运算。它会根据溶解氧仪表的4-20mA信号去判断要不要增开一台风机，但PID调节或者模糊控制那类东西，在大部分中小型污水站里其实用得很少，更多是依靠时间轮换和人工经验的叠加。

这也引出一个对初学者特别友好的事实：污水处理项目的PLC代码，80%以上都是开关量和模拟量的组合逻辑，真正的算法占比很低。你需要掌握的是如何把工艺逻辑转化成可靠的启停、保护和联锁程序，而不是沉迷于花哨的指令。这套1200程序里我甚至没有看到什么复杂的SCL或者高级指令，基本就是LD（梯形图）为主，偶尔用一下MOVE、比较指令、定时器，但整个程序非常稳定，这就是实战项目和教学项目的本质区别。

2. 为什么这个案例用的是S7-1200：中小型水处理的硬件选型逻辑

标题里明确提到了这是一套西门子S7-1200PLC程序。很多初学者会问：污水处理这么"大"的工程，为什么不用S7-1500或者S7-300/400？这里其实有一个很现实的项目分级问题。

2.1 什么样规模的污水站会选择1200

S7-1200定位是中小型PLC，但在水处理行业里它的出现频率远超想象。原因很直接：

• 一套日处理量几千吨到两三万吨的乡镇污水处理厂，I/O点数一般在几十到两百点左右，模拟量主要是液位、流量、pH、DO、MLSS这类信号，1200的扩展能力完全足够。
• 1200支持以太网通讯，做触摸屏组态直接用网线连就行，比老一代的MPI或DP通讯方便太多。
• 成本优势和供货周期在中小型项目里很重要，很多总包方和设计院在做方案时，只要点位够用，首选就是1200。

相应地，如果是几万吨甚至十几万吨以上的大型市政污水厂，点位上千，还要做复杂的冗余和大型SCADA系统，这时候才会看到1500或者更大型的冗余系统。这套程序对应的是中小型项目规模，所以1200是合理且非常经典的选择。

2.2 硬件配置里容易被忽略的几个细节

在看这套程序的同时，我去翻了对应的硬件组态配置，有好几个点值得你注意：

• CPU型号选择：根据程序里CPU的订货号，能看出项目方选的CPU具体是1214C还是1215C，两者的I/O点数和通讯接口数量不同。如果你想把程序下载到自己电脑里的仿真或实体PLC上运行，CPU型号必须匹配或向上兼容。
• 扩展模块：水处理项目里模拟量特别多，液位计、流量计、pH计基本都是4-20mA信号，所以程序中通常配置了SM1231 AI模块或者使用1215C自带的AI通道。点表里如果出现"AI0、AI1、AI2..."这样的地址，就是这些模拟量通道的映射。
• 通讯处理器：不少污水站在线仪表（比如COD、氨氮分析仪）走的是RS485的Modbus协议，这时可能需要CM1241 RS485模块，或者通过1200集成的RS485口做Modbus RTU主站。这套程序里有点表，说明上位机或者触摸屏通过以太网和PLC通讯，而仪表层的Modbus协议很可能是在PLC里通过MB_COMM_LOAD和MB_MASTER指令实现的。

这里有一个容易被忽略的实操细节：在很多实际项目里，1200的IP地址和触摸屏、上位机的IP必须在一个网段，并且PLC里往往需要设置一个固定的IP地址，而不是程序下载时临时分配的地址。如果现场调试时触摸屏连不上，第一件事就是去"设备组态-属性-以太网地址"里核对IP和子网掩码，而不是去改程序逻辑。

2.3 程序存储和数据类型的大致套路

再往细里说一点。在博途（TIA Portal）里打开这套项目时会看到，程序块的命名是有规律的。有人喜欢用中文名，有人喜欢用类似"FC100_Pump"这样的英文前缀，但这套程序块名称命名得比较规范。你会在程序里看到：

• 数据块（DB）按"设备单元"划分，比如泵房DB、生化池DB、加药间DB，里面存放对应设备的启停状态、手自动模式、运行时间、故障字等。
• 全局变量表（PLC tags）按信号类型分，DI、DO、AI、AO，信号名和点表里的中文描述一一对应。
• FC（功能）主要做逻辑运算和数据处理，FB（功能块）通常用于需要对多次调用进行数据保持的对象，比如多台水泵的轮换控制。

这种"数据集中、逻辑分层"的做法，是中型水处理项目里最标准的组织方式。一个人维护几年后依然能快速上手修改，靠的就是这种清晰的结构，而不是临场发挥的代码。

3. 通讯点表到底该怎么读：从地址映射到Modbus协议的实操拆解

通讯点表这个文件，可能是这套资料里最被低估的宝藏。初学者往往觉得点表就是一张"像Excel一样的地址对照表"，扫一眼就放着不管了。实际上，点表是一张能够还原整个项目信号关系的图，它同时包含了硬接线的I/O信号和走通讯协议的软信号。

3.1 点表里那些列的真正含义

典型的通讯点表通常包含这么几列信息：

上面的示例只是帮没有经验的朋友建立一个直观印象。真实项目里的点表数据量和字段会更多，但核心逻辑是一样的。你在读点表时，最有价值的一项工作，是从"地址列"推断出这台设备的信号被PLC放到了什么存储区域。

比如"MW100"这种地址，意味着整型（16位）数据存在M100开始的字里。如果是"MD104"，就是32位实数（REAL）。触摸屏或者上位机如果要读取这个数据，引用的变量名必须指向同一地址区域，否则通讯就会出错。

3.2 硬接线信号和通讯信号怎么区分

点表里如果是DI/DO/AI/AO，通常对应硬接线到PLC扩展模块上的信号。例如一台变频器的"运行反馈"是DI信号，接入SM1221模块某个输入点，那么点表地址可能是"I0.3"或者"I8.0"，取决于模块安装的槽位。

而"通讯信号"则不同。它的来源是别的设备通过通讯协议（最常见是Modbus）发给PLC的寄存器数据，在点表里一般标注成类似"MW200"这样的M区地址。PLC里的Modbus通讯指令会把从站设备返回的数据写到M区或DB区，然后再由程序逻辑去处理。

这套程序里比较典型的一个例子是：COD在线分析仪通过Modbus RTU把实时测量值写到PLC的某段寄存器里，点表里把起始地址、数据长度、数据类型、字节序都标注了出来。如果你自己动手写过Modbus通讯指令，你就知道收到数据后如果"破解"不对，数据就是乱的，这在点表里会写明高低字节顺序或者交换方式。

3.3 一个实际的通讯排查思路

我曾在现场遇到过一个问题：触摸屏上液位显示数值不停跳变，但实际水池液位没变。排查的第一步就是看PLC程序里的模拟量通道是否正常（从现场仪表传到PLC的4-20mA是否在量程内），第二步就是看点表里这个液位对应的地址有没有被别的逻辑重复写入。后来发现是通讯点表里把两个不同的仪表地址映射到了同一段M区，导致数据被互相覆盖。这个案例说明：点表不仅仅是"看"的，它也是排查通讯故障的第一手依据。

所以在学习这套程序时，我强烈建议你做一个动作：在点表里挑出三个典型的信号——一个DI（泵状态）、一个AI（液位）、一个Modbus通讯寄存器（比如在线仪表数据），然后去PLC程序里搜索这些地址。你会发现它们分别出现在硬件中断、扫描循环和通讯背景数据块中，这种交叉验证能让你迅速建立对整套系统的立体感。

4. 触摸屏组态的核心设计思路：画面分层与数据绑定的门道

标题里提到"触摸屏包含了组..."，虽然没有说完，但结合常见的水处理项目组成，可以合理推断这套资料里一定含有触摸屏组态工程文件。触摸屏（HMI）在中小型污水站里承担的角色，可不只是"看数据"那么简单，它往往是操作员日常控制设备的唯一入口，所以触摸屏画面怎么组织，直接关系到现场操作的效率和安全性。

4.1 画面结构要跟着工艺走，而不是跟着PLC变量走

好的触摸屏画面，第一原则是让操作员在不需要懂PLC的情况下就能看懂整个工艺。这台触摸屏的组态工程里，画面层级一般都按这样来分：

• 首层：总览画面。显示全厂工艺流程、各池液位、总进水量、总出水量、主要设备运行状态。操作员扫一眼就能知道全厂有没有异常。
• 二层：工段画面。按预处理、生化池、加药间、污泥脱水间等分画布，操作员需要具体操作某台泵或者看某一段的仪表数据时就进到对应画面。
• 三层：设备操作面板。比如"提升泵1号操作面板"，里面有手自动切换、启动停止、当前电流、频率设定、故障复位、运行时间累计等。

这个分层逻辑和水处理工艺流程是严格对应的。反过来说，如果你看到一套HMI工程把所有变量全部堆在一张画布上，那基本能断定这个项目要么很小、要么组态工程师缺乏工艺理解。

4.2 触摸屏变量和PLC地址是怎么绑定的

触摸屏和S7-1200之间通过以太网通讯后，HMI里定义的每个变量都必须指向PLC的一个地址。最常见的绑定方式有两种：

• 直接指向I/Q/M地址：比如"HMI_启动1号泵"变量连接PLC的M0.0，那这个按钮按下时，PLC的M0.0就被置为1。
• 指向DB数据块变量：HMI变量连接的是PLC的某个DB块（如"Pump_DB".StartCmd），在触摸屏组态里会定义一个"数据块变量"，通过绝对寻址方式访问DB内偏移量。

这套触摸屏程序里应该大量使用了第二种方式。好处是变量名有语义，调试方便，程序移植时不容易乱。但要注意一点：DB块访问需要开启"非优化访问"或者在HMI和PLC之间使用S7通讯时保持地址一致性。博途中有一些项目为了严谨，会启用HMI变量在PLC侧的"保持性"和"可见性"设置，这块细节在导入HMI工程后可以在变量管理器里看到。

4.3 报警和操作记录：HMI里容易被忽略但最关键的内容

真正做水处理的现场，操作员对触摸屏的核心需求其实是两类：一是设备的手动操作，二是报警信息。这台触摸屏组态里应该包含了报警窗口和报警记录：

• 报警分类：一般都会分"故障报警"和"提示信息"。故障报警比如"1号提升泵过载"，提示信息比如"液位到达高报警值"。在HMI组态里，报警变量可以配置为BOOL型触发，也可以配置为数值上下限触发。
• 操作记录：HMI可以记录操作员按下了哪些按钮、什么时间操作的，这个功能常被称为"事件记录"。出安全事故或者责任纠纷时，这套记录是非常关键的追溯依据。

看这套触摸屏工程时，千万不要只看画面好不好看，而要去思考每个画面的跳转逻辑和变量联动是否符合现场逻辑。比如：点击"自动模式"按钮时，HMI把什么变量置位？PLC程序里响应这个变量后，手自动状态切换是否有保护？如果操作员在手动状态下误触发自动启动命令，程序会不会阻断？这些都是HMI和PLC联调时需要想清楚的问题。

5. 拿到这套程序后，按什么顺序学习最高效

最后这部分，主要写给拿到程序包后有点无从下手的朋友。我自己的习惯是：不要一来就深挖某一行梯形图，而是按照下面这个顺序去啃，能少走很多弯路。

5.1 先复现项目结构

用博途打开项目后，第一件事是打开"项目树"，逐个看：

• PLC变量表（Tags）：把所有变量名的命名规律过一遍。
• 程序块列表：看有哪些OB、FC、FB、DB。水处理项目里OB1是主程序，OB100是初始化（暖启动），OB35是循环中断（常用来做定时采样），OB10/OB20这类时间中断可能用不到，但看有没有配置。
• 工艺对象：看有没有PID或轴工艺对象配置，水处理里PID可能用于曝气或者加药，但实际启用与否要看代码。

做这一步的目的，是建立"我这个项目到底由哪些零件组成"的全局认知。

5.2 按"数据流"而不是"程序段"顺序去读

很多教学书教你是按照程序逐段往下读，但在真实项目里，程序块之间会互相跳转、调用，按顺序读会非常痛苦。我建议你按数据流来：

1. 输入信号（模拟量、DI）是怎样被采集和量程转换的。
2. 量程转换后的数值到哪里去了（比较器？PID？报警逻辑？）。
3. 处理后的结果如何驱动输出（DO、AO）或者改变设备状态。
4. 设备状态如何反馈给HMI和报警系统。

这套程序里的模拟量处理通常是先经过FC105这样的模块做标定（把0-27648转换为工程单位），如果程序里没有用FC105而是手动写的缩放逻辑，那反而值得多看一眼，因为手动缩放里藏着量程上限下限的巧妙调整办法。

5.3 动手修改一处小逻辑，验证自己的理解

模拟也好，实体PLC也好，学编程唯一有效的验证方法就是改。我建议你在这个项目里找一个相对简单的逻辑做实验，比如：

• 把某台泵的启动延时从5秒改成8秒，观察程序里需要改哪些定时器的预设值。
• 增加一条新的报警逻辑，比如"进水流量超过异常值"，看你怎么添加比较指令和报警位。
• 修改HMI的一个按钮，让它除了置位启动命令之外，同时复位故障字。

做完这三件事，你对整套程序的理解深度会远超"读一遍"。

5.4 摸清通讯点表里"地址规划"的套路

最后建议你把通讯点表当成一份独立的技术文档来学习。小到如何规划Modbus寄存器地址段，大到如何统一PLC与HMI的命名规则，这套点表都会给你一个可参考的模板。将来你自己做项目时，照着这个模板去画点表、定地址、做联调，能省下太多撕扯的时间。

在这个行业里，水处理PLC项目其实是最典型的"经验积累型"领域。工艺变化不大，控制要求稳定可靠，真正拉开差距的是你对设备的理解深度、对通讯链路的掌握和对现场故障的预见性。这套包含1200PLC程序和通讯点表的真实项目案例，恰好把这几个维度都覆盖到了。

最后再分享一个个人体会：我后来维护的好几个污水站项目，控制逻辑都能从这套程序里找到影子。并不是说照抄，而是它的架构方式——把工艺理解编译成数据结构、把设备控制拆解成独立功能块、把通讯和交互单独切开——成了我脑子里最稳定的"认知脚手架"。你也一样，拿到这套程序后，别急着收藏吃灰，按我说的顺序过一遍，最好再找一台PLC实际跑一跑，那种从点表到画面、从信号到逻辑全部串起来的感觉，才是这行最有成就感的时候。