Architecture

Distributed services

Quatm is distributed: drivers, data managers, property logging, message routing, web access and the GUI run as independent operating-system processes connected by local IPC or TCP.

flowchart TB
    subgraph Clients[Clients]
        GUI[Desktop GUI<br/>PySide6]
        WEB[Web console<br/>browser / mobile]
    end

    BUS[(ZeroMQ event bus<br/>data · images · commands · properties)]

    subgraph Control[Control]
        PM[Process & task supervision]
        EXP[Experiment runtime<br/>Experiment · scans · queue · looper]
    end

    subgraph Services[Services]
        DATA[Data & image managers]
        PROP[Property logger]
        MSG[Message hub / logger]
        HEALTH[Device health & leases]
        WEBHUB[Web hub]
    end

    subgraph Hardware[Hardware]
        DRV[Device drivers<br/>VISA · serial · TCP · USB · GPIB · DLL]
        RT[FPGA / ADwin / real-time controllers]
    end

    GUI --> BUS
    WEB --> BUS
    BUS --> PM
    BUS --> EXP
    EXP --> DATA
    EXP --> PROP
    PM --> MSG
    PM --> HEALTH
    DATA --> DRV
    EXP --> RT
    DRV --> Hardware
    WEBHUB --> WEB
    MSG --> BUS
    HEALTH --> DRV

Failure isolation and network transparency

Every major component can run as an independent operating-system process. Clients and services communicate over local IPC or TCP, so a control PC, a data-analysis machine and a remote laptop can share one experiment without sharing one process. The architecture is intentionally fail-isolated and network-transparent: image processing does not block timing, and a slow browser cannot stall acquisition.

For the deeper architecture description, see Communication layer and the repository’s quatm/docs/ directory.