企业官网建设流程全解析

这个项目改到第三版才敢说逻辑通了。标题里的“改3”不是随便起的：第一版IO点排得乱七八糟，程序全堆在OB1里，改一个点要翻半天；第二版把结构梳理出来了，PLC侧看着挺像样，结果HMI联机仿真死活连不上，变量一大片红色感叹号；直到第三版我才真正把西门子S7-1200 PLC、TP700精智屏、博途V16的PLCSIM和HMI仿真整条链路完整跑通，也把灌浆机的工艺逻辑重新捋了一遍。

这套系统说白了就是给海洋灌浆机做监控：PLC负责泵、阀、搅拌器的控制，TP700负责显示压力、流量、液位这些数据，操作员在触摸屏上启停设备、设定灌浆压力、看趋势曲线。它适合正在学博途、准备做PLC+HMI项目、尤其是对IO表设计和联机仿真有需求的朋友参考。这篇文章我就从三次迭代讲起，把选型逻辑、IO表逐位拆解、程序模块划分、HMI组态和联机仿真的完整配置过程全部摊开说，重点讲那些文档上查不到、但实际调试一定会踩的坑。

1. 为什么叫“改3”：三次迭代里真正卡住我的问题

1.1 初版：IO表没规划，程序全堆在OB1

第一次动手的时候，我脑子里只有“PLC控制泵和阀”这个粗线条，IO地址完全是想到哪个编哪个：灌浆泵启动放在Q0.0，搅拌电机放在Q0.3，结果中间又插了指示灯和蜂鸣器，等程序写了一半发现IO不够用，只能硬着头皮挪地址，挪完还得回程序里一个个改。

程序更惨，所有逻辑全写在OB1里，一段扫描周期下来几千行代码，里面全是M0.0、M10.3这种没有任何注释的中间位。当时觉得能跑就行，但真正的问题出现在改需求的时候——甲方要加一个“冲洗泵故障自动停灌浆泵”的联锁，我愣是在OB1里翻了二十分钟才找到冲洗泵的反馈触点。那会儿我就意识到，这个项目不重构根本没法往下面做了。

1.2 改2：结构规范了，仿真却联不上

第二版我把程序按功能拆了FB和FC，泵控制做成一个FB，阀控制做成一个FB，DB块也单独建了，自认为已经很专业了。但真正做联机仿真的时候翻车了：PLC侧用PLCSIM跑得很欢，TP700的HMI仿真一启动就提示连接中断，变量表里一片红色叹号。

当时我反复检查网络组态、设备IP、变量连接，看着都对，就是连不上。后来才发现问题出在两台设备的时间设置和连接机制上——博途V16的HMI仿真启动时，需要明确选择要连接的PLC实例，而且PLC必须已经下载到PLCSIM并处于RUN状态，我先启动HMI仿真再下载PLC，顺序反了，连接自然建立不起来。这个坑让我记住了：联机仿真有严格的启动顺序，不能想当然。

1.3 改3：IO表先行，闭环逻辑重新定

第三版我彻底换了个工作方法：先把IO表完整画出来，人人评审确认，再写一行程序。地址按功能分区，泵、阀、仪表、报警每组预留空位，模拟量通道提前算好量程，程序里要用哪个点直接查表。

工艺逻辑上，改3最核心的一处调整是压力闭环方案。初版和改2都用PID直接控制变频器转速来调灌浆压力，仿真看着没问题，但工程上实际灌浆时，泵低频运行容易造成浆液沉积，压力波动很大。改3改成泵保持工频运行，PID输出给出浆比例调节阀的开度，通过改变出浆阻力来稳定压力，这个改动看着简单，实际效果天差地别。

2. 设备选型定案：为什么用1214C搭配TP700而不是其他组合

2.1 这套组合的适用边界

先交代硬件底子：PLC用的是S7-1200家族的1214C DC/DC/DC，HMI是TP700精智面板（Comfort Panel）。选这套组合不是因为“大牌稳妥”，而是算过账之后觉得它刚好卡在海洋灌浆机这个监控需求的甜点上。

CPU 1214C自带14路数字量输入、10路数字量输出和2路模拟量输入、2路模拟量输出，通道数正好覆盖一套中等规模灌浆机的核心IO需求。再加上一个模拟量扩展模块，压力、流量、液位、密度这些全都能接得下。TP700是7寸屏，分辨率800x480，在控制柜面板上尺寸合适，而且它是Comfort系列，跑WinCC Runtime Advanced，历史趋势、报警记录、用户管理都支持，不像Basic面板那样功能被砍得厉害。

如果换成S7-1500或者更大的HMI，性能是过剩的，成本却翻倍；如果选国产小PLC加文本显示器，又撑不起趋势曲线和报警归档这些功能。所以这套组合在“够用、可扩展、成本可控”这三者之间平衡得最好。

2.2 网络规划和IP分配

选型定了之后，紧接着要解决通信问题。S7-1200和TP700之间走的是Profinet，在博途V16里组态一个PN/IE网络就行。这里有一个我见过很多人犯的错：IP地址随手填，现场接线时才发现和别的设备冲突。

我的做法是：PLC站IP固定为192.168.0.1，TP700固定为192.168.0.2，子网掩码统一255.255.255.0。仿真阶段用着没问题，将来到了现场，如果要把触摸屏接到上位机或者工厂局域网，这个网段规划也不会在路由上给自己挖坑。还有一个细节：TP700的项目里要指定“接口”为集成的PN接口，连接对象选择S7-1200的PLC站，通信驱动选PROFINET，这样才能在HMI变量表里直接引用PLC符号地址。

2.3 扩展模块与接线预留

IO点数必须留余量，这是改3的硬规矩。CPU本体的10个数字量输出看着好像够了，但你还得考虑出厂后的现场改造：客户可能临时要加一路抽真空泵、一路清堵振动器，如果没有预留输出点，到时候只能外挂继电器箱，既难看又增加故障点。

我最后留了Q1.0、Q1.1两个备用输出点，模拟量输入也留了AI5备用，程序里这些备用点全部做了符号定义但暂不接线，IO表里也单独列了一个“备用”分区。仿真测试的时候，备用点还能用来模拟故障信号，一举两得。扩展模拟量模块的地址不用去记死，在博途设备组态里模块一拖上去就会自动分配地址，但要把地址登记回IO表，防止后面查线的时候对不上号。

3. IO表逐位拆解：这份表是整个监控系统的地基

3.1 数字量IO规划

第三版我把IO表当成项目的第一份正式交付物来做。数字量输入统一从I0.0开始排，按“安全类-模式类-泵类-阀类-报警类”分组，每组之间留两个空点位用于后期扩展。下面这份是实际用的表，地址我做了脱敏调整，但结构完全一致：

注意I0.0急停是常闭触点，这个点接线的意义很关键：急停回路采用硬件断电优先，即急停按下直接切断泵接触器控制回路的电源，PLC这边读到的急停信号只是用来做状态显示和故障记录。不是不信任PLC，而是安全回路必须独立于程序运行，这是海洋设备这类高可靠性场景的底线逻辑。

3.2 模拟量通道与量程换算

S7-1200 CPU本体自带模拟量输入IW64、IW66和模拟量输出QW80、QW82，扩展模块地址由组态自动分配。我这些通道的具体分配如下：

模拟量换算我统一用NORM_X和SCALE_X指令对，不建议用加减乘除硬算原始值。举例，灌浆压力IW64读出的原始值是0到27648，对应4到20mA，量程0到1.6MPa，程序里NORM_X把原始值归一化到0.0-1.0，再SCALE_X映射到0.0-1.6，输出就是实际MPa值。之所以强调这个做法，是因为HMI上显示和报警都要用工程值，而PID计算也需要一致的量纲，换算逻辑集中在一个FC里，所有测量值都走同一套函数，出问题好排查。

3.3 IO表先行的好处与排布技巧

IO表先行的最大好处不是文档漂亮，而是它能逼你在写程序之前把所有可能性都想一遍。比如泵类反馈触点，如果不在IO表阶段就规定“反馈信号必须接到PLC输入”，到接线时施工队很可能把接触器辅助触点接到硬线互锁回路里，PLC完全读不到泵的真实状态，程序里的故障判断全变成空转。

排布技巧上有一条很实用：模拟量通道号尽量和工艺顺序一致，压力、流量、液位、密度排成连续地址，仿真时在PLCSIM的IO视图里强制赋值，一眼就能看到一组连续数据变化，调试体验好很多。另外每个IO行都留一列“接线端子号”，这个可以在设备到货、接线图出来之后再补，但表结构一开始就要留好，否则后期回填的时候会非常痛苦。

4. 灌浆控制程序的模块划分与核心逻辑

4.1 OB、FB、FC、DB怎么分工

程序结构我在改3里彻底重写了，原则是“每个工艺动作一个FB，每个FB一个专属DB，公共计算放FC，周期任务丢给循环中断OB”。主程序OB1里只做调度和模式判断，不直接写设备级逻辑。

具体划分是这样的：OB1负责调用自动流程和手动模式；FC100专门做模拟量工程值换算，所有AIW原始值进来，转成工程值供全局使用；FB110灌浆泵控制，包含启停条件、运行反馈超时判断、故障停泵逻辑；FB120搅拌器控制，负责浆液搅拌和液位联锁；FB130压力调节，内部调用工艺对象PID_Compact，输出比例阀开度；OB32是循环中断块，周期设1秒，专门做流量累计和批次记录。

为什么要把流量累计放到循环中断OB里而不是OB1？因为OB1的执行时间不固定，扫描周期会随程序量波动，如果在一个不固定的周期里做“累计量 = 累计量 + 瞬时流量 × 扫描周期”，误差会累积得很离谱。循环中断OB32的周期是硬件定时保证的，1秒执行一次，累计精度可靠得多。这个细节是改3从仿真数据里对比出来的：放OB1时累计流量比实际多了将近4%，放到OB32之后误差基本可以忽略。

4.2 压力闭环：改3最关键的一处调整

压力控制是灌浆工艺里最要紧的一环。灌浆压力太高会把地层压裂，太低浆液又填充不密实，所以必须做恒压控制。前面说了，改3把控制方案从“PID控变频器”改成了“PID控比例阀”，泵工频运行保证浆液持续输送，比例阀通过改变流通面积调节出浆阻力，从而稳住压力。

PID_Compact的参数我按这样的逻辑整定：设定值SP来自HMI上的“目标灌浆压力”，过程值PV是AI_灌浆压力的工程值，输出值范围0-100对应比例阀开度。比例阀是“失电关闭”型，所以控制方向要选反作用，PID输出增大时阀开度变大、压力下降，方向反了系统会正反馈狂震，这个在仿真阶段就能看出来。

增益和积分时间我给的是“能快速响应但不过冲”的组合：增益1.8，积分时间3秒，微分不用。灌浆压力本身是慢变量，微分容易把传感器噪声放大，我试过加微分之后曲线毛刺明显变多，果断去掉。还有一个经验值值得说：PID输出要设输出限幅，比例阀开度限制在15%到85%，低于15%阀基本在憋压，高于85%阀已经接近全开，继续加大开度只会让执行机构疲劳，对压力控制没有任何帮助。

4.3 流量累计与批次记录

流量累计放到OB32里做，每1秒执行一次：批次累计量 = 上次累计值 + 瞬时流量 × 1秒，再把秒单位换算成分钟或升。瞬时流量单位是L/min，除以60再累加就是升。这个计算用REAL类型做，数据块里要分别存“批次累计量”“总累计量”“本班累计量”，HMI上可以随时查看和清零。

批次记录也是改3加的。灌浆机一个很重要的要求是“每一注浆批次都要有数据可追溯”，我建了一个批次记录DB，批次号、开始时间、结束时间、总灌浆量、平均压力、峰值压力、结束原因（正常完成/手动中止/故障急停）全都存进去。HMI用一个表格控件显示最近20条记录，操作员每完成一个批次，自动写入一条。这个功能初版没做，后来甲方提出要做质量追溯，只能回头补，补的时候才发现，如果没有提前在DB里留好数据区，后期加记录功能要把变量表动一遍，麻烦得很。

5. TP700画面组态与变量联动：监控界面不只是好看

5.1 画面层级怎么搭

TP700的画面结构我按“总览-流程-参数-趋势-报警-记录”六级来搭。主画面是设备总览，用简易的管道示意图把灌浆泵、搅拌罐、比例阀、流量计都画出来，设备运行时对应的泵图标变色，阀门开度用水平填充块实时显示。这个画面是操作员待得最久的一屏，信息密度要适中，关键数据直接放在图形旁边，一眼就能看到。

第二层是灌浆流程画面，按“冲洗-搅拌-灌浆-结束冲洗”四个步骤做成顺序控制状态显示，当前步骤高亮，下一步提示文字显示在底部。操作员在这个画面可以切换手动/自动模式，每个泵和阀旁边都有手动的启停按钮和状态灯。这里要注意一个设计原则：手动操作按钮必须在画面上有明示的“手动模式”状态指示，而且是红色底纹，防止操作员在自动模式下误触手动按钮，这个在船舶和海洋设备的操作规范里是比较看重的。

参数设定画面放目标压力、PID增益、积分时间、批次目标量等设定值，这个画面要绑用户管理权限：只有管理员组的用户才能修改PID参数，操作员只能改目标压力。TP700的用户管理在运行时配置里做，不用写PLC程序，但登录状态要在画面顶部显示，方便知道当前操作权限是谁的。

5.2 变量连接、报警与归档

TP700的变量有两种来源：一种是直接引用PLC符号地址，勾选“连接到PLC”后选择对应的PLC变量，这样HMI上的压力、流量、液位这些数据就实时同步了；另一种是HMI内部变量，只用于画面内部计算和中间逻辑，不占用PLC通信带宽。

报警组态我用离散量报警和模拟量报警混搭。离散量报警接液压站故障、泵轴承超温这些硬接点信号，触发条件选上升沿；模拟量报警接灌浆压力高限、低液位这类需要阈值判断的信号。报警文本里要带“&”变量引用，比如“灌浆压力高报警 当前值 & MPa”，触发时HMI会自动替换成实时数值，操作员不用去翻趋势图也能知道现场压力到多少了。

趋势曲线这里有一个容易忽略的点：TP700跑的是WinCC Runtime Advanced，历史数据要看“数据日志”的组态。如果不建数据日志，趋势视图只能显示当前瞬态值，历史曲线是空的。我把灌浆压力、出浆流量、搅拌罐液位三个变量组态成1秒采样周期，存到数据日志里，趋势视图运行时就能回放整个灌浆过程的曲线，这个对工况分析非常有用。仿真阶段这个功能也能验证，只要连上PLCSIM，数据日志就会跟着写入。

5.3 仿真阶段的HMI细节

HMI仿真和实物屏有一处体验差异很大：实物屏是触摸的，仿真时鼠标就是手指。画面按钮要做得足够大，至少40x40像素，否则仿真时用鼠标点起来很费劲，这也是我实际调试时体会到的。另外，TP700仿真运行时，画面切换按钮用的系统函数是“Change Screen”，但有一个坑是：仿真模式下的画面号必须和实际运行时完全一致，如果在仿真过程中调整过画面结构，必须先完整编译再启动运行系统，否则切屏可能跳到错误画面。

还有一个细节值得注意：HMI里所有涉及数值输入的地方，都要设上下限和数据类型校验。仿真时人是不看键盘直接往触摸屏里输数字的，物理屏会弹小键盘，但仿真环境不会，有时会直接吃进错误格式。我习惯把输入变量的上限下限在属性里写死，比在PLC里做限幅更提前一步，从交互上就把误操作挡在外面。

6. 博途V16联机仿真全流程：从PLCSIM到HMI Runtime

6.1 仿真前的组态检查清单

联机仿真跑通之前，有几项检查必须逐条过，漏一个都可能导致最终连接失败，我把自己的检查顺序列在这里：

1. PLC设备和TP700设备必须挂在同一个PN/IE子网下，IP地址规划好且不冲突。
2. HMI设备组态里必须建好“连接”，连接对象指向S7-1200 PLC站，不能是空连接。
3. HMI变量表里至少引用一个PLC变量，否则运行时根本不需要建立通信链路，你也就发现不了连接问题。
4. 程序完整编译，PLC侧无错误，HMI侧无错误，警告可以先不管但错误必须清零。
5. PLCSIM需要提前安装好，并且确认当前项目使用的PLCSIM版本和TIA V16匹配。

我在改2里栽过的跟头就是第2条漏了——当时HMI变量全部用的内部变量，画面能开但“PLC连接状态”显示断连，实际上我根本没建HMI和PLC之间的连接。这个检查是最容易被忽略的。

6.2 完整启动顺序与连接确认

正确启动顺序是：先在博途项目树里选中PLC，点“开始仿真”（PLCSIM），编辑下载到虚拟PLC，等PLCSIM进入RUN状态；接着再回到项目树，右键TP700设备，选“启动运行系统仿真”。这时候博途会弹出一个对话框，要求选择用来通信的PLC实例，必须勾选刚才启动的那个PLCSIM实例，确认后HMI仿真画面才会显示出来。

HMI画面起来之后，怎么看连接有没有真正建立？一个最直接的方法：在HMI画面放一个文本显示，绑PLC里的运行时间变量，如果这个数字在跳，说明通信链路是通的。或者直接看HMI运行时菜单里的连接状态，显示绿色对勾就没问题。如果显示红色断开，先回到PLCSIM看一眼PLC是不是被切到了STOP，再检查HMI连接对话框里选的实例对不对。

连接建立了，再往下就是联调验证。我在PLCSIM的IO视图里强制I0.2为1模拟灌浆泵运行反馈，然后HMI上点灌浆泵启动按钮，观察Q0.0是否置位、泵图标是否变绿、运行指示是否点亮。这套操作把PLC程序逻辑和HMI显示联动一次性验证完，不需要任何真实硬件，改3的整机逻辑就是这么在办公室调完的。

6.3 我踩过的三个仿真坑及根因

第一个坑是HMI仿真启动后找不到PLC实例。根因是我先启动了HMI运行系统仿真，后启动PLCSIM，导致弹窗选择实例时列表为空。解决办法就是严格按PLC先、HMI后的顺序来，顺序反了一切都白搭。

第二个坑是趋势曲线时间戳乱跳。仿真运行时PLCSIM和HMI各自取PC系统时间，看起来应该一样，但实际发现归档曲线的时间轴和实时数据对不上。排查下来是PC系统时间在仿真期间被某个软件改乱了。解决方式是在“控制面板-日期和时间”里勾上与网络时间同步，或者每次仿真前手工校准一次，问题基本消失。这个坑在纯PLC仿真里完全遇不到，只有PLC+HMI联机仿真的场景才会暴露。

第三个坑是PID_Compact在仿真环境下的表现。PLCSIM能跑PID指令，但没有真实压力反馈给它，工艺对象内部的状态变量不会正常变化，如果只靠仿真数据来调PID参数，得出的增益和积分时间完全不能代表现场工况。我的处理办法是：在PLC程序里加一个“仿真开关”M_SIM，置1时压力过程值不是读AIW64，而是用DB里的一个手动设定值替代，仿真时我手动改变这个值模拟压力波动，观察PID输出和比例阀开度响应。这个方法能验证闭环逻辑的正确性，但参数整定还是得等实物接完线再做。

7. 联调收尾：从仿真验证到实物的过渡经验

仿真跑通只是第一步，从仿真到实物调试之间还有一道必须补的功课。我把改3的全部IO点做一个Excel表格，打印出来带到现场，逐个点核对接线，这个工作看着枯燥但最有价值：IO表上写的是I0.2接泵反馈，如果现场线接到I0.3，程序所有逻辑全部错乱，而且非常难查。

我习惯在硬件上电之前，用PLC的强制输出功能（在实物PLC上通过在线诊断强制Q点置位）逐点测试DO回路，强制Q0.0时接触器应该吸合，强制Q0.3时阀门应该打开。DO回路测完再测DI：短接输入端子，确认PLC输入指示灯和HMI画面对应的状态变化一致。这一步做完，IO表是否正确才算真正闭环了。

模拟量通道的标定也建议在现场做一次零点和满量程测试：用信号发生器给4mA和20mA，看看PLC内部换算出的工程值是否分别是0和满量程，偏差超过0.5%就要检查接线和量程设置。不要相信仿真阶段的数据，仿真时PLCSIM里的模拟量是直接赋值进去的，不会暴露接线电阻和干扰问题，但现场一个屏蔽层接地没做好，AI值就可能飘出天际。

最后再分享一个我自己的习惯：每次仿真前把整套IO模拟一遍——强制I0.0到I1.2的每一个点置位再复位，同时盯着HMI画面看状态灯有没有跟错。这个动作看起来笨，但能帮你把IO地址错误、HMI变量关联错误、注释写错一类的低级问题全部暴露出来。仿真跑得越细，现场调试就越省劲。我在改3这个项目里，靠着仿真阶段几乎把逻辑问题全清完了，到现场之后只花了一天半就完成联调，这在以前根本不敢想象。