去年接手了一个高炉冲渣系统改造项目核心内容是把原来的继电器控制柜整体升级成基于AB 1756 PLC上位机的自动化控制系统。项目范围涵盖了冲渣泵、回水泵、补水阀、气动蝶阀以及沉淀池和热水池的液位控制最后还要把几十台设备的运行状态全部整合到中控室画面上。接这种项目很多工程师的第一反应是“先写程序”但我的习惯恰恰相反——先把冲渣池的工艺摸透把每个水泵和阀门在工艺流程里到底干什么、为什么这么干搞清楚然后才动手选硬件、画原理图、写代码。这篇内容不是教科书更像一段项目复盘。从工艺摸底、硬件选型到PLC联锁逻辑设计、上位机画面整合再到现场调试和踩坑记录我把整个链路里值得注意的地方都摊开讲。如果你也接到类似的高炉冲渣、轧钢浊环水、甚至烧结冷却水控制系统这篇可能帮你少走不少弯路。1. 冲渣池到底要控什么一次工艺摸底比写程序更重要1.1 先搞清楚水带着渣走了哪条路高炉熔渣从出铁场渣沟流下来进到粒化器或者冲制箱被高压水打散水淬瞬间变成渣水混合物再进入冲渣池。渣粒在池子里沉淀水经过溢流回到热水池或冷水池最后由泵送回粒化器继续参与循环。这里面有几个关键点直接决定控制逻辑怎么设计。第一粒化器进水压力必须稳定。水压不足时渣淬不碎高温熔渣遇到水还会产生大量蒸汽炉前操作环境会非常恶劣甚至有安全风险。所以冲渣泵的运行状态是系统里最高优先级的对象任何联锁都不能轻易把它停掉除非真的到了必须停的地步。第二整个水系统是个循环平衡。渣量大时水温和渣量都上来水池液位会波动需要补充新水、撤掉热水补水阀和排污泵就要跟着动作。第三渣池里的液位信号往往不像清水池那么干净渣水界面上有泡沫、有波动甚至液位计被渣糊住这些都是后来调试踩坑的重灾区。1.2 把控制对象分成三类优先级立刻清晰我在项目启动会上跟甲方讨论时习惯把所有设备分成三类这样后面做点表和写逻辑时就有章法了。对象类别典型设备控制的本质动力设备冲渣泵、回水泵、排污泵启停、联锁、备用切换、轮换执行机构气动蝶阀、补水电动调节阀开关控制、阀门开度调节检测仪表液位计、压力变送器、温度、流量数据采集、越限报警、参与联锁这三类里仪表是最容易被轻视的。经常有人吐槽“PLC程序有问题”最后查来查去发现是液位计信号本身在跳。冲渣池的仪表工作环境确实很差蒸汽大、泥浆多液位计很容易被渣糊住。所以我在这个项目里给水池液位做了双重配置雷达液位计加静压式液位计程序里做判断两个信号偏差超过一定范围就报仪表故障不参与自动控制。PLC程序写得再漂亮信号是脏的也白搭。2. 硬件选型和点表统计1756机架上每一块模块都是算出来的2.1 为什么选ControlLogix 1756这个系统点位不算多但可靠性要求高。ControlLogix 1756系列属于中型到大型PLC之间扩展性好适合这种跨电气室、中控室、现场多个区域的系统。加上甲方整个厂区都在用AB产品备件通用工程师也都熟悉选1756是顺势而为。具体配置大致是这样的CPU用1756-L72带SD卡扩展存储通信模块配一块1756-EN2T通过EtherNet/IP连接操作站和远程IO机架用1756-A13电源根据负载选了1756-PA75。IO模块方面数字量输入用1756-IB16数字量输出用1756-OB16模拟量输入用1756-IF8收4-20mA信号调节阀输出用1756-OF4。这里想提醒一个细节数字量输出模块后面尽量加中间继电器隔离不要用PLC板卡直接驱动MCC柜里的接触器线圈。虽然OB16本身有隔离但现场电磁干扰和触点冲击都不可控中间继电器既便宜又好换出问题时不至于伤到板卡。端子排我选的是1756-TBCH可拆卸端子调试时不用带电拆线安全很多。2.2 点表统计预留20%是行业底线配置机架前必须先把点表统计出来。我把这个项目的脱敏点位情况列在下面供参考信号类型数量主要对象DI132泵运行/停止/故障、阀开到位/关到位、手自动状态、紧停输入DO84泵启停、阀门开/关、故障复位、声光报警输出AI48水池液位、管路压力、水温、电机电流AO8补水调节阀开度、变频器转速给定备用通道每个类别预留了约20%的备用通道。预留不是浪费是给调试期间新增信号和后续改造留余地。点表定得越细硬件配置就越精确后面改动的成本越小。我还要求每个AI点都写清楚量程、单位、对应变送器型号和是否有隔离每个DO点都标好端子号和中间继电器号。这些信息在后面打点调试时就是唯一依据省去大量翻图纸的时间。2.3 网络架构控制与监控一条以太网走完网络结构不复杂但要说清楚。中控室放两台操作站和一个工程师站都装FactoryTalk View SE客户端和Studio 5000编程软件。电气室的PLC机柜里有CPU和EN2T通过工业交换机连回中控室。现场远程IO站如果距离超过200米用1734-AENTR远程适配器接到网络上。与高炉主控系统的联动信号我选的是硬接线干接点。虽然跨PLC用Producer/Consumer标签共享数据在AB平台里很方便但不同系统之间的通信一旦依赖太重某一端重启或网络闪断时就会出现莫名其妙的联动问题。冲渣系统和炉前系统的联锁就那么几个点比如“允许冲渣”“冲渣模式请求”用干接点最直接、最可靠。如果非要跨品牌做数据交换我一般建议加Modbus TCP网关至少故障边界是清晰的。3. PLC程序的核心不在画图而在联锁水泵与阀门时序的设计思路3.1 程序结构把逻辑拆成可维护的块这个项目用Studio 5000 v32开发任务规划如下主任务MainTask周期10ms负责IO刷新、数据预处理、设备控制和报警处理另外建一个周期任务做模拟量滤波和设备心跳监视。设备逻辑我全部封装成了AOIAdd-On Instruction。水泵统一用Pump_Ctl阀门统一用Valve_Ctl。这样做最大的好处是六台泵调用同一个AOI同样的启停逻辑只需要写一遍现场如果发现某个时序问题改一个AOI定义所有实例全部生效不用一台一台去翻梯形图。泵AOI的接口大致是这样设计的变量方向说明i_bStartCmd输入上位机或就地启动命令i_bStopCmd输入上位机或就地停止命令i_bAutoMode输入自动模式标志i_bFault输入综合故障信号i_bOutletOpen输入出口阀开到位反馈o_bRun输出泵运行状态输出o_bStartReq输出输出到MCC的启动指令o_bStopReq输出输出到MCC的停止指令o_bAlarm输出泵报警汇总AOI内部用梯形图写状态机外部调用时只需要正确赋值输入输出逻辑一目了然。别小看这个封装习惯后期甲方电工维护时会省很多事。3.2 先开阀再启泵一句话解决水锤问题冲渣泵的启动顺序我反复跟现场强调过先开出口阀收到开到位反馈再启动水泵。道理是流体力学的常识——如果阀门全关时启动水泵出口管路里的水被突然推动压力瞬间升高形成水锤轻则管路法兰渗漏重则把止回阀敲坏。老式的继电器控制经常是先启泵再开阀那是为了简化逻辑但代价是管路寿命明显缩短。完整的启动顺序是收到启动命令且所有允许条件满足输出“开出口阀”指令收到阀门开到位反馈或开阀指令发出3秒后阀门正常到位输出“启动水泵”指令监视泵出口压力和电机电流10秒内压力建立否则报“启动失败”并停泵。停止顺序正好反过来先停泵确认泵停止收到停止反馈或电流降为0延时5秒再关出口阀。这样做的目的是防止管路里的渣水倒灌导致泵反转。泵反转看着不起眼但对机械密封和轴承的损伤是持续性的时间长了会漏油漏水。3.3 自动模式的液位联动让每次启停都有延时和死区自动模式不是简单写一句“液位高了就启泵低了就停泵”那样做迟早出事。渣水池液位信号波动本来就大如果阈值设得紧泵会频繁启停一小时启停五六次接触器和电机都受不了。我的做法是给所有自动启停条件加入死区和延时确认。简单说液位超过启动阈值并且持续10秒才允许启动低于停止阈值并且持续10秒才允许停止。中间重叠区域就是死区防止液位在临界点来回穿越导致设备反复动作。补水调节阀用PID控制液位偏差作为过程值AO输出到调节阀正作用方式液位高了开大阀补水低了下调开度。泵组轮换逻辑我也加了。每次自动启动时比较各泵累计运行时间优先启动运行时间最短的那台泵这样不会出现一台泵用到坏、另一台长期闲置的情况。备用泵自动投入时还会先检查泵的在位状态和综合故障信号防止把有问题的泵当备用切进去。3.4 联锁保护不是越多越好而是越准越好联锁表是这个项目里我和甲方反复讨论出来的。下面列几个核心联锁联锁条件动作说明热水池液位低低停回水泵防止回水泵抽空气蚀泵轴承温度≥95℃停对应泵防止抱轴磨损电机综合故障停泵并闭锁必须人工复位才能再次启动出口压力低于0.15MPa持续10秒停对应泵防止泵空转损坏泵启动后10秒压力未建立停对应泵判定启动失败这里要强调一个原则PLC联锁不是安全保护的最后一道防线。急停回路和MCC柜里的电机保护都应该是硬接线的独立回路PLC只是监视状态。联锁的目的是减少设备损坏和工艺事故但绝对不能依赖PLC来兜底安全。我在设计时跟甲方电气主管明确了这个边界所有紧停信号进PLC只做状态显示真正的切断动作由电气硬回路完成。4. 上位机画面整合让操作员一屏看全局、三键能启机4.1 画面前先定导航总貌、区域、设备三层上位机画面整合这个环节很多项目都栽在不重视信息架构上。只做一张大流程图把几十台设备全堆上去操作员根本找不到按钮。我的做法是三层导航结构。第一层是总貌画面把整个渣水循环系统浓缩成一页显示所有水池液位、主要管道压力、水泵运行状态和报警汇总条。操作员在总貌层就能判断系统当前是否正常。第二层是区域画面按泵组、阀门、水池仪表分成几个页签每个页签下是相对完整的分区流程图。第三层是设备操作面板点任意一台泵或阀门的图标就弹出单体设备的操作界面。4.2 泵操作面板上除了启停还要有“为什么不能启动”这是很多初做上位机的人最容易忽略的地方。画面上放了一个启动按钮用户点了却没反应操作员第一反应是PLC坏了或者程序有bug实际上往往只是某个允许条件不满足。我把PLC里的联锁条件逐个映射到画面上的状态列表每条条件实时显示“满足”或“不满足”绿色表示满足红色表示不满足。操作员一点启动按钮发现没反应低头看这个列表就知道哪里没到位。举个例子泵无综合故障满足模式选择为远程不满足当前就地出口阀已开到位满足这个功能实现起来不复杂但现场使用体验提升非常明显。调试期间甲方操作员对着这个列表自己就能排除一半问题不用整天打电话叫工程师来处理。4.3 用Global Object和参数化显示管住几十台设备如果每台泵单独做一套画面重复工作量太大而且以后改版要改几十处。在FactoryTalk View SE里我全部用参数化显示配合Global Object完成。先做一个标准的Pump_Panel画面模板画面内部都用参数#N来区分设备号。每个泵的入口按钮跳转时传对应的设备编号比如Pump_PanelN1。一台泵的模板六台泵都能用阀门同理。动画方面泵运行用绿色填充停止灰色故障红色闪烁阀门开到位绿色、关到位灰色、无反馈黄色液位高低用Fill水平填充动画水流方向用Polyline线段动画。这些动画看起来只是视觉效果但本质上是数据可视化。操作员扫一眼颜色就能判断设备状态判断速度明显比看数字快。颜色规范必须在整个厂区统一不然换个操作员就看不懂了。4.4 报警、趋势和权限这三件事别拖到最后报警、趋势和用户权限如果放在项目最后才做往往会因为时间不够被砍掉或者做得很糙。我的建议是跟主画面同步规划。报警方面PLC里把报警条件和报警确认状态做成标签上位机用FactoryTalk Alarm and Event统一展示。报警分组按设备类型分泵类、阀门类、仪表类、通讯类。每一条报警都要有报警文字、发生时间、确认按钮报警时画面闪烁加声音提示。趋势方面关键模拟量做24小时趋势包括水池液位、冲渣压力、泵电流、水温。采样周期1秒足够太短数据量大趋势图拖动起来会卡。权限方面操作员可以看画面和启停设备工艺技术员可以修改液位设定值和PID参数工程师才允许在工程师站进行程序下装和画面修改。所有操作记录都要留存我在这套系统里自建了一个事件日志记录操作人、操作时间、操作对象和操作内容写到SQL Server里方便后续追溯。5. 现场调试链路从强制打点到联动试车每一步都要留痕5.1 没打点之前千万别试车现场调试最容易出问题的环节就是打点测试。很多项目试车时才发现某个端子接错了查线查到崩溃根源就是打点没做细。我的调试流程是第一步PLC切到测试模式输出全部禁止。用Studio 5000的快速监视窗口逐点强制DO确认MCC柜或继电器箱对应的继电器动作同时看现场设备有没有反应。第二步对应DI信号现场短接或者模拟状态观察PLC输入状态变化再对照上位机画面是否同步。第三步模拟量通道用信号发生器分别给4、8、12、16、20mA记录上位机显示的工程量数值验证量程换算是否正确。每次打点结果都记录在表格里包括点号、位号、设备名称、动作结果、测试人、测试时间。这张表在后面对照问题时就是排查索引。别嫌麻烦这一步做扎实了后面联动试车会顺利很多。5.2 单机试车先把手动模式跑通手动模式试车的目标是确认每一台设备在PLC和上位机控制下都能独立动作。水泵试车时先确认泵的转向正确然后逐步升压观察电流和出口压力是否平稳。阀门试车时开阀、关阀指令各操作几次核对开到位和关到位反馈的时间同时留意有没有异响。这个阶段我最关注的是参数显示真实性。比如压力变送器量程是0到1.6MPa4-20mA信号经过PLC模块换算后上位机显示的压力必须和现场压力表一致。如果发现偏差优先检查变送器量程设置和PLC模块的工程单位换算不要一上来就怀疑硬件。5.3 联动试车模拟故障比正常操作更重要单机试车通过后才开始自动模式联动。先把水位人工调整到正常区间让自动逻辑接管观察泵的启停、阀门的开关、PID调节是否稳定。然后做故障模拟测试这是整个调试里最能发现设计缺陷的环节。比如用信号发生器模拟出口压力低的工况观察PLC联锁是否在设定时间内停泵上位机报警是否正确触发。再比如短接轴承温度高信号看是否只停对应泵而不影响其他泵。每次模拟都记录实际动作时间和设定值对比偏差超过500毫秒就要分析原因。6. 冲渣水系统的运行日志几个典型的坑和完整排查链路6.1 液位波动导致泵频繁启停最后发现是信号在跳系统投运一个月后甲方反馈说回水泵启停特别频繁有时候一小时七八次。我到现场后先看趋势曲线发现热水池液位信号在1.9米到2.1米之间来回震荡而自动启动阈值是2.0米停止阈值是1.8米。液位信号频繁穿越启动阈值导致泵反复启停。接下来我做了三件事第一在PLC里增加一阶低通滤波滤波时间常数设200毫秒第二调整自动判断逻辑液位超过启动阈值必须持续10秒才允许启泵低于停止阈值持续10秒才允许停泵第三在现场仪表侧检查雷达液位计安装位置发现探头离进水管太近水面波动被直接放大。这三步做完泵启停频率明显下降。后来和仪表工程师沟通才知道液位计供应商默认的响应速度很快用在清水池没问题用在渣水波动环境就必须配合软件滤波和判断延时。这个坑的本质是仪表响应速度和工艺波动之间的匹配问题。6.2 气动蝶阀反馈不到位导致程序卡死有一次甲方报告说某台冲渣泵启动流程卡在“正在开阀”状态。我到现场查程序发现开阀指令已经发出20秒但开到位反馈一直没收到AOI内部状态机就一直停在等反馈这一步。查线发现反馈开关本身没问题但阀门的开度只有85%就触发了限位反馈信号其实不到位。气动蝶阀在渣水介质里长期运行阀板附着物多行程阻力变大阀门实际无法完全开到机械限位位置。程序如果用硬性“必须开到位”的条件就会像这次一样卡死。我的解决办法是在AOI里增加一个超时容错逻辑开阀指令发出10秒后如果开到位反馈没有到位程序自动解除当前等待状态报警提示操作员确认阀门实际状态允许操作员手动继续或放弃本次启动。程序逻辑不能因为一个反馈点丢失就把整个系统锁死这是设计原则问题。后来我还把这类阀门的到位判断改成了“软到位”模式阀门开度达到95%以上就认为开到位机械限位只作为辅助信号。现场反馈运行稳定很多。6.3 上位机画面所有标签全部变星号通讯链路断了这个问题的排查过程也是典型的网络故障链路。某天操作员报告两台操作站所有数据显示横杠和星号PLC柜指示灯正常就地设备运行状态没变化。第一步检查交换机指示灯正常第二步查RSLinx的OPC连接状态发现OPC服务器与PLC的会话断了第三步看到诊断日志PLC侧EtherNet/IP连接超时被复位。进一步分析发现PLC的EN2T模块当天曾因电源波动发生过一次重启但操作站侧FactoryTalk View SE没有自动重连机制会话没有恢复。解决方式是在FactoryTalk View SE的数据服务器配置里启用自动重连同时给EN2T的端口配置做了静态快速连接避免因网络扫描引起连接抖动。另外我还加了一个心跳标签上位机每隔5秒读一次PLC系统时钟一旦心跳丢失立即在画面上提示通讯中断而不是让操作员看着满屏横杠猜问题。这类问题在工厂环境里并不少见很多时候罪魁祸首不是设备本身而是电源波动和网络配置的细节。最后说几句冲渣池自动化做下来我的体会是程序写得再漂亮画面上联锁条件列得再清楚最终还是要回到对工艺的理解上。水和渣的耦合关系处理不好再好的控制逻辑也白搭。我现在每接到类似的渣水系统项目都会先蹲几天现场和操作工聊聊他们平时怎么开泵、怎么关阀、最怕什么情况然后再动手写程序。这个系统后续如果要扩展可以考虑加泵的振动监测做预测性维护也能在手机端看关键运行数据和报警推送。不过先把当前这套逻辑维护好比什么都重要。整套项目的核心文档、点表、联锁逻辑表、画面操作说明我都整理成交付资料了后续运维直接照着查就行。