How uibkaccsev/-bergang works
This repository appears to be a Python-based testbench application for VESC/motor measurements, with a packaged Windows executable for end users.
1. Top-level purpose
- The project centers on an automated motor/drive measurement workflow: starting a test, selecting motor/configuration data, acquiring signals, detecting motor behavior, and writing measurement protocols.
- The presence of VESC_Testbench.exe suggests the repo is meant to be deployed as a desktop tool rather than a library.
2. Launch and UI boundary
- exe_entry.py and gui_launcher.py are the main entry points.
- gui_launcher.py likely starts the user-facing application, while exe_entry.py is the executable bootstrap used when the project is bundled into the .exe.
- This is the outer boundary where an operator interacts with the system.
3. Measurement workflow/orchestration
- messablauf.py is the clearest sign of a central measurement sequence controller.
- It likely coordinates the order of operations: setup, triggering instrument reads, collecting data, evaluation, and final reporting.
- This module is the main “spine” of the application and probably calls into the specialized measurement components below.
4. Motor and signal analysis subsystems
- Motordaten_detektion.py suggests logic for detecting or extracting motor data from measurements.
- BEMF-aktualisierung.py and bemf_protokoll.py indicate a back-EMF-related analysis/reporting path.
- These modules likely consume raw measurement data and produce derived results used in the workflow and logs.
5. Oscilloscope-based acquisition
- oszi_BEMF_measure.py and oszi_dm_measure.py indicate dedicated oscilloscope acquisition scripts for different measurement modes.
- OscilloscopeStream_dm.csv is likely an example capture, template, or recorded dataset used by the measurement code.
- This is a hardware-facing subsystem that probably interfaces with an oscilloscope or streamed waveform data source.
6. Power supply / external hardware control
- lan_PSU.py likely manages a laboratory power supply over the network.
- This is an important hardware boundary because it implies the testbench does not only read data but also actively controls test conditions.
- If diagramming the system, this should be shown as a separate device integration path alongside the oscilloscope and motor controller.
7. Motor controller configuration
- mcconf_set.py suggests configuration of the motor controller, likely VESC-related settings.
- This is probably the setup layer that applies parameters before or during a test run.
- It sits between the operator workflow and the motor hardware.
8. Logging and reporting
- messprotokoll_V3.py appears to be the main measurement protocol/report generator.
- bemf_protokoll.py is a specialized protocol path for BEMF measurements.
- These modules likely persist results, measurements, and evaluation summaries, forming the output side of the architecture.
9. Configuration/data assets
- config/Lastmotor.json and config/Motorauswahl.json are persistent configuration inputs.
- They likely store selectable motor/load-motor definitions and parameters used by the workflow.
- These JSON files are a clear data boundary: user-facing measurement code depends on them for test setup.
10. Runtime shape
- The repository is primarily a Python application with hardware integration, likely running on a Windows machine connected to lab equipment.
- The .exe packaging suggests the runtime can be distributed without requiring the user to run Python directly.
- The architecture is therefore best drawn as: operator/UI → workflow controller → measurement/control modules → external devices, with config files and protocol outputs as supporting data paths.
11. Key external dependencies inferred from structure
- Oscilloscope / streaming measurement source
- Network-controlled lab power supply
- Motor controller / VESC device
- Local filesystem for configs, CSVs, and protocols
- Windows executable packaging for deployment
12. How to diagram the boundaries
- Put the GUI/executable at the top.
- Show messablauf.py as the orchestration core.
- Branch from it to:
- acquisition modules (oszi_*, Motordaten_detektion.py)
- control/config modules (lan_PSU.py, mcconf_set.py)
- reporting modules (messprotokoll_V3.py, bemf_protokoll.py)
- Place config/*.json and CSV files as inputs, and measurement protocols as outputs.
13. What is not clear from the repo
- The README provides no architectural detail.
- The exact hardware protocols and whether the oscilloscope/PSU are vendor-specific cannot be confirmed from filenames alone.
- Still, the module names strongly indicate a lab/testbench application focused on motor and BEMF measurement automation.
Main entry points: messablauf.py Workflow · oszi_dm_measure.py DM measure · oszi_BEMF_measure.py BEMF measure · gui_launcher.py GUI launcher
Components 17
Interface
User-facing launch and application entry points.
- Exe entry · Windows executable bootstrap for bundled execution.
exe_entry.py - GUI launcher · Starts the operator-facing application.
gui_launcher.py
Workflow
Measurement orchestration and result generation.
- Workflow · Coordinates the measurement sequence from setup to completion.
messablauf.py - MC config · Applies motor-controller configuration before or during tests.
mcconf_set.py - Protocol · Generates the main measurement protocol and results output.
messprotokoll_V3.py - BEMF report · Writes back-EMF-specific protocol output.
bemf_protokoll.py
Hardware
Device integration and acquisition modules.
- DM measure · Oscilloscope acquisition path for dm measurements.
oszi_dm_measure.py - BEMF measure · Oscilloscope acquisition path for back-EMF measurements.
oszi_BEMF_measure.py - Motor detect · Extracts or detects motor data from measurement signals.
Motordaten_detektion.py - BEMF update · Updates or transforms back-EMF related measurement data.
BEMF-aktualisierung.py - LAN PSU · Controls the lab power supply over the network.
lan_PSU.py - Oscilloscope · External waveform acquisition instrument.
- Power supply · Externally controlled laboratory power supply.
- Motor controller · VESC or related motor-control target under test.
Data
Configuration and captured measurement assets.
- Lastmotor · Load motor configuration data used by the workflow.
config/Lastmotor.json - Motor selection · Motor selection and parameter data for test setup.
config/Motorauswahl.json - Stream data · Example or captured oscilloscope stream data.
OscilloscopeStream_dm.csv
Connections 17
- Exe entry → GUI launcher: starts · Executable bootstrap launches the UI application.
- GUI launcher → Workflow: invokes · The UI hands control to the measurement workflow.
- Workflow → MC config: configures · Workflow applies controller setup before measurement.
- Workflow → DM measure: runs dm capture · Workflow triggers oscilloscope-based dm measurement.
- Workflow → BEMF measure: runs BEMF capture · Workflow triggers oscilloscope-based BEMF measurement.
- DM measure → Oscilloscope: reads · DM measurement acquires signals from the oscilloscope.
- BEMF measure → Oscilloscope: reads · BEMF measurement acquires signals from the oscilloscope.
- DM measure → Motor detect: feeds · Captured signals are analyzed for motor data.
- BEMF measure → BEMF update: feeds · Captured signals are processed for BEMF updates.
- Motor detect → Protocol: summarizes · Detected motor data is written to the main protocol.
- BEMF update → BEMF report: summarizes · BEMF analysis is written to the specialized report.
- Workflow → LAN PSU: controls · Workflow can enable or adjust the power supply.
- LAN PSU → Power supply: drives · Network control targets the laboratory power supply.
- MC config → Motor controller: applies settings · Configuration is pushed to the motor controller under test.
- Workflow → Lastmotor: loads · Workflow reads load-motor configuration data.
- Workflow → Motor selection: loads · Workflow reads motor selection data.
- DM measure → Stream data: uses sample · DM measurement can consume or mirror stream capture data.