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.

1. System Uniqueness & Paradigm Shift

The Programmable Machine Controller (PMC) represents an unprecedented, industry-first hardware-software ecosystem that completely redefines traditional industrial automation interfaces. Traditional setups strictly segregate machine control logic (the PLC) from operator terminal interfaces (HMI panels) and standard peripheral I/O cards, forcing them to exchange data over slow, cyclic network communication layers. This separation causes significant software latency, data packet arbitration, and deterministic processing jitter.

The PMC breaks this paradigm through its proprietary Unified Core Architecture. It seamlessly merges the industrial computing core, standard field expansion I/O, and physical high-ergonomics operator controls (buttons, analog joysticks, rotary encoders, and switches) into a single, unified execution and mechanical layer on a standard DIN rail. By eliminating intermediate communication barriers, the controller achieves complete architectural fusion.

2. The Core Mechanics of the GARM Paradigm

To coordinate execution-critical physical controls alongside standard digital data traffic on a shared interface, the platform incorporates the GARM structural principle. GARM explicitly splits real-time control mechanics into two autonomous, parallel operational planes that interact asynchronously without blocking one another:

• The Physical Execution Plane: When an operator triggers a hardware input component (e.g., a physical button or joystick), the action immediately directs a raw electrical potential down a dedicated line within the physical fabric. This signal routes straight to the central controller processor core or actuator inhibitor circuit, entirely bypassing software protocol stacks, packetization overhead, and buffering queues.
• The Digital Verification Plane: Concurrently and independently, a parallel digital protocol channel packages the event information into a standard communication packet. This digital track handles capability logging, resource mapping, global diagnostics, and asynchronous software status confirmation post-factum within a deterministic 100 to 400 microseconds heartbeat interval.

3. Hybrid Inter-Module Interface & Zero-Protocol Mapping

The unified physical backbone comprises a specialized shared signal fabric containing a fixed pass-through bundle of 36 to 72 dedicated raw conductors alongside an independent digital protocol line. When an ergonomic operator block or standard high-density I/O module docks onto the common rail system, it initiates an automated Zero-Protocol Mapping handshake:

1. Discovery & Interrogation: The newly attached hardware component transmits its digital profile packet through the digital plane to the CPU. This profile explicitly defines its exact operational hardware layout (e.g., specific counts of push-buttons, rotary dials, or analog joysticks).
2. Dynamic Commutation: The central processor analyzes its current physical resource grid, isolates free lines from the 36-72 hardware pool, and sends back an allocation map. The module instantly reconfigures its internal solid-state switching matrix to map the physical controls directly onto the designated lines of the shared hardware bus.
3. IDE Variable Synchronization: Within the unified 3o|||sheet engineering environment, all physical and touchscreen interface elements map directly to abstract logical identifiers and internal controller variables. The hardware level synchronization entirely avoids manual network address allocation, variable linking, or packet decoding blocks inside the controller application software.

4. Runtime Criticality Tiers & Resource Allocation

To safeguard system stability, optimize conductor utilization, and enforce deterministic timing bounds, the PMC system strictly classifies all incoming runtime signals into three dedicated architectural tiers: