企业官网建设流程全解析

说实话，切纸机在车间里的地位一直挺微妙的。前面是印刷机、复合机这样的大设备，后面连着包装线，它夹在中间，看起来就是“咔嚓一刀”的动作，技术含量好像不高。可真管过车间的人都知道，这台设备一旦停下来，整个后道工序都会跟着一起等。几年前我给一家纸制品厂做设备数据采集改造，第一次把切纸机的运行数据接上Web服务器做大屏展示时，车间主任盯着屏幕看了好一会儿，说了句：“我干了二十年，第一次知道这台机器每天实际切了多少刀、停了多少次。”

这句话让我印象特别深。切纸机这类长期被忽视的“非主流设备”，反而是数据采集和远程监控投入产出比最高的对象。原因很简单：它的数据链路短、信号源明确、改造风险低，但生产价值极高。这篇文章就围绕一套完整可落地的切纸机数据采集远程监控方案，聊聊从现场设备层到Web监控层的完整链路，包括传感器怎么装、PLC数据怎么读、Modbus和MQTT怎么转换、监控平台怎么搭，以及我实际踩过的坑。

1. 切纸机为什么值得做数据采集和远程监控

很多工厂一提到数据采集，首先想到的是给大型印刷机、复合机、分切机做改造，切纸机往往排在名单最后。但从实际收益来看，切纸机反而是最应该优先做的设备。

1.1 切纸机是连续生产里的“咽喉设备”

切纸机在工艺链上的位置决定了它的重要性。前面几道工序把纸生产出来，切纸机负责把宽幅纸卷切成客户需要的尺寸，后面紧接着打包、堆垛、入库。一旦切纸机停机，前端的料没法往后走，后端的包装线没料可用，整条线都得降速或者停产。

更麻烦的是切纸机的故障往往是突发性的。刀具磨损到一定程度，切出来的纸边会出现毛刺、尺寸偏差，操作工不一定能第一时间发现；等到质检环节发现问题，可能已经连续生产了几千张次品。这种“隐性浪费”在人工巡检模式下很难避免，但有了数据采集之后，刀具寿命可以通过切割次数和振动特征来预测，完全可以在故障发生前安排换刀。

1.2 切纸机的数据采集量小、见效快

对比化工、电力行业的DCS系统，切纸机的数据采集规模小得多，一般一台设备只需要采十几个点位。这意味着实施周期短、调试难度低、成本可控。如果只是做单机监控，一套传感器加网关加云平台的方案，预算远远低于大型产线改造。

同时切纸机的电气系统普遍比较简单，很多老设备连PLC都没有，正好可以走外挂传感器方案；稍微新一点的设备带PLC和变频器，直接从控制器里读数据就行。这种灵活性让切纸机的数据采集在技术路线上非常通透。

1.3 核心数据点先盘清楚再动手

做数据采集不能上来就买设备，第一步一定是在现场把监控对象盘清楚。我总结了一份典型的切纸机数据点表，实施前对照着核对现场情况，能省很多返工时间。

这张表建议打印出来，去现场逐项核对。很多设备实际能提供的数据点比理论上少，比如老式切纸机没有刀具温度传感器，那这个点位就可以先不做；有些数据PLC里已经有了，就不需要额外再加传感器，直接通讯读取最省事。

2. 设备层方案：老设备加传感器，新设备走PLC

切纸机的型号差异很大，有老式的机械切纸机，也有带触摸屏的数控切纸机。设备新旧程度直接决定了采集方案的设计思路。

2.1 老设备改造：外部传感器方案

电气系统比较老的切纸机，可能只有几个接触器和继电器，没有PLC，也没有变频器。这种设备做数据采集，需要在现场加装外部传感器和采集模块。

常用的做法是加装一个数据采集IO模块，支持模拟量和数字量输入，然后通过RS485或者以太网接口和网关通讯。具体要加的传感器包括：

• 接近开关用于检测切刀动作和累计切割次数，安装在切刀往复运动的机械位置附近，每切一刀输出一个脉冲。
• 编码器安装在送纸辊或者切纸长度测量辊上，用于计算实际切纸长度和送纸速度。
• 电流互感器（电流变送器）卡在主电机的电源线上，输出4-20mA或0-10V信号，通过模拟量模块采集。
• 压力变送器安装在气压或液压系统的管路上，监测压力值以及压力低报警。

这种方案的好处是不动设备的原有电气回路，风险低；坏处是需要现场接线布线，施工量相对大一些。建议传感器信号线走独立的屏蔽电缆，和动力电缆保持一定距离，避免变频器干扰导致计数不准。

2.2 新设备方案：优先走PLC通讯

如果是近几年出厂的切纸机，基本都标配PLC和变频器。这种情况下不需要额外加装太多传感器，直接从PLC里读取寄存器即可。

常见的PLC品牌和通讯方式如下：

从PLC取数有几个优势。首先是数据准确性高，PLC内部已经处理过的计数、报警、速度数值，直接读取即可，不用再做传感器标定；其次是布线量少，一条通讯线就把数据全传上来；再次是便于后续增加点位，只要PLC程序里有变量，随时可以加。唯一需要注意的是向设备厂商或电气工程师要一份PLC变量表，明确每个参数对应的寄存器地址。

2.3 一个典型的PLC通讯点表设计

假设一台切纸机用的是西门子S7-200 SMART PLC，Modbus地址规划如下：

这个地址表在实施前必须和PLC程序核对，最好做一次点对点测试。我就遇到过地址偏移一位导致数据全部错乱的情况，排查了很久才发现是Modbus地址起始地址理解不一致造成的。

3. 数据上云：从Modbus到Web Server的通讯链路设计

数据采上来之后，怎么稳定地传到Web服务器，是整个方案的技术核心。这里涉及两层链路：现场设备到网关、网关到Web平台。

3.1 三段式架构：采集层、边缘层、平台层

切纸机数据采集系统通常采用三层架构。

采集层负责对接设备现场，包括传感器、PLC和采集模块，主要任务是获取原始信号和寄存器数据。边缘层是数据采集网关，负责通过Modbus RTU/TCP等协议读取采集层数据，进行协议转换、格式清洗，然后通过MQTT上传到平台层。平台层就是Web服务器，运行MQTT Broker、数据库和Web应用，实现数据存储、实时看板、历史查询和报警通知。

这套架构清晰，层次之间解耦，以后要增加设备或者更换平台都很方便。

3.2 为什么选Modbus加MQTT这对组合

Modbus的工业地位就不用多说了，几乎所有PLC都支持Modbus RTU或者Modbus TCP，现场设备端用Modbus最稳。那传输层为什么用MQTT而不是直接写数据库？

核心原因是MQTT是轻量级的发布订阅消息协议，适合弱网环境和不稳定网络，而且天然支持多设备接入。切纸机现场网络环境通常一般，直接写数据库遇到网络抖动会导致数据丢失，而MQTT的消息队列机制可以缓存数据，等网络恢复后再继续推送。另一个好处是Web端和手机端都可以订阅同一个MQTT主题，数据的实时性和多端一致性同时解决。

如果设备在同一个局域网内，也可以考虑直接用Node-RED读Modbus，再通过WebSocket推给前端，结构更简单。但如果要考虑多车间远程监控、公网访问，MQTT是更稳妥的选择。

3.3 边缘网关的选型与配置

边缘网关的选择范围很广，从几十块钱的DTU模块到几千块的工业网关都有。我个人建议根据实际现场情况选，不必盲目追求贵的。适合切纸机场景的网关需要具备以下能力：

• 支持Modbus RTU/TCP主站或者从站功能，能主动轮询PLC数据；
• 支持MQTT协议，能够把采集到的数据转换后发布到平台；
• 带一定的离线缓存能力，网络断开时不丢数据；
• 至少2路串口加1路以太网口，方便同时接多台设备；
• 支持远程配置和固件升级，省得跑现场。

网关的配置一般包括三个步骤：配置Modbus从站设备参数、配置数据采集点表、配置MQTT发布参数。

以Node-RED为例，先添加一个Modbus节点，设置PLC的IP地址和端口，一般S7-200 SMART的Modbus TCP默认端口是502；然后配置数据点表，每个点对应一个寄存器地址；再添加一个MQTT输出节点，设置服务器地址和主题，主题一般命名为factory/切纸机编号/telemetry的格式，方便后续区别设备。

3.4 Modbus采集数据的格式转换

采集到的原始Modbus数据通常是整数或者位，有时候还需要进行字节交换、大小端转换。比如累计切割次数是32位双字，读取时可能需要把高低16位合并。这里放一个常用的Node-RED函数节点示例：

let regs = msg.payload; let high = regs[0]; // 高16位 let low = regs[1]; // 低16位 let cutCount = (high << 16) + low; let telemetry = { deviceId: "sheeter-01", timestamp: new Date().toISOString(), running: regs[2], speed: regs[3] / 10.0, // 假设速度值乘以10上传 cutCount: cutCount }; return { payload: JSON.stringify(telemetry), topic: "factory/sheeter-01/telemetry" };

处理完之后，为了让数据在公网传输更稳，建议对MQTT发布设置QoS级别为1，确保消息至少送达一次。同时定期检查网关的内存占用和日志，避免网关长时间运行后的资源泄漏问题。

4. 远程监控平台搭建：Web看板、报警和报表

平台层的目标是把网关传上来的数据变成车间管理和操作工能直接看的东西。Web监控平台不需要做得特别复杂，但核心功能必须齐全。

4.1 Web监控平台的核心功能设计

一个切纸机远程监控平台，至少要包含五个模块。

实时监控看板是首选功能，用数字、仪表盘、曲线图等形式显示设备当前运行状态、速度、切割次数、报警状态，刷新频率建议控制在1-2秒，既保证实时性又不给服务器太大压力。

历史趋势查询也很重要，按时间范围查看切纸速度、电机电流、切割次数等参数的历史曲线，用于分析设备效率和工艺稳定性。这里特别建议保存“报警前后时段”的数据，方便故障复盘。

报警管理模块负责设定阈值和报警规则，报警产生后通过页面弹窗、声音提示或者消息推送给相关人员。这里可以用消息推送，但要注意推送频率别太频繁，否则大家会麻木。

生产报表模块按班次、日、月汇总统计数据，包括运行时长、停机时长、切割总次数、废品数、平均车速等，Excel导出功能几乎是标配，车间主任非常依赖这个。

设备管理模块用于维护设备档案和参数配置，记录每台切纸机的保养时间、刀具更换记录，把运维工作和数据采集结合起来。

4.2 数据存储选型与实际设计

切纸机数据的特点是写入频率高、查询以时间范围为窗口、数据量不算特别大。一台切纸机如果每5秒上报一条数据，一天大约产生17280条记录；10台设备就是17万条，一年下来大约6000万条。这个数据量用传统关系型数据库也能扛，但查询性能会逐渐变差。

更推荐使用时序数据库，比如InfluxDB或者TimescaleDB。InfluxDB使用简单，保留策略灵活，可以自动清理过期数据；TimescaleDB则是PostgreSQL扩展，适合团队熟悉SQL的情况。如果平台还要对接ERP、MES系统，TimescaleDB可能更合适，因为数据可以方便地和其他业务表关联。

这里给一个InfluxDB的数据写入示例，假设用Node.js接收MQTT消息并入库：

const mqtt = require('mqtt'); const Influx = require('influx'); const client = mqtt.connect('mqtt://your-server-ip:1883', { username: 'iot', password: 'yourpassword' }); const influx = new Influx.InfluxDB({ host: 'localhost', database: 'paper_factory', schema: [ { measurement: 'sheeter_metric', fields: { speed: Influx.FieldType.FLOAT, cutCount: Influx.FieldType.INTEGER, current: Influx.FieldType.FLOAT, alarmCode: Influx.FieldType.INTEGER }, tags: ['deviceId'] } ] }); client.on('connect', () => { client.subscribe('factory/+/telemetry'); }); client.on('message', (topic, payload) => { const data = JSON.parse(payload.toString()); influx.writePoints([ { measurement: 'sheeter_metric', tags: { deviceId: data.deviceId }, fields: { speed: data.speed, cutCount: data.cutCount, current: data.current, alarmCode: data.alarmCode }, timestamp: new Date(data.timestamp) } ]).catch(err => console.error('写入失败：', err)); });

注意InfluxDB的字段类型必须是固定的，同一个measurement里不能混用类型，否则会报错。比如speed字段第一次写入是浮点，后面就不能写成整数。

4.3 报警规则的设计不要只盯着阈值

报警是远程监控里最直接产生价值的功能，但报警规则如果设计不好，很容易变成“狼来了”的尴尬局面。我的建议是报警规则要有层级、有上下文。

基础的阈值报警比如电机电流超过额定值1.2倍、气压低于0.4MPa，这类直接报警。但更好的做法是加上时间条件，比如电流超过阈值持续5秒才报警，避免瞬时波动导致误报。第二层是状态类报警，比如设备连续30分钟无切割动作但电机仍在运行，这种状态异常比单纯参数超限更有意义，可以直接对应到“空转”或者“堵纸”。第三层是趋势类报警，比如切割长度偏差连续10次超过1mm，说明刀片已经磨损或者进纸机构有异常，这时候预警的价值很大。

报警推送建议采取分级策略：一般报警推到Web页面和邮件，关键报警推送到消息通知。消息通知最好附带设备编号和故障代码，让维修人员到场前就知道是什么问题。

下面是几种常见报警规则示例：

5. 实施过程中最容易踩的坑

数据采集远程监控，听起来是个标准方案，但现场实施时问题一个接一个。挑几个我遇到过的典型坑讲讲。

5.1 Modbus通讯不上，先查线再查配置

遇到过好几次现场报“数据采不上来”，到了现场排查发现是RS485接线A/B接反了。RS485总线看起来简单，但实际布线时需要注意很多东西：屏蔽层单端接地、终端电阻匹配、总线长度不超过1200米、分支线尽量短。如果是Modbus TCP，多半是IP地址冲突或者PLC的Modbus从站功能没有启用。

建议实施时准备一本Modbus调试工具，先用电脑直接连接PLC读取寄存器验证地址和数据类型，确认没问题再配置网关。这样能一次性把“地址错误”和“网关配置错误”两个变量隔离开，减少排查复杂度。

5.2 切割次数计数不准的问题

切割次数是切纸机数据采集里最折磨人的一个点。用接近开关计数时，如果传感器安装位置太靠近机械振动大的地方，会因为抖动产生误脉冲；如果传感器响应频率不够，高速切纸时又会漏计数。PLC内部计数器读取则要注意数据类型，16位整数最大只能计到65535，超过之后会溢出，必须用32位双字读取，并在读取时处理高低位。

另外还要考虑断电和停机的处理。建议用掉电保持型寄存器或者网关本地缓存累计值，避免设备重启后计数归零。

5.3 Web平台部署的三大注意事项

Web平台部署看起来简单，但有几个容易被忽略的细节。

外部数据库连接串里的密码千万别写在代码里直接提交到仓库，至少设置成环境变量。MQTT Broker要开启密码认证，并且每台设备用自己的账号，方便吊销权限。如果Web平台需要通过公网访问，建议用反向代理加密通道，同时开启双因素认证。

监控页面的刷新频率也要合理。很多工程师喜欢做成1秒刷新，其实切纸机的数据变化没有那么快，3-5秒刷新已经足够。刷新太快反而会给Web服务器和数据库带来不必要的压力，特别是在10台设备以上时，流量叠加不可忽略。

服务器的时间同步也很重要，如果服务器和网关的时钟不一致，时序数据就会错乱，影响报表统计。建议在网关和服务器上都配置NTP自动校时。

5.4 离线缓存和断点续传

工业网络不稳定是常态，断网几小时也是有可能的。如果网关没有离线缓存能力，网络一断就丢数据，整个监控系统形同虚设。建议选择支持SD卡缓存或者内置存储的网关，断网时把数据暂存到本地存储，等网络恢复后按时间顺序补传。

补传时注意不要一次性堆太多数据，这样容易把MQTT Broker撑爆。可以设置一个限速机制，例如每次补传100条，间隔1秒再继续传。数据库端也要注意做数据去重，防止重复写入。

6. 后续扩展的一些实用思路

切纸机的数据采集远程监控做扎实之后，很容易往更多方向扩展，这里分享几个我实际验证过比较有价值的方向。

6.1 从单机监控到多机联网报警推送

单台切纸机跑稳定了，可以把同车间的分切机、复卷机、横切机都接入同一个平台。此时只需要在MQTT主题上增加设备ID前缀，比如factory/slitter-02/telemetry，平台端的分组看板和集中报警中心就能自动适配。多设备接入后，报警规则的优先级管理就需要重点考虑了，可以按设备重要性设置报警等级，避免次要设备频繁打扰维护团队。

6.2 数据反哺生产管理

监控数据积累到一定量后，能做的事情比单纯“看状态”多得多。比如根据切纸机历史运行数据和实际产量，可以计算出每台设备的OEE（设备综合效率），找出长期效率偏低的设备进行专项改善；也可以把切割次数、刀片材质和刀具磨损数据进行关联分析，建立更准确的刀具寿命模型，把定期换刀优化为按需换刀，降低刀具成本。

6.3 联动MES和ERP

如果工厂已经有MES系统，可以把切纸机的设备状态、产量数据、报警记录通过API接口推送过去，在MES工单页面直接关联设备数据，生产管理人员无需切换到监控系统就能看到设备情况。这个集成在技术实现上不难，难点在于数据格式的梳理和接口约定，建议先输出一份详细的数据字典，再讨论接口对接方案。

6.4 移动端轻量化监控

Web平台做好之后，加一个移动端适配页面要比单独开发App划算得多。车间主任在路上、在家里都能随时打开手机看设备状态。移动端的核心不在于展示全部数据，而在于报警及时触达和快速确认。把报警确认功能做成在手机上点一下“处理中”，再把处理状态同步到Web端，整个流程就形成了闭环。

做切纸机数据采集这个项目给我最大的体会是，工业数据采集的技术门槛并没有想象中那么高，真正稀缺的是对现场设备的理解、对数据价值的判断，以及对施工细节的把控。一套方案能不能落地、能不能产生实际效益，往往取决于你有没有把每个接线端子、每个寄存器地址、每个报警策略想清楚。如果你正准备给自己的切纸机做数据采集改造，建议先花一周时间蹲在车间里，把设备的运行规律、故障类型、管理痛点摸透了再动手——这个功夫，比选什么硬件、用什么协议都值钱。