3o|||sheet is a universal software environment for developing applications for Programmable Logic Controllers (PLCs).

• Hardware Independence
• Integrated Development Environment (IDE)

A lightweight, cross-platform IDE built on OpenJDK. Runs on single-board computers with minimal resources.

Supports LD, FBD, and ST languages plus a virtual machine instruction set for advanced logic design.

Offers extensive debugging capabilities: developers can modify code in real-time without physically restarting the PLC.

The development environment can create executable programs for the PLC in two modes:

• Classic PLC mode — cyclic model (OB, OB100). An optimized, economical mode that contains a minimum of additional programs.
• RTOS PLC mode — preemptive multitasking via a 1 ms timer interrupt. In this case, the IDE will additionally install a virtual real-time 3o|||sheet OS to execute tasks in parallel.

Is a standalone application that compiles text programs written in LD, FBD, ST and .3osheet into executable bytecode for a virtual machine.

The compiler can be integrated into third-party development tools (for example, Visual Studio, etc.).

It includes a complete set of tools for working with complex custom variables, virtual stack, and context management, enabling the development of sophisticated recursive algorithms and multithreaded tasks (coroutines).

Register-based Virtual Machine running safely in a sandbox. Works on devices with only 8 KB RAM and full peripheral access.

• Low-memory devices (~8 KB RAM)
• Safe sandboxed execution
• Controls GPIO, timers, UART, I²C, SPI, etc.
• Architecture-independent design

The system supports two modes of operation: either the execution of multiple independent contexts (virtual machines running distinct programs) or a single program operating in DME mode with N replicas

The platform incorporates a unique divergent architecture designed for maximum reliability and fault tolerance in safety-critical applications. Divergent Multi-Version Execution (DME) is a runtime semantic consistency verifier for diversified executions. Each replica is compiled independently, producing distinct physical code and data memory layouts while preserving identical opcode-level semantics and isomorphic control-flow graphs. Faults are detected by comparing canonical instruction traces—including opcodes, register identifiers, loaded/stored values, and computed results—while explicitly discarding layout-dependent addresses. The approach targets bare-metal embedded systems without an MMU, particularly 32-bit controllers. DME transforms low-level correlated perturbations into observable semantic divergence or structural address-space collapse without altering program semantics.

The Programmable Machine Controller (PMC) is a hardware-software ecosystem powered by 3o|||sheet. It integrates the industrial controller, I/O modules, and operator controls (buttons, joysticks, encoders, and touchscreens) into a single execution layer, removing the need for separate PLC hardware and HMI panels that communicate over slow communication protocols.

Unified Core Architecture & Single Interface

Traditional PLC systems provide a controller and I/O expansion, while buttons, encoders, joysticks, faders and other operator controls are normally selected and integrated separately. The result is often a control system assembled from components with different mechanical designs, interfaces and manufacturers. PMC changes this model. The processor module becomes the core of a configurable physical control system. A user can snap on the modules required for the machine: conventional I/O modules when expansion is needed, or operator modules when a physical control interface is required.

• All-in-One CPU Module — A single controller handles standard industrial I/O processing, physical operator inputs, and touchscreen coordinates simultaneously.
• Zero-Protocol Mapping — Hardware inputs, analog joysticks, digital encoders, and virtual touchscreen buttons map directly to internal variables, reducing communication latency and configuration overhead.

The key idea is simple: operator controls are not external accessories connected to the PLC; they become native physical resources of the PLC.

The PLC as a Physical Workspace Builder

PMC allows the same platform to become either a conventional PLC or a complete physical operator console. The developer chooses the required modules and assembles the controller around the actual human interface of the machine.
Examples include:

1. • CPU + standard I/O modules for a conventional automation controller.
2. • CPU + buttons + encoders + joysticks + display for a machine operator panel.
3. • CPU + specialized control modules for a custom professional console.

One Platform, Many Workspaces

The same PMC design language can support very different human-machine environments. The point is not that all applications look identical; it is that all of them can be built from the same coherent modular platform.
Representative application concepts:

• • An operator workspace for a complex industrial or energy installation, where ergonomics, clarity and reliability are critical.
• • A DJ performance console on stage, combining encoders, buttons, faders, displays and performance controls.
• • A lighting designer's console for stage, theatre or events, optimized around fast visual and tactile control.
• • A combine harvester driver's control console, integrating robust buttons, joysticks, displays and machine functions.
• • Specialized machine and production-line control panels.

Unified Mechanical and Industrial Design

The mechanical interface is part of the PMC architecture. Processor, I/O and operator modules are designed as members of the same product family, allowing the physical interface to look and feel like a deliberately designed console rather than a collection of unrelated PLC components and third-party controls. This makes industrial design and ergonomics functional parts of the platform. A PMC system can be shaped around the human task—from a compact machine panel to a highly specialized professional operator console—while retaining a common mechanical and logical foundation.

• High-Priority Elements (Zero-Protocol) — Reserved exclusively for physical operator interface controls (buttons, joysticks, encoders) that require immediate system response. Direct hardware routing over the I/O lines minimizes delays caused by packet packaging, network arbitration, or software stack processing.
• Standard-Priority Expansion (CAN Protocol) — Once all direct I/O lines are fully allocated, any further system expansion shifts to the CAN interface.

Unified Core Architecture

A single computing core handles machine logic, standard industrial I/O and physical operator inputs. Buttons, joysticks, encoders and other controls can therefore be mapped into the same controller resource model instead of being treated as unrelated external devices.

Dynamic Hardware Resource Mapping

When an operator module is connected, it identifies its digital profile to the CPU. The CPU evaluates the current resource map and assigns available physical lines to the module. The module then routes its physical controls onto those assigned lines. This creates a configurable hardware layer in which the physical topology can be changed without requiring the application to be rewritten for every individual panel arrangement.

Hybrid Architecture: CAN Control Plane + Direct I/O Data Plane

Control Plane — CAN

• Module discovery and registration
• Profile interrogation and resource assignment.
• Diagnostics and configuration
• Low-priority and standard expansion data

Data Plane — Direct I/O

• High-priority physical operator controls
• Buttons, joysticks, encoders and similar signals
• Direct hardware path to controller I/O resources
• No runtime packet transport required for the direct path

Zero-Protocol Data Path

In PMC, “Zero-Protocol” refers specifically to the critical runtime data path. CAN is still used for discovery, registration, configuration and resource allocation. Once the physical resources have been assigned, selected high-priority controls can use a direct hardware I/O path instead of passing through a conventional runtime communication protocol stack. The architectural objective is therefore not “no protocol anywhere,” but a protocol-free real-time I/O path for the signals where deterministic response is most valuable.

Scaling and Resource Allocation

The direct I/O layer provides 36–72 physical lines for high-priority elements. Once the direct resources are fully allocated, additional expansion can use the CAN interface for standard I/O, sensors, diagnostics, configuration and other lower-priority traffic.

Product Advantages

• One platform for PLC, I/O and the physical operator workspace.
• A constructor-like approach to building machine controls.
• A unified mechanical and visual design across modules.
• Specialized ergonomic consoles without relying on a collection of unrelated third-party controls.
• Dynamic assignment of physical hardware resources.
• A direct hardware path for high-priority operator inputs.
• CAN-based discovery, configuration, diagnostics and scalable expansion.
• The same platform can remain a conventional PLC when no physical operator modules are required.

The Product Vision

PMC turns the industrial controller from a fixed electronic box into a platform from which a specific human workspace can be built. Build the machine. Design the workspace. The processor is the core; the physical interface is assembled around it according to the machine, the operator and the task.

From an industrial operator workspace to a DJ console, from a lighting designer's desk to a combine driver's control panel, the underlying principle remains the same: one modular platform, one design language, configurable hardware and a unified control architecture.