企业官网建设流程全解析

去年冬天接手了一个换热站改造项目，控制柜里还是老式的继电器加手动操作，每到寒潮降温，值班电话就没停过——不是二次网温度掉得厉害，就是补水泵烧了。后来用西门子S7-1200把那套系统重新搭了一遍，从仪表选型、IO分配、程序编写到上位机调试，整个过程走下来，踩了不少坑，也攒了不少可以直接拿回去用的经验。这篇就把整个程序搭建的思路、关键代码逻辑和调试心得整理出来，给准备做换热站自控或者正在跟这类项目的同行做个参考。

1. 换热站自控到底在控什么：把需求写在程序前面

很多刚接触换热站项目的朋友容易犯一个毛病，上来就打开TIA Portal开始拖PLC变量，还没搞清楚现场工艺就急着写代码。我自己的经验是，程序写得顺不顺、调试省不省力，七成取决于动手前有没有把控制需求拆透。换热站自动化不是简单地把几个泵接上变频器就算完事，它要解决的是热网平衡、舒适度、能耗和设备寿命这几件事的交叉问题。

1.1 换热站在供热系统中的角色

集中供热系统里，热源厂生产高温热水（一次网），居民楼里的暖气走的是低温热水（二次网），换热站就是这两张网之间的“转换器”。一次网的热水经过板式换热器，把热量传给二次网，二次网通过循环泵把热水送到各楼栋。这套系统里最核心的控制变量有两个：一是二次供水温度，决定末端暖气够不够热；二是供回水压差，决定循环泵转速和水力平衡。剩下的补水定压、热量计量、安全联锁，都是围绕这两个核心变量展开的。

换热站自控系统要做的，就是根据室外温度、二次回水温度、用户需求等信号，自动调节一次网侧的电动调节阀开度，控制循环泵和补水泵的运行，让二次供水温度稳定在设定值附近。说直白点，就是“按需供热”——天热了少烧点，天冷了多放点，而不是像以前那样人工凭感觉调阀门。

1.2 换热站的典型控制对象与控制目标

我做一个项目之前，会先列一张控制对象清单，写清楚每个对象的类型、控制方式和安全约束。以某城区的供热换热站为例，典型的控制点包括：

控制目标说起来很简单：二次供水温度稳定在设定值±1℃以内，供回水压差稳定，补水系统保持定压，系统端具备自动/手动切换能力。但真正做起来就会遇到各种各样的工程问题——比如温度设定值不是固定不变的，要随室外温度做补偿曲线；循环泵不能只做PID调速，还要考虑最低频率防喘振；补水泵的启停逻辑里必须加延时，否则系统刚失压就补、补完就停，水泵一天启停上百次直接报废。

1.3 影响程序方案的三个关键设计决策

换热站自控方案的差异，主要看三个决策点：

第一，是否要做分时供热。很多换热站白天和夜间的供热需求差别很大，如果客户有分时控制的要求，程序里就要加时间中断（OB10），按照工作日/周末、白天/夜间切换温度设定值。这个功能看起来不难，但涉及设定值平滑切换，做不好会导致温度波动大。

第二，循环泵用压差控制还是温差控制。北方常见的做法是供回水压差控制，稳定且对管网适应性强；节能角度有人会选温差控制（二次供水与回水温差恒定），但对负荷变化反应滞后，小温差时容易触发频率下限。这两个方案对应不同的PID回路结构，写在前面比写完再改省事得多。

第三，手动与自动的无扰切换。换热站现场经常需要手动操作——调试阶段、设备检修、极端天气下的人工干预都离不开手动模式。但手动/自动切换如果没做无扰处理，PID输出会瞬间跳变，调节阀猛然全开或全关，轻则系统震荡，重则水锤损坏设备。我见过一个站就是切换瞬间阀门大动作，把板换垫片都冲漏了。所以程序里必须做手/自动切换时的输出缓冲。

2. 基于S7-1200的硬件选型与IO分配：不多花一分钱的组态方案

S7-1200做换热站项目，硬件上绕不开CPU选型、模拟量模块、通讯方案这三件事。很多项目预算有限，业主恨不得每一块钱都花在刀刃上，但硬件省过头了，后面调试能把你折磨疯。

2.1 为什么选S7-1200而不是200 SMART或1500

先说结论：中小型换热站、泵站项目，S7-1200是性价比和性能之间的甜点位。200 SMART虽说价格更低，但模拟量精度、程序容量、以太网通讯能力都偏弱，做两个PID回路再加一堆逻辑就捉襟见肘了，而且后期接上位机还得靠Modbus转以太网模块，徒增故障点。1500当然性能更强，但PLC本体加模块的成本够买一两台变频器了，用在换热站这种点数三四十个的项目上确实浪费。

S7-1200的1214C DC/DC/DC加上两块模拟量输入模块，差不多能覆盖一个标准换热站的全部IO。CPU本身自带以太网口，直连触摸屏或上位机，连转换器都省了。要注意的是选型时要确认CPU固件版本和TIA Portal软件版本是否匹配，我遇到过固件版本太新，博途版本不支持导致无法下载程序的尴尬事。

2.2 标准换热站的IO清单与硬件配置

下面这份配置表，是我在一个典型换热站项目里的实际配置，可以当参考模板用：

IO分配上，我的惯例是数字量输入预留20%冗余，模拟量输入只占模块的80%容量，避免后期加测点没地方接。一个换热站典型IO分配大概是：DI 14点左右（手自动切换、泵启停反馈、故障反馈、阀门限位等），DO 6-8点（泵接触器、电磁阀、报警灯），AI 12点左右（一次供回水温度、二次供回水温度、一次供回水压力、二次回水压力、室外温度、补水流量等），AO 3点左右（调节阀、循环泵、补水泵）。

2.3 温度采集的抗干扰与防呆设计

换热站现场环境其实不算太恶劣，但要命的干扰源集中在变频器电缆和动力电缆上。PT100测温如果用了两线制，信号线跟动力电缆走同一个桥架的话，到了PLC里温度能差出两三度，PID系统跟着来回抖。所以温度信号我建议全部用带屏蔽的三线制或四线制PT100，屏蔽层单端接地。如果现场仪表用温度变送器输出4-20mA，模拟量模块侧必须并隔离器，成本也就一两百块一个，省下的是调试时间。

还有一个防呆设计——模拟量通道的量程设置一定要在硬件组态里跟实际变送器量程一一对应。SM1231模块每通道可以单独设置测量范围，比如PT100的-50℃到200℃、4-20mA的0到1.6MPa等。最怕的就是程序里算好了工程量，结果硬件组态没改默认量程，温度显示翻倍，一查硬件发现通道还停在0-27648的原始值对应100℃量程。

3. 程序组织块与功能划分：让现场维护的人看得懂你的代码

S7-1200程序搭建的骨架是“组织块（OB）+函数块（FB/FC）+全局数据块（DB）”。代码能不能长期稳定运行、现场维护的人能不能看得懂，核心就看这一层怎么规划。模块化不是写给人看的漂亮架子，它是故障定位最快的路径。

3.1 OB组织块的合理布局

一个标准的换热站程序，至少需要以下几类组织块：

• OB1（主循环）：处理设备运行主逻辑，包括泵组控制、阀门控制、报警汇总。
• OB10（时间中断）：分时供热切换、整点记录、或定时轮询数据。
• OB35（循环中断）：固定周期执行PID——我用的是100ms周期，即10Hz采样频率，对换热站这种惯性大的温度回路已经绰绰有余。
• OB100（启动组织块）：初始化全局DB里的默认参数，例如温度设定初始值、PID参数开机装载。
• OB82（诊断中断）：扩展IO模块报错时触发诊断报警，把报警信息写入专门的DB供上位机读取。

我见过有人把PID放在OB35里，又把循环泵控制也放在OB35里，结果一个程序周期里又是PID又是冲洗逻辑，循环中断被拖到500ms以上。正确做法是OB35里只做温度PID和压差PID的计算，把计算结果存在DB里，OB1再去读取并执行输出逻辑。

3.2 功能块的模块化方案

程序内部建议按设备功能拆成若干FB，每个FB对应一台设备或一类控制逻辑。比如：

每个FB的内部逻辑保持只跟自己的设备相关，设备间的联锁关系放在OB1里协调。这套结构的最大好处是，调试时不至于改一个水泵逻辑结果把PID也带崩了。

我单独提一下背景DB里的数据管理。S7-1200的FB背景DB默认是保持型的，但要注意——如果某个参数（比如PID设定值）不想在断电后丢失，DB变量的“保持性”属性必须设置成“保持”。不设的话，PLC一断电重启，所有设定值全部回默认，半夜停电再来电，换热站按错误参数运行一晚上，后果可想。初始化OB100里除了装默认参数，还要把需要复位的标志位清零，比如故障锁存、手自动切换记忆等。

3.3 手自动切换与输出无扰设计

手自动切换这个坑值得专门拿出来说。程序里要区分两层手自动：一层是PLC层面的手自动（触摸屏上切换），另一层是柜面物理开关的手自动（就地/远程）。两层之间用硬接线DI做最终裁决，柜面开关在“就地”位置时，PLC必须无条件放弃对设备的自动控制权，这是安全底线。

软件层面的无扰切换，我的做法是：PID回路专门设一个状态字，切换前把PID输出值写入手动给定值，切到自动后再从手动给定值继续PID计算。也就是说，切换瞬间调节阀开度保持原位，然后PID在这个基础上慢慢调整。这比从0开始重新算要平滑得多。补水泵和循环泵的切换则要注意变频器给定值斜坡——从手动频率切到自动频率给定，我会在PLC里做斜坡函数（例如每100ms变化0.5Hz），防止频率直接跳变导致的水击。

4. 二次供水温度PID与泵组连锁：核心闭环的编写与整定

换热站最关键的当然是温度控制闭环——一次网电动调节阀开度决定换热量，二次供水温度做反馈，这是一个典型的过程控制问题。但只写一个PID回路远远不够，泵组、补水、报警、联锁这些逻辑跟PID回路配合不好，温度控得再准，系统也会出各种幺蛾子。

4.1 PID控制逻辑的实现结构与计算周期

S7-1200自带的PID_Compact指令算是博途里讨喜的指令，它能自动处理手动/自动切换、输出限幅、积分作用和反作用方向，省去很多底层工作量。但再好的指令，如果整定参数不对，照样白搭。

PID块启用前必须先搞清楚控制对象是正作用还是反作用。换热站温度控制是典型的反作用系统：二次供水温度偏高时，要减小调节阀开度（关小节流），降低换热量。PID_Compact里把控制方向配置成“逆”方向（Reverse），否则温度一高阀门反而开大，系统会直接飞掉。这个方向搞错，我见过同行在现场调了一整天，最后发现是方向反了。

控制周期上，温度回路周期选1秒比较稳妥。有些朋友为了“响应快”把PID周期压到100ms，结果温度噪声稍大，调节阀小碎步来回摆动，电动执行器寿命肉眼可见地缩短。要知道电动调节阀本身是个有死区有滞环的机械机构，你给它5Hz的更新频率，它根本跟不上，只会让阀门机构磨损加剧。

PID参数初值方面，以一个一次网调节阀（DN100，4-20mA控制）为例，我的参考起点是：比例增益Kp约0.8-1.2（输出百分比与温度偏差百分比之比），积分时间Ti约120-180秒，微分时间Td设0（不开微分）。温度系统的惯性大，微分容易把噪声放大，初调阶段一律关掉微分。

4.2 室外温度补偿与设定值生成

固定温度设定值只能满足“不出事”，谈不上“供热质量”。规范的换热站程序应该做室外温度补偿曲线——室外温度越低，二次供水温度设定值越高。程序里通常做一个线性插值表：

注意设定值变化时不能直接跳变，要做斜坡限制（比如每分钟最多变化0.5℃），否则PID还没反应过来，温度还没到设定值，输出已经推到上限了。我在程序里专门写了一个斜坡函数：从设定值DB读取目标值，经过斜坡限幅后再送给PID的Setpoint输入。这个细节看着简单，实际有没有斜坡，供热效果区别非常明显。

4.3 循环泵两用一备与压差联锁

循环泵一用一备的核心逻辑是：运行泵故障时自动切到备用泵，备用泵启动前先检查管网压力是否正常，防止空转。变频器控制上，压差PID输出0-100%对应变频器0-50Hz。

这里有几个必须加的安全逻辑：

• 最低频率限制：循环泵变频器下限我一般设25Hz。低于这个频率，水泵扬程不够，管网末端不循环，还会引起泵体过热。压差PID输出不能直接把0%给变频器，要做一个输出下限映射——PID输出0%对应25Hz，100%对应50Hz。
• 变频转工频互锁：如果现场为了赶流量做了工频旁路，程序里必须做MRS双线圈互锁（用中间变量而不是直接驱动输出），防止接触器同时吸合造成短路或水泵过载。
• 低压保护：二次回水压力低于某个绝对值（例如0.15MPa）时强制停泵，防止泵汽蚀。

压差设定值一般0.25-0.35MPa，具体看楼层高度和管网阻力。整定压差PID比温度PID简单——对象惯性小，Kp可以给大点（1.5-2.5），积分时间短一点（30-60秒）。两个PID回路之间其实也有耦合：温度回路动阀门，压差回路也要跟着动泵，两套回路的调节速率如果能错开（温度慢、压差快），系统稳定性会好很多。

4.4 补水泵的延时与防频繁启停

补水泵是设备损耗的大户，绝大多数问题出在启停逻辑太“敏感”。系统里轻微渗漏、压力表波动、管道排气都可能导致压力瞬时下降，补水泵如果一看到低压力就启动，高压力就停，一个晚上可以启停几十次，电机和接触器都扛不住。

我的标准做法是：

1. 压力低于0.10MPa（定压点下限）时开始计时，连续5秒仍低于下限才启动补水泵。
2. 补水泵运行后，压力升到0.15MPa（定压点上限）时停止。
3. 如果补水泵连续运行超过5分钟压力仍没上来，判定系统漏水或补水水源不足，停泵并报“补水超时”故障。
4. 补水泵的启停之间加最小间隔时间（比如60秒），防止压力波动导致的短循环。

补水泵如果也是变频控制的，那逻辑复杂度跟循环泵差不多了，但小型换热站补水泵功率小、定量补就够了，用启停控制加延时逻辑反而更可靠，少了一个变频器故障点。

5. 通信、调试与上线：从TIA仿真到现场运行的最后一公里

程序写得再漂亮，到现场跑不起来也是白搭。换热站调试的坑集中在通信组态和现场信号对接上，这一节说说我用下来的套路。

5.1 触摸屏与上位机的以太网组态

S7-1200最大的优势之一就是原生以太网，不用像200 SMART那样挂Modbus转以太网模块。组态时注意三点：

第一，PLC、触摸屏、上位机必须在同一个网段。常见的坑是工程师笔记本用的网段跟现场不一样，第一次下载程序时下不进去，还以为CPU坏了。下载之前先Ping一下PLC地址，通了再下。

第二，设固定IP而不是DHCP。PLC侧在设备属性里指定IP（例如192.168.0.10），触摸屏设192.168.0.11，上位机设192.168.0.12。别图省事用DHCP，交换机一旦重启，设备IP全变了，全站瞎。

第三，上位机如果选择西门子的WinCC，变量连接用S7协议，在TIA Portal里把变量表导出到WinCC，记得检查数据类型映射——BOOL对应二进制变量，INT对应16位无符号，REAL对应32位浮点，映射错了画面显示乱码。

除了WinCC，也可以用组态软件（比如组态王、力控）走OPC UA或者Modbus TCP。S7-1200做Modbus TCP服务器很方便，调用Modbus_Slave指令就行。如果只是远程看一下数据，用Modbus TCP够用，也能省掉WinCC高昂的授权费用。

5.2 现场调试的标准顺序

我调试换热站程序基本遵循一个固定顺序，这个顺序帮我省掉过大量返工：

1. 先查硬件接线的正确性：用万用表挨个量DI点的通断，模拟量用信号发生器给标准值，逐个校准模块的量程和偏置。这个步骤花1-2小时，后面能省的可能是几天时间。
2. 下载程序，做纯逻辑测试：把变频器、调节阀的AO输出线先断开（或者用模拟量信号发生器代替），在触摸屏上手动操作，验证所有逻辑动作和互锁条件是否正确。做过这一步后，程序里的逻辑错误基本能消灭掉七成。
3. 接上执行机构，开环测试：手动模式下手动控制调节阀开度、变频器频率，观察执行机构是否跟随，方向是否一致。这一步专门暴露接线和模块方向的问题。
4. 闭环投运：全部切自动，先设固定温度设定值，跑半小时看温度曲线，再启用室外补偿曲线和分时控制。
5. 做故障模拟：人为断开传感器信号、给泵加故障信号，验证报警和联锁动作。这一步最被忽视，但恰恰是自动化系统可靠性的一环——平时不出事，一出事就靠这些联锁兜底。

5.3 调试中常遇到的三个疑难杂症

第一个，温度显示正常、PID不调节，调节阀纹丝不动。先别怀疑PID参数，先怀疑AO输出被限幅了。我遇到过AO模块的输出上限配置成了27648的50%，结果PID输出50%以上全被截断，阀门永远只能开一半。检查硬件组态里的输出限幅值，顺便看一下PID的OutputLimit_Upper和Lower。

第二个，两台泵频繁切换。如果程序里做了“运行泵故障切备用泵”，而故障信号是常闭型的——接线没接好导致状态反了——程序就认为泵一直在故障，来回切换。这种问题排查起来先看状态位，把两台泵的反馈信号强制置位看逻辑走向，不用一上来就翻程序。

第三个，PID投运后系统震荡，周期在3-10分钟之间。多半是积分时间太短。温度系统的大惯性决定了积分时间必须给足，我把积分时间加到240秒以后震荡基本消失。震荡不是先加微分，而是先拉长积分时间，这也是我调温度回路最常用的手法。

6. 调试中最容易翻车的环节：我总结的检查清单与避坑笔记

最后这部分算是一个压箱底的总结，不是大道理，全是小细节。每一个都是我真金白银换来的教训，做换热站自控的同行们值得在开工前过一遍。

6.1 现场仪表与执行机构的坑

换热站用的压力变送器、温度变送器，传感器供电方式五花八门。两线制4-20mA变送器需要回路供电，模块的电源要从PLC侧的24V取，但如果PLC电源容量不足，多路变送器同时接入会引起电源电压跌落，模拟量读数集体偏低。规划电源时要给传感器、隔离器、中间继电器、触摸屏都留出足够的功率余量。我的习惯是PLC的24V电源只给PLC和DI点供电，传感器和隔离器单独用一个DC-DC开关电源，两层电源电气隔离，干扰也能分离开。

电动调节阀的选型坑也常见——有些便宜的阀门执行器是开关型（全开全关）而不是调节型（0-100%定位）。买回来接上4-20mA信号，阀门根本不动作，或者动作了也是一卡一卡的。换热站的调节阀必须是带位置反馈的调节型执行器，这条要在采购单里写死。

6.2 程序逻辑层面的隐患清单

这个清单我每次调试验收前都会过一遍，少踩一半的坑。

6.3 与客户交接时我坚持要做的三件事

程序调试完成，不等于项目交付完成。换热站自控有个特殊性——它不只是技术工程，还是运行管理工程。交接时有三件事我几乎每次都坚持做：

第一，给值班员做过一次完整的操作培训，重点是：告警代表什么、什么情况可以复位、什么情况必须现场检查。很多报警灯亮了没人敢动，稍微培训一下，运维效率能翻一倍。

第二，把工程文件、变量表、IO分配表、程序架构说明都整理成一份资料包留档。换热站不是一次性工程，保温改造、换热器清洗、泵更换，都涉及程序微调。资料齐全了，后来人才能改得动你的程序。

第三，把PLC程序做一次归档并设置密码保护，同时把解锁密码单独交给业主的技术负责人。保护是为了防止值班人员误操作删改逻辑，留密码是为了不让后来的维护变成“黑盒”操作。

结尾

做换热站自控这几年下来，我最深的感受是：这套系统的难点不在“自动化”三个字上，而在“可靠”二字。温度控得准不准是水平问题，但联锁动不动、切换顺不顺、报警准不准，是设备能不能长期安全运行的根本问题。程序结构其实就那几大块——PID回路、泵组逻辑、报警联锁、通信组态，难的是每个细节都不凑合。S7-1200在这个场景里的角色很称职，代码量不大、调试工具友好、跟触摸屏和上位机的通信也省心。如果你正在做一个换热站项目，我建议从需求清单开始，把每个控制对象的逻辑先写成文字再说程序的事。等你上电调试那一天，你会感谢自己当初认认真真做的那些表。