What inoGUI and inoCORE are¶
inoGUI is the editor and inoCORE is the runtime. Together they are an HMI and PLC system for small machines: one desktop application, one project file, and a panel that both shows the machine and controls it.
inoCORE runs on the ESP32 family and on selected STM32 processors.
In development
The system is being built. Everything on this page describes behaviour that exists in the current build, but there is no public release yet.
The idea in one sentence¶
The visualisation and the control logic are data, not code: the editor compiles screens, tags, alarms, function block diagrams, bus mappings and peripherals into one versioned binary package, and the panel executes that package without ever parsing text or being recompiled.
That single decision is what makes the rest possible. A change to a screen or to a rung of logic is a file upload measured in kilobytes, not a firmware build. The panel loads a screen in under a millisecond because there is nothing to parse.
What runs on the panel¶
Control logic¶
Programs are drawn as function block diagrams. The block library is the one a machine builder expects:
- timers and counters —
TON,TOF,TP,CTU,CTD, edge detectors, latches - arithmetic, comparison and selection blocks
- process blocks —
PIDwith anti-windup and bumpless auto/manual,RAMP,PT1,SCALE,LIMIT, comparator with hysteresis - machine blocks —
MOTORandVALVE, each with feedback supervision, a latched fault and acknowledgement - motion blocks named after PLCopen —
MC_POWER,MC_MOVEVELOCITY,MC_STOP,MC_RESETand the position blocks
Blocks can be grouped into composite blocks with their own interface, so a drive or a machine section becomes one block you drop into a diagram. Composites are expanded at compile time — the panel executes a flat list, with no recursion and no interpreter.
The cycle is the classic one: read inputs into a process image, run the logic on that snapshot, write outputs, wait for the period. Logic never touches the hardware directly.
Fieldbuses¶
| Bus | Role |
|---|---|
| Modbus RTU over RS485 | master and slave |
| Modbus TCP over Ethernet or Wi-Fi | master and slave |
| CANopen | manager, and the panel as a node |
| Raw CAN | frames without CANopen — batteries, BMS, solar inverters, chargers |
| MQTT | telemetry and Home Assistant |
Details: Modbus, raw CAN, MQTT and Home Assistant.
Drives¶
Frequency inverters are driven through the CiA 402 state machine over CANopen, wrapped in blocks so the state machine is not your problem. The reference device is the Lenze i550, verified on the bench. See FBD, axes and drives.
Peripherals¶
Chips on the board's I²C and SPI buses are added to the project in the editor: the ADS1115 analogue-to-digital converter, the TCA9555 port expander, a PCF8563 real-time clock. Retentive values are written to FRAM or EEPROM if the board has them. See peripherals and system services.
What runs on your desk¶
The editor is a native desktop application. It embeds the same renderer the panel uses, so what you place on the canvas is drawn by the same code that will draw it on the glass — fonts, colours and rounding included.
It also holds the catalogues: boards, modules, dev kits, CANopen device descriptions and Modbus register maps. Adding a device to a project means picking it from a catalogue, not typing register addresses out of a manual.
Before anything is deployed, the editor checks the project against the board: screens against the display and its resolution, CAN blocks against a CAN transceiver, Modbus RTU against an RS485 line, peripherals against a free bus, the package size against the flash slot. A mismatch is an error on your desk rather than a stuttering panel on a machine.
What the customer's browser gets¶
WebVisu is the same visualisation rendered in a browser, served by the panel. Configuration is fetched once over HTTP; after that only changed tags travel over a WebSocket. A write from the browser is a command the panel may refuse, not a poke into memory.
WebVisu is included at every licence level.
Hardware¶
The reference platform is the ESP32-S3, and everything has to fit it. The ESP32-P4 is the faster variant, not the fallback: if something does not fit on the S3, the design changes, not the platform.
- Large 7" glass (800×480) uses an SSD1963 controller on a 16-bit Intel 8080 bus
- Smaller displays (2.4"–3.5") use SPI controllers, which work on the classic ESP32 as well
- Boards, modules and dev kits come from a signed catalogue; each entry carries its pinout, fitted memory and the runtime built for it
Declared limits¶
The editor refuses a project that exceeds them at compile time, so you find out at your desk. They are also the numbers on the datasheet.
| Limit | Value |
|---|---|
| Tags | 512 |
| Alarms | 128 |
| Screens | 32 |
| Widgets per screen | 64 |
| Raw CAN frames / signals | 32 / 128 |
| Published MQTT tags | 64 |
| Distinct Modbus TCP targets | 4 |
| WebVisu clients | 2 |
Not a safety device
The system is not intended for safety functions. Emergency stop, guard doors, light curtains and end-of-travel limits must be hard-wired. Stopping a drive over CANopen is not a safety function; the inverter's STO terminals are.