Projekt Mechatronik DC AC

DriveLink

An open-hardware variable frequency drive (VFD) for three-phase induction motors, developed for the course Projekt Mechatronik at Munich University of Applied Sciences (HM).

DriveLink rectifies single-phase 230 V AC mains into a ≈325 V DC link and drives the motor through an Infineon IM06B50GC1 CIPOS Mini intelligent power module (600 V / 50 A). The power stage is controlled by an STM32G474 whose firmware is generated from a PLECS model, while a detachable ESP32-S3 HMI provides an OLED display, rotary-encoder control, and a WiFi web dashboard. This repository contains everything needed to reproduce the device: KiCad schematics and PCB layouts, firmware, the PLECS model, enclosure CAD files, and documentation.

⚠️ Safety warning — This device connects directly to mains voltage and its DC link operates at ≈325 V. The DC-link capacitors store a lethal charge even after disconnection. This is a student prototype: it is not certified for mains-connected installations and must only be operated by qualified persons, behind an isolation transformer or RCD, inside a closed enclosure. Reproduce and operate it at your own risk.

Status: working prototype — see Known limitations.

Pitch video

https://github.com/user-attachments/assets/3f33c3a8-9b28-4335-b2a6-baa4afd1d7ac

Features

• 230 V AC single-phase input: bridge rectifier, NTC inrush limiting, 4× 560 µF DC link
• Three-phase output for induction motors, open-loop V/f control, 10 kHz sinusoidal PWM
• Output frequency adjustable from −100 to +100 Hz (sign = direction of rotation)
• Motor-control firmware generated from the PLECS model (PLECS Coder, STM32G4x target)
• ESP32-S3 HMI with 128×64 OLED (SH1106), rotary encoder, and two buttons
• Standalone WiFi access point with a live telemetry dashboard and JSON API
• Telemetry: DC-link voltage, shunt-based phase currents, module temperature
• KiCad 10 hardware projects, 3D-printable enclosure with Fusion 360 sources

System architecture

Block schematic of the implemented system (editable source: system-block-diagram.svg).

The system consists of two boards:

• Mainboard (Mainboard/) — the complete power path: mains input with rectifier and NTC, DC link, IM06B50GC1 inverter stage, shunt current measurement, plus the STM32G474RE controller, auxiliary buck/step-down supplies, and fan control. The schematic is split into sheets (rectifier, VFD, STM, Buck_Converter, Step_Down_Converter, cooling).
• HMI module (HMI/) — an ESP32-S3 board with display, encoder, and buttons that mounts in the enclosure front. It sends the frequency setpoint to the mainboard and receives telemetry over a 3-wire UART link.

The two boards speak a small framed serial protocol, specified in docs/UART_PROTOCOL.md.

Repository layout

Toolchain

Building the hardware

Assembled DriveLink mainboard (front and back).

PCBs

1. Open Mainboard/Projekt_Mechatronik_DC-AC.kicad_pro and HMI/PCB/VFD-HMI-Module.kicad_pro in KiCad 10.

2. Export Gerber and drill files (File → Fabrication Outputs) and order the boards — the prototypes were manufactured by JLCPCB with default settings.

3. Source the components: the mainboard BOM is included as Projekt_Mechatronik_DC-AC.csv (semicolon-separated, with datasheet links); export the HMI BOM from KiCad if needed. Key parts:

   Function	Part	Manufacturer
   Power module (3-phase inverter)	IM06B50GC1 (600 V / 50 A)	Infineon
   Motor controller	STM32G474RETx	STMicroelectronics
   HMI controller	ESP32-S3 module	Espressif
   Rectifier	GBU5010	MCC
   Inrush limiter (NTC)	SL32 5R020	Ametherm
   DC-link capacitors	4× ESMM401VSN561MA40S, 560 µF / 400 V	Chemi-Con
   Current shunts	3× GMR100HJBFHR020, 20 mΩ / 7 W	Rohm

4. Assemble and solder the boards (mostly SMD; the power module, connectors, and electrolytics are through-hole).

Enclosure

The case/ folder contains the printable enclosure:

• housing.f3z / housing.step — the main enclosure (Fusion 360 archive and neutral STEP)
• HMI_blende.stl — front bezel for display, encoder, and buttons
• Propeller_groß.f3d / .step — impeller for the cooling fan
• Mainboard/Ständer.stl — stand for bench operation of the bare PCB

Print the STLs on any FDM printer (no special settings required); use the STEP/F3Z sources to adapt the design.

Building the firmware

The device runs two firmwares: the HMI firmware (hand-written, PlatformIO) and the motor-control firmware (generated from the PLECS model).

HMI firmware (ESP32-S3)

cd HMI/Firmware
pio run -e esp32-s3-devkitc-1                 # build
pio run -e esp32-s3-devkitc-1 -t upload       # flash via USB
pio device monitor -b 115200                  # serial log

platformio.ini defines two environments: esp32-s3-devkitc-1 for the actual HMI hardware and esp32 for bench tests on a generic ESP32 devkit. All library dependencies (U8g2, ESP32Encoder, ESPAsyncWebServer, ArduinoJson) are fetched automatically on first build.

Motor-control firmware (STM32G474)

The PLECS model is the single source of truth for the motor control — the STM32 code is generated, not written by hand:

1. Open plecs/VFD_SW.plecs in PLECS (the Coder target STM32G4x is preconfigured in the model).

2. Open Coder → Coder options…, choose an output directory (e.g. plecs/VFD_SW_codegen, which is gitignored), and click Build to generate the sources (VFD_SW_1.c, …) and the makefile VFD_SW.mk.

3. Copy plecs/dirty_patch/build.ps1 into the output directory and run it:

   cd plecs/VFD_SW_codegen
   pwsh ./build.ps1     # or run in Windows PowerShell

   The script activates the embedded UART code (see below) and runs make clean && make, producing an .elf binary.

4. Connect an ST-LINK to the mainboard's SWD header and flash the .elf with STM32CubeProgrammer.

How the "dirty patch" works

The generated firmware needs UART code (STM32 HAL) to talk to the HMI, but PLECS also compiles the model's C-Script for host-side simulation, where no HAL exists. The UART implementation therefore lives inside the model's C-Script blocks wrapped in comment guards:

/*//                      ← guard line: everything below is a comment…
#define UART_ENABLED
... real UART code ...
//*/                      ← …until here

#ifndef UART_ENABLED
void uart_init(void) {}   /* no-op stubs used during simulation */
...
#endif

• In simulation the guards stay in place: the UART block is one big comment and the no-op stubs compile instead.
• For the target build build.ps1 deletes the guard lines from the generated VFD_SW_1.c, activating the real implementation before calling make.

The files in plecs/dirty_patch/ (code_declarations.c, start_function_code.c, output_function_code.c) are reference copies of those C-Script sections. To change the UART code, edit it inside the PLECS model and keep the copies in sync.

Operating manual

1. Assemble both boards into the enclosure, connect the motor phases, and close the case before applying mains power.
2. Switch on the mains input. The NTC soft-start charges the DC link; the HMI boots into the STOPPED state (no output).
3. Control the drive from the front panel:

The display shows the live output frequency (large, right) and the pending setpoint (left, in static mode) in the top half, and DC-link voltage plus module temperature in the bottom half. When the output is disabled, STOPPED is shown and 0 Hz is commanded.

Web dashboard & API

The HMI opens its own WiFi access point:

• SSID: DriveLink — Password: DriveLink123
• Dashboard: http://192.168.4.1 — live telemetry chart and remote frequency control

The dashboard is backed by a small JSON API that can also be used directly:

# Read telemetry
curl http://192.168.4.1/api/status
# → {"frequency_hz":50.00,"voltage_v":324.10,"temperature_c":42.5,"output_disabled":false}

# Set the frequency setpoint (clamped to −100…+100 Hz)
curl -X PUT http://192.168.4.1/api/status \
     -H "Content-Type: application/json" \
     -d '{"frequency_hz": 42}'

Developing without hardware

HMI/pc_testing/ contains helpers for working on the HMI without a powered mainboard:

• web_test.py — serves the dashboard locally at http://127.0.0.1:8000 with simulated telemetry, and can forward setpoints to a connected device; useful for dashboard UI work. The browser assets (static.html, chart.js) are the sources for the copies embedded in HMI/Firmware/include/web.h — after editing them, update the raw literals there.
• uart_test.py — emulates a mainboard on a USB-UART adapter, answering setpoints with a rough induction-motor model. Note that it still speaks an older protocol revision (see docs/UART_PROTOCOL.md).

Known limitations

Honest notes from the project report and code:

• The current measurement is unreliable — the amplifier signal arriving at the STM32 is too noisy, so phase currents are not displayed.
• Due to a signal-wiring mix-up in the PLECS model, the temperature is transmitted in the L1-current telemetry slot; the HMI compensates in software (see docs/UART_PROTOCOL.md).
• Rapid setpoint changes cause visible motor jerk — there is no frequency ramp yet.
• At continuous 50 Hz operation the module reaches 60–70 °C; a larger fan is planned.
• The telemetry frame has no checksum and no byte stuffing, so occasional frames are dropped (tolerated by design).

Documentation

• docs/Doku/doku.pdf — project report with design calculations (German, LaTeX sources included)
• docs/UART_PROTOCOL.md — HMI ↔ mainboard serial protocol specification
• docs/infineon-im06b50gc1-datasheet-en.pdf — power module datasheet
• docs/Plakat/ — project poster; docs/Pitch/ — pitch video; docs/Gantt-Diagramm/ — project schedule

Team

Developed as part of Projekt Mechatronik at Munich University of Applied Sciences (HM), supervised by Prof. Dr. Marek Galek and Prof. Dr. Ulrich Unterhinninghofen:

• Martin Kistler — martin.kistler@hm.edu
• Florian Langlechner — florian.langlechner@hm.edu
• Valerian Moser — valerian.moser@hm.edu

License

This project is licensed under the GNU General Public License v3.0 — see LICENSE.