EEZ Studio pairs an LVGL GUI designer with a SCPI instrument console in one Electron app

Two audiences in one project file

EEZ Studio is a cross-platform low-code visual tool for desktop and embedded GUIs with LVGL support, and the Instruments side adds remote control of test and measurement equipment. Those two halves are usually separate tools bought from separate vendors, and the design choice here is that they share one project.

On the project side, you get a modular visual environment for designing TFT display screen decorations and defining user interaction. The build step generates C++ that can be included directly in STM32CubeIDE for STM32 targets, or in the Arduino IDE for Arduino-compatible targets. So the output is firmware source, not a binary you cannot read.

The supported graphics target is LVGL 8.x and 9.x. Project templates are pulled from giteo.io repositories, and projects can be compared against each other, which is a modest but real convenience when a display layout is being ported between variants of the same product.

On the instrument side, the target is anything speaking SCPI, from EEZ's own BB3 T&M chassis and H24005 programmable power supply through vendors such as Keysight, Rigol and Siglent. Interfaces are serial over USB, Ethernet, and VISA via a free R&S VISA implementation.

The through-line is EEZ Flow, the flowchart-based low-code programming layer, which is used both for the instrument dashboard and for the test and measurement scenarios the product is built around.

Instrument definition files are the interoperability hinge

The piece that makes the instrument side usable with equipment you did not buy from Envox is the Instrument definition file, or IDF. The README describes an IDF builder with context sensitive SCPI command help, based on the XML structure of the Keysight Offline Command Expert command set, and the Instrument module imports both EEZ Studio generated IDFs and Keysight's own command sets directly.

From an IDF the application derives more than a command palette. Context sensitive SCPI help with search comes from it, and user defined shortcuts can come predefined from an imported IDF, where a shortcut may be a single SCPI command, a sequence of them, or Javascript. The same feature list covers Javascript for task automation such as writing a logfile or uploading and downloading a programming list.

The SCPI help can also be generated outward: the README describes a command help generator based on bookmarked HTML produced from an .odt file through a separate EEZ WebPublish extension for OpenOffice and LibreOffice. That is documentation tooling built on top of the tool, and it is the part most teams will not touch.

There is also an IEXT catalog of instrument extensions with a growing number of supported instruments, which is the mechanism for hardware-specific behaviour beyond the generic SCPI surface.

The measurement features are where the tool stops being a GUI editor

Once you are connected to instruments, the feature list turns into an instrument console. Sessions are the organising idea: interaction with each SCPI instrument is session oriented, a dynamic environment holds multiple instruments for configuration and access, and there is a history of all activities with search and content filtering, plus quick navigation through a calendar heatmap or a sessions list.

On the data side you get measurement data displayed as graphs, FFT analysis, harmonics, and simple maths functions covering Period, Frequency, Min, Max, Peak-to-Peak and Average. Graphs export as CSV. Files can be uploaded from the instrument to the PC with an image preview, which is how a screenshot gets attached to a test record, and downloaded in the other direction for transferring instrument profiles.

There is a simple arbitrary waveform editor with envelope and table modes. For a bench tool, that is the difference between being able to log a measurement and being able to stimulate the device under test.

The dashboard itself is built with a drag and drop editor for the instrument's desktop, and the logic behind it is flowchart based rather than script based, which is what makes the same scenario definition usable by someone who does not write code.

Installation, the AppImage flag, and the Electron shell

A 64-bit OS is required in every case, stated up front rather than discovered later. On Linux you pick a .deb or .rpm for your distribution, or the self-executing .AppImage, which needs the executable bit set through the file's Permissions panel before it will start. If the AppImage misbehaves on your distribution, the README suggests starting it with --no-sandbox, for example ./EEZ-Studio-[version].AppImage --no-sandbox.

The macOS and Windows sections of the README are truncated in what is available here, so the installers to expect there are not documented in the text available.

The application itself is Electron. package.json names the main entry as build/main/main.js, the start script is `electron --trace-warnings --trace-deprecation .`, and postinstall runs electron-rebuild, which recompiles native modules against your local Electron version. That last step is the usual Electron build pain and it happens automatically, but it means npm install needs a working build toolchain on the machine rather than just a download.

The source is TypeScript compiled with tsc, with LESS stylesheets compiled separately for the light and dark themes, and the version in package.json is 0.30.0 while the last tag is v0.29.0 from 2026-08-02. The last push to the repository was on 2026-10-15, so development is ahead of the tagged release.

Licensing is split, and the split matters

The application is GPL v3, and the README states contributions use the C4.1 process with contributors listed in CONTRIB.TXT. There is also a THIRD-PARTY-LICENSES.TXT file at the root.

The generated output is the more interesting part, and the README is explicit about it. Envox states it does not claim ownership rights to the source code generated by the Build command, except in the case of a project that uses EEZ Flow when that project is given under the MIT licence. The user owns the.eez-project file and all the source code generated from the file template definitions that are part of it.

So the model is: your project file is yours, your generated GUI code is yours, EEZ Flow based output comes with MIT terms rather than GPL, and some generated files may be MIT, BSD 2.0 or public domain. For a commercial product with proprietary firmware, that distinction is the reason to read the paragraph twice before you build on it.

Support is a separate matter again. The README says reported issues are processed by the Envox team on a best effort basis, with prompt direct support offered under paid support plans, and points at a Discord server and Discussions as the community routes. That is a realistic expectation to set before you depend on it for a deadline.

Editorial conclusion

Adopt EEZ Studio if you build test and measurement benches where the front panel, the device under test and the instrument commands belong in one editable project, and you generate firmware from a.eez-project file. Before installing, confirm you have a 64-bit OS and read the ownership note, since the generated C++ is yours but EEZ Flow output has its own terms.

Frequently asked questions

Official sources

1. eez-open/studio on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases