Wexiödisk · 2023 → · work
Software Engineer at Wexiödisk
I write the control software and the Qt/QML touch interface inside Wexiödisk's industrial dishwashers, and the telemetry that reports every machine back to the cloud. Firmware that has to be right in a kitchen at noon, and screens that work with wet hands.
- Layers
- interface, application, services, data, firmware
- Built with
- C++ · QML · Linux · Rhapsody · IoT · Embedded Systems
- 1U1 microcontroller · runs Linux and the C++ control software
- 2J1 sensor header · temperature, level, door, pressure
- 3K1–K3 relays · heater, pump, door lock
- 4M1 radio · Wi‑Fi and BLE, meander antenna
- 5WD‑Touch panel · 7" QML interface over an FPC ribbon
- 6J2 field bus · RS‑485 to the rest of the machine
- 7D1–D3 status LEDs · heartbeat, link, fault
- 8Cloud link · MQTT over TLS, telemetry every cycle
The problem
A commercial dishwasher in a restaurant or a hospital kitchen runs dozens of programs a day, and nobody should have to think about it. Wexiödisk builds those machines. When I joined in 2023 the control software had three jobs at once: run the machine safely, give staff a screen they could use with wet hands and no time, and start reporting to the cloud so that a whole fleet of machines could be watched and maintained from one place.
What I built
I work on WD-Touch, the control system that runs across several machine types. The control logic is C++ on embedded Linux1, modelled in IBM Rational Rhapsody, where I design and implement the state machines that decide what a program does and what it must never do. On top of that sits a QML touch interface5: large targets, high contrast, glove-friendly, translated for the markets the machines ship to. Below it I have written firmware in C for the peripheral boards6 that talk to sensors2 and actuators3, so that the parts of the machine agree with each other.
The second half of the work is the IoT platform rolled out across the fleet: the connectivity layer that collects telemetry, sends it to the cloud8, and brings status and maintenance alerts back. Every release goes through simulation and hands-on testing on real machines before it ships, and I write the documentation that lets the next developer understand the control system without me in the room.
What I learned
That the interesting problems are at the seams. A safety state machine has to be provable, an interface has to be obvious at a glance, and telemetry has to survive a kitchen’s Wi‑Fi. Each is a different kind of engineering, and the product only works when all three agree. I also learned what a clear document is worth: the time it takes a new developer to find their way around dropped once the control system was properly written down.