ETI Test Bench App

Windows desktop app for ETI breaker-cycle testing. The UI is an Electron shell over a Flask + Socket.IO backend that drives two Festo motors, reads NI DAQ data, stores test metadata in SQLite, and writes per-cycle CSV files.

What the app does

• Creates and manages test records.
• Stores per-test settings per circuit type.
• Runs single steps or full multi-cycle tests.
• Acquires force/contact data from NI DAQ during motor motion.
• Saves raw and analysed measurement files.
• Supports sensor zero-offset calibration and motor-rotation correction.

Runtime overview

• Desktop launcher: Start_App.bat
• Electron wrapper: electron/
• Backend server: backend/app.py
• UI templates: templates/
• Frontend JS: static/js/
• Hardware control: hardware_interface/
• Database: backend/app.db
• Default measurement output: Meritve/
• Default circuit settings: default_settings/*.json

Main hardware/software path

1. Electron starts the Flask backend on http://127.0.0.1:5050.
2. Flask serves the UI and exposes REST + Socket.IO endpoints.
3. hardware_interface/stepes_manager.py coordinates steps/cycles.
4. hardware_interface/motors.py talks to two Festo drives over Modbus/TCP.
5. hardware_interface/daq.py reads the persisted NI task CB_tester_NI_task.
6. Results are stored in SQLite and exported as CSV under the selected save path.

Requirements

• Windows
• Python environment with packages from requrements.txt
• Node.js for Electron
• NI-DAQmx installed and persisted NI task named CB_tester_NI_task
• Reachable Festo drives at:
  • 192.168.0.2
  • 192.168.0.4

Running the app

Preferred:

Start_App.bat

Manual:

cd electron
npm start

Data and database

• SQLite file: backend/app.db
• Main tables:
  • tests
  • test_settings
  • app_status
  • calibration_data_zero_offset
  • torque_correction_coefficients
• Measurement files:
  • <saving_location>/<test_name>/<cycle_number>/*.csv
  • <saving_location>/<test_name>/analysed_data.csv

Database note:

• Current schema initialization is in backend/db.py.
• Existing migration only adds dmc_code and comments.
• The production-safe motor fixes listed below do not require DB schema changes.

Festo motor connection diagnosis

This is a code-based diagnosis, not proof of the physical root cause. The code strongly suggests that the app has weak detection and reporting of transient motor communication loss.

How connection loss is currently handled

• The app connects both motors once at backend startup.
• After a disconnect, the app does not keep an active health monitor.
• On the next move or position read, hardware_interface/motors.py tries:
  • shutdown()
  • connect()
• Only one reconnect attempt is made.
• After every completed or stopped test, motors are explicitly shut down, so the next operation must reconnect again.

Why the disconnect can look random

1. The underlying festo-edcon Modbus layer stops its I/O thread on any I/O exception and closes the client.
2. The project code catches most motor exceptions and converts them to False, so the real error is hidden.
3. The app usually notices the problem only on the next motor read/write, not when the link first drops.
4. The step executor has a hard 7.0 second watchdog for motor threads. If motion/recovery takes longer, the app stops motion and the failure can look like a disconnect.
5. The backend emits motor_status_changed, but the active frontend socket manager does not subscribe to it, so operators do not get a clear motor-state event.

Most likely software-level causes from the code

• Transient Modbus/TCP interruption, EMC noise, switch/cable issue, or drive reset.
• Drive becomes not operational or faults during motion, which the library treats as communication interruption.
• Lazy reconnect inside worker threads with no retry/backoff and no lock around reconnect/shutdown.
• Motor timeout in step execution shorter than worst-case recovery/reference time.
• Exceptions swallowed in try_execute_operation(), which makes failures look intermittent and harder to diagnose.

Relevant code paths

• App startup connects motors: backend/app.py
• Motor wrapper and reconnect logic: hardware_interface/motors.py
• Step timeout and motor thread monitoring: hardware_interface/stepes_manager.py
• Modbus I/O thread shutdown on communication error:
  • venv/Lib/site-packages/edcon/edrive/com_modbus.py
  • venv/Lib/site-packages/edcon/edrive/telegram_handler.py

Important behavior to know

• A disconnect during idle may not be visible until the next step starts.
• A disconnect during motion may end as:
  • silent False from motor wrapper
  • no data from step execution
  • generic step/test failure in UI
• The current implementation is reactive, not robustly fault-aware.

Production-safe next steps

These changes are safe from a database perspective because they do not require schema changes:

• Stop swallowing the original motor exception. Log the real exception and fault details.
• Add reconnect retries with backoff instead of a single reconnect attempt.
• Add a lock around motor connect() / shutdown() / reconnect flow.
• Make the 7.0 second step watchdog configurable and larger than worst-case motion + reconnect time.
• Surface motor_status_changed in the frontend so operators see motor health immediately.
• Add explicit logging around:
  • connect start/end
  • reconnect attempt count
  • fault code
  • operation-enabled state
  • timeout vs true disconnect

Short conclusion

From the code, the problem is not the database. The main weakness is motor communication fault handling: the low-level library drops communication on I/O errors, and the app recovers only partially, with hidden exceptions and weak UI reporting. That is why the disconnect can appear random even when there was a real Modbus/drive interruption underneath.