WinCC嵌入式Excel报表：VBS脚本驱动Excel自动生成生产报表实践

做化工车间上位机改造那会儿车间主任给我提了一个看似简单的要求每天凌晨自动生成前一天的班次产量报表文件必须是 .xlsx打开就能打印表格里要有平均值、最大值、合格率还要能按班组自动汇总。说实话WinCC 自带的报表控件不是不能做但想按他脑子里那套 Excel 习惯来呈现光是调样式、补统计公式就够折腾好几天。后来我把思路从“报表控件”切到“让 WinCC 直接驱动 Excel 生成报表”问题反而一下就解开了。这篇就把我在 WinCC 嵌入式 Excel 报表上的完整探索写出来包括技术选型、VBS 脚本、采坑记录、模板设计和最后落地的细节。如果你正在做 WinCC 项目被车间主管的报表需求反复折磨这篇文章应该能帮你少走一大段弯路。1. WinCC 里的“嵌入式 Excel 报表”到底是什么很多人听到“嵌入式”第一反应是嵌入式 Linux、MCU 开发那一类东西。但在 WinCC 的场景里“嵌入式 Excel 报表”指的是把 Excel 作为自动化对象植入到 WinCC 的运行环境中由 WinCC 的 VBS 脚本来创建 Excel 进程、打开模板、写入数据、保存文件最后让报表跟着组态系统一起自动运行。本质上是一种基于 COM/OLE 自动化的跨应用集成。1.1 自带报表控件的边界什么场景下它真不够用WinCC 自带报表能力并不弱报警记录、变量记录、趋势曲线都能出但实际项目里大家还是绕不开 Excel原因很现实。先说格式。自带的表格控件样式是“组态风格”打印出来像设备说明书车间主任要的是那种带表头、合并单元格、条件格式、自动求和、还能手工加备注的生产统计表。你让他对着 WinCC 自带报表界面去操作他大概率不接受。再说灵活性。报表需求永远是项目验收前最后冒出来的变更项。“这个班次加一列合格率”“这个区域要按设备型号分类”“周五要自动附带本周趋势汇总”如果每次需求变化都去重新组态画面、调整布局、切换归档字段交付节奏会被拖垮。Excel 模板可以在组态软件之外随便改改完保存脚本下次运行自然生效这个解耦优势非常明显。还有就是统计口径问题。生产报表里的平均值不是简单的算术平均可能是“剔除停车时段”“过滤掉量程下限”“只统计设备运行状态为自动时段的数值”。这些条件用 WinCC 自带报表很难写但在 Excel 模板里预置一个 AVERAGEIF 或者 SUMIFS 公式脚本只需要把原始数据填进对应区域统计逻辑完全交给 Excel 公式去算维护成本极低。1.2 嵌入式 Excel 报表能做到什么程度我实测下来这套方案能做到的远超“把数据导出成表格”数据源层面能读 WinCC 实时变量也能读历史归档还能读用户归档里缓存的数据。输出层面可以生成 .xlsx、.xls、.csv也能另存为 PDF 直接进打印流程。展示层面报表里可以预置单元格公式、数据有效性、条件格式、数据透视表、图表脚本只负责“填数”统计和趋势展示全交给 Excel。触发层面可以绑定画面按钮用鼠标点击生成即时报表可以用全局脚本定时器比如每天 0 点 5 分生成日报可以用变量触发比如产量累计值变化超过某个阈值就生成异常监控报表。最重要的是整套方案完全跑在 WinCC 自带的 VBS 脚本引擎里不需要额外装第三方报表软件也不需要单独的报表服务器。只要现场 Windows 环境有 Office这套逻辑就能转起来。2. 技术路径怎么选我调研过的三种方案对比在确定用 VBS 直接驱动 Excel 之前我研究过好几种实现路径这里列出来给读者一个清晰的选型参考。不同方案的实现成本、稳定性和维护难度差别还挺大的。2.1 方案一OLE 自动化脚本直接驱动 Excel这是最终采用的主流方案。思路很简单在 WinCC 的 VBS 脚本里执行CreateObject(Excel.Application)创建一个独立运行的 Excel 应用程序对象然后用这个对象的 Workbooks、Worksheets、Cells、Range 等子对象去操作文件。数据从 WinCC 里读出来直接赋给单元格最后保存退出。优点功能最全。Excel 的所有能力包括公式、图表、格式、打印设置都能用脚本控制代码写好后复用到多个项目只需换模板。缺点对运行环境要求高。Office 的版本、位宽、DCOM 权限、账户权限都会直接影响脚本稳定性需要花一点时间做环境适配。适合场景正式的生产日报、交接班报表、性能统计报表等所有“要交付给管理员长期使用”的报表。2.2 方案二CSV 中转最简单但格式受限先让 WinCC 把变量数据按文本拼成 CSV 文件写到磁盘再用 Excel 打开。适合快速调试验证数据链路或者数据量特别大、对格式完全没要求的场景。优点实现最简单稳定性极高几乎不受 Office 版本困扰只要逗号和换行别搞错就行。缺点格式很弱。没有表头合并、没有字体样式、没有公式中文编码还容易乱码。适合场景给开发人员自己核对数据、临时导出批量趋势、快速备份原始记录。这个方案我一般在项目初期用来验证变量读取逻辑是否正确。等数据链路确认无误后再切换到模板方案。2.3 方案三用户归档 Excel 模板组合WinCC 的用户归档功能User Archive可以当作一个轻量数据库使用。先把关键数据按周期写入用户归档报表脚本再读取归档数据填充到 Excel 模板里。优点数据可追溯性强。原始数据先落库后续不管报表需求怎么变数据都还在不会因为漏采丢数。缺点多一层配置。要在 WinCC 里定义归档变量、配置归档周期脚本也要多写一段读写归档的逻辑。适合场景需要审计追踪的罐区报表、批次报表或者管理层要求“必须能看到原始数据明细”的场合。2.4 三种方案怎么选直接上结论对比维度OLE 自动化CSV 中转用户归档 模板实现复杂度中高极低中格式丰富度最高最弱中高数据可追溯性一般依赖模板差最强环境依赖Office 版本/权限几乎无依赖 WinCC 配置最适合场景正式交付报表调试期验证审计类报表如果是做项目交付我强烈建议直接上第一种把功夫花在脚本健壮性和模板设计上。CSV 方案我一般只作为应急手段。用户归档方案则是在业主明确要求“修报表不能丢原始数据”时的加分项。3. 核心实战用 VBS 脚本把 WinCC 变量写进 Excel确定好技术路线接下来的核心就是写脚本。这一节从对象模型、完整示例、历史数据扩展和触发方式四个方面拆开讲。3.1 对象的层次关系先理清楚WinCC 嵌入式 Excel 报表的脚本难点不在语法而在对象模型。Excel 本身是一个多层的对象结构最顶层的Application对象代表整个 Excel 程序它下面有Workbooks集合代表所有已打开的工作簿文件每个Workbook下面有Worksheets集合代表工作簿里的 Sheet具体要操作某个 Sheet 里的单元格就用Worksheet下的Cells(row, col)或Range(A1:B2)。WinCC 侧的变量读取相对简单。在 WinCC VBS 脚本里通过HMIRuntime.Tags(变量名).Read就能把组态里建立的变量值读出来返回值是一个 Variant可以直接赋给 Excel 单元格。图形编辑器里的 I/O 域和变量是一一对应的脚本里引用的变量名必须是 WinCC 变量管理中实际存在的名字否则运行时会报“变量不存在”。理清这两个对象体系剩下的就是填数据逻辑。3.2 一个能直接用的日报生成脚本我找一个实际项目的简化版日报脚本来演示。场景是每天凌晨自动读取三个反应釜的温度平均值、最大值和当日总产量生成一张带统计公式的 Excel 报表。Dim objExcel, objWorkbook, objSheet Dim tagAvg1, tagMax1, tagValue 创建 Excel 应用对象 Set objExcel CreateObject(Excel.Application) objExcel.Visible False objExcel.DisplayAlerts False 打开预置的报表模板 Set objWorkbook objExcel.Workbooks.Open(D:\Report\Template\DailyReport.xlsx) Set objSheet objWorkbook.Worksheets(日报) 读取 WinCC 实时变量 tagAvg1 HMIRuntime.Tags(REACTOR1_TEMP_AVG).Read tagMax1 HMIRuntime.Tags(REACTOR1_TEMP_MAX).Read 写入 Excel 对应单元格 objSheet.Cells(2, 1).Value Date 日期 objSheet.Cells(2, 2).Value Time 生成时间 objSheet.Cells(2, 3).Value tagAvg1 平均温度 objSheet.Cells(2, 4).Value tagMax1 最高温度 保存并退出 objWorkbook.Save objWorkbook.Close objExcel.Quit Set objSheet Nothing Set objWorkbook Nothing Set objExcel Nothing这段脚本可以直接放在 WinCC 全局脚本编辑器的 VBS 模块里。注意几个细节首先是DisplayAlerts False必不可少。如果不关掉Excel 在关闭文件时如果检测到任何未保存内容或格式兼容问题会弹出一个模态对话框把脚本卡死在那里WinCC 那边表现就是“报表没出来Excel 进程倒挂了一堆”。其次是objExcel.Visible False让 Excel 在后台静默运行。现场操作员不需要看到可视化的 Excel 窗口弹出又消失那样反而容易引起误操作。最后是对象释放的写法。Set objSheet Nothing这种习惯务必要养成尤其是有打开动作的脚本不然你会发现任务管理器里的 EXCEL.EXE 越攒越多这个问题后面专门展开讲。3.3 从历史归档取数进阶方向日报只读当前值还不够车间经理往往要过去 24 小时的趋势数据比如“昨晚 8 点到今早 8 点每半小时一个温度点”。这个需求就不能只读变量当前值了得从 WinCC 历史归档里取数。WinCC 的历史归档数据存放在 SQL Server 里官方推荐的访问方式是 WinCC 自带的 OLEDB Provider。脚本里可以做一次 ADO 连接查询把指定时间范围内的归档数据取出来循环写入 Excel。思路大致是这样Dim conn, rs Dim connStr, sqlStr Dim startTime, endTime connStr ProviderWinCCOLEDBProvider.1;Catalog项目名;Data Sourcelocalhost\WINCC Set conn CreateObject(ADODB.Connection) conn.ConnectionString connStr conn.Open sqlStr SELECT Value, TimeStamp FROM ArchiveData WHERE TagName REACTOR1_TEMP AND TimeStamp ? AND TimeStamp ? Set rs CreateObject(ADODB.Recordset) rs.Open sqlStr, conn, 1, 1实际项目中OLEDB Provider 的连接串、数据库目录、归档表结构会随 WinCC 版本不同略有差异建议动手前先在目标环境里用查询工具连一次确认列名和时间字段写法。我自己第一次接这个功能时就是因为文档版本和现场版本不一致在连接串上浪费了两个小时。另外提醒一句直接 SQL 查归档是一把双刃剑。查询效率高、取数灵活但一旦查询条件写错时区、时间格式、变量名拼写轻则查不到数据重则把不相关的历史数据拉出来造成统计错误。拿到生产数据做报表之前一定要找一个已知结果的时段做对比验证。3.4 脚本触发方式按钮、定时、条件都能做脚本写好后触发方式的设计决定了用户体感。画面按钮触发在 WinCC 图形编辑器里放一个按钮鼠标点击事件里调用这段 VBS。适合“操作员临时需要立马出报表”的场景响应速度取决于 Excel 启动时间通常两三秒内出文件。全局脚本定时触发在全局脚本的触发器中配置周期比如每 24 小时在 0 点 5 分执行一次。适合日报、月报这种固定节奏的报表。注意设置一个延迟不要在 0 点整去执行因为归档和累计值可能还在归零或结算中。变量触发当某个控制字变量变化时触发脚本。适合“批次结束自动生成批次报告”的流程由 PLC 在配方完成时置位WinCC 检测到后自动生成报表。我最终采用的是“定时日报 按钮补报 变量触发批次报告”三合一方式覆盖了车间绝大多数使用场景。4. 实测踩坑这五个问题几乎每个项目都会遇到光有脚本能跑通 Demo 不算完嵌入式 Excel 报表真正考验人的是现场环境。这一节把我踩过的坑按出现频率排序每个都给出排查链路和最终解法。4.1 任务管理器里堆满的 EXCEL.EXE进程残留问题第一次部署时上午跑完三份日报下午远程登录现场一看任务管理器里躺了二三十个 EXCEL.EXE 进程内存占用把工控机拖得喘不过气。排查链路的起点不是脚本而是确认 Excel 进程到底是谁创建的。WinCC 脚本执行时创建的是独立的 Excel.Application 进程理论上脚本跑完调用Quit就会退出。但如果脚本中途抛出异常比如某个变量读取失败、模板文件被占用Quit这行代码根本没机会执行Excel 进程就会一直挂在后台。我当时犯了两个错误。第一个是在脚本里把保存和退出的代码放在业务逻辑最后前面任何一行报错都会跳过清理代码。第二个是脚本里重复引用了多个局部变量即使正常执行对象的引用也可能在最后释放时被持有导致Quit实际没有完全杀掉进程。解法是给脚本加一层“保底清理”逻辑在Quit之后再执行一次系统清理命令On Error Resume Next objWorkbook.Close objExcel.Quit Set objSheet Nothing Set objWorkbook Nothing Set objExcel Nothing如果现场已经堆积了顽固进程直接写一个清理函数通过 WMI 杀掉所有 Excel 进程Function KillExcelProcesses() Dim objWMI, colProcesses, objProcess Set objWMI GetObject(winmgmts:\\.\root\cimv2) Set colProcesses objWMI.ExecQuery(SELECT * FROM Win32_Process WHERE Name EXCEL.EXE) For Each objProcess In colProcesses objProcess.Terminate Next End Function这个函数可以放在定时触发器里每天凌晨生成报表前先执行一次把所有残留 Excel 进程清干净。经过这样处理之后现场的 Excel 残留问题基本绝迹。4.2 CreateObject 失败与 DCOM 权限配置脚本在开发机上跑得好好的换到现场工控机上就报“没有注册类”或“拒绝访问”。这个现象十有八九是 DCOM 权限的问题。桌面环境运行脚本时当前登录用户就是交互式用户默认有权限创建 Excel.Application。但 WinCC 运行时若以服务方式后台运行或者操作员账户是受限用户Excel 的 COM 组件默认不允许非交互用户启动。排查方法清晰直接Win R 输入dcomcnfg打开组件服务依次展开“组件服务 - 计算机 - 我的电脑 - DCOM 配置”找到“Microsoft Excel Application”项打开属性在“安全”选项卡里把“启动和激活权限”和“访问权限”都改成自定义添加运行 WinCC 的账户有时是 LOCAL SERVICE 或特定域用户并赋予“本地启动”和“本地激活”权限。这一步在施工文档里几乎不会写但对部署成功率的影响是决定性的。我第一次远程调试时没往 DCOM 想先在系统日志里翻授权错误翻了半天才对上号。4.3 Office 位宽与 WinCC 版本匹配还有一次印象很深现场装了 Office 64 位脚本一直报自动化错误。之前听说过 32 位进程调 64 位 COM 会失败但一直没当回事直到亲历一次才彻底记住。WinCC 传统架构的 VBS 脚本宿主是 32 位进程它在运行时通过 COM 调用 Excel要求 Excel 的 COM 注册表信息也必须是 32 位的。如果你装的是 64 位 Office32 位进程会找不到对应的 COM 接口表现就是“自动化错误”或者 CreateObject 成功但后面对 Workbook 的调用全部无效。解法很简单WinCC 嵌入式 Excel 报表场景统一安装 32 位 Microsoft Office。即使 Windows 系统是 64 位Office 装 32 位也一样能跑而且更兼容老项目里遗留的 ActiveX 控件。这个约束在上位机选型时就要写进采购清单否则等软件都部署完再改 Office 版本又得折腾一遍配置文件。4.4 弹窗与安全设置被忽略的隐形杀手Excel 自动化最隐蔽的坑是弹窗。脚本执行过程中如果 Excel 弹出一个对话框整个过程就会挂起等待用户点击而现场工控机是无人值守的于是报表永远卡在“生成中”。常见弹窗来源分几类文件损坏恢复提示。上次生成报表时断电了Excel 留下了恢复文件下次打开模板时弹“是否恢复”。受保护的视图。模板文件从网络共享盘拷来的Excel 默认认为来自网络的文件不安全弹保护提示。宏安全提示。模板里如果带了宏Excel 会弹“启用内容”警告。兼容性检查。xlsx 文件用到老格式函数关闭时提示格式兼容。应对方案是在CreateObject之后集中设置objExcel.DisplayAlerts False objExcel.AutomationSecurity 3 禁用宏 objExcel.AskToUpdateLinks False objExcel.AlertBeforeOverwriting False objExcel.FeatureInstall 0同时建议把模板文件统一放在本地固定目录避免每次从网络共享盘读取。“受保护的视图”可以在 Office 的信任中心设置里把本机报表目录加入受信任位置。4.5 运行账户权限与网络路径问题最后一个大坑是保存路径。脚本落地时如果把文件写进C:\Windows\System32或系统盘根目录运行账户权限不够时保存静默失败或者抛“权限被拒绝”异常。更麻烦的是这种异常往往被 wincc 脚本引擎吞掉日志里只留一条笼统的“运行时错误”排查成本极高。我的习惯是所有报表文件统一存到非系统盘下的专用目录比如D:\ReportOutput\事先在系统层面赋予 WinCC 运行账户“写入”权限。如果项目要求把报表写到网络共享目录供办公区查看务必用标准 UNC 路径并且确认运行账户对该共享目录有写入权限。跨机器权限问题比本地权限隐蔽得多现场经常出现“脚本在开发机正常在服务器上无任何报错但文件就是不出来”的情况。文件名尽量带日期时间戳避免覆盖干净。模板和工作产出文件严格分离模板只读产出文件另存。5. 从能用变好用模板设计、定时触发与自动发布脚本稳定了下一步就是把报表从“能用”打磨成“好用”。这一节讲四个细节都是在实际交付中让业主满意度明显提升的设计。5.1 模板预格式化把样式工作从脚本里挪到 Excel 里模板预格式化是我做嵌入式 Excel 报表最重要的方法论。指导思想是脚本里只写数据不写样式。所有表头、列宽、边框、字体、统计公式、条件格式全部在 Excel 模板文件里预先做好。具体做法是先用 Excel 手工做一份日报模板里面预置好固定的表头区域日期、班次、变量名、单位、时段。数据填充区留出固定的行脚本将数据按行写入。统计区用 SUMIFS、AVERAGEIFS 公式引用数据填充区比如“合格率 合格数 / 总数”。图表区插入折线图或柱状图数据源直接指向数据填充区Excel 自动刷新。这样做的好处非常明显。现场业主改需求时不需要改任何脚本直接在 Excel 模板里加一列、加一个公式、改一下图表样式保存模板即可。脚本只管往既定单元格填数模板里是什么样生成出来的报表就是什么样。脚本维护成本和需求变更是解耦的。5.2 定时调度触发器配置里的小门道WinCC 全局脚本的定时触发器有三种类型周期触发器、每日触发器、日期/时间触发器。我的经验是每天凌晨的日报别用严格的“周期触发器”用“每日触发”更清晰。比如设置每天 0 点 10 分执行这样即使凌晨网络或 PLC 有短暂波动也给了归档结算余量。月报则在每月 1 日 0 点 15 分执行。关键一点是触发时间要避开 WinCC 自身的归档压缩时段。凌晨 0 点 30 分到 2 点之间部分老版本 WinCC 会做后台数据整理如果此时频繁查询历史归档报表生成速度会明显变慢。实际项目里我把日报放在 3 点 30 分执行既避开数据结算高峰又不影响早上 6 点前的打印需求。5.3 报表自动保存与发布定时任务只是生成一个 Excel 文件还不够领导通常会要求“自动放到共享文档”或者“变成 PDF”。在 VBS 里几行代码就能实现 另存 PDF objWorkbook.ExportAsFixedFormat 0, D:\ReportOutput\DailyReport_ Year(Date) _ Month(Date) _ Day(Date) .pdf需要邮件推送的场景可以用 CDO 对象直接发 SMTP 邮件。这个功能我一般在业主明确要求时才启用因为它依赖现场邮件服务器的 SMTP 地址、端口和认证信息而且邮件投递失败会反过来干扰脚本的稳定性。如果条件允许更推荐让报表文件只写本地共享目录由业主自己的办公自动化系统去抓取。5.4 大型报表的性能优化思路当报表数据量变大比如一个月的数据逐小时展开行列数上万时逐单元格赋值会让脚本慢得难以忍受。见过最夸张的一次生成一张月报花了 12 分钟业主以为程序死了。优化的核心思路是“批量赋值”。先算好结果矩阵用二维数组一次性写入 Excel 的 Range 区域这个操作比逐单元格循环快一两个数量级Dim arrData(1 To 100, 1 To 5) 填充数组... objSheet.Range(objSheet.Cells(2, 1), objSheet.Cells(101, 5)).Value arrData另外一个性能要点是控制 Excel 的刷新行为。写数据之前把屏幕刷新关掉等全部数据写完再打开objExcel.ScreenUpdating False 大量写入操作... objExcel.ScreenUpdating True同样的报表优化后从 12 分钟降到 40 秒以内这个提升非常可观。6. 最后分享一点个人体会整套 WinCC 嵌入式 Excel 报表方案做下来我最大的感觉是——它不是一个“会不会写脚本”的问题而是一个“怎么理解现场报表需求”的问题。脚本语法半天就能学会难的是把 WinCC 的变量体系、归档体系、触发机制和 Excel 的公式、图表、格式体系捏合成一个能被车间操作员天天稳定使用的东西。过完这些坑之后我现在做项目的固定流程是先在仿真环境跑一天脚本确认 Excel 进程零残留、模板文件权限正常、历史归档取数结果与手算值一致再往现场部署。另外也想提醒一句Excel 报表虽好用但也别把所有逻辑都塞进脚本数据量太大时该用用户归档或者数据库中间层还得用否则报表本身会成为 WinCC 运行性能的拖油瓶。