The Live Blog

The foundations are in place: the Node.js backend is running, Socket.io is broadcasting in real time, and two protocols are already connected — Modbus TCP (port 502) and Siemens S7 (ISO-TSAP, port 102). Before being able to display anything, the data needs to be named: every PLC register to be read or written must be declared with its address, protocol, type and polling speed.

The Settings page, a protected cockpit

I start with the Settings page, which must be protected by a PIN code. It centralises all system configuration in sections that let you address the elements to read/write, where and how to do it: PLCs, network devices, system tags. Then, shortly after, the rest falls into place: visual tags to define how tags are displayed on the workstation, trends to track value evolution, recipes that let me add batch functions to the tag creation module, Grafcets and finally alarms. All the infrastructure is configured here before building the supervision pages.

The system tag table

Each tag declares its PLC, its register type (MW, MF, MD, M, I, Q, DB for S7…), its address, its display label and its polling cycle. A "Reactive Mode" checkbox forces the tag into the 150 ms cycle — useful for buttons and direct outputs. A Test Read button lets you immediately verify the value read from the PLC within the form.

Visual Tags, the first layer of graphical representation

A Visual Tag is a presentation layer placed on top of a system tag: you choose a graphical type for it, and it displays the value in real time. The detection logic is automatic based on the register type:

A visual tag is configured in Settings — name, source tag, graphical type, unit, decimals, colours. Once created, it appears in the page editor sidebar of the dashboard, ready to be drag-and-dropped onto any supervision page.

Real-time data architecture

The core of the runtime rests on a cyclic polling loop on the backend side, coupled with Socket.io to push values to all connected clients simultaneously.

Page management and routing

LivePLC is an SPA (Single Page Application). Supervision pages are stored in the database — each page has an identifier, an associated department, and a list of widgets with their positions and configurations. The frontend loads the configuration via the API, instantiates the widgets, and starts consuming data via Socket.io.

Departments, services and authorised devices

Fairly early on, I realised that a factory cannot have a single supervision screen shared by everyone. A notion of department was needed — a logical zone grouping pages, users and permissions.

Each department can be protected by a PIN code. Devices (tablets, operator PCs) are registered with a unique UUID and assigned a department and a home page. When a tablet is recognised, it goes directly to its context.

Alarms integrated into the runtime

The alarm engine continuously evaluates conditions on tags (thresholds, rising/falling edges, logical combinations). When an alarm triggers, it appears in the alarm bar at the top with its criticality level and a configurable sound. Acknowledgements are recorded in a journal.

The first prototypes of LivePLC were designed entirely for vertical reading on a small screen. Pages displayed as a list of widgets stacked on top of each other, scrolling vertically — exactly like a mobile web page. Simple, effective, and accessible from any phone on the factory wifi network.

Prototype v1, Zone Moussage supervision (startup sequence), January 2026

Upper sheet, electrical circuits in real time. URL 192.168.2.70:5173 visible: live in production, on the factory network.

The runtime is the main usage mode of LivePLC: the screen the operator sees on the shop floor. It displays sensor values, machine states, and active alarms. Unlike edit mode, the runtime is in controlled read-write mode — you can send commands to the PLCs, but you cannot modify the layout.

📝

Update — One month later, first field comparison

One month after the first lines of code, LivePLC is being tested on the factory network.

It was time to put them side by side: the proprietary supervision system that had been in place for years, and my version running on a smartphone.

The video is clickable — click on it!

Proprietary supervision, compiled, Windows-only, impossible to customise

LivePLC, an Android browser is all you need. Same page, same data, from a smartphone on the shop floor

From the very first weeks, LivePLC's layout was based entirely on a 12-column vertical grid system inspired by Bootstrap. The idea was simple and consistent with the original project: pages are edited on a PC but designed to be read on a smartphone. So you compose vertically, and everything adapts automatically. This model held for the first few weeks — until the limitations on PC screens made themselves felt.

Goal of the day: design a layout adapted to the technician's smartphone, comfortably editable from a PC

The principle: React-Grid-Layout on 12 columns

I used React-Grid-Layout (RGL) — a grid drag-and-drop library. The editing surface is divided into 12 columns. Each widget occupies a width expressed in number of columns (w) and a height in grid units (h). Position is defined by x (starting column) and y (row).

A full-width widget has w: 12. Half-screen, w: 6. Most importantly: when you add a widget in portable mode, it is automatically initialised at w: 12 — full width — to adapt to the small screen without any extra configuration. RGL handles automatic stacking of widgets downward (y: Infinity).

How to edit a mobile page from a PC

An important subtlety: you create pages from a PC screen, but preview the result on a smartphone. The editor therefore displays the grid inside a container whose width simulates a smartphone (approximately 390px). You drag the widgets, resize them — and see in real time how they will look on the operator's phone.

RGL calculates positions in relative units (columns/rows). When the app opens on a real smartphone, the columns resize proportionally to the actual screen width. A w: 6 widget occupies exactly half of any phone, whether it is 360px or 430px wide.

Limits that appeared very quickly

The system works very well for its intended use: mobile visualisation. But very quickly I thought that LivePLC could also be used on fixed supervision screens in control rooms — 24 or 27-inch Full HD monitors.

And there, the vertical grid layout shows its limits. On a 1920×1080 screen, having all widgets in a single full-width column is an ergonomic disaster. Horizontal space is wasted, you have to scroll vertically to see all the information, and you completely lose the synoptic view you can have with a real SCADA.

The conclusion was clear: there needed to be two distinct and equivalent layout modes. And the same page would need to support both simultaneously, with automatic conversion in both directions. But before that, I already had a TODO list growing by the hour. I would come back to it later with the Fixed Mode ↔ Portable Mode switch.

The two layout modes did not yet exist at this stage — the pivot came a few weeks later. Versioning and the Resource Monitor were the major additions of this session. The goal of versioning: each widget should be a self-describing autonomous unit, and the editor should never need to know the specific properties of each component. The deeper stake was this: the Dashboard code should only implement its own editing features — it should become generic, its load minimised to stay responsive as the widget library grows. Without this architecture, each new widget would have burdened the central component. With it, the Dashboard can embed any future widget without knowing about it in advance.

Goal of the day: make the Dashboard generic by decoupling widget definitions from the editor, and measure the impact of pages on browser performance

The WIDGET_REGISTRY, single source of truth

Each widget is registered in WIDGET_REGISTRY, a central dictionary. An entry maps a type ("GaugeWidget") to: its React component, its version, its default values, and its list of configurable properties.

WIDGET_REGISTRY = {
  "GaugeWidget": {
    component: GaugeWidget,
    version: "2.1",
    defaultConfig: { min: 0, max: 100, unit: "" },
    defaultW: 3, defaultH: 3,
    definition: {
      properties: [
        { key: "min", type: "number", label: "Minimum" },
        { key: "max", type: "number", label: "Maximum" },
        { key: "unit", type: "string", label: "Unité" },
      ]
    }
  }
}

When LivePLC loads a page, if the version stored in the database is lower than the registry version, an automatic migration is offered — new properties receive their default values. Goal: an old project must remain compatible with all versions of LivePLC and widgets to allow smooth migrations and improvements.

The auto-generated properties panel

The properties panel on the editor side is dynamically generated from the definition.properties list of the selected widget. Supported property types:

• tag — selector with autocomplete on available tags
• number — numeric field with validation
• string — free text
• color — colour picker with industrial palette
• boolean — on/off toggle
• select — drop-down list
• tagList — multi-tag selection (multi-curve charts)

Changes are visible in live preview immediately — without saving. It is a UX detail that completely changes the pace of work.

Widget templates

A template is a widget configuration saved with a name. You create it from any configured widget. Templates appear in the toolbar in a dedicated section. Dragging a template onto the page instantiates the widget with all its properties ready — including in fixed mode with the appropriate dimensions.

The "Import from the other mode" feature, explained in the next article, also relies on this system: imported widgets keep their configuration (colours, thresholds, associated tags) — only positions change.

A multitude of templates for a single component:

But also the ability to create custom blocks by selecting widgets in the layout, handy for reusing them on other pages:

The Resource Monitor, ensuring pages stay responsive

One of the problems I explicitly wanted to avoid with LivePLC is latency. Not network latency to the PLCs — that is manageable — but display latency, that one-second freeze where the interface stutters when navigating between pages. That is exactly what you experience with many existing supervision software packages, and it is often what drives operators to complain — and rightly so.

To measure this objectively, I developed the Performance Monitor in parallel with versioning. Accessible via the "System Stats" button in the navigation bar, it overlays on any viewed page without disrupting it:

The "System Stats" button in the navigation bar — accessible in edit mode, hidden in runtime mode

Main panel on an active page: 13 FPS, 39 widgets, 1099 DOM nodes, 28 PLC tags, 4 ms ping, 6.99 KB/payload. Here we see the problem: 13 FPS — page slightly too heavy for the hardware running it, or perhaps a few optimisations needed...

"Time evolution" view, 34 logged data points. RAM max 96 MB, FPS max 60, DOM max 1181 nodes. Last page: "Flow rate monitoring"

The DOM: the unexpected bottleneck

The panel displays six key indicators in real time for the open page:

The DOM: the unexpected bottleneck

While developing this tool, I put my finger on something I had not been measuring until then: in a browser, every visible HTML element is a node in the DOM (Document Object Model). The more nodes a page has, the harder the render engine works on every update — even if few nodes are actually changing. In the screenshot above, we see 1062 DOM nodes for a production supervision page: a figure to watch, because beyond a certain threshold animations and updates start to stutter.

In practice: a page with 40 well-designed widgets can be lighter than a page with 15 poorly optimised widgets, if those 15 widgets each generate a hundred nested nodes. The Performance Monitor makes this phenomenon visible and measurable without leaving the interface.

That is why I chose to provide it directly inside LivePLC — not in a developer console. The person building supervision pages should be able to check that what they are creating will not slow down the system in production. A page's responsiveness is not just an infrastructure question: it is also a design question.

In the very first version of LivePLC, widgets displayed data as-is: a Modbus address, a raw value, a generic label. Something like %MF4294 = 30745.08. Useful for debugging, but unusable for an operator who does not know their PLC's memory addresses.

Before visual tags — the variable list with raw PLC addresses (%MF4304, %MW4276:3…)

After — the same data, but with readable labels, units and a value range

Idea of the day: create an abstraction layer between raw PLC addresses and the operator display — so the interface no longer speaks in registers but in business values

What is a visual tag

A visual tag links a PLC address to a human-readable display. It contains: a readable name ("Polyol tank 1 level"), a unit (kg, °C, %, V…), a min/max range for scaling, colour thresholds (green = normal, orange = warning, red = alarm), and the number of decimal places to display.

But what makes it a foundational concept is the multiplier effect: once the visual tag is configured, I can use it in any widget. A gauge, a thermometer, a numeric display, a mini-trend — all will read exactly the same definition. If I fix the unit or the thresholds, all widgets update automatically, across all pages, in both layout modes.

The two screenshots above show the difference in concrete terms: on the left, the raw variable list with Modbus addresses — what a developer sees. On the right, the same data after the visual tag layer — what an operator or technician sees.

Displaying values as a list is useful — it served me well during the first few weeks. But a supervision interface should show things, not just list them. When an operator looks at the temperature of a preheating oven, they should see "60°C on a red gauge" and immediately understand it is in the normal zone — not read "60.3" and mentally search for whether that is good or not.

That day, I built the first truly visual widgets: the circular gauge, the thermometer, the level bar and the animated tank.

Sheet preheating — two real-time thermometers (60.3°C and 40.9°C). These are real data, read directly from the PLC.

Polyol tank levels — fill bars with value in kg. One tank selected for production (ON), the other not.

Goal of the day: moving from raw value lists to visual representations — a supervision interface should show, not just list

The circular gauge

This is the reference widget for analogue measurements. The arc colours according to the configured zones: green for the normal range, orange for warnings, red for alarms. Thresholds are defined in the visual tag, not in the widget itself — which means a gauge created from a well-configured tag is ready to use with no additional setup.

The thermometer and the tank

The thermometer is a vertical variant with a more intuitive representation for temperatures. The tank (TankWidget) deserves a special mention: it has a gentle wave animation that makes reading the level more natural — you "see" the liquid rather than reading a percentage.

Widget templates

A feature added that same day: templates. A template is a widget configuration saved with a name. Once the thermometer is properly configured for preheating temperatures (range 0-150°C, green 20-90°C, alarm at 100°C), I save it as a template. On the next page, I drag the template and the widget is ready — I only need to change the source tag.

Visualising is half the work of a supervision system. The other half is acting: starting a motor, changing a setpoint, opening a valve. That day I added the first command widgets, including the setpoint slider — and that is when I realised that writing to a PLC from a browser deserved careful treatment.

Goal of the day: allow the operator to act on PLCs from the interface, with safety mechanisms adapted to an industrial context

The write logic

When an operator moves a slider, a value must be sent to the PLC. On the backend side, the tag must be declared in RW (read-write) or W (write-only) mode. The POST /api/write route receives the value, calls writeTag() on the correct protocol handler, and the PLC receives the setpoint within a few milliseconds.

Writes do not follow polling cycles. They are event-driven — triggered by user interaction, not by a loop. The only speed limit is the network latency between the Node.js server and the PLC.

The slider: write on release, not continuously

For a temperature or speed setpoint, sending the value at every pixel of slider movement would be counterproductive. I configured the slider to write only on release — when the operator lets go of the cursor, the value is sent once. While dragging, a local display shows the target value without sending anything to the PLC.

This detail matters in an industrial context: a setpoint that changes 50 times per second during a mouse drag can trigger oscillations in the control system. Writing on release eliminates this risk.

Double-tap confirmation for critical commands

The momentary button sends 1 while pressed and 0 on release — like a wired pushbutton. For critical commands (motor start, process valve opening), a two-step confirmation dialog intercepts between the click and the send.

On a smartphone, this mechanism is essential: an accidental touch on a "Start" button in portable mode is far more likely than on a mouse. Double-tap confirmation makes this risk negligible.

Once WIDGET_REGISTRY is in place and the properties panel is auto-generated, creating a new widget becomes a matter of a few hours. The foundation is solid: each component knows how to configure, version and migrate itself. All that is left is to build on top of it.

The following weeks see new components rolling in at a sustained pace:

📝

TextWidget 13/02

Static text with formatting templates, ideal for labels and zone titles.

🛢️

TankWidget + ClockWidget 15/02

Animated tank/level with liquid fill. Clock synchronised to shop floor time.

🎚️

SliderWidget 15/02 v2

Linear, rotary or 180°/270° arc slider. PLC tag write on release in real time.

⚙️

PumpWidget + ValveWidget 17/02 v3

Animated pump (rotation, flow) and valve (open/closed/in-progress), linked to state tags. Automatic pipes between components.

🔔

AlarmWidget 03-04/03

Local/global alarms, 3 severities (info/warning/critical), multi-conditions AND/OR. Evaluation engine on backend side.

📷

WebcamWidget 05-06/03

MJPEG/HLS streams (Axis cameras), video recording, consultable archive with scrollable timeline.

Very early in development, a problem arose: how to manage several different devices in the same factory — a fixed operator PC, maintenance tablets, supervision screens on the lines — with different permissions and home pages for each one?

The usual solution would be a user accounts system. I preferred a different approach, better suited to the industrial context: device-based authentication.

Goal of the day: manage dozens of heterogeneous shop-floor devices with different permissions, without a complex accounts system

Per-device JWT, persistent identification

When a device connects to LivePLC for the first time, it generates a unique device_id (UUID) stored in localStorage, and requests access to the server. The administrator validates the device from Settings — assigning it a workstation name, a department and a start page. The server issues a signed JWT, also stored in localStorage.

On each reconnection, the JWT is verified server-side. If valid: the device immediately finds its context (department, home page) — with no password entry required. If the JWT is expired or revoked, the device goes back through the approval cycle.

QRCodePage, temporary kiosk access

The QRCodePageWidget generates a QR code pointing to a specific LivePLC page. When an unregistered device scans this QR, it opens the page in kiosk mode — read-only, with a limited duration (configurable on the widget), and no access to the rest of the application.

A "Kiosk Mode — Read Only" banner is displayed on the smartphone connected to the same wifi network as LivePLC, with a visible countdown. On expiry, access is revoked and the user is redirected to a "Session ended" screen. If the browser is closed before expiry, the kiosk session is cancelled (sessionStorage rather than localStorage — expires on browser close, by design).

Here the camera screen is shared for 10 minutes via the QR code. Once the QR code is scanned, it is consumed and a new one must be generated to allow another visitor or registered device to access this page directly.

Equipment QR codes, the workshop document hub

The QR codes system goes further than simple page consultation. Each piece of equipment in the factory can receive a printed QR code stuck on it. The scan opens a page dedicated to that equipment, with several types of configurable content:

• Documents: PDFs, images, web links, technical manuals.
• Dashboard page: direct link to a LivePLC supervision page.
• Time tracking: entry/exit form for breaks or interventions.
• Quality control: full form with photo, signature and compliance status.

Documents are filtered by authorised department — Maintenance, Production, Quality, Safety. A maintenance technician does not see documents reserved for the Quality department, and vice versa.

Integrated quality control

Quality control is directly integrated into the equipment hub, accessible with a single scan. The form offers five options:

Each inspection is timestamped and stored in the database — photo in base64, vector signature, status, controller name. The history is consultable from any authorised device.

One of the recurring criticisms of web supervision tools is their dependence on proprietary gateways to communicate with PLCs. Either they only speak OPC UA, or they require an expensive third-party middleware to connect Modbus.

LivePLC integrates the drivers directly into its Node.js backend. Currently: 4 active protocols (ready to use) and 13 stubs (architected, activatable by installing the corresponding npm package and a few production tests to validate them).

Goal of the day: not be limited to a single PLC manufacturer — architect an extensible multi-protocol system for any machine fleet

The 4 active protocols

The 13 stubs, activate in 4 files

The architecture is designed so that adding a protocol is purely a matter of configuration. Each protocol exposes the same interface (connect, disconnect, readTags, writeTag) and is referenced in a central PROTOCOL_REGISTRY.

Activating a new protocol takes 4 steps: create the driver file in backend/protocols/, register it in index.js, add its specific columns in database.js, and add the option in Settings.jsx.

Why stubs were architected so early

The decision to architect the stubs from the start rather than waiting for customer requests comes from a simple conviction: in industry, the PLC fleet is heterogeneous. A factory rarely has just one PLC manufacturer. A Schneider line sits alongside a Siemens conveyor, Mitsubishi drives, and sensors with Modbus outputs.

Proposing a tool that only talks to Siemens or Modbus is closing the door on half the projects. Having the stubs architected lets you say: "OPC UA? Ready. Allen-Bradley? 20 minutes to activate EtherNet/IP. BACnet for building systems? Available."

While developing the equipment QR codes system in LivePLC, I gradually built something that had little to do with industrial supervision. Forms, document management, intervention histories — useful, but foreign to the primary calling of a SCADA.

The conclusion was clear: this part deserved its own application. Qwipment was born from this realisation.

The idea: LivePLC's QR codes had grown so much they deserved their own application

The name

Qwipment is a stylistic twist on "Equipment". The leading "Q" is a nod to the QR code without spelling it out. Pronunciation: "Kwipment". Registered domains: qwipment.fr and qwipment.com.

Slogan: "Scan. Connect. Know." — the same workflow as LivePLC, but applied to equipment management rather than process supervision.

What Qwipment does

Qwipment is an industrial QR code manager. Each piece of equipment receives a unique QR code. The scan opens a page dedicated to the equipment, with:

• Its documents (manuals, technical sheets, procedures)
• Its forms (attendance, quality control, checklists, custom)
• LivePLC supervision pages if the equipment is connected to a PLC
• HATALINE actions if a CMMS is in place (periodic inspection, work order...)

The key idea: the Suite Connector

This is the concept that differentiates Qwipment from a simple document manager. Qwipment is not a silo — it is a hub that aggregates content from the entire software suite.

Each application in the suite exposes a standard endpoint:

GET /suite-connector/contents?uid={equipment_uid}

// Réponse LivePLC :
[{ "app": "LivePLC",  "type": "supervision_page",
   "label": "Page Ligne 1", "icon": "monitor" }]

// Réponse HATALINE :
[{ "app": "Hataline", "type": "form",
   "label": "Vérification périodique", "icon": "clipboard-check" }]

Qwipment queries all configured connectors and displays results grouped by application, with each app's colours. A single QR scan → Qwipment documents + LivePLC supervision page + HATALINE maintenance actions — depending on what the user's department is authorised to see.

One QR code, different experiences by role

This is where the Suite Connector reveals its full power. Each department head independently configures their own access rules through the same Qwipment interface. A single QR code per piece of equipment — but the content displayed is entirely personalised based on the profile of the person scanning.

Everything is independently configurable by each department head, through the same interface, in the same application, with the same QR code for each piece of equipment. The technician, the quality manager and the visitor all scan the same code — each sees only what their profile authorises.

Since the very first commit of LivePLC in January 2026, I've been keeping a list of every idea that crosses my mind : features to add, optimizations to make, bugs to fix, tracks to explore. It lives in my personal todo app, and it just keeps growing with every dev session and my day-to-day fieldwork. Every problem solved generates two new ones; every new feature reveals three use cases I hadn't thought of.

Here is a full inventory, sorted by category: what's been done, what still needs doing, and above all what seems most promising in the short term.

This list is both my logbook and my roadmap. Some items have been waiting for months; others emerge from a conversation or a problem encountered on the factory floor that same morning. One thing is certain: the learning and prediction modules represent the real qualitative leap ahead : moving from a supervision system that displays to one that predicts.