LabVIEW test-automation portfolio project demonstrating automated test sequencing, NI-DAQmx acquisition, Modbus TCP communication, safety logic, fault injection, validation, and TDMS logging.
The application runs a three-stage electric-motor test sequence, acquires measurements through interchangeable data sources, evaluates acceptance and safety criteria, reacts to system faults, and records measurements plus test metadata for later review.
Core technologies: LabVIEW | NI-DAQmx | Modbus TCP | Python / PyModbus | TDMS | Git
Project documentation: Setup & Run Guide | Technical Architecture | Validation Matrix
| Area | Implementation |
|---|---|
| Test executive | LabVIEW state machine with 1000, 2000, and 3000 RPM stages |
| Measurement sources | Software simulator, simulated NI-DAQmx hardware, or Modbus TCP |
| Industrial communication | Modbus TCP command/feedback exchange with communication-loss detection |
| Safety | Independent safety trips, automatic FAULT transition, and zero RPM/load command |
| Test evaluation | Configurable acceptance limits with latched test-failure result |
| Fault testing | Overcurrent, overtemperature, high vibration, and RPM sensor failure injection |
| Data logging | TDMS measurement channels plus final-result and configuration metadata |
| Validation | Nine documented end-to-end and fault-handling scenarios in VALIDATION.md |
- Automated LabVIEW state-machine test sequence
- 1000 RPM, 2000 RPM, and 3000 RPM operating points
- Configurable load commands and acceptance limits
- Three interchangeable measurement sources:
- software motor simulator
- NI-DAQmx with simulated NI cDAQ hardware
- Modbus TCP virtual motor controller
- Modbus TCP command and measurement exchange
- Separate acceptance-failure and safety-trip logic
- Communication-loss detection
- Controlled fault injection
- TDMS measurement and metadata logging
- Test-failure latching and automatic FAULT transition
- State-entry timer reset and measurement-settling logic
- Operator-oriented HMI
IDLE
|
v
TEST_1000_RPM 1000 RPM / 25% load
|
v
TEST_2000_RPM 2000 RPM / 50% load
|
v
TEST_3000_RPM 3000 RPM / 75% load
|
v
COMPLETE
Each active test stage runs for approximately five seconds. A short settling period is applied after each setpoint change before acceptance criteria are allowed to latch a test failure. Safety monitoring remains active during that settling period.
MotorTestBench_Main.vi
|
+--------------------+--------------------+
| | |
v v v
State Machine Measurement Source Test Controls
|
+--------------+--------------+
| | |
v v v
MotorSimulator NI-DAQmx Modbus TCP
| | |
+--------------+--------------+
|
v
MotorMeasurements.ctl
|
v
InjectFaults.vi
|
v
EvaluateMotorLimits.vi
|
+-------------+-------------+
| | |
v v v
HMI TDMS Logging Fault Handling
The application uses a common MotorMeasurements.ctl typedef so downstream logic does not need to know whether the data came from software simulation, DAQmx, or Modbus TCP.
For the design rationale, state-machine behavior, safety hierarchy, timing logic, and subsystem boundaries, see ARCHITECTURE.md.
The common measurement cluster contains:
- Actual RPM
- Torque (Nm)
- Current (A)
- Temperature (°C)
- Vibration (mm/s)
The DAQ subsystem uses explicit initialization, acquisition, and shutdown VIs:
DAQ_Initialize.viDAQ_ReadMeasurements.viSensorScaling.viDAQ_Shutdown.vi
Development was performed with simulated NI hardware in NI MAX:
- NI cDAQ-9174 chassis
- NI 9205 analog-input module
- channels
ai0:4
Channel mapping used by the project:
| Channel | Measurement |
|---|---|
| ai0 | Temperature |
| ai1 | Current |
| ai2 | Torque |
| ai3 | Vibration |
| ai4 | RPM |
The sensor transfer functions used here are simplified software mappings for test-automation development, not calibrated physical sensor models.
Physical NI hardware commissioning was not performed in this project.
The Modbus path consists of:
Modbus_Initialize.viModbus_WriteCommands.viModbus_ReadMeasurements.viModbus_Shutdown.vi
LabVIEW maintains the Modbus session across the main loop, writes command registers, and reads measurement registers from a Python-based virtual motor controller.
Development connection:
IP Address : 127.0.0.1
Port : 5020
Device ID : 1
| Address | Signal |
|---|---|
| 0 | Commanded RPM |
| 1 | Load % |
| 2 | Actual RPM |
| 3 | Current x10 |
| 4 | Temperature x10 |
| 5 | Torque x10 |
| 6 | Vibration x10 |
| 7 | System Status |
Values with x10 scaling are transported as integer Modbus registers and converted back to engineering values in LabVIEW.
The virtual controller is implemented in Python using PyModbus:
ModbusSimulator/
modbus_motor_server.py
requirements.txt
The server accepts commanded RPM and load, calculates simplified motor measurements, and exposes them through the Modbus register map.
For complete environment setup and run instructions, see SETUP.md.
Acceptance failures and system safety trips are intentionally separated.
Acceptance checks include RPM error and configurable current, temperature, and vibration test limits. An acceptance violation can latch TEST FAILED while allowing the test executive to continue.
Safety conditions cause the state machine to enter FAULT and command RPM/load to zero. Safety handling includes:
- overcurrent
- overtemperature
- excessive vibration
- RPM sensor failure injection
- Modbus communication loss
The safety path remains active during the post-transition settling period.
InjectFaults.vi supports controlled test scenarios through FaultInjectionMode.ctl:
NONEOVERCURRENTOVERTEMPERATUREHIGH_VIBRATIONRPM_SENSOR_FAILURE
This allows safety behavior to be validated without physical motor hardware.
TDMS_LogMeasurements.vi logs the following channels under the motor-data group:
Actual_RPMTorque_NmCurrent_ATemperature_CVibration_mm_sTimestamp
The application also stores test configuration and final-result metadata as TDMS properties.
The documented validation matrix is available in VALIDATION.md.
Validated scenarios include:
- full software-simulator test sequence
- full Modbus TCP test sequence
- overcurrent safety trip
- overtemperature safety trip
- excessive-vibration safety trip
- RPM sensor failure
- Modbus communication loss
- repeated test execution with timer reset
- Modbus transition settling without false RPM-failure latching
MotorTestBench.lvproj
MotorTestBench_Main.vi
MotorSimulator.vi
MotorMeasurements.ctl
DAQ_Initialize.vi
DAQ_ReadMeasurements.vi
DAQ_Shutdown.vi
SensorScaling.vi
Modbus_Initialize.vi
Modbus_WriteCommands.vi
Modbus_ReadMeasurements.vi
Modbus_Shutdown.vi
ModbusRegister.ctl
EvaluateMotorLimits.vi
InjectFaults.vi
FaultInjectionMode.ctl
TDMS_LogMeasurements.vi
ModbusSimulator/
TestEvidence/
README.md
SETUP.md
ARCHITECTURE.md
VALIDATION.md
- LabVIEW Community Edition
- NI-DAQmx
- NI MAX
- simulated NI cDAQ-9174 / NI 9205
- Modbus TCP
- Plasmionique Modbus Master
- Python
- PyModbus
- TDMS
- Git / GitHub
This is a portfolio and test-automation learning project. The motor model, sensor scaling, and virtual controller are simplified simulations intended to exercise software architecture, acquisition, communication, logging, validation, and fault-handling workflows.
It does not claim physical motor/dynamometer commissioning or physical NI hardware commissioning experience.