Pixsys TC620 Edge HMI

Your companion guide to the Pixsys TC620 deep-dive: the full software stack, the live-demo architecture, source code, and every step to rebuild one panel that replaces your HMI, PLC, and edge gateway.

Everybody thinks this is "just an HMI." They're wrong. 🏭⚡

Most people look at an industrial touchscreen and see a pretty panel that shows some numbers on a factory wall. The Pixsys TC620 is something else entirely: a full edge computer that happens to have a touchscreen. In this build, one box runs real PLC logic, containerized apps, and cloud connectivity — all at the same time, live on my desk.

This article is your companion guide to the full video. Here you'll find the complete software stack, the live-demo architecture, the source code, and every step you need to rebuild this on your own bench. 👇

🎥 The Full Video

---Coming soon---

Why the TC620 Is Not "Just an HMI"

On this hardware, the HMI and the PLC are not two separate boxes wired to each other — they live in the same box. The CODESYS runtime runs right on the panel. That single fact is the whole story, and everything else in this build flows from it.

Here's what's actually inside:

Compute: Rockchip RK3588 — 4× Cortex-A76 @ 2.4 GHz, 64-bit ARMv8, 32 GB eMMC, 4 GB RAM. This is an 8-core edge computer, not a microcontroller driving a display.

Note on chip options: Pixsys offers the TC620 with an optional, older RK3399 on some SKUs (no NPU). The unit in this video is the RK3588 — that's the one you want if edge AI is anywhere on your roadmap.

The rest of the hardware that matters:

• Display: 12.1″, 1280×800, capacitive multi-touch, 16.7M colors, 400 cd/m² — bright enough for the real shop floor, not just the lab.

• Two Ethernet ports — one full Gigabit, one 10/100. This dual-port setup lets you separate two networks (more on why that matters below).

• Fieldbus support: RS485, CANopen, EtherCAT, PROFINET, EtherNet/IP — connect directly to shop-floor equipment.

• Built-in UPS + real-time clock with battery backup — a power loss won't corrupt your files; the device restores cleanly.

• IP65-rated front panel, aluminium frame — you can wash it down and it won't care.

The Software Stack 🧱

This is where it gets interesting. The TC620 is a Linux device with a PLC runtime plus a container engine, all in one panel. Here's the full stack, bottom to top:

Yocto Linux (embedded OS)

→ CODESYS 3.5 runtime (TargetVisu + WebVisu, OPC UA server)

→ Podman container engine (Docker-compatible)

→ Node-RED + Grafana (each in its own container)

→ Pixsys Web Portal (device config + remote assistance)

A few things worth calling out:

• Podman under the hood, Docker-compatible on top. Your existing Docker images just work — you pull docker.io images straight from the UI — but it's rootless Podman running them. Keep your commands consistent: use podman, not docker, when you go to the terminal, or you'll hit stuck container states.

• CODESYS comes pre-installed. You don't install the runtime yourself; it ships on the panel. You just start/stop it — from the IDE, or straight from the Pixsys web portal.

• The Pixsys Web Portal is the control center: reboot, firmware updates, network config, VNC toggle, container management, a terminal, and a CODESYS start/stop tab — all from a browser.

The Live Demo: Vibration Monitoring Pipeline 📈

On standard hardware this would be several boxes: a PLC, an edge device, a gateway. Here it's one box doing everything. This is the exact data flow from the video:

Balluff SmartLight + condition-monitoring sensor → IO-Link Master → Modbus TCP → TC620 (CODESYS runtime) → OPC UA → Node-RED (container) → MQTT (test.mosquitto.org) → Grafana (container)

Walking the flow:

1. A Balluff condition-monitoring sensor measures vibration (X/Y/Z V-RMS) and temperature, feeding an IO-Link Master.

2. The TC620 acts as a Modbus TCP client, reading the sensor data directly from the IO-Link master (which is the Modbus server) over Ethernet port 2 — the dedicated factory network. The second Ethernet port connects the laptop for CODESYS programming, kept completely separate.

3. CODESYS does the logic: converts the raw registers to real values, runs the threshold check, and writes back over Modbus to trigger the SmartLight colors when vibration crosses the limit.

4. An OPC UA server built inside CODESYS exposes those variables so container apps can read them.

5. Node-RED (running as a Podman container) reads via OPC UA and publishes to MQTT.

6. Grafana (another container) subscribes to the broker and renders the time-series dashboard.

The result: three independent visualization layers off one panel — CODESYS TargetVisu/WebVisu, the Node-RED dashboard, and Grafana — displayed across tabs on a single HMI, with the CPU sitting around ~22% load. Plenty of headroom left for AI workloads.

"Why route through Node-RED? CODESYS can publish MQTT directly." 🤔

This comes up every time, so let's address it head-on. Yes — CODESYS can publish MQTT on its own. I route through Node-RED on purpose, and it's only possible because of the TC620's containerized runtime:

• Decoupling — data routing lives separate from control logic. I can change where data goes without touching PLC code.

• Multi-destination fan-out — one incoming stream, many downstream targets, added without redeploying the PLC.

• Access for non-PLC developers — IT/data folks can build on top of the pipeline without ever opening the PLC project.

On standard HMI hardware you couldn't do this without adding a separate edge PC. Here it's just another container. That's the whole point.

🧑‍💻 Source Code & Resources

Everything you need to rebuild this is here:

📦 CODESYS project (Modbus client, vibration logic, OPC UA server, TargetVisu/WebVisu):

68MB

Pixsys_vibration_monitoring_comments.projectarchive

Open

🔴 Node-RED flow export (OPC UA read → MQTT publish):

21KB

pixsys_node-red.json

Open

📊 Grafana dashboard JSON (vibration + temperature panels):

16KB

pixsys_grafana.json

Open

Quick-reference details from the demo:

• Pixsys web portal login: user user / password 123456 (change this on your unit!)

• Node-RED container port mapping: host → container 1880

• WebVisu URL pattern: http://<HMI-IP>/webvisu.htm

• Device: Pixsys TC620-A-P4-WT2 — install the device package in CODESYS to see the model under device topology.

Container persistence gotcha: --restart always alone won't survive a reboot on this setup — you also need podman-restart.service explicitly enabled. And for internet access on IPv4-unavailable units, set IPv6 DNS (2001:4860:4860::8888) so containers can pull images.

The Verdict

So, TC620, "just an HMI"? Not even close. It's an edge computer, a PLC, and a gateway in one panel, and the containerized architecture is what unlocks all of it. If you build automation or IIoT systems, this is a category of device worth knowing about.

I'm going to keep digging into this platform — there's more coming, including a look at the logiclab-opcua.service layer I deliberately left out of this video. Subscribe so you don't miss it. 🚀

Key notes:

♥️ Work With Me

I regularly test industrial automation and IIoT devices. If you'd like me to review your product or showcase it in my courses and YouTube channel:

📧 Email: [e-mail] or drop me a message on LinkedIn