这篇讲赢式科技在无锡新吴区一家零部件制造企业实施的 PLC 通讯和数据采集项目。客户有两条产线、二十多台设备，目标是把设备数据采上来做产线数字化管理。项目从点表确认到最终验收约 4 个月，下面按实施顺序展开。
项目背景和要解决的问题
客户产线以西门子 S7-1200/1500 为主，另有几台三菱设备。改造前，产量靠操作工每小时填一次白板，设备故障要等人来喊，质量追溯只能查到批次、查不到当时设备参数。管理层定了三个硬目标：设备状态实时可见、产量自动统计、质量数据能按批次追溯。
这种需求听起来标准，但真正决定项目质量的是实施细节：PLC 侧怎么配、数据怎么分层采、反控怎么保证安全。下面逐一讲。
第一步：点表三方确认，锁死范围
进场第一周不开工写代码，先做点位梳理。我们组织工艺、设备、软件三方坐在一起，逐台设备确认：采哪些点、PLC 地址是多少、数据类型、倍率和单位、该点位归谁负责。点表打印出来三方签字，作为合同附件。
这一步看着慢，实际最省钱。以前见过项目进场后口头加点位，最后变更多出一倍工作量。点表锁死后，全项目两百多个点位基本没再变更，只有两个新增点位走了书面变更单。
第二步：西门子PLC通讯配置
西门子设备走 S7 协议，PLC 侧需要客户电气工程师配合做几项配置，这些是最容易出问题的地方：
- 博途里对应 DB 块要取消"优化的块访问"，否则第三方上位机拿不到绝对地址；
- PLC 属性中勾选允许来自远程对象的 PUT/GET 通信；
- 核对实际下载的程序版本和点表地址一致，防止现场程序和图纸不符；
- 几台三菱设备通过协议网关统一转成 Modbus TCP 接入。
配置中发现一台设备的 DB 块地址和图纸对不上，最后以 PLC 内实际程序为准重新核对了这台设备的全部点位。这也说明点表确认必须对着真实程序，不能只看图纸。
第三步：数据采集架构
采集服务部署在车间工控机上，按数据性质分层设置轮询节奏：
| 数据类型 | 周期 | 例子 |
|---|---|---|
| 设备状态、报警 | 500ms | 运行/停机/故障、报警字 |
| 工艺参数 | 2s | 温度、压力、扭矩 |
| 累计量、计数 | 5s | 产量计数、通电时长 |
采集服务带断网缓存：数据库连接中断时数据写入本地队列，恢复后按时间戳补传。所有数据统一打工控机时钟，避免设备时钟漂移导致数据错位。累计量还做了防回跳处理，设备重启清零时不会把报表冲成负数。
另外，三菱设备通过协议网关接入时，我们没有把所有读请求压在同一个网关上，多台设备共用网关的做了分流，防止网关成为通讯瓶颈。这类瓶颈点要在方案阶段算清楚，不能等数据堵了再回头加设备。
第四步：上位机软件开发和反控安全
上位机用 C# WPF 开发，SQL Server 存储。画面包括产线总览、单机监控、报警中心、批次追溯和报表中心。批次号扫进站后，该批次生产过程中的关键参数自动关联，客诉时输入批次就能调出当时的设备数据。
项目含少量反控（参数调用、复位），实施上设了三道保险：指令带唯一编号和回执确认，超时自动重发只发一次；上位机二次弹窗确认；PLC 侧保留硬件联锁，任何软件指令都绕不过设备自身的安全条件。反控权限单独分配，普通操作工账号只能看不能发。
验收指标和给无锡工厂的建议
验收没有只看"系统能不能开"，而是按量化指标：采集完整率连续两周 99.9% 以上、产量计数和实际入库误差小于 0.1%、报警从发生到弹窗小于 2 秒、批次追溯 10 秒内出结果。全部达标后签字。
给无锡工厂的建议：立项时就把点表确认机制和量化验收指标写进合同，再要求供应商说明 PLC 侧配合事项，避免实施时扯皮。需要本项目脱敏资料，打 15001875806（微信同号）或发邮件到 ys_soft@163.com 索取。