如果我直接给你一段“WinCC 做污水处理界面”的标题，很多人脑子里浮现的会是那种一屏铺满管线、阀门、液位、泵，颜色艳得刺眼的画面。真做过现场的人知道，难点从来不是画几个矩形，而是在变量、通信、动态化、导航结构、报警趋势这几层之间把关系理清楚，画面对应的每一根管道后续都要能追到变量上。这篇东西围绕一套用WinCC V7.5 SP2从零组态的污水处理监控界面展开，从变量规划一直讲到自定义菜单栏、报警趋势，最后把工程文件的组织和交接方式交代清楚。适合两类人看：一类是刚接手经典版 WinCC 项目、被一堆 .pdl 文件和脚本绕晕的工程人员；另一类是 PLC 侧已经跑通、需要自己做上位界面的自控爱好者，手里有一套运行版授权，想做个像样的中控画面。整个过程不依赖博途，走的是经典 WinCC 那套图形编辑器、变量管理、全局脚本加控件的老路子，稳、可控、调试手段多，缺点也一并说。

1. 为什么这套界面最后落在经典 WinCC V7.5 SP2 上

1.1 三条硬约束把方案范围压窄了

污水处理这个场景的上位界面有个特点：画面不多，但变量密度高、状态组合多、操作工 24 小时盯着看。一个中等规模的站点，工艺段通常拆成预处理、生化、深度处理、污泥、加药、脱水几块，每块下面几十个到上百个点位。加上液位、流量、溶解氧、pH、浊度这些模拟量，整体变量规模在八百到两千点之间，属于不上不下的区间。

真正定选型的是三条约束。第一条是既有 PLC 程序不能动，S7-300 那套老程序已经在跑，DB 块地址都嵌进了下游设备厂商的接口文档里，上位侧只能去适应它，不能反过来要求改程序。第二条是操作工的习惯，现场班组已经用惯了某种操作顺序，界面的按钮位置、确认弹窗、报警确认方式最好别翻新，翻新就要重新培训，运维方最怕这个。第三条是离线可用，站点网络条件一般，界面本身不能依赖外部服务，所有资源必须落在本机工程里。

经典 WinCC 在第一条上优势明显，它的 S7 通道成熟到近乎笨重但极少出错，地址直接写 DB 号加偏移，跟 PLC 侧的程序员对表就行。第二条靠自定义菜单和确认弹窗来做适配，后面会详细讲。第三条是天然的，整个工程就是一个文件夹，复制走就能跑。

相比之下，新版的组态平台更现代，但对老 DB 地址的兼容要绕一层，而且一旦工程版本升级，老站点的授权和运行环境都要跟着动，这个成本在运维阶段会被无限放大。所以这类项目我的默认选择就是经典版，除非对方明确要求所有站点统一到新平台。

1.2 运行版点数怎么配，别一上来就买大

点数配置是新手最容易多花钱的地方。WinCC 的授权按外部变量点数分级，常见档位是 128、512、1024、2048、8192 这些，内部变量不算点数。污水处理站的实际外部点数怎么估？一个比较靠谱的算法是：模拟量点位乘以 1，数字量点位按每台设备的状态、故障、运行、就地/远程四个信号计算，再乘一个 1.15 的冗余系数。

举个具体的账：六台泵、八台搅拌器、若干电动阀和气动阀，加上各类液位流量在线仪表，粗算下来一千二百个外部点出头。这种规模配 2048 档，留出的余量足够后续加一两套在线仪表和几条信号。硬要卡到 1024 档，等现场增加设备的时候就只能升级授权，而升级授权的麻烦程度不比重新采购低多少。

还有一点经常被忽略：归档变量是否占点数。过程值归档的变量本身来自外部变量，已经计过一次；但如果你用的是“归档变量拷贝”或者做了大量冗余归档，磁盘和内存压力会上去，机器配置要跟着提。站点机柜里的工控机通常不会给你 i7 加 32G 内存，所以归档策略要在设计阶段就定下来，而不是等到运行一个月发现历史数据打不开。

1.3 先定工艺分区，再谈画面风格

界面规划顺序我建议是：工艺分区 → 每区一屏 → 悬浮菜单 → 全局报警条 → 趋势/报表入口。先分区的原因很实际，污水处理的工艺是有严格先后顺序的，进水泵把水抽上来，经过格栅、沉砂、初沉、生化、二沉、深度处理、消毒，最后排放或回用，污泥从二沉池底部排出，进浓缩、脱水。这个流程决定了操作工的心智模型，界面顺着水流方向从左往右排，他看一眼就知道自己站在哪个环节。

风格上不要追求酷炫。深灰或深蓝底、浅色管线、状态用有限的几种颜色（绿运行、灰停止、红故障、黄报警、蓝就地），这套配色是行业里几十年沉淀下来的，操作工看到绿色就认为是正常，你换成青色他能愣半秒。字体选常规的宋体或 Arial，字号在 14 到 16 px 之间，全屏运行在 1920×1080 的显示器上，最远视距两米左右能看清就够了。别用花体，别用细体，工控屏的显示效果和设计稿差得远。

2. 变量表没理清楚，画面做到一半就得全返工

2.1 按工艺段分变量组，别按设备类型分

这是我最想强调的一条。新手习惯按“泵”“阀”“仪表”分类建变量组，看着整齐，实际组态时会很痛苦，因为画面是按工艺段组织的，主界面里的泵和阀来自不同变量组，写脚本时要到处翻。正确的做法是变量组结构跟画面结构一一对应：预处理组、生化组、二沉组、深度处理组、污泥组、公共组。每组里的变量名带前缀，比如YU_P01_Run（预处理的 1 号泵运行），前缀 YU、SH、EC、SD、WN、CM 分别对应几个工艺段。

这样做的收益在写脚本时最明显。自定义菜单切换、报警过滤、趋势分组，全都按前缀来做，一个循环就能批量处理。变量名长度控制在 24 个字符以内，用下划线分隔层级，别用中文变量名，虽然经典 WinCC 支持，但跨语言环境和脚本处理时容易出问题。

变量组的另一层价值是导入导出。变量可以导出成 Excel 或者 CSV，跟 PLC 侧的地址表对一遍，比在变量管理器里一个个点开快得多。我在项目里一般会把变量表做成 Excel 维护，包含变量名、数据类型、DB 地址、量程下限、量程上限、工程单位、报警限值、备注这八列，PLC 侧和上位侧共用同一份表，有问题当场就能查出来。

2.2 结构变量在污水处理界面里的实际收益

污水处理有个特别适合结构变量的场景：同类设备的批量处理。六台进水泵，每台都是“运行、故障、就地/远程、电流”四个信号；八台搅拌器也是类似结构。用结构变量（Structure Type）定义一个“泵”类型，包含上述成员，然后在变量管理器里实例化六次，成员地址自动按偏移递推。

结构变量真正的好处不在省事，在于画面对象可以复用。你在一个泵的图形里绑定了结构变量实例名，把这一组图形打成自定义对象，复制六个出来，每个只改变量前缀，其余全部继承。后期要加一个“累计运行小时”的信号，只需要在结构类型里加一个成员，所有实例自动获得，画面里再加一个 I/O 域绑上去就行。

代价也要说清楚：结构变量的地址是连续偏移的，要求 PLC 那边的 DB 块结构规整。如果 DB 里泵状态和电流之间夹了别的信号，偏移就对不上，只能拆开单独建。这种情况下别硬套结构变量，老老实实建普通变量，否则后面查地址会怀疑人生。

2.3 通信与采集周期的取舍

经典 WinCC 的 S7 通道下，连接参数里有一项“采集周期”，可以设成 100ms 到 1 小时不等的档位。这里有个经验值：过程值（液位、流量、pH、DO）用 500ms 或 1s，状态位（泵、阀）用 100ms 或 250ms。

为什么状态位要快？因为操作工按了启动按钮，如果画面上泵的颜色半秒后才变，他会以为没生效，再按一次，这就是典型的误操作来源。500ms 的延迟在人眼看来已经很明显了。

为什么不全部用 100ms？因为通信负载会上去。一个连接上挂一两千个变量，全部 100ms 采集，S7-300 的通信资源会被吃掉不少，而且 CPU 的扫描周期可能被通信任务打断。实际配置里，同一批状态位可以合并在一个周期性读取的 DB 里，减少请求次数。

还有一个隐蔽的坑：变量采集周期和画面更新周期是两回事。变量采回来是 100ms，但画面对象如果设了“变量更新”为 2s，你看到的变化还是 2s 一次。图形编辑器里对象的动态对话框有个“更新周期”选项，默认跟着变量走，但如果你用的是直接连接，更新周期要在连接上设定。调不清楚的时候，界面就是会“慢半拍”，而且找不到原因。

3. 主工艺流程图的组态：管道、液位、泵状态怎么画才不卡

3.1 用图形库搭底图，别把一张位图贴上去

我见过不少项目，主界面直接拿 CAD 导出的图片当背景，然后在上面盖透明的按钮和文本。这种做法的界面看着挺像样，但后续改不动：改一个管道走向要重做整张图，加一个点位要重新对位置，而且图片缩放后文字会糊。

正规做法是用图形编辑器的标准对象和图形库拼。管道用多边形或折线（Polyline）画，设定线宽和拐角样式，双击可以进入顶点编辑模式调整走向；罐体用矩形加椭圆组合，或者直接用图形库里的“罐”对象；泵和风机用圆形加内部图形，或者从图形库里挑通用符号再改颜色。所有对象都是矢量的，缩放不失真，改起来只是移动一个顶点。

这里有个效率技巧：建一个“符号库画面”。把做好的泵、阀门、搅拌器、流量计、液位计打包成自定义对象（Customized Object），放在一个单独的 .pdl 里，主界面从这个符号库拖过来用。自定义对象可以带接口属性，比如“变量前缀”“显示文字”，拖到画面里只需要填前缀，图元内部的动态全部自动关联。

管道的画法还有一个细节：别用一个多边形画完整条管线。要从中间断开，因为后续要做流动动画或者局部变色。一条从进水泵到格栅的管道，至少拆成三段，中间留出阀门和流量计的位置，这样管道颜色变化时不会连累整个图元。

3.2 液位与管道流动的动态化做法

液位是最基本的动态。做法很简单：画一个矩形代表罐体，再画一个矩形代表液体，液体矩形的“高度”属性做动态，源变量是液位值，量程 0 到 100，目标范围 0 到罐体高度。这里要注意矩形是从上往下长的，所以液体矩形的锚点要设在底部，或者用一个“填充”属性配合剪裁。

更省事的方案是用棒图（Bar）对象，它的方向可选上下左右，绑定变量后自动按量程填充，颜色也能动态。缺点是样式比较单一，圆角、渐变这些都做不了。要好看就用矩形自己算，脚本里SetPropDouble(lpszPictureName, "LiquidRect", "Height", h);，其中 h 根据变量值算出来。

管道流动动画是另一个高频需求。经典 WinCC 没有原生的流动效果，常见三种做法：

我一般用第二种，但会控制对象数量：只在主界面的关键干管上做流动，支管不做。频率设 500ms，位移两个像素，肉眼看上去就是连续的。脚本里用一个全局内部变量做相位计数器，全局脚本每 500ms 加一，各段管道的脚本读这个计数器算自己的坐标，这样所有管道的相位是同步的，看起来不像各流各的。

液位的动态还有一个平滑问题。变量 500ms 采一次，液位在小数点后第二位跳动，如果你把矩形高度直接绑上去，液面会一跳一跳。解决办法是在脚本里做一阶滤波：新高度 = 旧高度 × 0.7 + 目标高度 × 0.3，这样液面移动是缓动的，看起来舒服很多。这个技巧在模拟量显示上通用，压力、温度都适用。

3.3 泵、阀、搅拌器的状态色与闪烁规范

状态显示要建立一套严格对应关系，不能随意：

• 绿色常亮：设备运行中，且无故障
• 灰色常亮：设备停止，允许启动
• 红色常亮：故障，禁止启动
• 黄色闪烁：报警未确认
• 蓝色常亮：就地控制，上位不可操作
• 深灰加斜杠：通信中断或数据无效

闪烁要慎用。一个画面里同时闪烁的对象超过三四个，操作工的眼睛就花了。我的做法是只有“未确认的新报警”才闪，确认之后转为常亮，这样闪烁本身就带着“需要处理”的语义。实现上用一个内部变量“有未确认报警”驱动，闪烁频率 1Hz 左右，别做太快，2Hz 以上会让人烦躁。

还有一点是关于故障信号的锁存。PLC 侧的故障位可能是瞬时的，比如过载跳闸后热继电器复位，故障位就消失了。上位界面如果直接跟随这个位，故障一闪而过，操作工根本没看见。正确做法是在 PLC 侧做锁存（用 SR 触发器记住故障），上位只负责显示，确认操作通过写一个复位位回给 PLC。如果 PLC 程序改不了，那就只能在上位侧用脚本做锁存，用一个内部变量记录故障状态，直到操作工点确认才清掉，这种方案的缺点是工程重启后锁存状态丢失，要评估能否接受。

4. 自定义菜单栏：按钮组加画面窗口的导航实现

4.1 为什么弃用系统自带菜单

经典 WinCC 运行时有系统菜单和工具栏，能显示画面树、能后退前进，但样式是 Windows 原生风格，跟工艺画面完全不搭，而且操作工容易误触。更重要的是，系统菜单无法做权限级的灰化控制，你的人机权限体系如果要求“普通操作工看不到参数设置页”，系统菜单做不到，自定义菜单几行脚本就搞定了。

自定义菜单的结构一般是这样：顶部横向一条导航栏，放五到七个主按钮（总览、预处理、生化、深度处理、污泥、趋势、报警），每个按钮下方可以展开二级菜单，主画面区域用一个或多个画面窗口承载具体内容。底部再放一条状态栏，显示当前用户、当前时间、报警总数、通信状态。

导航栏高度控制在 60 到 80 像素，按钮宽度均分，选中态用底色区分（比如未选中是深蓝、选中是亮蓝加底部高亮条）。这套东西画起来不难，难在状态管理和权限联动。

4.2 菜单按钮的选中态与脚本逻辑

选中态的经典实现是：每个按钮在“背景色”属性上做动态，源是一个内部变量MENU_ACTIVE，值等于按钮编号时显示高亮色，否则显示底色。这种方案的好处是不用写脚本刷新，变量一变所有按钮自动响应。

按钮的鼠标单击事件里，写这么一段 C 脚本：

#include "apdefap.h" void OnClick(char* lpszPictureName, char* lpszObjectName, char* lpszPropertyName) { // 设置当前激活菜单编号 SetTagWord("MENU_ACTIVE", 2); // 切换主内容区画面窗口的内容 SetPropChar(lpszPictureName, "MainWindow", "PictureName", "02_PreTreat.pdl"); // 同步更新画面标题 SetText(lpszPictureName, "TitleText", "预处理工艺段"); }

关键点是画面窗口的 PictureName 属性用SetPropChar来改，这一句比OpenPicture好得多。OpenPicture会替换当前整个画面，导致顶部导航栏也跟着消失，而画面窗口方式是“容器 + 内容”，导航栏始终在，切换只换内容区。这也是做专业界面和做练习界面的分水岭。

还有一个细节：切换画面时最好把上一个画面窗口里可能残留的操作状态清掉。比如某个阀门操作弹窗开着，切走了再切回来它还开着，容易误操作。做法是在切换前先SetPropBOOL(lpszPictureName, "ValvePopup", "Visible", FALSE);把所有弹窗先关一遍。

4.3 画面窗口嵌套的层级与命名规则

画面窗口的嵌套层级建议不超过两层。第一层是主内容区（固定占屏幕 70% 到 80% 的面积），第二层是弹出式操作面板（阀门操作、参数设置、确认对话框）。第三层嵌套会让画面刷新变慢，而且调试时找不到对象。

命名规则要定死：主内容窗口叫MainWindow，弹窗统一前缀Popup_，弹窗内部的控件前缀跟弹窗名对应。原因在于跨画面脚本寻址。WinCC 的SetPropChar第一个参数是画面名，第二个是对象名，如果你在全局脚本里操作另一个画面里的对象，画面名必须写全，对象名写错一个字母就静默失败，没有任何报错。

画面窗口的几个属性必须调对：

“适应画面”这个属性特别坑，如果勾上，内容画面会自动缩放到窗口大小，比例不对时图元会变形，管道变扁、圆变椭圆。关掉它，内容画面按设计尺寸 1:1 显示，窗口小的地方裁掉，这比变形好看得多。

4.4 用户权限与按钮灰化

经典 WinCC 的用户管理里可以建用户组，每个用户有 0 到 17 的授权等级。菜单按钮的“允许操作员控制”属性可以绑授权等级，等级不够时按钮自动灰化不可点。这一层是系统自带的，不用写脚本。

但实际问题在于运行时切换用户。有的站点要求操作工交接班时切换账号，如果画面已经打开，权限等级变化不会自动刷新按钮状态。解决办法是在登录成功后强制刷新一次当前画面：脚本里调用SetPropChar重新设置一遍主内容窗口的 PictureName（哪怕是同一个画面），触发一次重绘，权限检查就会重新执行。

还有一种场景是临时授权，比如维修人员需要进参数页调整 PID 参数，但不想给他永久权限。做法是在参数页入口按钮上加一个二次验证：点按钮弹出一个小面板，输入动态口令，验证通过后写一个内部变量TEMP_AUTH为真，参数页按钮的可见性跟着这个变量走，同时启动一个 15 分钟的倒计时脚本，时间到自动清掉。这套东西不难写，但一定要有，否则现场权限管理形同虚设。

5. 报警与趋势：让操作工从一屏里看出问题

5.1 报警分类与颜色约定

报警记录里定义的报警，类别和颜色要跟工艺重要性挂钩。我的分法是三类：

• 故障类（红色）：设备跳闸、通信中断、仪表断线，必须立即处理
• 越限类（黄色）：液位过高过低、pH 超范围、溶解氧偏低，需要关注
• 提示类（蓝色）：设备启动完成、阀门到位、自动模式切换，仅作记录

颜色在报警记录的“消息类别”里定义，运行时的报警控件会自动按类别着色。千万不要把所有报警都设成红色，一天几百条红字滚过去，操作工很快就会对红色脱敏，真正的大故障反而被淹没。

报警文本要写清楚发生了什么、在哪个设备、可能的后果。别只写“1 号泵故障”，写成“1 号进水泵故障跳闸，请检查热继电器”。看起来啰嗦，但夜班人员看到的就是这条文本，多十个字可能就是半小时的排查时间。

报警的数量控制也是个学问。一个中等站点，稳态运行时每小时新增报警超过二十条，说明限值设得太紧或者信号有抖动。常见原因是模拟量的报警限值贴着正常波动范围设，比如 pH 正常在 7.0 到 7.5 波动，限值设成 6.8 和 7.6，一天到晚报个不停。正确做法是加延时确认，报警记录里可以设置延迟时间，信号持续超出 30 秒才产生报警，瞬时抖动就被过滤掉了。

5.2 趋势控件的常用配置

趋势控件（WinCC Trend Control）配置起来有几个必调的项。时间轴默认是相对时间，操作工更习惯看“最近两小时”或者“今天 8 点到 12 点”，可以在控件属性里配置时间范围选择器。Y 轴建议按变量自动缩放而不是固定量程，因为液位和流量的数值差好几个数量级，固定量程会导致小信号在图上是一条直线。

曲线数量控制在一屏最多六条。再多就分页或者做变量选择下拉框。每条曲线的颜色要固定，并且和主界面上该变量的显示颜色一致，这样操作工在主界面看到黄色液位，切到趋势页看到黄色曲线，认知是连续的。

归档的存储策略要提前规划。过程值归档按“循环归档”配置，设置单个归档段的大小和备份段数，比如每段 100MB，保留 4 段，超过就自动覆盖最老的。这样磁盘占用是可控的，不会某天早上发现 C 盘满了导致运行时报错。归档周期建议 1 分钟，关键参数（pH、DO）可以 10 秒，别设太密，一是没必要，二是查询时拖慢响应。

5.3 报警确认与记录追溯

报警确认有两个层次：单条确认和组确认。报警控件上一般放两个按钮，一个是“确认选中”，一个是“全部确认”。全部确认要加二次确认弹窗，防止误点导致所有报警被清掉。

确认动作要写回记录，报警控件自带“确认用户”和“确认时间”列，配置上就能显示。有些站点还要求把报警导出成 Excel 存档，控件支持导出功能，配一个按钮触发Export方法即可，导出路径固定到一个共享目录或者本地指定文件夹。

历史报警的查询是运维阶段的高频需求。默认查询只能按时间范围，实际排查问题时经常是“上周三晚上那台泵到底报了什么”，这时候时间范围选择就很重要。可以在报警控件旁边放两个日期时间选择控件，把值绑定到查询条件上。这块的实现方式各个版本略有差异，稳妥的做法是查一下当前版本控件支持的方法，不要凭记忆写。

6. 联调阶段踩到的几个坑和排查过程

6.1 画面切换明显卡顿，问题不在画面本身

现象是：导航栏点切换到生化段，画面要等一秒多才出来，而且切换瞬间整个界面会闪一下白。

第一反应是画面太复杂，图元太多。数了一下，生化段大概两百多个对象，其中带动态的有一百多个，这个量在经典 WinCC 里不算大，不应该卡。用交叉索引查了一下变量引用，发现有个液位对象绑了三个不同的动态（高度、填充色、可见性），每个动态的更新周期都是 100ms，而变量本身是 500ms 采集的，白白多刷了几次。

第二个怀疑点是画面窗口的“适应画面”属性被勾上了。果然，这个属性一开，每次切换都要做一次缩放计算，两百个对象重算一遍布局，卡顿就来了。关掉之后切换时间降到三百毫秒左右。

还闪白的问题，是因为画面窗口背景色是白色，内容画面还没加载完的那一瞬间露出来了。把画面窗口背景色改成跟主界面一致的深灰，闪烁就看不出来了。这个属于纯视觉技巧，但效果立竿见影。

6.2 C 脚本写了不执行，八成是这几处

脚本不执行是最常见的求助。按经验，检查顺序是这样的：

1. 触发条件：画面对象的脚本挂在什么事件上？鼠标单击、属性变化、还是画面打开？挂错事件就永远不触发。属性变化的脚本要确认那个属性真的在变。
2. 语法错误：脚本编辑器里点“编译”，有错会提示。但要注意，画面脚本和全局脚本是两个编译入口，画面里写的脚本要在画面编辑器里编译，全局脚本在全局脚本编辑器里编译，很多人只编译了一边。
3. 变量名拼写：SetTagWord("MENU_ACTIVE", 2)里的变量名如果不存在，脚本静默失败，不报错。用变量管理器的“查找”功能确认变量存在，注意大小写。
4. 对象名拼写：SetPropChar里的对象名跟图形编辑器里的对象名必须完全一致，包括空格和特殊字符。中文对象名在这里特别容易出问题。
5. 权限：如果用户权限等级不够，脚本里的某些操作会被拒绝。

排查工具是 APDiag，经典 WinCC 自带的诊断程序，能看到脚本执行的日志和错误信息。这个工具的入口在开始菜单的工具文件夹里，很多人干了几年不知道它存在。打开它之后再复现问题，错误信息就出来了，比盲猜快十倍。

还有一个特别隐蔽的坑：C 脚本里的字符串比较。if (GetTagChar("Mode") == "Auto")这种写法是错的，C 里字符串不能这么比，要用strcmp或者strcmpi。写错了不报错，条件永远为假，脚本看起来“没反应”。这个坑我踩过不止一次。

6.3 字体、分辨率与全屏运行

设计阶段在 1920×1080 的显示器上排版，现场工控机是 1366×768，全屏一跑，右边和下边的对象直接被裁掉。这种问题要在设计阶段就规避，做法是把项目属性里的画面尺寸设成目标机的最小分辨率，在更小的画布上排版，留出边距。

字体问题也很常见。在设计机上用某种字体排好，到现场机器上没装这个字体，系统自动替换成别的，字宽变了，原本对齐的文本全歪。解决办法是只用系统自带字体，宋体、黑体、Arial、Tahoma 这几样，别用下载的艺术字体。哪怕设计师觉得不好看，稳定压倒一切。

全屏运行要隐藏系统标题栏和任务栏。经典 WinCC 运行时可以通过启动参数或者脚本调用系统的窗口 API 来隐藏，也可以直接在计算机属性里配置成全屏模式。任务栏遮挡的问题，一般是通过设置运行时的窗口置顶来解决，这个在计算机属性的“图形运行系统”里能找到对应选项。

还有快捷键的问题。默认情况下 Alt+F4 能直接关掉运行系统，操作工误按一下界面就没了。要屏蔽的话，需要在运行系统里配置热键，把关闭相关的组合键禁用掉。同时建议保留一个隐藏的退出方式，比如按住某个角落五秒，或者特定账号登录后才有退出按钮，否则运维人员自己都关不掉。

6.4 授权与运行时弹窗

运行版授权不对，界面能起来但会周期性弹提示，或者运行两小时自动退出。这是正版机制，没什么好绕的，老老实实把授权装对。要注意的是授权版本和软件版本要匹配，V7.5 SP2 的授权和更早版本的授权不通用，装错了运行时会报“授权不完整”。

还有一种情况是点数不足，外部变量超过授权点数时，超出部分的变量读不到值，界面上显示成一堆问号或者零。这种情况不会明确报错，只会表现为“某些点位没数据”。排查时用变量管理器的在线监视，看哪些变量状态异常，如果是一整批连续的变量都没数据，基本可以确定是点数超了。

另外注意演示模式的限制。没有授权时运行系统会进入演示模式，只能跑一小时，超时后自动退出。现场调试阶段经常遇到调试到一半界面没了，就是这个原因。正式投运前必须把授权装到位，并且在计算机属性里确认授权状态。

7. 工程文件的组织与交接

7.1 目录结构怎么划分才好交接

一个能交付的 WinCC 工程，不应该只是一个 .mcp 文件。实际交付时我会整理成这样的结构：

WWTP_HMI_V1.2/ ├── Project/ # WinCC 项目文件夹（含 .mcp） ├── Doc/ │ ├── 变量表.xlsx # 变量名、地址、量程、报警限值 │ ├── 画面结构说明.md # 每个 .pdl 的用途和层级关系 │ ├── 脚本清单.md # 全局脚本和画面脚本的功能说明 │ └── 操作手册.pdf # 面向操作工的简版说明 ├── Backup/ │ └── WWTP_HMI_V1.2_20240115.zip └── README.md # 版本、环境要求、启动方式

Doc目录里的东西比工程文件本身更重要。变量表是后续所有排查的基础，画面结构说明能让人在半小时内看懂这套界面是怎么组织的，脚本清单能避免接手的人误删关键逻辑。我做过的项目里，交接后出问题最多的情况就是接手人不知道某个脚本是干嘛的，删掉之后某个功能静默失效，几个月后才被发现。

README里要写清楚：软件版本（V7.5 SP2）、需要的授权点数、运行环境（操作系统版本、分辨率）、起始画面名、默认登录账号（不写密码，写账号名和密码获取方式）、以及已知的未完成项。未完成项这一条特别重要，坦诚写清楚比让人自己发现好得多。

7.2 版本管理与备份策略

WinCC 项目不适合直接用文件同步工具做版本管理，因为它的文件结构复杂，多个文件之间有引用关系，中途同步很容易出现半新半旧的状态。我的做法是按里程碑打包压缩，每次大的改动之后，把整个项目文件夹压缩成带日期的 zip，放在 Backup 目录里，同时在 README 里记一行改了什么。

压缩前有一个动作必须做：关闭项目再打包。项目打开状态下某些文件是锁定的，直接压缩可能得到不完整的工程。另外，打包之前先在软件里做一次“项目复制”（Project Duplicator 或者复制项目功能），生成一份干净的副本，再压缩副本，这样能规避很多奇怪的文件一致性问题。

备份的频率建议是每天一次，重大改动前额外做一次。磁盘上保留最近十个版本就够了，更老的传到外部存储。工控机的硬盘寿命和稳定性都不如服务器，别指望它。

7.3 现场上线前的自检清单

上线前我一般会走一遍这个清单，逐项确认：

最后两项特别容易被忽略。“关了出不来”这个情况真会发生，隐藏退出入口设得太隐蔽，自己都忘了怎么触发，只能强制结束进程，运气不好还会损坏项目文件。断电恢复测试则是模拟现场停电，工控机重新上电后，运行系统应该自动启动并停在起始画面，如果配了自动登录，还要确认登录状态正常。

工程文件交接的时候，我会当面带接手人走一遍：打开项目、找到起始画面、改一个变量看画面响应、切换几个页面、导出一次报警。这十几分钟的操作比给他一份几十页的文档管用，因为动手走过一遍，路径就记住了。文档是备查的，不是用来学的。

界面这东西，做得好不好，最终不是看截图漂不漂亮，而是看夜班人员在凌晨三点被报警叫醒之后，能不能在十秒内定位到问题在哪台设备、哪个工艺段。所有关于变量命名、菜单结构、颜色规范、报警分级的讲究，都是为这十秒服务的。我个人的习惯是，每做完一屏，自己闭上眼睛想一遍：如果现在这台泵跳了，我的第一眼会落在哪？如果落点不对，那这一屏就得改。