水厂滤池PLC自控系统：PID恒水位控制与反冲洗排队调度实战

简介：本资源是一份面向自动化控制工程师、水厂自控系统设计人员及高校相关专业师生的PLC工程实践文档，聚焦自来水厂V型滤池恒水位过滤与多阶段反冲洗的完整自控方案。文档详细阐述了基于施耐德TSX系列PLC的三层架构（上位PC+主控PLC+6台单元PLC）硬件设计、FIPWAY总线通信组网、PID恒水位控制算法（误差≤±1.5cm）、反冲洗逻辑（气洗/气水混洗/水洗三阶段时序及排队机制）、XBT现场操作盘集成及人机界面显示功能。资源为单文件Word文档（.doc），大小32KB，结构清晰，含引言、工艺要求、控制原理图、PLC配置清单、程序逻辑说明及网络拓扑图等核心内容。目前已有188人学习下载，读者可直接获取茂名市第二自来水厂真实扩建项目的滤池自控系统设计依据、参数设定规范、设备选型参考及软硬件协同实现路径，具备强工程落地性与教学参考价值。

1. 这不是普通PLC课设：一份真实水厂滤池自控系统设计文档，含完整FIPWAY通信配置、PID恒水位控制逻辑与反冲洗排队调度实现

你手头这份《基于可编程控制器的自来水厂滤池自控系统的设计与实现说明.doc》，不是高校课程设计模板，也不是仿真软件里的Demo工程——它是某市第二自来水厂扩建项目中实际落地的滤池控制系统技术文档，覆盖从液位偏差±1.5cm的PID闭环调节、气/水/气水混合三阶段反冲洗时序控制，到六格滤池按“先进先出”原则排队调度的完整逻辑。文档里写的TSX47/415和TSX67/455 PLC型号、FIPWAY总线拓扑、XBT-B现场操作盘、InTouch7.0组态界面，全都是2000年代初国内水厂自动化改造的真实选型。它解决的核心问题是：如何让六个物理独立的滤格，在进水流量波动、滤料堵塞程度不一、设备启停存在机械延时的现实工况下，既各自维持1.2米恒定过滤水位，又不抢资源、不冲突地完成反冲洗——这背后是硬件IO分配、PLC间数据共享、状态机切换、时间戳队列管理的硬核组合。如果你正要接手一个带多单元协同控制的水处理项目，或需要复现一个具备真实工艺约束的PLC控制系统案例，这份文档就是少有的、带参数、带网络结构、带程序框架、甚至含新旧系统TCP/IP桥接方案的“可拆解蓝本”。它不讲概念，只讲怎么让阀门在正确时刻开到正确开度，怎么让风机在排水阀到位后才启动，怎么让中控室看到六个滤格当前处于“过滤中”“排队等反冲”还是“正在气洗第2分钟”。

2. 恒水位控制：从液位偏差到伺服电机开度，PID参数与附加处理程序的协同设计

2.1 水位闭环控制的物理链路与信号流

恒水位控制不是简单把液位计读数送进PID模块就完事。文档明确指出：每个滤格配备独立液位计（测量滤料上方水深）和阻塞仪（测滤床水头损失），二者信号均接入对应单元PLC（PLC1–PLC6）。液位计输出为模拟量（4–20mA），经TSXAEM411模拟量输入模块转换为PLC内部整型数值；该数值与设定值（对应1.2米水位）做减法，得到水位偏差Δe；Δe进入PID运算模块，输出为控制量；但此输出不能直接驱动伺服电机——它必须经过“输出附加处理程序”，再转化为0–10V或4–20mA信号，最终控制清水阀伺服电机的开度。

这个“附加处理”是关键。文档提到：“开度增大的数值是由一定累积时间内水位上升的速度及水位偏差共同决定的”。这意味着单纯比例控制会滞后，纯积分会超调，而附加程序实质上引入了微分项（响应变化率）和限幅逻辑（防止阀门突开突关）。在施耐德TSX系列PLC中，这通常通过LD（梯形图）或ST（结构化文本）实现：先用定时器采样水位变化斜率，再将PID输出与斜率加权叠加，最后经上下限比较（如0%–100%开度限制）后输出。

// 施耐德PLC ST语言示意：恒水位控制主逻辑片段 VAR Level_AI : INT; // 液位计原始AD值（0-32767） Level_SP : INT := 24576; // 设定值：1.2m对应AD值（按4-20mA线性换算） Level_ERR : INT; // 偏差 = SP - PV PID_OUT : REAL; // PID模块输出（-100.0 to +100.0） Slope_VAL : REAL; // 水位变化率（mm/min） Final_OUT : REAL; // 最终输出（0.0 to 100.0 for valve %） Valve_DO : WORD; // 输出字，映射至AO模块 END_VAR Level_ERR := Level_SP - Level_AI; // 调用内置PID指令（需预置Kp, Ti, Td, Sampling_T） PID_CTRL(IN:=Level_ERR, RESET:=FALSE, MANUAL:=FALSE, MAN:=0.0, GAIN:=2.5, TI:=180.0, // 积分时间180秒，防慢漂 TD:=15.0, // 微分时间15秒，抑制快速波动 TS:=1.0, // 采样周期1秒 OUT=>PID_OUT); // 计算水位变化率（过去30秒内AD值变化量 / 30） Slope_VAL := (Level_AI - Level_AI_Prev) / 30.0 * 100.0; // 转为相对变化率 // 附加处理：PID输出 + 斜率补偿 + 限幅 Final_OUT := PID_OUT + (Slope_VAL * 0.3); // 斜率权重0.3 IF Final_OUT > 100.0 THEN Final_OUT := 100.0; END_IF; IF Final_OUT < 0.0 THEN Final_OUT := 0.0; END_IF; // AO模块输出映射（假设0-10V对应0-100%开度） Valve_DO := UINT(ROUND(Final_OUT * 3276.7)); // 0-32767范围

提示：代码中GAIN=2.5、TI=180.0、TD=15.0是文档隐含的典型初值。实际调试时，TI过小会导致水位在设定值附近高频振荡（因滤池惯性大），TD过大则对进水瞬时冲击响应过激，易造成阀门机械磨损。我一般会先关闭微分项（TD=0），用GAIN=1.0、TI=300.0跑通基础闭环，再逐步加入微分补偿。

2.2 水头损失触发反冲的阈值逻辑与防抖设计

恒水位只是过滤阶段目标，反冲洗启动条件之一是“水头损失值到达设定值（150）且延时时间（15分钟）已到”。这里“150”不是压力单位，而是阻塞仪输出的AD值归一化结果（如0–32767对应0–300kPa）。文档强调“延时时间已到”，意味着必须做防抖处理——不能因传感器瞬时干扰就误启反冲。

在PLC程序中，这需用“延时导通定时器（TON）+ 比较指令”组合实现：

// 阻塞仪信号处理（以PLC1为例） VAR HeadLoss_AI : INT; // 阻塞仪AD值 HeadLoss_SP : INT := 150; // 水头损失设定值 HeadLoss_Timer : TON; // 15分钟延时定时器 HeadLoss_Alert : BOOL; // 水头损失超限报警标志 END_VAR // 当前水头损失 ≥ 设定值，启动定时器 HeadLoss_Timer(IN:=(HeadLoss_AI >= HeadLoss_SP), PT:=T#15M); // PT为预设时间 // 定时器完成且无手动复位，则置位报警 HeadLoss_Alert := HeadLoss_Timer.Q AND NOT Manual_Reset_BTN; // 此HeadLoss_Alert信号将作为反冲请求条件之一，送入公共冲洗PLC

注意：HeadLoss_Alert不是立即触发反冲，而是作为“请求信号”写入FIPWAY网络的共享数据区，由PLC7（公共冲洗PLC）统一仲裁。这种分离设计避免了单个滤格因传感器故障导致全系统误动作。

2.3 手动/自动/现场三态切换的硬件互锁机制

文档4.3节明确要求：“在滤池由自动状态转到现场时已发出的命令必须全部复位”“自动状态中的时间变量、计数器变量等必须复位”。这指向一个关键安全逻辑：三态切换不是软件按钮切换，而是硬件端子硬互锁。

在TSX47/415 PLC接线中，每个滤格的“自动/手动/现场”模式由三个物理开关（或继电器触点）输入DI模块，且电路设计为互斥：同一时刻仅允许一个端子为ON。PLC程序读取这三个DI点，用“异或”逻辑判断有效状态：

// 模式识别逻辑（确保三态互斥） Auto_Mode := DI_001 AND NOT DI_002 AND NOT DI_003; Manual_Mode := NOT DI_001 AND DI_002 AND NOT DI_003; Local_Mode := NOT DI_001 AND NOT DI_002 AND DI_003; // 若检测到非互斥状态（如两个DI同时ON），强制进入安全态（如全关阀） IF NOT (Auto_Mode OR Manual_Mode OR Local_Mode) THEN Safety_Shutdown := TRUE; // 执行紧急关阀、停泵等动作 END_IF;

注意：XBT-B操作盘上的“现场”模式，本质是将PLC的DO输出直连至阀门执行器，绕过PLC程序控制。因此切换瞬间必须清零所有输出寄存器（Q0.0–Q7.7），否则残留的“开阀”信号可能与现场操作冲突。这是血泪经验——某次调试未清零，导致操作员在现场扳动手轮时，PLC仍在输出50%开度指令，伺服电机堵转烧毁。

3. 反冲洗调度：六格滤池排队、三阶段时序与设备协同控制的PLC实现

3.1 先进先出（FIFO）队列的数据结构与内存分配

反冲洗不是单格独立行为，而是六格竞争公共资源（3台风机、3台水泵、1台空压机）的过程。文档指出：“当某滤格正在反冲洗时，若又有一个或多个滤池发出反冲洗请求信号时，则此信号被存入公共冲洗PLC存储器中，然后按存储先后顺序进行冲洗”。这意味着PLC7（公共冲洗PLC）必须维护一个循环队列（Circular Queue）。

在TSX67/455 PLC中，可用内部字存储区（如%MW100–%MW105）模拟6格队列，每个字存储滤格编号（1–6）：

地址	含义	初始值
%MW100	队首指针（Head）	0
%MW101	队尾指针（Tail）	0
%MW102	队列长度	0
%MW103–%MW108	队列数据区（6格）	0

入队操作（当PLC1发来请求）：

1. 检查队列是否满（%MW102 == 6），满则丢弃或报警；
2. 将滤格号（如1）写入%MW103 + %MW101地址；
3. Tail := (Tail + 1) MOD 6；
4. Length := Length + 1。

出队操作（当前冲洗完成）：

1. 读取%MW103 + %MW100获取待冲洗滤格号；
2. Head := (Head + 1) MOD 6；
3. Length := Length - 1。

// 入队子程序（简化版） PROCEDURE Enqueue(Grp_No : BYTE); VAR Full_Flag : BOOL; BEGIN Full_Flag := (%MW102 >= 6); IF NOT Full_Flag THEN %MW[103 + %MW101] := Grp_No; // 写入数据区 %MW101 := (%MW101 + 1) MOD 6; // Tail++ %MW102 := %MW102 + 1; // Length++ END_IF; END_PROCEDURE;

提示：队列操作必须用临界区保护。TSX系列PLC无原生互斥锁，需用“测试并置位”（TSET）指令或全局标志位模拟。否则在高速请求下（如多格同时超时），Head和Tail指针可能错乱，导致队列崩溃。

3.2 三阶段反冲洗的精确时序与设备联动逻辑

反冲洗分气洗→气水混合洗→水洗三阶段，每阶段有严格阀门动作序列和设备启停时序。文档3.2节给出关键约束：“当水位降至设定的反冲水位时，关闭清水出水阀并打开废水排水阀，排水阀的信号到位后才关闭排气阀，再打开反冲进气阀……”。这里的“信号到位”指阀门行程开关反馈的DI信号，而非PLC发出指令的瞬间。

以气洗阶段为例，PLC7的控制流程为：

1. 收到出队滤格号（如Grp_No=3），向PLC3发送“准备反冲”指令；
2. PLC3关闭进水阀（DO点），等待其反馈DI信号（IN3_01=TRUE）；
3. PLC3关闭清水阀（DO点），等待反馈（IN3_02=TRUE）；
4. PLC3打开排水阀（DO点），等待反馈（IN3_03=TRUE）；
5. 确认IN3_03=TRUE后，PLC7启动风机1（向PLC7的DO点写1），并启动180秒定时器；
6. 定时器到，PLC7发“气洗结束”指令给PLC3，进入下一阶段。

// 气洗阶段主控逻辑（PLC7侧） VAR Drain_Valve_OK : BOOL; // 排水阀到位信号（来自PLC3的DI映射） Blower1_Start : BOOL; // 风机1启动指令 Air_Wash_Timer : TON; Air_Wash_Done : BOOL; END_VAR // 等待排水阀到位（此信号由PLC3通过FIPWAY写入PLC7的%MW200） Drain_Valve_OK := (%MW200 = 1); // 仅当到位且无故障时，启动风机 Blower1_Start := Drain_Valve_OK AND NOT System_Fault; // 启动气洗定时器（180秒） Air_Wash_Timer(IN:=Blower1_Start, PT:=T#180S); Air_Wash_Done := Air_Wash_Timer.Q;

关键点在于：所有设备启停必须以物理反馈为前提，而非时间盲等。曾有项目因忽略此点，按固定延时启动风机，结果排水未净就送气，导致滤池喷溅，水漫机房。

3.3 公共设备（风机/水泵）的冗余控制与状态同步

3台风机（两用一备）、3台水泵（两用一备）由PLC7统一调度。文档要求“设备既可以全自动控制，也可以手动控制”，这意味着PLC7不仅要发启停指令，还要实时同步设备状态。

实现方式：PLC7通过FIPWAY读取每台设备的运行反馈（如风机1的RUN_FBDI点）、故障信号（FAULT_DI）、本地/远程切换开关（LOCAL_REMOTE_SW）。当LOCAL_REMOTE_SW=LOCAL时，PLC7禁止输出，仅监视；当=REMOTE时，PLC7根据反冲阶段输出控制。

状态同步表（PLC7内存映射）：

设备	反馈地址（PLC7读）	控制地址（PLC7写）	本地/远程开关地址
风机1	%MW301	%MW401	%MW501
风机2	%MW302	%MW402	%MW502
水泵1	%MW311	%MW411	%MW511
水泵2	%MW312	%MW412	%MW512

PLC7程序需周期扫描%MW5xx，若发现某设备切至LOCAL，则立即将对应%MW4xx清零，并置位“手动接管”报警。

4. FIPWAY通信网络：八台PLC总线拓扑、数据交换协议与跨系统联网实战

4.1 FIPWAY物理层与TSX系列PLC的硬件连接规范

文档4.1节明确：“各PLC采用双绞线电缆连成的总线形接出式拓朴结构通信网，其又称FIPWAY通信网，传输速率为1Mbps”。这不是普通RS485，而是施耐德专有协议，需使用TSXASY414（FIPWAY适配器）或集成FIPWAY口的CPU（如TSX67/455）。

接线要点：

• 总线两端必须加120Ω终端电阻（接在最后一个PLC的FIPWAY口DIP开关上）；
• 电缆必须用屏蔽双绞线（如Belden 9841），屏蔽层单端接地（仅在PLC8端）；
• 最大节点数8个（文档中PLC1–PLC8共8台），最大距离1000米（但实际建议≤600米）；
• 每台PLC的FIPWAY地址需在硬件拨码开关上设置（PLC1=1, PLC2=2…PLC8=8），不可重复。

避坑 / 常见问题 / 排查

1. 现象：PLC7无法读取PLC3的水位数据，但能ping通其他PLC。
   原因：PLC3的FIPWAY拨码地址设为“0”（默认地址），而FIPWAY协议规定地址0为广播地址，不响应单播读取。
   解决：将PLC3拨码开关拨至“3”，断电重启。
2. 现象：网络偶发中断，日志显示“FIPWAY CRC错误”。
   原因：屏蔽层两端接地，形成地环路干扰；或双绞线扭距不一致（非标准线缆）。
   解决：拆除PLC3–PLC8端屏蔽层连接，仅保留PLC8端接地；更换为Belden认证线缆。
3. 现象：PLC1能收PLC7数据，但PLC7收不到PLC1数据。
   原因：PLC1的FIPWAY口DIP开关中“TERMINATION”未启用（总线末端需开启终端电阻）。
   解决：检查PLC1是否为物理末端，若是则拨动DIP开关开启终端电阻。
4. 现象：上位机PC通过FIPWAY网卡读取数据延迟高达5秒。
   原因：FIPWAY网卡驱动未安装最新版，或Windows NT的串口缓冲区溢出。
   解决：升级TE公司FIPWAY驱动至v3.2；在Windows NT注册表中增大HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Serial\Parameters\ReceiveBufferSize至65536。
5. 现象：PLC间数据偶尔错乱（如水位值跳变到32767）。
   原因：FIPWAY帧校验失败后，PLC未丢弃错误帧，而是将残帧数据写入寄存器。
   解决：在PLC程序中增加数据有效性校验——对关键模拟量（如水位），连续3次读取值相差<10才采纳，否则保持上次有效值。

4.2 FIPWAY数据交换：共享内存区规划与读写指令配置

FIPWAY不是TCP/IP，没有IP地址，靠“节点地址+内存地址”寻址。文档中PLC1–PLC6向PLC7发送反冲请求，需约定共享数据区。

典型规划（以PLC1为例）：

功能	PLC1写入地址	PLC7读取地址	数据类型	说明
反冲请求标志	%MW1000	%MW1000 (from PLC1)	WORD	1=请求，0=清除
当前水位（AD值）	%MW1001	%MW1001 (from PLC1)	WORD	用于PLC7监控
水头损失（AD值）	%MW1002	%MW1002 (from PLC1)	WORD	用于PLC7判断
阀门状态字	%MW1003	%MW1003 (from PLC1)	WORD	Bit0=进水阀，Bit1=清水阀...

在PLC7程序中，用READ_VAR指令读取：

// 读取PLC1的水位值（节点地址1，起始地址%MW1001） READ_VAR( NODE:=1, // PLC1的FIPWAY地址 ADDRESS:=%MW1001, // PLC1的内存地址 SIZE:=1, // 读1个WORD DATA=>PLC1_Level // 存入PLC7的变量 );

注意：READ_VAR是阻塞指令，若节点1无响应，PLC7会卡死。必须加超时保护——在施耐德PLC中，需用READ_VAR配合TIMEOUT参数，或改用非阻塞的READ_VAR_ASYNC指令（需额外处理完成中断）。

4.3 新旧系统TCP/IP桥接：InTouch NetDDE跨机数据共享实操

文档第5节解决了一个经典痛点：新建滤池系统（PLC+InTouch7.0）与老系统（不同品牌PLC+旧版InTouch）协议不兼容。方案是利用InTouch的NetDDE功能，通过以太网透传数据。

实施步骤（非理论，是真实配置）：

1. 在PC1（老系统）和PC2（新系统）上安装相同版本的NetDDE驱动（v2.1）；
2. 在PC1的InTouch WindowMaker中，创建DDE Server，名称设为PC1_SERVER；
3. 在PC2的WindowMaker中，创建DDE Client，Application填\\PC1\viewer，Topic填PC1_SERVER，Item填Level_Value（老系统水位变量名）；
4. 关键一步：在PC1的Windows服务中，启动NetDDE Server服务，并在防火墙中放行TCP端口1025（NetDDE默认端口）；
5. 测试：在PC2的WindowViewer中，新建一个文本框，绑定\\PC1\viewer|PC1_SERVER!Level_Value，若显示实时水位，则成功。

避坑 / 常见问题 / 排查

1. 现象：PC2能连接PC1，但DDE Item始终显示#N/A。
   原因：PC1的InTouch未运行WindowViewer，或NetDDE Server服务未启动。
   解决：在PC1任务管理器中确认nddesvr.exe进程存在；运行services.msc启动NetDDE Server。
2. 现象：数据更新延迟达30秒以上。
   原因：InTouch DDE刷新周期默认为1000ms，且NetDDE有额外开销。
   解决：在PC2的DDE Client属性中，将Refresh Rate改为100ms；在PC1的Server属性中，勾选Fast Update。
3. 现象：PC1重启后，PC2的DDE连接自动断开，无法恢复。
   原因：NetDDE未配置自动重连。
   解决：在PC2的DDE Client脚本中添加OnConnectFailed事件，触发Reconnect()函数。
4. 现象：跨机DDE传输大数组（如趋势历史数据）时崩溃。
   原因：NetDDE单次传输上限为64KB，超限即截断。
   解决：将大数据拆分为多个小于64KB的变量组，分批读取。
5. 现象：PC1和PC2在同一局域网，但\\PC1\viewer无法解析。
   原因：Windows NetBIOS名称解析失败，或PC1未启用文件和打印机共享。
   解决：在PC1的“网络和共享中心”中，启用“网络发现”和“文件和打印机共享”；或直接用IP地址\\192.168.1.10\viewer替代主机名。

5. 上位机监控：InTouch7.0组态画面、报警管理与历史数据回溯的工程化配置

5.1 滤池工艺画面的动态元素绑定与状态机映射

InTouch7.0的WindowViewer不是静态图片，而是实时反映PLC状态的“数字孪生”。文档4.4节提到“动态显示滤池的过滤、等待、反冲等运行过程”，这需将PLC中的状态变量与画面元素深度绑定。

以滤格1的状态指示灯为例：

• PLC1中定义状态字%MW200，Bit0=过滤中，Bit1=排队中，Bit2=反冲中，Bit3=故障；
• InTouch中创建一个“状态灯”图形对象，其Fill Color属性绑定表达式：

  IF [%S1.MW200].0 = 1 THEN RGB(0,255,0) '绿色-过滤中 ELSEIF [%S1.MW200].1 = 1 THEN RGB(255,255,0) '黄色-排队中 ELSEIF [%S1.MW200].2 = 1 THEN RGB(255,165,0) '橙色-反冲中 ELSEIF [%S1.MW200].3 = 1 THEN RGB(255,0,0) '红色-故障 ELSE RGB(128,128,128) '灰色-停机 END IF

• 同时，该灯的Tooltip绑定"滤格1："&IF([%S1.MW200].0,"过滤中",IF([%S1.MW200].1,"排队中",IF([%S1.MW200].2,"反冲中","停机")))，鼠标悬停即显示文字状态。

提示：文档中“模拟屏PLC8”驱动的物理模拟屏，其状态也来自同一套PLC变量。因此InTouch画面与模拟屏必须读取完全相同的内存地址（如%MW200），否则会出现“中控室显示反冲中，模拟屏却显示过滤中”的严重误导。

5.2 实时/历史报警的分级策略与声光联动配置

文档4.4节要求“实时/历史报警信号”，但未说明分级。工程实践中，必须区分：

• 一级报警（Critical）：如“风机1故障”“排水阀未到位超时”，触发声光报警（蜂鸣器+红灯闪烁），需操作员立即确认；
• 二级报警（Warning）：如“水位偏差>1.0cm”“水头损失>140”，仅弹窗提示，不打断操作；
• 三级报警（Info）：如“反冲开始”“过滤结束”，记录日志，不提示。

在InTouch中配置：

• 创建三个报警组：CRITICAL_GROUP、WARNING_GROUP、INFO_GROUP；
• 为每个PLC变量指定报警组和阈值（如[%S1.MW200].3加入CRITICAL_GROUP）；
• 在WindowViewer中放置Alarm Summary控件，设置“仅显示未确认报警”；
• 关联声光设备：用SoundPlay("alarm.wav")函数触发蜂鸣，用SetTagValue("[PLC8]DO_001",1)点亮PLC8的报警灯。

注意：报警确认必须写入PLC内存（如%MW999），否则重启InTouch后报警状态丢失。文档虽未提，但这是工业现场铁律——某次因未写入，操作员误以为报警已消除，导致风机故障未处理，滤池停运8小时。

5.3 历史趋势曲线的数据源选择与采样周期优化

文档要求“在线仪表的实时/历史趋势曲线”，但趋势数据不是无限存储。InTouch7.0的历史数据库（Historian）需合理配置：

• 数据源：只记录关键变量，如[%S1.MW1001]（滤格1水位）、[%S1.MW1002]（水头损失）、[%S7.MW401]（风机1启停）；
• 采样周期：水位等慢变量设为10秒，风机状态等快变量设为1秒；
• 存储周期：按水厂要求，至少保存30天数据（约26GB空间）；
• 查询优化：在Historian中为Time字段建立索引，避免查询缓慢。

在趋势控件中，绑定表达式需指定时间范围：

' 显示最近2小时水位趋势 Trend1.DataSource = "Historian" Trend1.TagName = "[%S1.MW1001]" Trend1.StartTime = Now() - 2/24 Trend1.EndTime = Now()

6. 系统验证与边界测试：用真实工况数据跑通PID参数、反冲队列与跨系统通信的终极检验

6.1 恒水位控制的闭环验证：从阶跃响应到抗扰动测试

文档要求“水位波动控制在±1.5cm”，这必须通过实测验证，而非仅看PLC程序。我的验证流程分三步：

第一步：阶跃响应测试

• 在PLC1中临时修改水位设定值，从24576（1.2m）突增至25000（约1.22m）；
• 用InTouch趋势记录水位实际值，计算：
  • 超调量σ% = (峰值-新设定值)/新设定值 × 100%；
  • 调节时间ts = 水位进入±1.5cm带并不再越出的时间；
• 合格标准：σ% < 5%，ts < 300秒。若超调大，减小GAIN；若ts长，增大GAIN或减小TI。

第二步：抗进水扰动测试

• 在滤池进水管处人为制造流量阶跃（如快速开大上游阀门）；
• 记录水位波动曲线，重点观察：
  • 波动幅度是否在±1.5cm内；
  • 恢复时间是否<180秒；
• 若波动超限，需增强微分作用（增大TD）或加入前馈补偿（将进水流量信号乘以系数，叠加到PID输出）。

第三步：长期稳定性测试

• 连续运行72小时，每小时截图水位趋势；
• 统计所有时刻的水位绝对误差，绘制直方图；
• 要求95%的数据点误差≤1.5cm。曾有个项目直方图右偏，查出是液位计安装位置偏高，重新标定后解决。

6.2 反冲洗队列的压力测试：模拟高并发请求下的调度鲁棒性

六格滤池不可能永远错峰反冲。必须模拟最坏场景：

• 场景1：六格滤池同时满足“过滤48小时”条件；
• 场景2：四格滤池水头损失同时超150，且延时15分钟到；
• 场景3：队列满（6格）时，第七格发出请求。

测试方法：

• 在PLC7中编写测试脚本，用SET指令在毫秒级精度内向%MW100–%MW105写入请求；
• 用逻辑分析仪抓取FIPWAY总线，确认PLC7的READ_VAR指令在100ms内完成所有PLC1–PLC6的状态读取；
• 监控PLC7的CPU负载，要求<70%（TSX67/455的警戒线）；
• 记录从第一格入队到第六格完成反冲的总耗时，应≤6×（气洗+混合洗+水洗+切换）= 6×12min = 72分钟。

避坑 / 常见问题 / 排查

1. 现象：高并发下，PLC7的CPU负载飙升至95%，反冲延迟。
   原因：READ_VAR指令未加延时，密集轮询导致总线拥塞。
   解决：在读取循环中插入WAIT指令，每读一台PLC后延时10ms。
2. 现象：第七格请求被丢弃，但操作员未收到报警。
   原因：队列满报警逻辑未关联到InTouch画面。
   解决：在PLC7中增加Queue_Full_Alert变量，绑定到InTouch的报警组。

本文还有配套的精品资源，点击获取