简介：Web组态设计器FUXA是一套基于 Vue.js 与 Node.js 的 Web 工业组态设计器源码，面向自动化、物联网和监控面板开发场景，帮助不熟悉编程的工程师通过浏览器完成控制逻辑的图形化配置与实时监控。包内共含 1195 个文件，大小约 13.92MB，以 SVG 图标、TypeScript 逻辑、HTML 页面、JavaScript 脚本和 CSS 样式为主，还包含字体文件、JSON 配置、Dockerfile 等，整体结构清晰，便于在前端工程中使用。设计器支持拖拽式图形界面，通过预设控件与自定义逻辑搭建监控画面，并可结合 OPC UA、MODBUS 等常见的工业协议与硬件设备通信，可大幅缩短 Web 工业控制系统的搭建周期。已有 2656 人学习下载，具有一定的参考价值，既适合希望掌握 FUXA 源码结构并能二次开发的工程师，也能帮助前端开发者领会 Vue 组件化、响应式绑定及 Node.js 后端交互等核心实践。
1. Web组态设计器FUXA：一个能跑在浏览器里的工业HMI/SCADA
如果你在工厂里和电气设备打过交道，大概见过两类组态软件：一类是 WinCC、IFix、组态王 这种装着 Windows 授权狗、动辄上万的桌面软件；另一类是这几年冒出来的 Web 组态设计器，在浏览器里拖拖拽拽就能拼出一个监控画面。FUXA 是后一类里少见的开源选择，它的技术栈是 Node.js 加 Vue.js，天然适合中小型工厂做数据采集和远程监控。整套东西包含一个设计器、一个运行时和一个数据采集网关，不用装客户端，局域网里任何一台电脑打开浏览器就能看画面、做报表、查历史曲线。这篇笔记我打算从部署、画图、绑数据一路讲到常见故障排查，把能直接照抄的参数和步骤给你捋出来。
2. FUXA的架构与选型：为什么是Vue.js + Node.js这套技术栈
2.1 组态设计器在工业设备管理里的位置
工业现场的数据链路大致是：传感器和 PLC 通过 Modbus、OPC UA、S7 这类协议把数据送到采集软件，采集软件把数据整理成画面能用的数值，然后在屏幕上画出设备的状态、温度曲线、报警灯。传统组态软件把这三件事绑死在一个桌面程序里，一个人画图、另一个人改点表，版本经常对不上。FUXA 做的事情是把设计器和运行时拆开，设计器在浏览器里生成 JSON 格式的工程文件，运行时负责把这些 JSON 渲染成画面，网关负责和现场设备对话。这份资源的意义在于，它把这三层清晰地分开了，新来的同事不用拿着 U 盘到处拷组态文件，打开浏览器输入工程地址就能看到最新的画面。
2.2 网关、设计器与运行时三段式结构
FUXA 的工程本体是一个 Node.js 服务，这个服务同时扛着三件事：Express 提供页面访问接口，Socket.IO 负责画面和数据的实时推送，底层的采集器按设定的周期轮询现场设备。设计器是一个 Vue.js 单页应用，拖拽组件、配置属性、添加动画事件，最后生成一个 JSON 工程文件。运行时画面也是同一个 Vue 应用，但是处于只读模式，只负责把服务和设备传来的变量值渲染成图形状态。
这三段结构带来的直接好处是，画图工程师不用理解 Modbus 报文长什么样，他只关心画面里那个电机的旋转动画绑定到了哪个变量；负责仪表对接的人也不需要在画面里找半天按钮，他只要把采集器配置好就行。我见过一些团队把 FUXA 部署在边缘网关的盒子里，那个盒子同时跑采集和数据转发，画面通过 4G 网络暴露给不在现场的管理人员，这种用法比传统组态软件轻得多。
2.3 南向与北向接口：Modbus、OPC UA、MQTT 四大件
FUXA 在配置界面的「服务」菜单里管理数据源，目前比较常用的采集协议有 Modbus TCP、Modbus RTU、OPC UA、Siemens S7、MQTT、BACnet 这些。实际项目里最常用的是 Modbus TCP 和 MQTT 的组合：PLC 通过网线或者 4G 模块把数据推到 MQTT Broker，FUXA 订阅主题拿到 JSON 数据，画面直接绑定这些字段。OPC UA 则适合接那些已经做了设备建模的工厂，它的信息模型直接告诉你设备的温度、压力、状态在哪个节点上。
北向接口方面，FUXA 没有提供复杂的 REST API 文档，而是靠 Socket.IO 推送变量值给前端画面，同时它也留了一个 Web API 用来做外部系统集成。和我搭档过的实施工程师有个习惯：先用 Modbus Slave 模拟软件把数据发起来，把 FUXA 的采集链路调通了，再接真实的 PLC 设备。这个习惯几乎能规避掉一半的联调问题。
3. 部署与基础配置：从源码包到可编辑的工程环境
3.1 安装依赖与启动：两条启动命令的区别
拿到 FUXA 源码包之后，可以直接在项目根目录执行安装命令。常见做法是：
npm installnpm install会按照 package.json 里的依赖列表把 Node.js 模块全部装到本地。装完之后有两种启动方式，一种是直接运行生产模式：
npm start另一种是开发模式：
npm run dev两种模式的区别在于，npm start会把服务端代码直接运行在当前终端里，适合部署在正式服务器上；而npm run dev底层用的是 nodemon，它会监听源码文件的变化，你改了服务端代码保存之后，服务自动重启，适合在调试阶段用。我一般会在本地先跑npm run dev，确认配置无误之后再切到npm start。
启动成功的标志是终端输出一段监听地址，通常是http://localhost:1880。注意，FUXA 默认端口是 1880，不是常见的 8080，忘了这一点的人经常在防火墙和安全组规则上浪费时间。如果端口被占用了，优先检查是不是有别的服务抢占了端口。
3.2 配置目录的作用：引擎参数与文件路径
FUXA 的配置文件集中在项目目录下的config文件夹里，核心是server.js和db.js这两个文件。server.js里定义了服务端口、开启哪些服务模块；db.js则是负责数据库连接的。FUXA 默认使用一个 JSON 文件当作轻量级数据库来保存工程数据和用户账号，文件路径在配置里写死，不用额外安装 MySQL 这类重型数据库，这对一个小型监控项目来说已经够用了。
比较值得留意的是server.js里的ServeStatic配置项，它控制着前端静态资源从哪里吐出来。如果画面上的图标或者组件有时候显示不出来，大概率是这个路径配置和实际编译产物对不上了，直接修改配置路径指向dist目录就能恢复。
3.3 用户与权限设置：多角色管理的基本控制
FUXA 自带的用户管理在「设置」菜单里，管理员可以创建不同的账号。默认的用户名是admin，第一次登录之后应该立刻改掉密码。它的权限模型比较简洁，全局角色只有两种：管理员和普通用户。管理员可以进入设计器修改工程画面，普通用户只能查看运行时画面。在团队协作的场景下，可以让电气工程师都用普通用户账号看画面，只有组长保留管理员权限去改画面。
有一些老工程师习惯在一个团队里所有人都用 admin 登录，结果半夜有人值班误删了画面上的一个设备图元，第二天早上交接时才发现。这种事故很难追溯是谁做的，因为共用账号没有操作日志的个人维度。所以无论团队多小，我都建议至少两人一个账号，并且定期更换口令。
4. 用FUXA画一个监控页：从新建工程到发布运行
4.1 设备卡片组件与变量绑定的三步操作
打开设计器之后，左侧是组件面板，中间是画布，右侧是属性配置区。新建一个画面，先从组件面板里拖一个「矩形」或者「SVG图元」到画布上，把它当作设备的占位图形。
接下来需要把设备的数值变量绑定到这个图元上，操作步骤是：
// 在 FUXA 设计器的属性面板中，找到 Common 分组下的 // Variable Binding 属性，点击右侧的文件夹图标。 // 选择管理中已创建的变量，例如： // Modbus_RTU_Temperature_01 // 保存画面，点击右上角的 "Run" 进入运行时模式。变量绑定是整个组态设计器里最关键的一步，因为画面本身不产生数据，它只是数据的一个显示器。常见做法是在「变量管理」里先建好点表：变量名、数据类型、采集周期、读写权限。把变量绑定到图元之后，即使数值是数字型，也可以设置显示格式：整数、小数点后两位、或者映射成布尔状态的文字。比如一个开关量变量，0 显示为「停止」，1 显示为「运行」。
4.2 动画、事件与颜色映射：让画面动起来
组态画面如果只是静态显示数值，那还不如做一张 Excel 表。FUXA 的动画能力集中在「Animation」属性里，它支持设置图元的颜色、位置、角度、透明度和可见性随变量值变化。最常见的电机旋转动画可以参考下面这个配置思路：
// 针对 SVG 图元，选择 Transform 标签页 // 变量选择 Motor_Speed // 数值范围映射到角度范围：0 -> 0deg, 1000 -> 360deg // 颜色属性背景填充绑定 Device_Status 变量 // 当值 > 500 时背景变绿，值为 0 时背景变灰事件方面，FUXA 的设计器支持给图元添加 JavaScript 脚本。脚本里可以用this指代当前图元，通过value属性访问绑定变量的值。利用这个能力，可以在运行时画面上单击一个按钮，触发某个表计仪表的数值跳变，做演示模式时非常方便。需要留意的是，脚本是在浏览器端执行的，不要在脚本里写死和数据库有关的操作，它没有那个权限。
4.3 发布与运行时切换：Engineering 和 Runtime 两个模式
FUXA 的界面右上角有一个切换按钮，用来在 Engineering 和 Runtime 模式之间切换。Engineering 模式下你可以自由拖拽、修改图元和属性；Runtime 模式下画面按照工程文件的配置渲染，刷新操作和传感器数据同步刷新，但不会进入编辑状态。
发布到生产环境时有一个隐藏细节值得提一下：FUXA 用一段哈希串标识画面，部署到新服务器的地址之后，浏览器端可能缓存着旧的哈希地址清单，导致画面打开后是空白的。最直接的解决办法是清掉浏览器缓存，或者部署时就把服务端和前端资源编译产物一起更新。我习惯在发布前先在配置里改一个版本号，强刷浏览器，这样就能避免很多无谓的远程排查。
5. 避坑：从数据不刷新到画面崩溃的常见问题与排查
5.1 现象：画面上某个变量的数值长时间停留在最后一次更新
原因：最常见的是采集链路断开了，尤其是 Modbus TCP 这种简单的通讯方式，设备侧断电或者网线松动会直接导致采集器连着报错。还有一个隐蔽原因是采集周期配置得过长，比如变量的采集周期设置成了 600 秒，那画面 10 分钟才更新一次，看起来就像卡死了。
解决：打开 FUXA 左侧的「Diagnostics」面板，查看这个变量所属的服务信道有没有错误日志。如果是网络问题，用ping命令测试设备 IP 是否可达；如果是周期问题，把采集周期从 600 秒改成 10 秒。我一般先把周期调到 5 秒测一下链路，确认数据正常后，再根据设备负载适当回调间隔。
5.2 现象：部署到服务器后，画面能登录但图表和历史数据不加载
原因：FUXA 的历史数据存储默认写在一个 JSON 文件里，而且这个文件路径常被配置在局部的磁盘路径下。服务器上以服务方式运行时，权限不足，导致该文件只读，历史数据无法写入。
解决：把存储路径指定到一个普通系统用户可读写的目录，比如/opt/fuxa/data/，并给这个目录执行chown -R赋予文件权限。修改之后重启服务，历史数据就能正常写入了。
5.3 现象：同时打开多个浏览器标签页时，一个页面修改了变量，其他页面不同步
原因：FUXA 运行时模式的变量同步依赖 Socket.IO 的广播机制，多个浏览器标签页连接的是同一个服务端实例，理论上应该是同步的。但如果两个标签页打开的是不同的工程版本，浏览器缓存了老的前端资源，就会导致一个页面正常、一个页面乱套。
解决：新的标签页强制刷新一次缓存，或者关闭旧的标签页重新打开同一个运行时地址。做远程运维时需要留个习惯：改完画面重新发布之后，通知现场人员刷新浏览器，而不是直接在老页面上等它自动变化。
5.4 现象：系统长时间不操作后画面变成白屏，刷新之后又正常
原因：这种问题通常和浏览器标签页的可访问权限有关。Chrome 对后台标签页执行节流策略，长时间不活动的页面会暂停定时器，FUXA 画面依赖的定时刷新也被暂停了，重新激活标签页时页面状态异常。
解决：不使用任何自动操作的情况下检查网络请求日志，你会看到服务端有断线重连的逻辑。可以加一个 keep-alive 的 ping 定期发送，或者在使用场景中避免让浏览器标签页长期被切到后台。对于大屏监控这类长周期运行场景，更推荐用一个独立的显示器加一个专门跑浏览器的盒子，不要和办公电脑共用同一个页面。
5.5 现象：点击「Run」按钮后，画面用浏览器调试工具看不到数据，设备状态全部是离线
原因：服务器端的数据采集器并未启动，但设计器本身是正常启动的。运行时画面在渲染时向服务端请求变量值，得到的是采集器服务未启动的错误返回，所以每个图元的数据都处于离线状态。
解决：检查服务端日志，看是否报了「Failed to connect to device」等错误。若确认采集器未启动，回到服务端的配置界面，把启用的服务勾选打开并保存。我通常会写下一条检查流程：先确认服务端口通不通，再看数据源信道状态，最后看设备通信日志。
6. 进阶技巧：用FUXA的Web API做外部系统联动
6.1 在丹佛斯VLT 变频器的端口对接中做的事
之前有一次，一个车间希望把设备和 FUXA 的报警状态同步到企业微信的机器人上，但当时没有精力做完整的 MQTT 双向通信。后来发现 FUXA 本身附带了一个简单的 Web API，HTTP 接口可以用来读取变量和触发动作。虽然它的接口能力没有商业组态软件那么全面，但接一个定时轮询脚本已经足够。
我一般这样实现：在旁边放一个轻量的 Python 脚本，每隔 30 秒调用一次 FUXA 的变量值接口，把数值和设定的阈值做一次比较，发现越限就发一条消息到企业微信群里。
# polling_fuxa.py import requests import time # FUXA 采集到的变量名 variable = "VLT_Current" url = "http://localhost:1880/api/variables/" + variable while True: try: response = requests.get(url, timeout=5) value = response.json().get("value") # 阈值判断：电流超过 50A 视为过载 if value and value > 50: report_message(f"VLT 变频器电流异常: {value:.2f} A") else: print(f"当前电流: {value}") except Exception as exc: print(f"读取失败: {exc}") time.sleep(30) continue time.sleep(30)脚本里的url指向本地 FUXA 服务，variable变量名要和设计器里变量管理的命名完全一致，一个字符串错位就会导致请求返回空值。为了保证请求不被阻塞，我加了 5 秒超时和异常捕获。实际部署时还需要注意，不要在循环里频繁拉取那些毫秒级变化的变量，这种轮询方式适合秒级或分钟级的数据检查。
这个方案的思路本质上就是利用 FUXA 已有的数据采集能力，把组态画面当成「黑匣子」，外部业务系统不直接和 PLC 通讯，而是从组态层取数。从那以后我每次接到这种“组态和其他系统互通”的需求，都会先确认能不能在 FUXA 的 Web API 层解决，实在不行再考虑专门写采集服务。希望帮到你。
本文还有配套的精品资源，点击获取
