Skip to content

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 — PID with anti-windup and bumpless auto/manual, RAMP, PT1, SCALE, LIMIT, comparator with hysteresis
  • machine blocks — MOTOR and VALVE, each with feedback supervision, a latched fault and acknowledgement
  • motion blocks named after PLCopen — MC_POWER, MC_MOVEVELOCITY, MC_STOP, MC_RESET and 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.