接手项目的时候对方提了一句画面都挺满意就是每天要手工导数据做报表太痛苦了。这句话让我意识到很多WinCC项目做到最后实时画面只是及格线真正决定运营方用着顺不顺手的往往是一张张交班报表、日报表和报警统计表。WinCC里攒了大量过程数据如果只是停留在能看没有输出成能交差的表格系统价值就打了对折。这篇文章就把WinCC报表这件事从头到尾捋一遍包括实现方式、选型逻辑、实操步骤和我自己踩过的坑给正在跟报表较劲的同行一个参考。1. 报表在工业监控里到底解决什么问题1.1 从能实时看到能离线交差的跨越做工业监控这么多年我越来越觉得报表不是数据功能的锦上添花而是整个系统的刚需。实时画面解决的是现在怎么样报表解决的是刚才怎么样、今天怎么样、这个月怎么样。车间主任不会一直盯着屏幕看曲线但他一定会问夜班产量多少、哪台设备停了多久、几个报警没处理。这些问题全部要落到历史数据上落到一张结构清晰、时间范围明确、数值可靠的表上。WinCC在实时性这块做得很好趋势曲线、报警视图、变量监视都很成熟但历史数据的对外输出一直是很多工程师觉得别扭的地方。原因在于WinCC的数据默认存储在后台SQL Server数据库里它不是一个直观的表格软件要让数据变成一份像样的Excel或PDF中间要自己搭桥。也正是因为这个门槛市面上才有了各种土办法和专业办法接下来我会详细讲。1.2 WinCC报表的典型应用场景我接触到的WinCC报表需求大致逃不出下面几类交接班报表每班产量、运行时间、停机时间、班内报警次数通常按8小时或12小时切分。日/周/月统计报表均值、峰值、累计量用于生产分析和绩效核算。报警统计报表报警发生时间、确认时间、恢复时间用来评估设备故障频率和处理及时性。能耗报表水、电、气、蒸汽的瞬时流量和累计流量这部分往往还要对接能源管理。质量追溯报表某个批次产品对应的关键工艺参数曲线和数据点出了问题要能倒查。这些场景的共同特点是数据量大、时间范围明确、输出格式有约定。搞清楚了需求再选实现方式才不会白忙一场。我见过太多人上来就写复杂脚本结果发现用WinCC自带的打印作业就能满足白白浪费半天时间。2. 盘点WinCC出报表的四条路线别一上来就选最难的那条2.1 打印作业只花十分钟的轻量输出WinCC自带的打印作业Print Job是最容易被忽视的报表方案。它在WinCC项目管理器里就能组态支持行打印和页面打印两种形式。行打印适合把报警消息一条条打出来像流水账页面打印适合把变量记录某个时间段的数据以表格形式输出到打印机或PDF虚拟打印机。这个方案的优点是真省事不需要写一行代码。在打印作业编辑器里新建一个作业选择数据源——报警记录或者变量记录设定时间范围和打印周期再选一台打印机一个周期性报表就出来了。很多车间每天早上自动打印一份前一天的报警清单用这个功能就能实现。缺点也很明显版式固定、不能按需求做汇总和统计比如平均值、最大值、合格率这些计算它做不了。另外它面向的是直接打印场景如果要生成Excel文件再加工它就无能为力了。所以我的判断是如果需求只是要一份数据流水打印作业是最快路径一旦涉及统计计算、格式定制、电子化存档就要考虑下面的路线。2.2 用户归档把报表需求做成工艺数据用户归档User Archive是WinCC里一个很有意思的组件。它本质上是一组可以由组态自定义结构的数据库表运行时会话里通过脚本或画面操作往里写记录。很多人用它做配方管理但其实它也可以用来做报表数据源。举个例子你可以在用户归档里建立一个班次产量记录结构字段包括班次、日期、产量、设备状态、操作员。然后写一段脚本在每次交接班时把当前统计值写入一条新记录。这样报表要的数据不是从成千上万条原始归档点里实时算出来的而是事先算好存好的。出报表的时候只需要把这些记录读出来排版就行速度快、逻辑清晰。这个方案的思路是把报表数据变成生产数据来管理。它适合业务逻辑相对固定的场景比如班次记录、批次记录、检测结果登记。但如果你要的是一张灵活的、随时可以改时间范围和数据项的报表用户归档就不太合适因为它存储的是预先定义好的结果而不是原始的底层过程数据。2.3 VBS脚本导出Excel自由度最高的万能方案如果说上面两个是WinCC正统功能那VBS脚本导出Excel绝对是广大工程师用脚投票选出来的方案。思路很简单用WinCC全局脚本里的VBS写一段程序通过ADO连接WinCC的归档数据库查询出需要的数据然后调用Excel的COM对象把数据逐行写入工作表再按模板美化格式最后保存成.xlsx文件。这条路线的核心价值在于自由。你可以完全控制报表的样式、统计逻辑、文件命名规则和存放目录。今天要一张带logo的表头明天要加一列合格率判断后天要把多个变量放在一个工作表里对比全都能改。对于交付工程师来说这种可定制性意味着再奇葩的需求都有办法兜底。代价是学习曲线和调试成本。VBS的调试不像高级语言那么舒服WinCC脚本运行时报错信息又很隐晦加上Excel COM对象的版本兼容问题新手起步时容易受挫。但从效果回报来看这是目前WinCC报表项目里性价比最高的方案也是后面我要重点实操的一条路线。2.4 数据库直连加专业报表工具面向海量数据的终局路线如果你面对的报表需求特别重比如全厂几百个变量、每分钟一批数据、要求秒级出统计结果VBS逐行写Excel就会力不从心。这时候可以让专业的报表工具直接连WinCC的SQL Server数据库把查询和展现交给报表工具来处理。常见的组合是Crystal Reports、帆软报表FineReport、甚至直接用Excel的Power Query连数据库。思路是一样的WinCC只是数据源报表工具负责写SQL、做聚合计算、设计交互式报表页面。我见过有企业用帆软做了一套Web端生产报表班组长在手机上就能看当班产量底层数据就是直连WinCC数据库取出来的。这个路线的门槛在于要懂数据库查询还要理解WinCC的归档表结构。另外要特别注意权限和性能问题——生产系统的数据库不能随便让人跑全表查询否则会影响WinCC自身的读写性能。这条路线更适合已经有IT开发能力或者专业报表团队的企业对于单个项目的交付来说可能有杀鸡用牛刀的感觉。2.5 选型判断表实现路线灵活度上手难度适合场景典型局限打印作业低极低报警流水、周期数据打印不能做汇总统计格式固定用户归档中中班次记录、批次结果、配方记录只能输出预先定义的数据VBS导出Excel高中高定制报表、多种统计、交付出报告调试麻烦大数据量偏慢数据库直连加报表工具极高高海量数据、Web报表、多部门共用涉及数据库权限维护复杂判断原则就一条够用就好别炫技。先看需求能不能用最简单的办法满足满足不了再往上走。在我做过的项目里VBS路线占了六成以上不是说另外三种不好而是大多数交付场景的报表需求用VBS已经足够灵活地覆盖了。3. 实操用VBS脚本从WinCC归档数据库生成一张班次报表3.1 开工前的组态检查归档才是报表的数据源头开始写脚本之前有一件事必须确认你要查询的变量到底有没有加到变量记录Tag Logging里做归档。很多人报表查出来是空的第一反应是脚本写错了但实际上百分之六十的情况是变量根本没有归档或者归档周期设得太大导致某个时间段里一条数据都没有。在WinCC变量管理里右键需要归档的变量打开变量记录属性确认归档选项勾上了并且在变量记录编辑器里把采集周期设置合理。比如工艺参数要求秒级分析采集周期就不能用一分钟能耗累计量要算班累计原始归档的时间间隔也不能太大否则累计精度会受影响。另外要注意WinCC的归档数据是按时间分段存储的如果你查询的时间范围跨了归档段脚本里最好做分段查询再合并否则可能只查到某一段的数据。我在项目里通常会把查询范围限制在单个班次或者单日规避分段问题。3.2 连接WinCC数据库连接串与权限WinCC运行时的数据都放在本机或服务器的SQL Server里。要用VBS查数据第一步是建立ADO连接。标准的连接字符串是这样的Dim conn Set conn CreateObject(ADODB.Connection) conn.ConnectionString ProviderSQLOLEDB.1;Data Source.\WINCC;Initial CatalogWinCC_Project001;Integrated SecuritySSPI conn.Open这里有几个坑要提前说明。Data Source里的.\WINCC指的是本机SQL Server的命名实例WINCC这是WinCC默认安装实例名。如果WinCC装在服务器上客户端脚本要从网络访问就得改成服务器名\WINCC并且要确保SQL Server允许远程连接、防火墙端口放行。Initial Catalog是项目数据库名一般和项目名一致具体可以在WinCC项目的数据库属性里查到。权限方面连接用的是Windows集成认证运行WinCC画面的用户必须对该数据库有读取权限。现场经常遇到的情况是工程师自己登录有权限但交接班操作员登录的Windows账户权限不够导致报表脚本报错。解决办法是给相关用户组在SQL Server里授予db_datareader角色或者在连接串里使用专门的只读账号。3.3 核心SQL查询与脚本实现WinCC归档数据存储在一张张以LGT_开头的表里其中数字部分是归档段编号。查询某段时间、某个变量的值典型的SQL是这样SELECT DateTime, Value FROM LGT_#01 WHERE DateTime 2025-01-01 06:00:00 AND DateTime 2025-01-01 14:00:00 AND Value IS NOT NULL ORDER BY DateTime需要注意的是表名里的#在SQL中需要处理动态拼接SQL时表名要加方括号。变量和表的对应关系可以通过系统表查到但实操中我更推荐在WinCC变量记录编辑器里直接看分配关系省得绕弯。下面是一段完整的VBS脚本框架把查询结果写入ExcelDim conn, rs, sql Dim excelApp, wb, ws, rowIndex 1. 连接WinCC数据库 Set conn CreateObject(ADODB.Connection) conn.ConnectionString ProviderSQLOLEDB.1;Data Source.\WINCC;Initial CatalogWinCC_Project001;Integrated SecuritySSPI conn.Open 2. 查询班次数据 sql SELECT DateTime, Value FROM [LGT_#01] _ WHERE DateTime 2025-01-01 06:00:00 _ AND DateTime 2025-01-01 14:00:00 ORDER BY DateTime Set rs conn.Execute(sql) 3. 创建Excel对象 Set excelApp CreateObject(Excel.Application) excelApp.Visible False Set wb excelApp.Workbooks.Add() Set ws wb.Worksheets(1) 4. 写入表头和数据 ws.Cells(1, 1).Value 时间 ws.Cells(1, 2).Value 过程值 rowIndex 2 Do While Not rs.EOF ws.Cells(rowIndex, 1).Value rs.Fields(DateTime).Value ws.Cells(rowIndex, 2).Value rs.Fields(Value).Value rowIndex rowIndex 1 rs.MoveNext Loop 5. 保存文件 wb.SaveAs D:\Reports\ShiftReport_20250101.xlsx wb.Close False excelApp.Quit 6. 释放对象 Set rs Nothing Set conn Nothing Set ws Nothing Set wb Nothing Set excelApp Nothing这段脚本覆盖了连接、查询、写表、保存、释放完整链路。实际项目里还要加错误处理比如数据库连接失败时要弹出提示而不是让脚本默默崩溃。另外Excel对象的释放一定要做干净否则多次运行后会有一堆Excel进程残留在服务器上时间长了内存越占越多这个坑下面专门说。3.4 触发方式和报表文件组织脚本写完之后要考虑什么时候运行。WinCC里触发VBS脚本的方式主要有三种画面按钮点击、全局脚本周期触发、报警或变量事件触发。画面按钮操作员交接班时自己点一下生成报表最直观。周期触发用全局脚本的周期执行功能每天凌晨自动生成昨日报表。注意周期触发有最小时间限制通常用于每天一次或每小时一次的场景。事件触发比如某个变量变为1时生成报表适合批次结束自动出报告的场景。文件组织上我习惯把报表按日期分目录存放比如D:\Reports\2025\01\文件名带班次标记例如20250101_DayShift_Line1.xlsx。这样后续查找历史报表非常方便。还要定期清理过期报表不然硬盘会被塞满这看起来是小事但在无人值守的服务器上真会出问题。3.5 为什么要这样做设计逻辑说明可能有同行会问既然WinCC自带了趋势控件和表格控件为什么不直接在画面上显示报表非要导成Excel原因有两点。第一报表的使用者往往不在操作站前面。车间主任、生产调度、质量管理他们需要的是能在自己电脑上打开、能打印、能转发给别人的文件而不是跑去现场看某个操作画面。第二Excel是各岗位都认的通用格式。生产数据一旦落到Excel里可以继续做二次分析、做PPT、传系统这是WinCC自带控件给不了的开放性。所以数据库查询加Excel输出这套设计本质上是把WinCC从封闭的监控系统变成了开放的数据服务报表只是这个服务的第一层应用。4. 报表背后必须搞懂的WinCC数据组织方式4.1 归档数据是怎么落进SQL Server的WinCC的变量记录组件会按照你设定的采集周期周期性读取PLC里的变量值然后写入SQL Server数据库。这个过程是WinCC运行时自动完成的不需要你干预。但底下有几个细节直接影响报表准确性。第一点是采集周期和存储周期的区别。采集周期决定CPU多久去读一次值存储周期决定这些值多久写一次数据库。两者可以不同例如采集周期1秒存储周期30秒数据库里实际记录的是每30秒一个快照。报表查到的数据粒度是存储周期决定的不是采集周期。第二点是归档段。为了避免单张表无限增长WinCC会把数据按时间分成多个段每个段对应一张LGT_#xx表。段的切换时机和大小可以在变量记录属性里配置。查询时要意识到你查的是当前激活的段还是历史段如果跨段查询建议用系统提供的视图或联合查询方式。第三点是压缩数据。WinCC可以提供平均值、瞬时值、最大值、最小值等压缩归档用来减少磁盘占用并加快查询。如果报表只需要看趋势平均值直接查压缩数据段比查原始数据快一个数量级。这个优化手段在数据量大时特别好用。4.2 关键数据表结构认知虽然WinCC版本不同表结构细节会有差异但核心逻辑是相通的。变量归档数据表通常包含时间戳、数值、质量代码这几个核心列。时间戳记录该条数据的采集时刻数值列存储过程值质量代码表示该值的可靠性状态。报警记录表则是每一条报警消息一行包含报警编号、触发时间、确认时间、恢复时间、报警文本等字段。在写查询脚本时最常用的是按时间范围过滤数据。SQL层面要特别注意时间的格式和时区。WinCC里显示的时间通常是你组态时的本地时间但数据库存储时涉及UTC转换如果服务器时区设置不对查询结果会发现所有时间都偏移了几个小时。这个坑我至少遇到三次每次排查到最后都是时区问题。4.3 时间戳、采集周期和质量代码是三个最容易翻车的地方报表数据不对多半不是脚本语法问题而是数据本身的三个属性出了问题。时间戳的问题除了时区偏移还有时间不同步。很多现场的工控机和PLC之间没有做NTP时间同步PLC记录的报警时间可能和WinCC服务器时间差几分钟甚至更多。报表里如果混用了不同时间源的数据排序和统计都会乱。采集周期的问题主要是采集间隔太疏导致的数据盲区。比如一台设备瞬时温度波动很快但你一分钟才采一次报表里看到的峰值就永远小于实际峰值。这种问题在为什么报表显示最高温度只有80度实际都超90度了的质疑里非常典型。质量代码的问题常常被忽略。PLC通讯闪断、设备断电、变量被手动置位都会产生带质量问题的数据。如果报表不区分好坏值直接把坏值统计进平均值或累计量结果会有明显偏差。查询时加一层质量过滤或者至少在报表里把坏值单独标记出来是一个值得养成的习惯。5. 报表实施中的故障排查与性能优化5.1 报表空白或数据对不上完整排查链路这是报表交付里最常被问的问题。一张表跑出来是空的或者和现场实际值对不上大多数人第一反应是改脚本但脚本往往是无辜的。按下面这条链路排查能省很多时间。先确认时间范围。把报表里设置的开始和结束时间原样拿出来在SQL Server Management Studio里手动执行一遍看有没有数据。如果手动查有数据、报表没数据那是传参问题如果手动查也没数据说明查询本身针对的时间段没有归档记录要么变量当时没归档要么归档被停止了。再确认表名和变量对应关系。WinCC项目的归档表不止一张而且归档段切换后数据可能分散在不同表里。用错表名查不到数据是常见低级错误但也确实会发生。我习惯在脚本初期加一段诊断输出把当前正在查的表名、时间范围、记录数都写到日志文件里跑一次就清楚了。接着确认权限。数据库连接串、Windows用户权限这些在前面说过就不再展开了。最后才是检查脚本本身的逻辑比如循环写入时的行号计算、字段名拼写、类型转换。按这个顺序排查大部分问题都能在十分钟内定位。5.2 Excel导出偶发失败与进程残留VBS调用Excel看着简单实际运行中最大的敌人是Excel进程残留和权限隔离。先说进程残留。脚本每次创建一个Excel.Application实例如果脚本中途出错退出或者没有执行到Quit那一步这个Excel进程就不会销毁。反复运行几十次服务器上会积累大量看不见的Excel进程每个都占用几十上百兆内存最终导致系统卡顿甚至新Excel无法正常启动。我的习惯是脚本开头先清理一次残留进程用WMI查询并结束所有EXCEL.EXE进程。虽然暴力但对报表服务器这种专用环境来说效果比优雅释放更好。另外确保脚本每一步都加了On Error Resume Next和状态判断尽量保证能走到对象释放那一段。再说权限隔离。WinCC画面运行在用户会话里如果这个用户没有权限创建Excel对象比如受限的域账户脚本会直接报错。解决办法是给运行用户赋予本机普通用户权限或者把报表服务独立出来用专门账户运行。曾经有人试图在Service账户下操作Excel会遇到桌面交互问题这也是一个要避开的坑。5.3 数据量大时怎么让报表跑得快报表慢到没法用的场景一般发生在数据量达到百万级以上。这时候再去优化逐行写入Excel已经没意义了要从查询效率上动手。第一避免全表扫描。永远用时间范围作为第一过滤条件并且尽量让查询落在索引能够命中的范围。WinCC归档表上通常有时间索引只要SQL写法不导致隐式类型转换查询速度就不会太差。第二能用聚合查询就不要把原始数据拉到本地算。求一班平均值直接在SQL里用AVG函数把每秒一条的原始数据压缩成一条结果再写入Excel。这样网络传输量和Excel行数都大幅减少报表生成时间可以从几分钟降到几秒。第三考虑查压缩数据段。如果业务只需要看分钟级、小时级趋势就不要查秒级原始数据。用WinCC的压缩归档作为数据源数据量直接缩小几十倍对双方都是减负。第四如果是周期性自动报表可以把报表生成安排在凌晨数据量少的时候错开操作高峰。同时注意WinCC自身的归档进程和报表查询同时进行时磁盘IO会互相影响生产系统上尤其要留意。6. 做报表这几年我的几点体会每次做完一套WinCC报表我都会问自己一个问题如果明天操作员不用这个报表是因为它不好用还是因为根本不需要答案可以帮我判断需求理解是否到位。有个体会是真实的报表的需求永远会变。今天要班报下个月就要周报再过几个月要把合格率加进去。所以我在设计脚本时从不把数据源写死在代码里而是尽量通过配置文件或WinCC变量来设置查询对象和时间范围。这样后续调整需求时改配置比改脚本安全得多也不容易引入新问题。另一个体会是报表不只是技术活更是沟通活。好的报表要让看的人三秒内找到他想看的数据而不是扔给他一张密密麻麻的原始数据表。字段命名要贴近业务语言比如产量而不是Var001_Avg单位要标清楚时间范围要写明白异常数据要有标记。这些东西比脚本写得漂亮更能决定项目能不能顺利验收。如果你正在做一个WinCC报表的需求我建议先把使用者和使用场景问清楚再选实现路线。大部分人用VBS导出Excel已经能解决九成的问题少数重场景再考虑专业报表工具。先把第一步跑通后面都好说。
