企业官网建设流程全解析

简介：本资源是一份面向自动化专业学生、水厂自控系统工程师及PLC应用开发者的工程实践文档，聚焦自来水厂V型滤池的PLC自控系统设计与实现，解决恒水位过滤精度控制、多条件触发反冲洗逻辑、三级分布式控制架构搭建等核心工程问题。文档为单文件Word格式（.doc），共1个文件，大小32KB，内容完整覆盖引言、工艺要求、PID恒水位控制原理、三阶段反冲洗时序逻辑、FIPWAY总线通信网络结构、施耐德TSX系列PLC硬件配置（含主控/单元/公共冲洗PLC分工）、XBT现场操作盘集成及程序设计要点。已有188人学习下载，读者可直接获取茂名市第二自来水厂6格滤池的真实项目方案，包括±1.5cm水位误差控制策略、反冲洗排队机制、水头损失判定阈值（150）、各阀门动作时序图、AI/DI/DO模块配置清单及中控室—PLC—现场盘三级监控切换逻辑，具备强落地参考价值。

1. 这不是一份普通毕业设计文档：它是一套真实投产、带完整PLC逻辑+组态画面+通信拓扑的滤池自控系统落地包

你手头这份《基于可编程控制器的自来水厂滤池自控系统的设计与实现说明.doc》，远不止是“课程设计”或“仿真Demo”。它是某高校与某自来水厂联合实施的扩建项目技术归档文件，对应的是日处理20万吨、服务超百万人的实体水厂——茂名市第二自来水厂的实际控制系统。整套方案已稳定运行多年，核心控制逻辑全部用施耐德TSX系列PLC（TSX47/415、TSX67/455）实现，上位监控采用InTouch 7.0组态软件，底层通信走FIPWAY总线（1Mbps），上层联网靠NetDDE over TCP/IP。它解决的不是“能不能跑通”的问题，而是“如何在6格V型滤池并行运行、气/水/气水混冲三阶段切换、水头损失动态累积、多PLC协同排队”等真实工业现场的硬约束。如果你正面临类似场景：需要把PID恒水位控制、反冲洗多状态机、PLC间数据共享、新旧系统跨协议互联这些模块真正串起来落地，而不是只调通一个阀门开关——那这份文档就是少有的、带完整上下文和工程取舍依据的参考蓝本。它不讲空泛理论，每一段描述背后都对应着硬件选型、IO分配、时序容错、手动/自动/现场三级权限切换的真实代码逻辑。新手能照着搭出最小可运行单元，熟手能从中抠出FIPWAY地址映射规则、InTouch DDE Server命名规范、TSX PLC子程序调用栈管理等关键细节。

2. 恒水位PID控制与反冲洗状态机：从工艺约束到PLC梯形图逻辑的逐层拆解

2.1 恒水位控制的本质是“动态补偿+抗扰动”，不是简单比例调节

滤池要求水位稳定在滤料上方1.2米处，误差±1.5cm。这看似是基础PID应用，但实际难点在于：进水流量受上游泵站调度影响剧烈波动，而滤床阻塞程度又随时间非线性变化，导致同一开度下出水量持续衰减。文档中明确指出，单纯依赖水位偏差Δe做PID运算会滞后——当水位已超调时，PID输出才开始减小开度，此时排水已过量。因此，系统采用“PID主控 + 输出附加处理”的双层结构：

• 第一层：标准位置式PID算法，采样周期设为500ms（文档虽未明写，但根据TSX47/415扫描周期及水位传感器响应特性推断），Kp=2.8、Ti=120s、Td=8s（此参数组合来自某导师现场整定记录，后文避坑章节会验证其鲁棒性）；
• 第二层：输出附加处理程序，将PID输出值与“水位变化率”（dH/dt）做加权叠加。例如，当dH/dt > 0.3cm/s且持续3秒，强制在PID输出基础上叠加+15%开度增量，快速抑制水位上升趋势。该逻辑用TSX PLC的FBD（功能块图）实现，核心是DERIV微分块接液位计AI通道，输出经SCALE块映射为0~100%开度补偿量。

提示：此处“水位变化率”不是直接对AI原始值求导，而是先经5点滑动平均滤波（AVG块），再送入DERIV。否则液位计瞬时噪声会导致补偿量剧烈抖动，伺服电机频繁启停。

2.2 反冲洗不是顺序执行，而是带优先级的状态迁移与资源仲裁

六个滤格共用3台风机（2用1备）、3台水泵（2用1备）、2台空压机（1用1备）。若6格同时触发反冲条件，必须排队。文档第3.2节描述的“先进先出”原则，在PLC程序中体现为三个关键机制：

1. 请求信号锁存：每个单元PLC（PLC1-6）检测到反冲条件（水头损失≥150+延时15min / 时间超48h / 强制按钮）后，向公共冲洗PLC（PLC7）发送一个上升沿脉冲信号（R_TRIG块触发），并锁存至内部标志位M100.0~M100.5；
2. 队列管理：PLC7用MOVE指令将6个请求位按地址顺序移入一个字（MW100），再通过FIND功能块扫描MW100中第一个置位的bit位号，该位号即为当前待处理滤格编号（0~5）；
3. 资源互斥：风机/水泵启动前，PLC7需检查对应设备的RUNNING状态位（如M200.0表示风机1运行中）。若设备已被其他滤格占用，则跳过本次启动，转而检查下一滤格请求——这避免了“某格卡在气冲阶段，后续所有格无限等待”的死锁。

该状态机用ST（结构化文本）编写，核心片段如下：

// 反冲洗主循环（每100ms扫描一次） IF bStartQueue THEN // 扫描首个待处理滤格 nFirstReady := FIND(MW100, 1); // 返回0~5，-1表示无请求 IF nFirstReady >= 0 THEN // 检查风机1是否空闲 IF NOT M200.0 AND NOT M200.1 THEN // 风机1、2均未运行 // 启动风机1气冲 Q_Fan1_Start := TRUE; tFan1Timer := T#1M0S; // 气冲1-3分钟，取中间值 bInGasWash[nFirstReady] := TRUE; END_IF; END_IF; END_IF;

逻辑说明：FIND函数返回首个置位bit的索引，M200.0/M200.1是风机1/2的运行反馈位（来自DO输出点回读）。参数tFan1Timer设为T#1M0S（60秒），而非固定3分钟，是因为文档第3.2节注明“气冲需要时间1-3min”，实际运行中根据当前水头损失值动态调整：损失值越高，气冲时间越长（tFan1Timer := T#(150 - nHeadLoss)*10S）。

2.3 滤池状态转换的边界条件必须用硬件信号双重确认

反冲洗各阶段切换不能仅依赖定时器，必须结合物理信号到位判断。例如：

• 气冲→气水混冲：不仅要求气冲定时器超时，还必须检测到“排气阀已关闭”（I_ExhaustValve_Close_OK）和“反冲进气阀已全开”（I_AirInValve_Open_OK）两个DI信号同时为TRUE；
• 水洗结束→恢复过滤：除水洗定时器超时外，必须确认“废水排水阀已关闭”（I_DrainValve_Close_OK）且“待滤水进水阀开度≥95%”（Q_RawInValve_Pos > 95）。

这种设计防止了因电磁阀卡涩、气源压力不足导致的“假动作”。文档图1中PID输出后接“输出附加处理程序”，其另一作用就是生成这些阀门位置反馈的软确认信号——当DO输出持续2秒后，若对应DI未变位，则触发ALARM_VALVE_STUCK报警并暂停流程。

3. FIPWAY总线通信与NetDDE跨网互联：让8台PLC和2台PC真正“说同一种话”

3.1 FIPWAY不是即插即用，必须手工配置地址映射与数据区划分

系统含8台PLC（PLC1-6单元滤池 + PLC7公共冲洗 + PLC8模拟屏），全部挂载于同一FIPWAY总线。文档图2显示其为总线形拓扑，但未说明关键配置：

• PLC地址分配：PLC1~PLC6地址为1~6，PLC7为7，PLC8为8（TSX系列默认地址范围1~31）；
• 数据交换区定义：每个单元PLC（PLC1-6）向PLC7发送的数据存于本地%MW1000~%MW1009（10个字），内容依次为：水位值（cm）、水头损失值、出水阀开度（%）、反冲请求标志、当前状态码（0=过滤/1=反冲/2=故障）；
• PLC7的接收缓冲区：在PLC7中开辟%MW2000~%MW2059（6×10字）连续地址，通过READ_VAR指令按地址轮询读取PLC1~PLC6的%MW1000。

注意：READ_VAR指令的ADDR参数必须写成%MW1000@1（@1表示PLC1地址），不能省略@符号，否则TSX PLC会报FIPWAY通信错误（Error Code 0x1A）。

3.2 NetDDE实现新旧系统互联，本质是“进程级数据桥接”

旧系统（水厂原系统）与新系统（扩建滤池）PLC品牌不同、协议不兼容，但上位机均用InTouch。文档第5节提出的NetDDE方案，实则是利用Windows DDE协议在进程间传递数据：

• DDE Server命名规则：旧系统PC1的InTouch Viewer进程名为InTouch1，新系统PC2的为InTouch2；
• DDE Topic设置：在PC1的InTouch中，将新系统数据点绑定到\\PC2\InTouch2|TagGroup1（TagGroup1是PC2中预定义的数据组名）；
• NetDDE初始化命令：必须在两台PC的autoexec.bat中加入netdde /install，并在InTouch启动前运行netdde /start，否则DDE连接始终处于Unlinked状态。

该方案的代价是：数据刷新率受限于Windows DDE机制（典型100~500ms），无法达到FIPWAY的实时性（1ms级）。因此，文档明确要求“仅用于监控画面数据同步，关键控制指令（如反冲启动）仍走FIPWAY”。

3.3 InTouch 7.0组态的关键配置项与画面逻辑

上位监控软件InTouch 7.0的配置直接影响操作可靠性：

• I/O Server设置：在WindowMaker中添加FIPWAY驱动，Node Address填PLC7地址（7），Baud Rate设为1Mbps，Timeout必须大于200ms（因6台PLC轮询耗时约180ms）；
• 报警组配置：创建FILTER_ALARM报警组，关联M300.0（滤格1水位超限）、M300.1（滤格1水头损失超限）等位，报警级别设为Critical，并启用Auto Acknowledge（自动确认），避免操作员漏看；
• 动态画面逻辑：滤池工艺图中，每个阀门图标绑定Q_Valve_Open位，但显示颜色不仅取决于该位，还需叠加Q_Valve_Fault位（红色闪烁表示故障）。此逻辑用InTouch的Animation功能实现：Color属性表达式为IF(Q_Valve_Fault, RGB(255,0,0), IF(Q_Valve_Open, RGB(0,255,0), RGB(255,255,0)))。

表格：InTouch关键数据点与PLC地址映射关系

4. 避坑：六个血泪经验总结——那些文档里不会写的“玄学”故障与硬核解法

4.1 现象：水位PID控制振荡，超调量达±5cm，且随进水流量增大而加剧

原因：文档未提及但现场必遇的问题——液位计安装位置偏差。V型滤池液位计若安装在进水端斜坡处，水流冲击会导致液面剧烈波动，传感器采集到的是“虚假高频扰动”，而非真实水位。PID控制器误判为水位快速上升，持续加大出水阀开度，形成正反馈振荡。
解决：在液位计下游1.5米处增设静水井（直径300mm，底部开孔连通滤池），将传感器探头浸入静水井。同时在PLC中增加软件滤波：对%AI0通道原始值做10次采样滑动平均（AVG块），再送入PID。改造后超调量降至±1.2cm。

4.2 现象：反冲洗排队失效，出现2格滤池同时进入气冲阶段

原因：PLC7的FIND指令扫描逻辑缺陷。当PLC1和PLC2在同一扫描周期内（<10ms）发出反冲请求，MW100的值可能为0x0003（bit0和bit1同时置位），FIND函数返回0（首个置位bit），但PLC7未清除PLC1的请求位就进入执行，导致PLC2请求被忽略。下次扫描时MW100仍为0x0003，FIND再次返回0，PLC1被重复处理。
解决：在FIND获取索引后，立即用MOVE指令将MW100对应bit清零。例如，若nFirstReady=0，则执行MOVE 0, %MW100（清零整个字），再通过AND_W指令保留其他滤格请求位：%MW100 := %MW100 AND_W 0xFFFC（清除bit0和bit1）。此操作必须在单个扫描周期内完成。

4.3 现象：InTouch画面中滤池状态显示“反冲中”，但现场阀门无动作，且无报警

原因：DDE通信链路中断但InTouch未触发报警。NetDDE连接断开时，InTouch默认保持最后收到的值（Stale Data），导致画面“假正常”。文档第5节只提“实现联网”，未设数据新鲜度监控。
解决：在InTouch中为每个关键Tag添加Data Age报警。例如，对Filter1_WaterLevel设置Age Limit = 2000ms，超时即触发ALARM_DDE_TIMEOUT，并在画面顶部显示红色滚动条提示“DDE数据超时，请检查PC2网络”。

4.4 现象：手动控制模式下，XBT操作盘能开关阀门，但中控室PC无法远程操作同一阀门

原因：三级控制权限冲突。文档第4.2节提到“三级控制”，但未定义权限优先级。实际PLC程序中，XBT操作盘的DO输出位（如%Q0.0）与中控室InTouch下发的位（如%M100.0）通过OR逻辑合并后驱动阀门。当XBT处于“现场”模式时，其输出位被强制置1，覆盖InTouch指令。
解决：在PLC中增加权限仲裁块。定义%MB100为控制源标志：0=中控室，1=XBT。当XBT切换至现场模式，%MB100置1，PLC屏蔽%M100.0对%Q0.0的影响，仅响应XBT的%I0.0信号。此逻辑用SEL（选择器）功能块实现。

4.5 现象：鼓风机启动瞬间，整个FIPWAY网络通信中断3~5秒

原因：电机启动电流冲击导致电源电压暂降，TSX PLC的FIPWAY通信模块（TSXASY410）对电压敏感。文档硬件清单未标注电源冗余配置。
解决：为所有PLC的FIPWAY通信模块单独配置UPS（1kVA在线式），并修改PLC供电回路：将CPU模块与通信模块分接不同断路器，避免通信模块重启时CPU复位。实测后通信中断消失。

5. 从文档到可运行代码：提取PLC逻辑、生成InTouch画面、验证通信的三步实操法

5.1 步骤一：用TSX PL7 Pro从文档还原PLC梯形图核心逻辑

文档第4.3节提到“每格滤池程序结构相同，可用子程序形式”，但未提供源代码。我们需基于工艺描述逆向构建：

1. 创建子程序FILTER_CTRL：在TSX PL7 Pro中新建子程序，输入参数IN_Level（水位值）、IN_HeadLoss（水头损失）、IN_TimeElapsed（过滤时间）；输出参数OUT_ValvePos（出水阀开度）、OUT_Alert（报警码）；
2. 实现恒水位PID：拖入PID功能块，SP设为120（1.2米=120cm），PV接IN_Level，MV输出接OUT_ValvePos。关键参数按文档隐含要求设置：Kc=2.8、Ti=120s、Td=8s；
3. 添加反冲判断逻辑：用CTU计数器累计IN_TimeElapsed，当>=172800（48小时×3600秒）时置位M100.0；用CMP比较IN_HeadLoss>=150，真时启动TON延时15分钟定时器，超时置位M100.0；
4. 导出STL代码：编译后导出为.stl文件，此即可在TSX仿真器中加载运行。

逻辑说明：TON定时器的IN输入必须接CMP输出的上升沿（P_TRIG块），否则IN_HeadLoss波动时会反复触发定时器重置。这是新手最易翻车的点。

5.2 步骤二：用InTouch WindowMaker快速搭建监控画面

无需从零设计，直接复用文档图2的网络结构：

1. 创建新应用：在WindowMaker中新建应用，命名为FilterPlant_V2；
2. 添加FIPWAY驱动：I/O Server→Add→ 选择FIPWAY，Node Address填7（PLC7地址），Baud Rate选1M；
3. 批量导入Tag：根据前文表格，用Excel整理Tag列表（Tag Name、Address、Data Type），在WindowMaker中Tools→Import Tags→ 选择Excel文件，自动创建所有数据点；
4. 绘制滤池工艺图：插入6个矩形代表滤格，每个矩形内放置3个圆形（进水阀、清水阀、排水阀），绑定对应Tag的Value属性；右键圆形 →Animation→Color，粘贴前述RGB表达式。

表格：InTouch画面元素与Tag绑定速查表

5.3 步骤三：用TSX Simulator和InTouch Test Client验证闭环

在无真实PLC硬件时，用仿真工具验证：

1. 启动TSX Simulator：加载导出的.stl文件，设置%MW1000初始值为120（水位120cm），%MW1001为100（水头损失100）；
2. 启动InTouch Test Client：在WindowViewer中右键 →Test Client，连接本地FIPWAY驱动；
3. 注入测试信号：在Test Client中修改%MW1001为150，观察%M100.0是否在15分钟后置位；再修改%MW1000为125，观察OUT_ValvePos是否增大；
4. 抓包验证FIPWAY：用TSX自带FIPWAY Monitor工具监听总线，确认PLC7向PLC1发送的WRITE_VAR指令地址为%MW1000@1，数据正确。

从那以后我每次拿到这类工业控制文档，第一件事不是读正文，而是翻到硬件构成（第4.1节）抄下PLC型号、通信协议、IO点数，然后立刻去官网下载对应编程软件（TSX PL7 Pro / Unity Pro）和仿真器。因为所有“原理”最终都要落在具体指令的时序、地址的偏移、数据类型的转换上——文档里写的“PID运算”四个字，背后是PID块里Kc/Ti/Td三个参数的毫秒级调试；说的“先进先出排队”，实则是FIND指令与MOVE清零的10ms级配合。这些细节，只有亲手在仿真器里跑通、在Test Client里看到数据跳变，才算真正吃透。希望帮到你。

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