1. 这套S7-1200冷热水恒压供水程序到底解决了什么问题做过供水项目的人应该都有同感单体泵房的项目翻来覆去就那几套逻辑真正让人头疼的是多站点、冷热水双系统、恒压供水这种组合需求。泵多、站点多、模式多程序写到最后往往乱成一团调试的时候东改一下西补一下好不容易跑起来换个人维护又看不懂了。前阵子我完成了一套基于西门子S7-1200的程序案例正好覆盖了这种典型场景——四个PLC站、冷热水两套管网、多泵组恒压控制、变频与工频切换、多种程序块分层配置。整套程序不是简单的能启停泵的Demo而是把供水行业里最常见的控制需求做成了可以复用的逻辑框架。这篇文章就是把这套系统的设计思路、程序块配置、关键逻辑和调试心得完整拆开来讲给做供水、暖通、楼宇自控这些方向的朋友一个可参考的模板。不管你是刚接触S7-1200的新手还是已经在做自动化项目但没怎么碰过多站恒压供水的工程师这篇内容都能让你少走不少弯路。我会把为什么这么分站、为什么用这些程序块、恒压PID到底怎么调这些核心问题讲透顺带把我自己踩过的坑也交代清楚。2. 四个PLC站的角色划分与通信架构设计2.1 为什么要用四个PLC站而不是一台大PLC全搞定接到这种冷热水恒压供水需求时很多人第一反应是管他几个泵全部接一台PLC不就行了。硬件成本低、程序也简单一个主站把所有DI/DO/AI/AO都占了逻辑集中在一起调试方便得很。真到了现场你会发现这种方案看着省事实际麻烦事一堆。首先供水站点的物理位置往往分散——冷水泵房、热水泵房、水处理间可能分布在厂区不同区域信号电缆走线几百米是常事。模拟量信号在长距离传输中衰减和干扰的问题很突出压力变送器的4~20mA信号接进PLC之后再怎么滤波也不干净。其次单台PLC的I/O点数、通信带载能力有限泵组一旦上了规模点数迅速吃紧后期扩容完全没有余地。最后是可靠性——供水系统不允许长时间停机一旦单台PLC故障整个供水系统瘫痪维修压力巨大。这套项目里我采用的是四站分布式架构冷水供水主站、冷水供水备站、热水供水主站、热水供水备站。两套系统完全独立各自有主备冗余的关系。正常工作时冷水主站和热水主站分别承担各自系统的控制任务备站处于待机状态通过网络与主站保持数据同步。一旦主站出现故障或者需要停机检修备站可以在最短时间内接管控制权保证供水不中断。2.2 各站的功能定位与硬I/O分配逻辑四个站的硬件配置并不是简单复制功能定位决定了它们的I/O模板选型和点数分配站名核心功能主要I/O类型备注冷水主站冷水泵组启停、PID恒压控制、变频器频率给定DI/DO/AI/AQ模拟量通道较多所有泵的自动/手动模式切换冷水备站与冷水主站数据同步待机热备DI/DO为主模拟量通过网络读取避免重复接传感器热水主站热水泵组控制、回水温度监视、恒压控制DI/DO/AI/AQ需要配置热电阻或温度变送器输入热水备站与热水主站同步待机热备DI/DO为主与控制逻辑互为冗余对了冷水和热水系统我建议用完全独立的PID调节回路。因为冷水管网和热水管网的管径、长度、阀门特性都不一样系统阻尼差别很大共用一套PID参数调出来的效果一定两头都不理想。后面讲到PID整定时我会再细说这个问题。2.3 通信方式的选型为什么选S7-1200之间的以太网通信四站之间数据交互摆在面前的无非就几种选择PROFIBUS DP、PROFINET、S7单边通信、Modbus TCP。以S7-1200为主战平台的时候PROFIBUS需要额外加通信模块成本上不划算PROFINET IO虽然是西门子的主推协议但组态IO设备需要严格设定IP、设备名项目周期紧凑的时候配置起来也挺繁琐。我的做法是直接用S7-1200自带的以太网口做S7通信PUT/GET。S7-1200从固件版本4.0开始就支持PUT/GET通信不用额外硬件只要在组态里把通信伙伴的TSAP、IP地址配好就行。主站作为客户端通过PUT把需要同步的数据泵运行状态、变频器频率、PID输出值、故障字、运行模式等发送到备站的DB块指定地址备站作为服务端被动接收同时通过GET把备站自身的状态取回主站。这里要特别提一个经验通信数据不要直接打散成一堆单独的变量互相引用。最稳妥的做法是每个站规划一个专门用于通信的数据块比如DB_Com_Data把所有需要跨站交换的信息打包成结构体或者数组一次PUT/GET调用就能整块搬运。这样不仅程序界面清爽通信的可靠性也比零散读写高得多——因为S7通信的调用周期、超时判断都更好管理。通信周期的设计也要注意。恒压供水对压力数据的实时性要求比较高但不需要像运动控制那样微秒级同步。我一般把通信调用放在OB1里频率在50~100ms一次完全够用关键数据故障、模式切换则通过硬接线DI点做冗余互锁避免通信延迟导致安全性问题。3. 程序块架构OB、FC、FB、DB到底怎么分工3.1 S7-1200程序块的选型思路玩过S7-300/400的老工程师习惯把所有逻辑往OB1里堆FC满天飞全局DB随便建。这种风格在S7-1200里不是不能跑但是项目一旦上了规模程序的可维护性会变得非常差。S7-1200的程序块体系在博途环境里组织方式比Step7经典版更灵活用好FB的实例数据背景才是S7-1200编程的正确姿势。我在这套项目里做了这么几个层次的划分OB1主组织块调用主控制循环包括泵组控制、通信处理、状态刷新。OB100启动组织块上电初始化包括PID参数装载、DB数据的默认值恢复、通信握手复位。OB35循环中断组织块每100ms执行一次PID运算和模拟量滤波保证调节周期的稳定性。多个FB函数块泵控制逻辑FB、PID恒压FB、报警处理FB、通信同步FB。搭配的多种背景DB每个FB调用都需要自己的背景数据块保存该泵的独立状态。FC函数用于无状态的计算和转换比如工程量转换、模拟量滤波、泵切换逻辑的组合判断。全局DB共享数据块存放系统共用参数、配方数据、跨站通信数据。这个架构的好处在哪里泵和泵之间的控制逻辑完全一样只是I/O地址和参数不同。我用一个FB_Motor_Control反复实例化四次冷水两泵、热水两泵每次调用只需指定不同的背景DB和硬件地址程序量直接减少了一大半。后期加泵扩容同样动作多拖一个背景DB多写一行调用代码仅此而已。3.2 OB100初始化的细节S7-1200的保持性存储器Retain默认只有特定的M区和DB区内容能断电保持但供水项目的很多参数是不允许断电保持在错误状态的。比如泵的工频/变频切换状态、当前泵号选择、故障累积次数等如果断电前正处于2号泵工频运行的状态重新上电后若不清除极有可能导致误动作。我的OB100里做了这几件事把所有非保持型DB变量统一赋值默认值手动模式一律复位为自动模式读取当前泵组配置字比如冷水泵启停顺序、热备切换允许标志到PLC的系统变量区对通信DB进行握手校验握手不成功则强制通信数据清零避免备站接收上一轮残留数据误判主站状态恢复PID参数设定值并强制PID模块为手动模式等待系统启动条件满足后再切入自动。重点说下第3点。如果备站断电重启而主站正常运行主站会持续把数据推给备站但如果备站地址区未初始化接收到的数据时序是乱的可能出现备站认为主站泵全部停止、实则主站正在运行的危险状态。所以我要求备站OB100里必须把通信DB的数据有效性标志位置0直到收到主站连续三次以上有效握手报文才置1通信数据才开始参与逻辑判断。这个三重握手的经验是现场调试调出来的直接写最简单的方式反而容易出事故。3.3 OB35循环中断恒压调节的心脏OB35在S7-1200里的默认中断周期是100ms正适合做PID调节的调用周期。我把压力PID运算和模拟量滤波都放在OB35里而不是OB1中。原因是OB1的执行时间受程序分支影响扫描周期不稳定PID输出会抖动而OB35是固定时间触发运算周期恒定PID的积分项和微分项才不会被时基波动干扰。如果你把PID运算丢进OB1你会发现一个很微妙的问题——泵的变频频率会出现呼吸效应压力刚稳住又开始缓慢波动频率忽高忽低。这就是扫描周期不稳定带来的积分漂移。恒压调节这种带积分环节的闭环控制必须保证PID块以固定周期执行这是教科书里写过但很多人操作时会忽略的关键点。4. 恒压PID控制的原理与参数整定经验4.1 恒压供水的控制闭环PID在其中扮演什么角色说白了恒压供水的目标就是一句话不管用水量怎么变管网压力维持不变。用户端开水龙头管网压力立刻下降PLC通过压力变送器检测到这个偏差PID模块输出一个更高的频率给变频器变频泵提速加大供水量压力回升。用户关水龙头时过程相反频率降下来避免管网超压。这里PID的P比例负责响应当前偏差偏差越大输出变化越猛I积分负责消除稳态误差因为光靠比例总会存在一个静差——压力回不到设定值附近时积分慢慢把输出推上去D微分负责预判趋势压力变化很快时提前踩一脚刹车。供水系统我一般不使用微分或者把微分设得很小因为压力变送器信号本身有噪声和滞后微分放大了这些噪声容易让变频器频率抖起来。4.2 多泵恒压切换逻辑什么时候加泵、什么时候减泵单台变频泵在全速运行仍无法维持设定压力时系统必须投入第二台泵。这个投切逻辑如果傻按PID输出100%就加泵往往是失败的——PID输出频率到50Hz并不代表实际供水能力不足可能只是管网瞬间需求大等1~2秒压力回升后频率自然回落此时若已经加了泵反而造成过度供压、泵反复投切的振荡。实际项目中我采用的判据是双条件延时确认变频泵频率高于46Hz留出4Hz余量防止到达50Hz极限后无调节空间且实际压力低于设定值0.05MPa以上且这两个条件持续10秒钟不消失。减泵逻辑则相反变频泵频率低于28Hz、实际压力高于设定值0.05MPa以上、持续15秒。延时时间加泵短、减泵长目的是鼓励系统先保证供水充足再考虑节能避免泵频繁投切对接触器和机械密封的冲击。还有个关键点加泵时第二台泵直接工频运行变频泵维持PID调节减泵时退出工频泵变频泵重新接管PID输出。这种一变多工的模式在供水行业用得最多结构简单、造价低。如果有条件上多泵全变频当然更好但控制系统复杂度会明显上升。4.3 PID参数整定时我踩过的坑PID参数我这套项目里给了一组基础值P3.5I120s积分时间D0。但请注意这组值只适合我的系统不能直接抄。供水的管网结构千差万别管径、总长、泵型、阀门开度都会影响系统特性。整定PID我的建议流程是这样的先把PID所有作用关掉手动给定变频器固定频率比如35Hz观察压力稳定值逐步加P每加一次给一个小的设定值阶跃比如从0.30MPa改到0.35MPa观察压力超调是否增大P加到压力出现持续振荡频率波动超过±1Hz回退20%~30%作为最终P值加入积分项积分时间从大往小试一般从300s开始观察稳态时是否有缓慢的残余偏差积分时间太小会有周期性波动此时应该回调观察用水量突变时压力的恢复时间目标控制在5~15s内恢复不追求快但追求稳。这类系统的阶跃响应曲线会很明显——注意压力变送器的安装位置对整定影响也非常大变送器离泵出口越近压力反应越快PID越好整定但离用户端越近控制效果越贴近真实用水感受。现场条件允许的话双变送器方案是最稳妥的——泵出口装一个用于PID反馈远端管网装一个用于监控和泵投切判断。4.4 压力变送器的量程与信号滤波处理模拟量滤波这块看着不起眼实际效果巨大。供水管网因泵的叶片频率和管道共振会产生压力脉动这个脉动直接进入PID反馈会造成调节器输出持续小幅振荡时间久了变频器和电机都容易发热。我的做法是在FC_Analog_Filter里做一个一阶惯性滤波y_new y_old * 0.7 x_filtered * 0.3这个系数不是随手拍的。系数越大滤波越平滑但信号滞后也越厉害。0.3对应的时间常数大约0.5~1s既能把大部分脉动削掉又不至于影响PID响应的实时性。如果你用的压力变送器本身响应速度慢比如某些表头式变送器滤波系数可以适当加大到0.5再大压力反馈的实时性就保不住了。关于量程也要提醒一下冷水和热水系统的工作压力区间不同比如冷水系统设0.4MPa热水系统设0.3MPa压力变送器选型时就应该按各自的工作区间选量程不要所有传感器统一用0~1.6MPa量程——量程越大同样AD精度下压力分辨率越差恒压精度就无从谈起。5. 泵组控制逻辑的详细设计启停顺序、互锁、保护5.1 泵的启停顺序与轮换策略供水系统长期只开一台泵会造成这台泵过度磨损而另一台泵长期不转动、轴封卡涩。所以泵组控制必须具备轮换策略。我这套项目里采用了最实用的次数最少优先轮换方式每次加泵时PLC先查找所有泵中累计运行时间最短的一台作为下一台启动泵减泵时则优先停掉累计运行时间最长的一台。这需要在PLC里为每台泵记录运行小时数通过控制器自带时钟功能累加。轮换这块的最关键细节在于泵的启动间隔保护。同一管网内多台泵之间的启动时间必须错开至少30秒否则多台泵同时启动的启动电流叠加会对电网造成较大冲击还可能因为瞬间流量需求暴增导致管网水锤。所以加泵指令发出后其他泵即使满足加泵条件也会被一个加泵间隔计时器挡住等待前一台泵的启动间隔结束。5.2 干运行保护不管什么情况都不能让泵干转水泵最怕的就是缺水空转机械密封瞬间烧毁。供水系统的水源来自水箱或市政管网液位和进水压力都可能异常。我的保护逻辑分成三级第一级是水箱液位低报警——液位低于报警值但还没到危险值系统继续运行发出报警提示操作人员检查进水情况第二级是泵入口压力低联锁——入口压力低于某设定值时例如0.05MPa直接停止当前运行的泵组防止空转第三级是泵出口流量保护——如果入口压力正常但出口流量低于某值且持续一段时间判定为泵内气蚀或进口滤网堵塞停泵并报警。这三级的输出可以接入到FB_Motor_Control的禁止运行输入端只要任何一个保护条件不满足泵就不能启动运行中如果保护条件突然触发泵必须立刻停止。这类紧急停止逻辑我习惯放在独立于主程序循环的快速响应分支里确保即使主程序被其他代码阻塞保护逻辑也能及时执行。5.3 手自动模式切换与现场调试的安全保障程序里必须有完善的手自动切换机制这是现场调试和故障检修的救星。我的设计是每台泵都具备手动/自动/远程三种模式手动模式通过触摸屏或者就地控制箱直接启停PLC只监视状态不干预适合检修自动模式由PID、投切逻辑、轮换策略全权管理正常运行时的状态远程模式接受上位机或中央监控系统的指令适用于集成平台联动。模式切换时最容易出问题的是切换瞬间泵状态突变。比如泵正在自动运行操作员想切到手动如果程序没有处理好切换瞬间泵可能会停反之从手动切自动如果泵本来就处于停止状态但自动逻辑认为需要启动泵会突然启动可能吓到正在泵旁边作业的人员。我的解决方案是所有模式切换只改变PLC对泵的控制权不直接改变泵的当前物理状态——自动切手动时泵保持切换前的运行/停止状态不变只是之后PLC不再干预手动切自动时自动逻辑会重新评估是否需要启动但需要满足所有安全条件无报警的前提并且泵启动前会自动给出一个准备启动的提示。这套机制能极大减少现场调试中的意外事故。6. 实战调试中必须面对的坑通信、时钟、数据一致性6.1 S7通信PUT/GET的常见问题与对策多站通信用PUT/GET确实方便但也存在几个让人头秃的坑。第一个就是TSAP的配置错误。S7-1200在S7通信里作为客户端时伙伴TSAP通常设置成03.01作为服务端时伙伴TSAP一般是03.00。很多新手卡在这一步通信握手始终不通仔细核对TSAP和IP地址后问题立刻消失。另外S7-1200的PUT/GET默认只允许少量连接资源在通信伙伴较多时要确认CPU的连接资源数量是否够用。第二个坑是通信数据区的断连处理。以太网通信终究有中断的可能交换机故障、网线松动都可能导致通信中断。程序里我专门做了一个Watchdog计数器主站每成功执行一次PUT/GET计数器清零如果连续3个扫描周期数据未被刷新判定通信中断备站立即进入主站离线状态同时保持当前泵的运行状态不变并发出通信中断报警。这里有个原则通信中断时宁可保持现状报警也绝对不要默认主站所有泵已停止——否则备站接管后可能把正在运行的所有泵直接停掉造成供水事故。6.2 时钟同步报警时间戳一致性的隐形坑多个PLC站各自记录报警时时间戳如果不统一排查问题时就会相当混乱——冷水站记录的报警时间和热水站差几分钟甚至几十分钟对事故溯源非常不利。S7-1200本身没有GPS授时模块我采用的办法是一台主站作为时间基准通过S7通信把系统时间字段写入备站的系统时钟区域每执行一次通信就同步一次。这个操作看着简单但要注意S7-1200的时钟写入需要在特定系统块调用并且写时钟操作不能过于频繁一般每分钟一次足够否则CPU程序扫描循环里频繁读写系统时钟会影响性能。如果项目中有上位机直接用上位机作为NTP时间源统一校时是更省心的方案。6.3 数据一致性掉电、重启、在线修改程序时的保护策略在线修改程序时S7-1200支持对启用的块进行部分在线修改但供水系统运行中改程序本身就是高风险操作。我有一次在线修改泵控制FB内部逻辑改完下载的瞬间泵竟然短暂停止了——原因是背景DB参数被重新初始化导致泵的锁定位被清零。从那以后我定了两条规则涉及安全联锁或泵启停控制逻辑的在线修改必须先把系统切到手动模式背景DB的关键参数全部设置为保持性Retain重要状态字在程序启动OB100时从保持区恢复。这样做之后即使下载新程序导致部分DB重新初始化泵也不会因为状态丢失而误停。另外要强调的是DB变量名的规范。多站系统四台PLC上跑的虽然是同一套逻辑框架但各自IP、站点名、DB编号可能不同。如果变量名不规范备站调试时你根本分不清冷水主站DB100.DBX0.0和热水主站DB100.DBX0.0分别代表什么。我在这套项目里统一采用了前缀命名法WB_开头表示水泵Water BoosterHP_开头表示热水Hot WaterCP_开头表示冷水Cold Water后面紧跟功能描述比如CP_Pump1_Running、HP_PID_Setpoint这样跨站查阅时一眼就能判断变量归属后期维护的效率提升非常明显。7. 我怎么验证这套程序的可靠性以及后续可以怎么扩展7.1 仿真验证与现场调试的配合这套程序我并不是直接拉到现场就上线而是在博途仿真环境PLCSIM里做了一轮完整的逻辑验证。仿真时重点测了三块内容多泵投切的时序是否正确、PID在压力阶跃下的响应曲线是否合理、通信数据的有效性判断能否在模拟断网时正确触发。这里有个心得PLCSIM只能验证程序逻辑验证不了模拟量信号的电气特性和通信物理层的时序。比如压力变送器的信号抖动、变频器对频率设定的响应延迟这些只能在真实系统里调。所以我的建议是仿真验证准备要充分但心态上不要指望仿真能发现所有问题——仿真通过后到现场调试仍然是工作量最大的环节。现场调试阶段我按照先手动后自动先单站后联站先无负载后带负载的顺序推进。泵组空载调试时重点看继电器动作顺序和互锁逻辑带载后重点观察变频器频率变化、压力跟随曲线和泵投切振荡。这套流程走下来系统出问题的概率会低很多。7.2 后续扩展方向从多站恒压到智慧水务的中间形态这套S7-1200四站架构本身已经具备了向更大系统演进的潜力。当前系统是四站互相备份的平级结构如果未来要在厂区级做统一调度可以引入一个上位SCADA系统通过OPC UA协议把四站数据统一采集上来在服务器层面做能耗分析、用水预测和远程运维。S7-1200从固件版本4.4开始原生支持OPC UA服务器功能不需要额外网关硬件这给后续的接入留有很宽的余地。另外一个可以扩展的方向是把单泵的PID恒压升级为全变频泵组协同控制即所有泵都接变频器由PLC统一调度。这种方案节能效果更好尤其在低负载时段但控制算法复杂度成倍增加——需要解决泵的切换频率点和功率均衡问题。以S7-1200的性能做小规模的3~4泵全变频控制没有问题再往上就得考虑S7-1500或者更高级的控制器了。7.3 最后分享一点个人体会调完这套系统之后我印象最深的不是PID参数怎么凑出来的反而是**可靠性的核心在于简单**。很多人喜欢在程序里堆各种花哨的逻辑模糊控制、自适应PID、复杂的状态机但我在这类供水项目里越来越倾向于用最朴素的双条件判断加延时确认用最简单的结构做到故障时可预期、可排查、可快速恢复。用户不需要知道你的程序用了多少种算法他们只知道半夜停水的时候必须有人能在十分钟内把问题找出来。所以写程序的时候多想一想如果我一年后来维护这套系统还能不能在三分钟内看懂这段逻辑比炫技有用得多。这套四站恒压供水的程序框架目前我已经整理成了可复用的模板泵组的启停逻辑、PID恒压控制、通信同步、手自动切换这些核心模块都做成独立FB后续做类似项目时只需要改I/O映射和工艺参数不用再从零开发。对正准备做同类项目的朋友我的建议是先把OB35 PID 投切逻辑这条主线吃透再把多站通信的安全性数据有效性、断线保持、时钟同步补全一套能稳定运行的供水控制程序就八九不离十了。