PLC-Recorder高频转发功能实战：5步实现Websocket/MQTT实时数据推送

PLC-Recorder高频转发实战：打通工业数据实时推送的“最后一公里”

在工业自动化与智能制造项目中，数据采集只是第一步。如何将来自PLC、传感器等设备的实时数据，稳定、高效地推送到上层的SCADA、MES、大数据平台或自定义的Web应用中，往往是决定项目成败的关键“最后一公里”。许多工程师都曾面临这样的困境：数据采集软件功能强大，但数据却像被困在孤岛，难以与更广阔的系统生态实时联动。

PLC-Recorder的高频转发功能，正是为解决这一痛点而生。它并非简单的数据导出，而是一个内置的、高性能的实时数据流引擎。通过WebSocket和MQTT这类现代工业物联网（IIoT）标准协议，它能将毫秒级变化的PLC数据，以极低的延迟（可达100ms周期）主动“推送”出去。这意味着，你的监控大屏、手机App或数据分析模型，可以像订阅新闻推送一样，实时获取产线上的每一个状态变化，而无需反复轮询查询。

本文将从一个实战者的视角，而非产品手册的复述，带你深入理解如何配置和运用PLC-Recorder的S/TR授权功能。我们将通过一个模拟的“智能产线监控”场景，手把手完成从授权选择、协议配置到与第三方软件（如Node-RED、Grafana）对接的完整流程。无论你是系统集成商、MES开发工程师，还是希望构建私有化监控平台的团队负责人，这套清晰、可复现的操作路径都将为你提供直接的参考价值。

1. 理解核心：S与TR授权的实战意义与选型策略

在开始配置之前，我们必须先厘清PLC-Recorder授权体系中与高频转发直接相关的两个关键参数：S（客户端数）和TR（转发变量数）。这直接关系到你的项目成本与系统架构的扩展性。

很多初次接触的朋友容易混淆：我采集了500个变量，是不是就需要TR500的授权？答案并非绝对。高频转发是一个“订阅-发布”模型。你采集的变量可能多达上千个，但真正需要实时推送到外部系统（如一个大屏只显示关键产量、能耗、故障状态）的变量，可能只有几十个。TR授权限制的是你配置并启用了转发功能的变量总数，而非软件采集的变量总数。这给了我们极大的灵活性，可以在成本与功能间取得平衡。

S授权（客户端数）则决定了有多少个外部系统可以同时连接到PLC-Recorder并接收数据流。你可以将其理解为数据服务的“并发连接数”。一个典型的应用场景是：一个S2授权，可以同时服务一个部署在车间的SCADA监控站（WebSocket连接）和一个云端的MES数据中台（MQTT连接）。

为了更直观地对比不同授权组合的适用场景，我结合常见项目规模整理了以下参考表：

提示：在项目规划阶段，建议先用测试版（通常包含基础的转发功能）进行原型搭建，明确实际需要转发的变量数量和客户端连接数，再决定采购何种规格的授权，避免资源浪费或后期扩容麻烦。

授权激活实操：当你获得USB-KEY硬件授权后，插入电脑，打开PLC-Recorder的授权管理界面。系统会自动识别并显示可用的授权功能列表。确保你的授权型号中包含“S”和“TR”相关代码（例如-S4-TR10-）。激活后，软件对应的高频转发配置界面才会完全可用。

2. 协议抉择：WebSocket与MQTT的深度对比与场景化配置

PLC-Recorder的高频转发支持WebSocket和MQTT两种主流协议。选择哪一种，不是简单的“哪个更好”，而是“哪个更适合你的技术栈和网络环境”。让我们抛开枯燥的理论，从实际连接和使用的角度来剖析。

WebSocket更像一条专线电话。它在PLC-Recorder（服务器）和你的客户端应用（如一个用JavaScript编写的网页看板）之间建立一条持久化的、全双工的TCP连接。一旦握手建立，数据可以在这条通道上双向、低延迟地流动。它的优势是直接、简单，特别适合浏览器端的实时应用，无需引入额外的消息代理（Broker）组件。

MQTT则像是一个广播电台系统。PLC-Recorder作为发布者（Publisher），将数据发送到一个称为MQTT Broker的中间服务器（如Mosquitto, EMQX）。任何订阅了相关主题（Topic）的客户端（订阅者，Subscriber）都可以从Broker那里收到消息。这种发布/订阅模型的优势在于解耦、可扩展性和一对多分发。一个数据源可以轻松地让成百上千个不同客户端订阅，且客户端上下线对数据源无感。

为了帮你快速决策，我列出了一个更技术细节的对比：

• 连接性质：
  • WebSocket: 点对点，直接连接。
  • MQTT: 通过Broker中转，发布/订阅模式。
• 适用场景：
  • WebSocket: 直接内网浏览器HMI、桌面客户端应用、需要双向通信（如下发控制指令）的场景。
  • MQTT: 跨网络、多客户端、移动端App、数据需要持久化或与云平台（如阿里云IoT、AWS IoT）集成的场景。
• 配置复杂度：
  • WebSocket: 只需在PLC-Recorder中开启服务并设置端口，客户端直接连接该地址。
  • MQTT: 需要额外部署/配置MQTT Broker，并在PLC-Recorder中填写Broker地址、端口、认证信息等。
• 数据过滤：
  • WebSocket: 通常由服务器（PLC-Recorder）决定推送所有已配置的变量，或由客户端在连接时通过特定握手协议订阅。
  • MQTT: 通过主题（Topic）进行天然过滤，客户端可以只订阅自己关心的数据主题，非常灵活。

实战配置步骤（以V3版本界面为例）：

1. 进入转发配置：在PLC-Recorder主界面，找到“转发”或“通信”相关配置模块，启用高频转发功能。
2. 选择协议并配置：
   • WebSocket配置：

     服务端口：例如 9000 启用SSL/TLS：根据安全需求选择（内网通常可不启用） 访问路径：例如 /ws/data

     配置完成后，PLC-Recorder会作为一个WebSocket服务器运行在ws://你的IP:9000/ws/data。
   • MQTT配置：

     Broker地址：例如 192.168.1.100 或 mqtt.你的域名.com Broker端口：默认 1883 (非加密) 或 8883 (加密) 客户端ID：PLC-Recorder_Line1 (需唯一) 用户名/密码：如果Broker启用了认证 主题前缀：例如 plc/data/line1 (所有变量数据都会发布到此主题下) QoS等级：通常选择1（至少送达一次），平衡可靠性与性能。

3. 映射变量：这是最关键的一步。你需要从已采集的变量列表中，勾选那些需要被转发的变量，并为每个变量或变量组设置一个唯一的主题或数据标识。在MQTT中，这通常是主题后缀，最终形成完整的主题如plc/data/line1/temperature。在WebSocket的自定义协议中，也可能是一个变量ID。

注意：在配置MQTT时，务必确保网络防火墙开放了PLC-Recorder所在机器到MQTT Broker的对应端口（1883/8883）的访问权限。这是初期调试中最常见的连接失败原因。

3. 数据对接实战：从PLC-Recorder到第三方应用

配置好数据出口，下一步就是让数据“流”进你的应用。我们以两个最典型的场景为例：使用Node-RED进行数据流处理，以及使用Grafana进行可视化。

场景一：使用Node-RED作为数据枢纽和逻辑处理器

Node-RED以其图形化流式编程，成为快速集成IIoT数据的利器。它既可以作为MQTT的订阅者，也可以作为WebSocket客户端。

• 连接WebSocket：

  1. 在Node-RED面板中，拖入一个“websocket in”节点。
  2. 双击配置，类型选择“Connect to”，URL填写ws://[PLC-Recorder-IP]:9000/ws/data。
  3. 部署后，该节点连接成功，一旦PLC-Recorder有数据推送，消息就会流入后续节点。你通常需要一个“function”节点来解析PLC-Recorder特定的数据格式（通常是JSON），提取出你需要的变量值和时间戳。

• 连接MQTT：

  1. 拖入一个“mqtt in”节点。
  2. 配置一个连接到你的MQTT Broker的服务器节点（如果尚未配置）。
  3. 在“mqtt in”节点中，设置订阅的主题，例如plc/data/line1/+(+是通配符，匹配单级目录)。
  4. 消息负载（payload）通常已经是结构化的JSON数据，可以直接用“change”或“function”节点进行处理。

  一个简单的Node-RED流可能长这样：MQTT输入 -> JSON解析 -> 数据过滤/计算 -> 存入数据库 或 -> 发送到另一个API。你可以在几分钟内搭建出一个实时计算设备综合效率（OEE）或异常报警的流程。

场景二：使用Grafana实现专业级实时可视化

Grafana本身不直接连接PLC-Recorder，我们需要一个“桥梁”数据库。这里以时序数据库InfluxDB为例，展示一个经典架构。

1. 数据流链路：PLC-Recorder -(MQTT)-> Node-RED -(写入)-> InfluxDB <-(查询)- Grafana
2. 具体操作：
   • 如上所述，在Node-RED中订阅MQTT主题获取数据。
   • 添加一个“influxdb out”节点，配置好InfluxDB的连接信息（地址、数据库、测量名称等）。
   • 在function节点中，将PLC数据格式转换为InfluxDB的行协议（Line Protocol）格式。例如：

     // msg.payload 结构假设为 {variable: "Motor1_Temp", value: 45.6, timestamp: 1640995200000} var measurement = "plc_metrics"; var tag = "line=1"; var field = msg.payload.variable + "=" + msg.payload.value; var timestamp = msg.payload.timestamp * 1000000; // 转换为纳秒 msg.payload = measurement + "," + tag + " " + field + " " + timestamp; return msg;

   • 在Grafana中，添加InfluxDB作为数据源，然后就可以创建仪表盘。利用Grafana强大的查询编辑器，你可以轻松绘制实时曲线图、状态指示器、历史数据表格等。

这种架构的优势在于，数据被持久化在时序数据库中，Grafana不仅可以查看实时数据，还能进行丰富的历史数据回溯和对比分析。

4. 性能调优与故障排查：确保稳定可靠的转发服务

配置成功只是开始，在7x24小时运行的工业环境中，稳定性和性能至关重要。以下是我在实际项目中积累的几个关键点和常见坑位。

性能调优要点：

• 转发周期与变量数量的平衡：高频转发虽然能达到100ms，但并非所有变量都需要如此高的频率。对于缓慢变化的参数（如环境温度、设定值），可以设置为1秒甚至更长。在PLC-Recorder的变量转发配置中，合理设置不同变量组的采样周期，能显著减轻网络和接收端系统的负载。
• 网络带宽考量：估算一下数据流量。假设每秒转发100个浮点数变量（每个约8字节），100ms周期就是每秒10次，那么原始数据流量大约是100 * 8 * 10 = 8KB/s。加上JSON等协议开销，可能达到几十KB/s。对于千兆内网微不足道，但在通过4G/5G网络传输时，就需要精打细算，考虑使用更紧凑的数据格式（如PLC-Recorder可能支持的二进制格式）或压缩。
• MQTT QoS设置：QoS 0（最多一次）性能最高，但可能丢包；QoS 1（至少一次）确保送达，但可能有重复；QoS 2（确保一次）最可靠，但开销最大。对于大多数监控场景，QoS 1是不错的选择。如果数据用于关键计费或控制，则需要更谨慎的评估和可能的重试机制。

常见故障排查清单：

1. 客户端连接不上WebSocket：

   • 检查PLC-Recorder电脑的防火墙是否放行了配置的端口（如9000）。
   • 在浏览器中尝试访问http://[PLC-Recorder-IP]:9000（如果服务启用了HTTP探测），或使用telnet [PLC-Recorder-IP] 9000检查端口是否开放。
   • 确认客户端使用的WebSocket库支持标准的WS协议。

2. MQTT连接失败或断开：

   • 使用MQTT客户端工具（如MQTTX、Mosquitto客户端）直接连接Broker，测试基础连通性。
   • 检查PLC-Recorder配置中的Broker地址、端口、用户名和密码是否正确。
   • 查看Broker的日志，看是否有连接请求被拒绝（如认证失败）。
   • 检查网络是否存在不稳定的情况，考虑调整MQTT的“心跳间隔”和“连接超时”参数。

3. 收不到数据：

   • 首先确认PLC-Recorder的采集通道本身数据是否正常（查看其内置的数据监视器）。
   • 检查需要转发的变量是否已正确“激活”转发功能，并配置了正确的主题/标识。
   • 对于MQTT，在客户端工具中订阅#通配符主题，查看是否有任何数据从PLC-Recorder发布出来，以确定问题出在发布端还是订阅端。

4. 数据延迟大：

   • 检查PLC-Recorder的采集周期和转发周期设置。
   • 检查网络延迟，使用ping命令测试到Broker或客户端的网络状况。
   • 检查接收端应用（如Node-RED、自定义程序）的处理逻辑是否存在性能瓶颈，例如复杂的同步数据库写入操作。

记住，稳定的系统是调优出来的。建议在项目上线前，进行长时间的压力测试和断网重连测试，观察系统的表现。

5. 进阶应用：构建生产级数据转发架构

当你掌握了基础的单点转发后，可以思考如何将其融入更大规模、更可靠的生产系统。这里分享两个进阶思路。

架构一：高可用与负载均衡部署

对于关键生产线，单点故障是不可接受的。你可以考虑以下部署模式：

• MQTT Broker集群：使用像EMQX这类支持集群的MQTT Broker，实现Broker层的高可用。即使一个Broker节点宕机，PLC-Recorder也能自动切换到其他节点，客户端订阅也不受影响。
• 双PLC-Recorder热备：对于极其重要的数据源，可以考虑部署两台PLC-Recorder采集同一组PLC（需PLC支持多客户端访问），并配置相同的转发规则。客户端可以同时订阅两者，或通过上层应用进行数据源择优选择。

架构二：数据分发与边缘计算融合

PLC-Recorder的高频转发可以作为边缘计算节点数据出口的完美补充。

1. 原始数据流：PLC-Recorder将最原始的、高频率的工艺数据（如电流、位置）通过MQTT转发。
2. 边缘预处理：在靠近车间的边缘服务器上，运行一个轻量级计算服务（可以用Python、Node-RED等实现），订阅这些原始数据流。
3. 计算与聚合：在边缘侧实时计算衍生指标，如设备振动频谱、能耗效率、工艺参数CPK等。这些计算密集型任务在边缘完成，减轻了云端压力，也降低了对网络带宽的依赖。
4. 结果再转发：计算后的结果指标，通过另一个MQTT主题或直接调用API，发送给云端的MES或大数据平台。这样，云端收到的是已经过提炼的、价值密度更高的信息。

安全加固建议：

• 网络隔离：将PLC网络、数据采集网络（PLC-Recorder所在）、信息网络（MQTT Broker、应用服务器）进行VLAN或防火墙隔离，仅开放必要的端口。
• 协议加密：生产环境强烈建议启用MQTT over TLS/SSL（端口8883）和WSS（WebSocket Secure）。为PLC-Recorder和Broker配置有效的证书。
• 访问控制：MQTT Broker务必启用用户名/密码认证，并为不同的客户端设置精细的ACL（访问控制列表），限制其只能订阅或发布特定的主题。

最后，我想分享一个踩过的坑：在一次部署中，我们发现MQTT数据偶尔会间断性丢失。排查了很久，最终发现是PLC-Recorder所在虚拟机的系统时间发生了跳变，导致生成的部分MQTT消息时间戳异常，被某些中间件过滤掉了。这个经历提醒我们，工业数据系统的时钟同步（NTP）至关重要，不仅是PLC、采集服务器，连同MQTT Broker、数据库和应用服务器的时钟都应保持同步，这对于基于时间序列的数据分析和故障追溯尤为关键。

PLC-Recorder的高频转发功能，就像为你的工业数据流安装了一个高效、可控的“数据泵”。它可能不是项目中那个最耀眼的前端界面，但却是确保数据血液畅通无阻的核心动脉。花时间理解它、正确配置它，你的整个数据价值链都会因此变得更加健壮和灵敏。