简介Web组态设计器FUXA是一套面向工业控制领域的Web端组态开发工具源码适合希望快速搭建可视化监控与配置界面的前端及工业自动化开发者。项目以Vue.js构建前端视图层借助Node.js处理后端逻辑与API交互支持拖放式图形化编辑、远程配置、实时数据监控并兼容OPC UA、MODBUS等常见工业协议让不熟悉编程的工程师也能完成系统组态。资源包共1195个文件约13.92MB包含423个svg图标、271个ts脚本、117个html页面、107个js逻辑、96个css与16个scss样式以及字体、json配置、yml部署文件和fuxap工程示例结构完整覆盖前后端与资源素材。目前已有2649人学习下载。通过研读源码读者可掌握组态设计器的组件组织方式、前后端数据交互流程与工业协议接入思路并可直接复用其界面控件与工程模板快速搭建自己的Web工业监控应用。1. Web组态设计器 FUXA为什么它让传统上位机方案开始显得笨重如果你做过产线看板、设备监控或者边缘网关的本地可视化大概率经历过这样的循环先用某商业组态软件拖界面发现授权按点数收费换开源方案又卡在浏览器端实时刷新和协议适配上。FUXA 这个 Web 组态设计器解决的正是这个夹缝里的问题——它把组态编辑器和运行时都搬进浏览器用 Node.js 做后端前端基于 Angular通过 WebSocket 把设备数据推到画布上。你不需要装客户端不需要买运行时授权一台能跑 Node 的工控机或边缘盒子就能当服务端手机、平板、中控大屏打开浏览器就能看。适合谁做设备数据采集的自动化工程师、想快速搭内部监控看板的开发者、以及被商业组态授权费卡住预算的小团队。它不追求替代大型 SCADA但在「几十到几百个变量、多协议接入、快速出图」这个区间里落地速度确实比传统方案快一截。2. FUXA 的架构与协议接入从设备到浏览器画布的数据链路2.1 前后端分离的运行时结构FUXA 的部署形态很清晰一个 Node.js 服务进程对外暴露 HTTP 和 WebSocket 两个端口。HTTP 负责提供编辑器页面、项目文件和静态资源WebSocket 负责把设备侧采集到的实时值推给所有已打开的客户端。编辑器里画的图元、绑定的变量、配置的协议最终都序列化成项目文件存在服务端。运行时不需要重新编译改完保存刷新浏览器就能看到新画面。这个结构带来的直接好处是你可以在办公室的浏览器里编辑项目保存后产线上的大屏刷新一下就生效不用跑到现场去拷文件。代价是服务端必须一直在线且 WebSocket 连接质量直接决定画面刷新是否流畅。常见做法是把 FUXA 跑在一台和 PLC 同网段的边缘设备上比如一台低功耗工控机或树莓派级别的盒子。服务端只负责协议采集和转发不承担复杂计算CPU 占用通常很低。2.2 支持哪些协议怎么选FUXA 内置了多种工业协议驱动常见的有 Modbus TCP/RTU、Siemens S7、OPC UA、MQTT以及通用的 HTTP 请求。选型时按这个顺序判断场景推荐协议理由西门子 PLC已有变量表S7直接按 DB 地址读不用中间网关多品牌设备走标准OPC UA统一地址空间但配置略重仪表、电表、传感器Modbus TCP/RTU绝大多数支持寄存器地址明确设备已上报云平台MQTT订阅主题即可适合分布式第三方 HTTP 接口HTTP 请求轮询方式适合低频数据我一般会优先用 Modbus TCP因为调试工具多寄存器地址和数据类型一目了然。S7 在西门子环境里更直接但要注意 DB 块的优化访问设置否则读不到值。OPC UA 适合设备品牌杂、又不想逐个写驱动的场景但服务端证书和端点配置容易卡住新手。2.3 用 Modbus TCP 接入一个模拟设备下面这段是 FUXA 服务端启动和 Modbus 设备配置的最小操作。假设你已经在设备上装好了 Node.js 环境并且有一个模拟从站比如用 Modbus 模拟器工具开在 502 端口。# 克隆项目并安装依赖具体仓库地址以你实际获取的为准 git clone fuxa-repo-url cd fuxa npm install # 启动服务端默认端口 1881 npm start启动后浏览器打开http://设备IP:1881进入编辑器。在设备配置里新增一个 Modbus TCP 连接{ name: line1_plc, type: ModbusTCP, options: { host: 192.168.1.10, port: 502, unitId: 1, timeout: 2000 } }然后在变量表里添加标签绑定到具体寄存器{ name: motor_speed, address: 40001, type: uint16, scale: 0.1, unit: rpm }逻辑说明host和port指向你的从站设备unitId在单设备时通常为 1。address里的40001表示保持寄存器区第一个寄存器FUXA 内部会按 Modbus 功能码 03 读取。scale是线性缩放系数原始值乘以它得到工程值比如读到 1500实际显示 150.0 rpm。type必须和从站数据类型一致读 32 位浮点时要拆成两个寄存器并选 float 类型否则会出现字节序错乱。配置保存后在画布上放一个文本图元绑定motor_speed就能看到实时值。如果值不动先确认从站是否真的在响应再用 FUXA 自带的连接诊断看错误码。3. 用 FUXA 画第一张可交互看板图元、绑定与事件3.1 画布图元与变量绑定的基本操作FUXA 的编辑器是拖拽式的左侧是图元库中间是画布右侧是属性面板。画一张看板的流程通常是先放背景和分区框再放数值显示、状态指示灯、按钮最后逐个绑定变量。数值显示用文本图元属性里把「文本」改成变量绑定模式选择之前定义的motor_speed。状态指示灯用矩形或圆形图元绑定一个布尔变量然后配置颜色规则值为 true 时绿色false 时灰色。按钮用矩形加点击事件事件里可以写脚本或调用预定义动作。这里有个容易忽略的点图元的刷新频率不是单独设的它跟随变量采集周期。如果你把采集周期设成 100ms画布上所有绑定该变量的图元都会按这个节奏更新。变量多了之后WebSocket 消息量会明显上升所以采集周期要按实际需要设不要一律往快里调。3.2 用脚本处理逻辑联动FUXA 支持在事件里写 JavaScript这对做联动很有用。比如一个启动按钮按下后要把某个寄存器写 1同时弹出一个提示。// 按钮点击事件脚本 const device line1_plc; const tag start_cmd; // 写入值 1 await FUXA.writeTag(device, tag, 1); // 在画布上显示提示 FUXA.showMessage(启动命令已下发, info); // 3 秒后自动复位 setTimeout(async () { await FUXA.writeTag(device, tag, 0); }, 3000);逻辑说明FUXA.writeTag是运行时提供的写标签接口参数依次是设备名、标签名、写入值。showMessage在页面顶部弹提示第二个参数是级别。setTimeout做延时复位避免命令一直保持。注意写操作是异步的如果连续写多个标签最好用await串行否则可能因为协议层排队导致顺序错乱。参数上start_cmd对应的寄存器地址要提前在变量表里配好类型选线圈或保持寄存器取决于你的设备要求。写线圈用功能码 05写保持寄存器用 06 或 16FUXA 会根据变量类型自动选。3.3 多页面与导航的组织方式一个项目通常不止一张画面。FUXA 支持多页面左侧页面列表里可以新建、重命名、调整顺序。导航按钮绑定页面切换动作或者用脚本FUXA.openPage(pageName)。我一般会按「总览 → 分区 → 设备详情」三层来组织。总览放关键指标和报警汇总分区放该区域的设备状态详情放单个设备的参数和操作。页面切换时只有当前页面的图元会渲染后台变量采集不受影响所以切页不会丢数据。如果页面很多建议在命名上加前缀比如ov_表示总览zn_表示分区dv_表示设备这样在脚本里引用时不容易搞混。4. 避坑与排查FUXA 落地时最容易翻车的五个地方4.1 变量读到了但画布不刷新现象变量表里能看到值在变但画布上的图元一直显示初始值或零。原因图元绑定的变量名和变量表里的名称不一致或者图元所在的页面没有激活。FUXA 的绑定是按名称匹配的大小写和空格都算差异。解决在变量表里复制名称粘贴到图元绑定框不要手打。确认图元在当前打开的页面里切到别的页面再切回来看是否恢复。如果还不刷新检查浏览器控制台有没有 WebSocket 断连日志。4.2 Modbus 读回来是乱码或明显偏大的数现象寄存器读到了值但和实际工程值对不上比如温度显示 6500 而不是 25.0。原因数据类型或字节序配错了。Modbus 寄存器是 16 位的32 位浮点要占两个寄存器且不同设备的高低位顺序可能相反。解决先确认从站的数据格式手册把type改成对应的 float 或 int32然后在 FUXA 的变量配置里调整字节序选项。常见的有 ABCD、CDAB、BADC、DCBA 四种逐个试直到数值合理。缩放系数也要检查很多仪表原始值是放大 10 倍或 100 倍的。4.3 服务端跑一段时间后内存持续上涨现象FUXA 进程占用内存从几百 MB 慢慢涨到几个 GB最后被系统杀掉。原因历史数据缓存或日志没有限制。FUXA 默认会保留一定量的历史记录如果变量多、采集快内存增长会很快。解决在服务端配置里限制历史数据条数或关闭不需要的历史记录。日志级别调到 warn 或 error减少磁盘和内存写入。如果用了脚本里的定时器确认没有泄漏比如setInterval没有在页面关闭时清理。4.4 按钮写值没反应但读值正常现象数值显示正常刷新但点击按钮下发命令时设备不动。原因写操作的寄存器地址或功能码不对或者设备侧有写保护。有些 PLC 的保持寄存器区需要先使能写入权限。解决先用 Modbus 调试工具手动写同一个地址确认设备能响应。如果调试工具能写而 FUXA 不能检查变量类型是否选成了只读。线圈和保持寄存器的写功能码不同类型选错会静默失败。另外注意unitId多从站时写错站号也会没反应。4.5 浏览器打开慢或画面卡顿现象编辑器加载要十几秒运行时画面切换有明显延迟。原因项目里图元太多、图片资源太大或者 WebSocket 消息频率过高。解决把大图压缩后再导入避免在画布上放几百个独立图元能用组合的用组合。采集周期从 100ms 放宽到 500ms 或 1s对大多数监控场景足够。如果必须高频考虑在服务端做聚合只把变化量推给前端。5. 进阶用 FUXA 做报警记录与外部系统对接报警是组态软件里最容易被低估的部分。FUXA 本身有报警配置可以给变量设阈值和死区触发后在画布上显示报警条。但实际项目里往往还需要把报警存下来、推给外部系统。我的做法是在服务端加一层轻量处理用 FUXA 的脚本接口监听变量变化满足条件时写本地 SQLite 或发 HTTP 请求。// 在服务端脚本里监听变量做报警记录 const alarmTag motor_speed; const threshold 1200; // 对应 120.0 rpm FUXA.onTagChange(alarmTag, async (value) { if (value threshold) { const record { tag: alarmTag, value: value, time: new Date().toISOString(), level: warning }; // 写入本地记录具体存储方式按你的环境实现 await saveAlarmRecord(record); // 推送到外部接口 await fetch(http://your-api/alarm, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(record) }); } });逻辑说明onTagChange是变化触发不是轮询所以不会额外增加采集负担。阈值判断里加了简单的上限比较实际项目要加死区和延时避免抖动导致报警刷屏。saveAlarmRecord和fetch都是示意你需要按自己的存储和接口替换。注意外部请求要加超时和失败重试否则网络一断脚本可能堆积。验证报警是否生效可以手动把模拟从站的寄存器改到超限值看画布报警条是否弹出、本地记录是否写入、外部接口是否收到。三个环节逐个确认不要只看画布。最后说一个我自己的习惯每次改完项目先导出备份再上线。FUXA 的项目文件不大但一旦在编辑器里误删页面或改错绑定回滚比重新画快得多。另外服务端所在设备的系统时间要校准否则报警记录的时间戳会对不上后面查问题很麻烦。希望帮到你。本文还有配套的精品资源点击获取 FUXA Web组态设计器：浏览器端工业监控看板搭建与Modbus TCP实战
简介Web组态设计器FUXA是一套面向工业控制领域的Web端组态开发工具源码适合希望快速搭建可视化监控与配置界面的前端及工业自动化开发者。项目以Vue.js构建前端视图层借助Node.js处理后端逻辑与API交互支持拖放式图形化编辑、远程配置、实时数据监控并兼容OPC UA、MODBUS等常见工业协议让不熟悉编程的工程师也能完成系统组态。资源包共1195个文件约13.92MB包含423个svg图标、271个ts脚本、117个html页面、107个js逻辑、96个css与16个scss样式以及字体、json配置、yml部署文件和fuxap工程示例结构完整覆盖前后端与资源素材。目前已有2649人学习下载。通过研读源码读者可掌握组态设计器的组件组织方式、前后端数据交互流程与工业协议接入思路并可直接复用其界面控件与工程模板快速搭建自己的Web工业监控应用。1. Web组态设计器 FUXA为什么它让传统上位机方案开始显得笨重如果你做过产线看板、设备监控或者边缘网关的本地可视化大概率经历过这样的循环先用某商业组态软件拖界面发现授权按点数收费换开源方案又卡在浏览器端实时刷新和协议适配上。FUXA 这个 Web 组态设计器解决的正是这个夹缝里的问题——它把组态编辑器和运行时都搬进浏览器用 Node.js 做后端前端基于 Angular通过 WebSocket 把设备数据推到画布上。你不需要装客户端不需要买运行时授权一台能跑 Node 的工控机或边缘盒子就能当服务端手机、平板、中控大屏打开浏览器就能看。适合谁做设备数据采集的自动化工程师、想快速搭内部监控看板的开发者、以及被商业组态授权费卡住预算的小团队。它不追求替代大型 SCADA但在「几十到几百个变量、多协议接入、快速出图」这个区间里落地速度确实比传统方案快一截。2. FUXA 的架构与协议接入从设备到浏览器画布的数据链路2.1 前后端分离的运行时结构FUXA 的部署形态很清晰一个 Node.js 服务进程对外暴露 HTTP 和 WebSocket 两个端口。HTTP 负责提供编辑器页面、项目文件和静态资源WebSocket 负责把设备侧采集到的实时值推给所有已打开的客户端。编辑器里画的图元、绑定的变量、配置的协议最终都序列化成项目文件存在服务端。运行时不需要重新编译改完保存刷新浏览器就能看到新画面。这个结构带来的直接好处是你可以在办公室的浏览器里编辑项目保存后产线上的大屏刷新一下就生效不用跑到现场去拷文件。代价是服务端必须一直在线且 WebSocket 连接质量直接决定画面刷新是否流畅。常见做法是把 FUXA 跑在一台和 PLC 同网段的边缘设备上比如一台低功耗工控机或树莓派级别的盒子。服务端只负责协议采集和转发不承担复杂计算CPU 占用通常很低。2.2 支持哪些协议怎么选FUXA 内置了多种工业协议驱动常见的有 Modbus TCP/RTU、Siemens S7、OPC UA、MQTT以及通用的 HTTP 请求。选型时按这个顺序判断场景推荐协议理由西门子 PLC已有变量表S7直接按 DB 地址读不用中间网关多品牌设备走标准OPC UA统一地址空间但配置略重仪表、电表、传感器Modbus TCP/RTU绝大多数支持寄存器地址明确设备已上报云平台MQTT订阅主题即可适合分布式第三方 HTTP 接口HTTP 请求轮询方式适合低频数据我一般会优先用 Modbus TCP因为调试工具多寄存器地址和数据类型一目了然。S7 在西门子环境里更直接但要注意 DB 块的优化访问设置否则读不到值。OPC UA 适合设备品牌杂、又不想逐个写驱动的场景但服务端证书和端点配置容易卡住新手。2.3 用 Modbus TCP 接入一个模拟设备下面这段是 FUXA 服务端启动和 Modbus 设备配置的最小操作。假设你已经在设备上装好了 Node.js 环境并且有一个模拟从站比如用 Modbus 模拟器工具开在 502 端口。# 克隆项目并安装依赖具体仓库地址以你实际获取的为准 git clone fuxa-repo-url cd fuxa npm install # 启动服务端默认端口 1881 npm start启动后浏览器打开http://设备IP:1881进入编辑器。在设备配置里新增一个 Modbus TCP 连接{ name: line1_plc, type: ModbusTCP, options: { host: 192.168.1.10, port: 502, unitId: 1, timeout: 2000 } }然后在变量表里添加标签绑定到具体寄存器{ name: motor_speed, address: 40001, type: uint16, scale: 0.1, unit: rpm }逻辑说明host和port指向你的从站设备unitId在单设备时通常为 1。address里的40001表示保持寄存器区第一个寄存器FUXA 内部会按 Modbus 功能码 03 读取。scale是线性缩放系数原始值乘以它得到工程值比如读到 1500实际显示 150.0 rpm。type必须和从站数据类型一致读 32 位浮点时要拆成两个寄存器并选 float 类型否则会出现字节序错乱。配置保存后在画布上放一个文本图元绑定motor_speed就能看到实时值。如果值不动先确认从站是否真的在响应再用 FUXA 自带的连接诊断看错误码。3. 用 FUXA 画第一张可交互看板图元、绑定与事件3.1 画布图元与变量绑定的基本操作FUXA 的编辑器是拖拽式的左侧是图元库中间是画布右侧是属性面板。画一张看板的流程通常是先放背景和分区框再放数值显示、状态指示灯、按钮最后逐个绑定变量。数值显示用文本图元属性里把「文本」改成变量绑定模式选择之前定义的motor_speed。状态指示灯用矩形或圆形图元绑定一个布尔变量然后配置颜色规则值为 true 时绿色false 时灰色。按钮用矩形加点击事件事件里可以写脚本或调用预定义动作。这里有个容易忽略的点图元的刷新频率不是单独设的它跟随变量采集周期。如果你把采集周期设成 100ms画布上所有绑定该变量的图元都会按这个节奏更新。变量多了之后WebSocket 消息量会明显上升所以采集周期要按实际需要设不要一律往快里调。3.2 用脚本处理逻辑联动FUXA 支持在事件里写 JavaScript这对做联动很有用。比如一个启动按钮按下后要把某个寄存器写 1同时弹出一个提示。// 按钮点击事件脚本 const device line1_plc; const tag start_cmd; // 写入值 1 await FUXA.writeTag(device, tag, 1); // 在画布上显示提示 FUXA.showMessage(启动命令已下发, info); // 3 秒后自动复位 setTimeout(async () { await FUXA.writeTag(device, tag, 0); }, 3000);逻辑说明FUXA.writeTag是运行时提供的写标签接口参数依次是设备名、标签名、写入值。showMessage在页面顶部弹提示第二个参数是级别。setTimeout做延时复位避免命令一直保持。注意写操作是异步的如果连续写多个标签最好用await串行否则可能因为协议层排队导致顺序错乱。参数上start_cmd对应的寄存器地址要提前在变量表里配好类型选线圈或保持寄存器取决于你的设备要求。写线圈用功能码 05写保持寄存器用 06 或 16FUXA 会根据变量类型自动选。3.3 多页面与导航的组织方式一个项目通常不止一张画面。FUXA 支持多页面左侧页面列表里可以新建、重命名、调整顺序。导航按钮绑定页面切换动作或者用脚本FUXA.openPage(pageName)。我一般会按「总览 → 分区 → 设备详情」三层来组织。总览放关键指标和报警汇总分区放该区域的设备状态详情放单个设备的参数和操作。页面切换时只有当前页面的图元会渲染后台变量采集不受影响所以切页不会丢数据。如果页面很多建议在命名上加前缀比如ov_表示总览zn_表示分区dv_表示设备这样在脚本里引用时不容易搞混。4. 避坑与排查FUXA 落地时最容易翻车的五个地方4.1 变量读到了但画布不刷新现象变量表里能看到值在变但画布上的图元一直显示初始值或零。原因图元绑定的变量名和变量表里的名称不一致或者图元所在的页面没有激活。FUXA 的绑定是按名称匹配的大小写和空格都算差异。解决在变量表里复制名称粘贴到图元绑定框不要手打。确认图元在当前打开的页面里切到别的页面再切回来看是否恢复。如果还不刷新检查浏览器控制台有没有 WebSocket 断连日志。4.2 Modbus 读回来是乱码或明显偏大的数现象寄存器读到了值但和实际工程值对不上比如温度显示 6500 而不是 25.0。原因数据类型或字节序配错了。Modbus 寄存器是 16 位的32 位浮点要占两个寄存器且不同设备的高低位顺序可能相反。解决先确认从站的数据格式手册把type改成对应的 float 或 int32然后在 FUXA 的变量配置里调整字节序选项。常见的有 ABCD、CDAB、BADC、DCBA 四种逐个试直到数值合理。缩放系数也要检查很多仪表原始值是放大 10 倍或 100 倍的。4.3 服务端跑一段时间后内存持续上涨现象FUXA 进程占用内存从几百 MB 慢慢涨到几个 GB最后被系统杀掉。原因历史数据缓存或日志没有限制。FUXA 默认会保留一定量的历史记录如果变量多、采集快内存增长会很快。解决在服务端配置里限制历史数据条数或关闭不需要的历史记录。日志级别调到 warn 或 error减少磁盘和内存写入。如果用了脚本里的定时器确认没有泄漏比如setInterval没有在页面关闭时清理。4.4 按钮写值没反应但读值正常现象数值显示正常刷新但点击按钮下发命令时设备不动。原因写操作的寄存器地址或功能码不对或者设备侧有写保护。有些 PLC 的保持寄存器区需要先使能写入权限。解决先用 Modbus 调试工具手动写同一个地址确认设备能响应。如果调试工具能写而 FUXA 不能检查变量类型是否选成了只读。线圈和保持寄存器的写功能码不同类型选错会静默失败。另外注意unitId多从站时写错站号也会没反应。4.5 浏览器打开慢或画面卡顿现象编辑器加载要十几秒运行时画面切换有明显延迟。原因项目里图元太多、图片资源太大或者 WebSocket 消息频率过高。解决把大图压缩后再导入避免在画布上放几百个独立图元能用组合的用组合。采集周期从 100ms 放宽到 500ms 或 1s对大多数监控场景足够。如果必须高频考虑在服务端做聚合只把变化量推给前端。5. 进阶用 FUXA 做报警记录与外部系统对接报警是组态软件里最容易被低估的部分。FUXA 本身有报警配置可以给变量设阈值和死区触发后在画布上显示报警条。但实际项目里往往还需要把报警存下来、推给外部系统。我的做法是在服务端加一层轻量处理用 FUXA 的脚本接口监听变量变化满足条件时写本地 SQLite 或发 HTTP 请求。// 在服务端脚本里监听变量做报警记录 const alarmTag motor_speed; const threshold 1200; // 对应 120.0 rpm FUXA.onTagChange(alarmTag, async (value) { if (value threshold) { const record { tag: alarmTag, value: value, time: new Date().toISOString(), level: warning }; // 写入本地记录具体存储方式按你的环境实现 await saveAlarmRecord(record); // 推送到外部接口 await fetch(http://your-api/alarm, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(record) }); } });逻辑说明onTagChange是变化触发不是轮询所以不会额外增加采集负担。阈值判断里加了简单的上限比较实际项目要加死区和延时避免抖动导致报警刷屏。saveAlarmRecord和fetch都是示意你需要按自己的存储和接口替换。注意外部请求要加超时和失败重试否则网络一断脚本可能堆积。验证报警是否生效可以手动把模拟从站的寄存器改到超限值看画布报警条是否弹出、本地记录是否写入、外部接口是否收到。三个环节逐个确认不要只看画布。最后说一个我自己的习惯每次改完项目先导出备份再上线。FUXA 的项目文件不大但一旦在编辑器里误删页面或改错绑定回滚比重新画快得多。另外服务端所在设备的系统时间要校准否则报警记录的时间戳会对不上后面查问题很麻烦。希望帮到你。本文还有配套的精品资源点击获取