Waggot Cams work experience

Spintron / Camshaft Dyno

A Waggot Cams project to turn a camshaft test rig into an integrated remote-control and measurement system using a computer program, a Nucleo microcontroller interface, VFD control, encoder feedback, Keyence laser lift measurement, and physical CAD mounting work.

Computer program Nucleo / STM32 VFD control Encoder + Keyence laser CAD mounts Data analysis

Stylised real-world Spintron camshaft dyno rig with the background removed — Stylised real-rig overview image used as the public-facing Spintron / camshaft dyno visual.

What is being measured?

Camshaft motion becomes valve lift data.

A camshaft is a rotating shaft with shaped lobes that control when engine valves open and close. As each lobe rotates, it pushes through the valvetrain to lift the valve against the spring, then the spring closes the valve as the lobe rotates away.

Camshaft lobe, follower, pushrod, rocker arm, valve spring, and valve showing how rotating cam motion becomes valve lift

The Spintron project is about measuring that motion accurately. The encoder provides shaft angle and RPM, while the Keyence laser measures lift. The software then aligns those signals so the useful plot becomes lift versus camshaft angle, not just lift versus time or commanded motor speed.

Camshaft lobe: Converts rotation into a timed lift profile.
Laser measurement: Captures valve, follower, or target displacement.
Encoder reference: Turns shaft motion into measured RPM and angle.
Analysis output: Plots lift, velocity, acceleration, and jerk against cam angle.

Spintron analysis plot showing measured valve lift, velocity, acceleration, jerk, sample points, and valve open and close markers against continuous camshaft angle — Example analysis target: lift, velocity, acceleration, and jerk plotted against continuous camshaft angle.

Cam-lobe visualisation with problematic regions highlighted in yellow and red for engineering review — Cam-lobe visualisation showing highlighted regions where the measured or machined profile may need closer inspection.

How to read the motion data

Lift: Measured valve/follower displacement from the laser.
Velocity: How quickly the valve opens or closes.
Acceleration: How quickly valve velocity changes.
Jerk: How quickly acceleration changes. Highly sensitive to noise.

The useful engineering result is not just lift over time. It is lift, velocity, acceleration, and jerk plotted against camshaft angle using encoder feedback as the angular reference.

Interactive system overview

Spintron control and measurement architecture.

Component-level view of the PC dashboard, Nucleo controller, VFD drive path, encoder feedback, Keyence laser chain, analog front-end, and hardwired safety boundary.

System map Operator software, controller I/O, drive control, sensing, and data capture

Component cards show the main hardware and software blocks. Small circles on the connection lines open the wire type, signal carried, and implementation notes.

Operator layer

PC dashboard

The PC is the operator-facing layer of the system. It is used to configure runs, monitor live machine data, and review saved results, while the Nucleo remains responsible for machine-side timing and control.

Operator interface

What this block does

Builds RPM programs or loads uploaded RPM traces.
Sends run setup, start/stop commands, target RPM steps, and recording-window settings.
Displays desired RPM, measured RPM, capture status, and low-rate live data.
Opens saved high-speed run data for post-run analysis and plotting.

Operator review and run commands

Into PC

Measured RPM, capture status, live telemetry, saved run data, and analysis files.

Out of PC

Run profiles, target RPM steps, recording windows, start/stop commands, and analysis settings.

Design role

The PC is the supervisory dashboard, not the real-time machine controller. Time-critical control, measurement, and buffering stay on the Nucleo side.

Controller and DAQ

NUCLEO-H753ZI

The Nucleo is the timing-critical interface between the PC dashboard and the machine hardware. It counts encoder pulses, samples the conditioned laser signal, manages run-state buffering, and sends machine commands through the planned VFD communication path.

Machine interface controller

What this block does

Counts encoder A/B/Z pulses for shaft angle and measured RPM.
Samples the conditioned laser displacement signal through the ADC path.
Handles timing-critical capture, buffering, and run-state logic close to the machine.
Sends lower-rate telemetry and saved high-speed data back to the PC dashboard.
Sends VFD speed/run commands through the planned RS485/Modbus interface.

Into Nucleo

Encoder A/B/Z signals, conditioned laser ADC signal, safety/status inputs, and PC run commands.

Out to PC

Measured RPM, shaft angle, capture status, run state, telemetry, and buffered saved samples.

Out to machine

Planned VFD speed/run commands through the RS485/Modbus interface path.

Design role

The Nucleo keeps time-critical measurement and buffering close to the hardware, while the PC remains the supervisory dashboard.

Drive control

VFD

The VFD is the drive layer that controls motor speed. The PC dashboard sends the desired run profile through the Nucleo and planned RS485/Modbus path, but measured encoder RPM is treated as the true feedback signal.

Speed control layer

What this block does

Receives planned speed/frequency and run commands through the RS485/Modbus control path.
Drives the motor with controlled three-phase power.
Allows programmed ramp, hold, and run-down sections during a test.
Requires correct register mapping, enable logic, parameter setup, and commissioning before hardware operation.
Sits inside the machine safety boundary, with hardwired enable/stop logic separate from dashboard software.

Control note

Command vs measured response: The VFD controls the motor, but the encoder confirms what the shaft actually did.

Into VFD

Run enable conditions, target speed/frequency commands, ramp settings, and planned Modbus register writes.

Out to motor

Controlled three-phase drive output to spin the test rig through the motor and belt drive.

Feedback boundary

The VFD receives commands, but actual RPM and shaft angle are measured by the encoder feedback path.

Design check

Safe operation depends on VFD parameter setup, hardwired enable/stop logic, isolation, grounding, and commissioning tests.

Command interface

RS485 interface board

The RS485 board is the communication bridge between the Nucleo and the VFD. It converts the Nucleo UART command path into a differential RS485 signal for the planned VFD speed/run command interface.

VFD command interface

What this block does

Converts Nucleo UART TX/RX logic into an RS485 differential communication signal.
Sends planned Modbus-style commands for target speed, run state, ramp settings, and register writes.
Keeps the VFD command wiring separate from encoder feedback and laser measurement wiring.
Requires correct VFD register mapping, baud rate, termination, grounding, and commissioning before hardware operation.
Command communication is separate from hardwired safety, enable, and emergency-stop behaviour.

Command boundary

Command messages only: This board carries command messages only. Motor power comes from the VFD output, and machine safety must remain hardwired.

From Nucleo

UART-level VFD command messages from the machine-interface controller.

Interface role

Converts low-voltage UART logic into a noise-tolerant RS485 differential command signal.

To VFD

RS485 command pair connected to the VFD communication terminals for Modbus-style control.

Design check

Confirm isolation, termination, grounding, baud rate, register map, VFD enable logic, and commissioning procedure.

Mechanical drive

Drive motor

The drive motor is the physical actuator for the rig. The VFD controls motor speed, while the encoder feedback path confirms the actual shaft speed and angle instead of relying only on the commanded VFD target.

Physical plant

What this block does

Receives controlled power output from the VFD.
Drives the belt and output-shaft hardware that spins the camshaft.
Represents the real rotating plant, including inertia, load changes, vibration, and ramp behaviour.
Encoder feedback is used to measure the actual output response.
Guarding, mounting, cable routing, and drive isolation are practical design constraints.

Command vs feedback

Control note: The motor is commanded by the VFD, but the encoder provides the measured truth used for RPM tracking and data alignment.

Into motor

Controlled three-phase drive power from the VFD.

Mechanical output

Motor rotation transferred through the belt drive to the output shaft and camshaft hardware.

Measured response

Actual shaft speed and angle are measured downstream by the encoder feedback path.

Design check

The control system must account for acceleration ramps, rotating inertia, vibration, guarding, and safe shutdown behaviour.

Mechanical output

Output shaft and belt drive

The output shaft and belt drive are the mechanical output of the rig. This is the rotating system the measurement setup must track accurately so laser lift data can be aligned with real camshaft angle rather than only the commanded motor speed.

Measured rotating output

What this block does

Transfers motor rotation through the belt drive to the camshaft test hardware.
Provides the real mechanical angle and speed reference for camshaft testing.
Connects the physical rotating plant to the encoder feedback and data-capture system.
Requires good alignment, guarding, stiffness, and access for encoder mounting.
Any belt ratio or shaft-speed relationship must be accounted for when converting encoder counts to cam angle.

Command vs measured output

Control note: The VFD commands the motor, but this shaft is the mechanical output that must be measured and aligned with the laser lift data.

Mechanical input

Rotation transferred from the VFD-driven motor through the belt-drive path.

Mechanical output

Rotating camshaft/test shaft motion used for high-speed valvetrain measurement.

Measured reference

Encoder feedback converts shaft motion into measured RPM and angular position.

Design check

Alignment, guarding, shaft stiffness, belt ratio, encoder mounting, and safe high-speed operation must be checked before testing.

Rotational feedback

Crankshaft encoder

The encoder provides the angular reference used to align laser lift samples with camshaft position. It also provides measured RPM feedback, which is more useful for control and analysis than the commanded VFD target alone.

RPM and angle feedback

What this block does

Uses a US Digital H6-1024-IE-D incremental encoder for shaft angle and RPM feedback.
Provides quadrature A/B signals plus an index reference for once-per-revolution alignment.
Uses differential encoder signalling into a 26C32 / RS422-style receiver before the Nucleo timer inputs.
1024 CPR gives 4096 counts/rev with x4 quadrature decoding.
Final commissioning must check encoder speed rating against the selected mounting shaft.

Mechanical input

Rotating shaft position and speed from the crankshaft or selected encoder shaft.

Encoder output

Differential A/B/Z signals for direction, angle tracking, RPM calculation, and index reference.

To receiver board

Differential encoder signals are converted by a line receiver before entering the Nucleo timer inputs.

Design check

The selected H6 encoder is rated to 10,000 rpm mechanically. Because it is connected to the crankshaft, it sees 2x camshaft speed, so the mounting shaft must stay within the encoder speed limit.

Encoder interface

RS422 encoder receiver board

The receiver board sits between the shaft encoder and the Nucleo. It receives the differential A/B/Z encoder signals and converts them into MCU-safe A, B, and Z logic signals that the Nucleo timer inputs can count reliably.

Encoder signal conditioning

What this block does

Receives differential A+/A-, B+/B-, and Z+/Z- signals from the encoder cable.
Converts the differential encoder pairs into MCU-level A, B, and Z logic signals.
Improves noise immunity compared with single-ended encoder wiring.
Sends clean A/B signals to the Nucleo timer for x4 quadrature decoding.
Sends the Z/index pulse to the Nucleo for once-per-revolution reference alignment.

From encoder

Differential A/B/Z signal pairs from the shaft encoder cable.

Receiver role

Line receiver converts differential encoder signals into clean MCU-level logic signals.

To Nucleo timers

A and B go to timer encoder inputs for quadrature counting. Z provides the index reference.

Design check

Termination, shielding, grounding, signal polarity, and bench validation must be checked before high-speed operation.

Analog front-end

0–10 V to 0–3.3 V board

This board sits between the LK-GD500 and the Nucleo. It conditions the 0–10 V analog displacement output into a Nucleo-safe 0–3.3 V ADC signal while protecting the input and preserving enough bandwidth for lift capture.

Laser ADC interface

What this block does

Scales LK-GD500 OUT1(V) from 0–10 V down to the Nucleo ADC range.
Buffers the analog signal so the ADC sees a stable input.
Protects the ADC input from overvoltage and wiring mistakes.
Preserves enough signal bandwidth for lift capture.
Requires calibration so ADC voltage maps cleanly back to displacement.

ADC interface note

Signal boundary: The LK-GD500 provides the measurement output, but this board makes that signal safe and usable for the microcontroller ADC.

From LK-GD500

0–10 V analog displacement signal from OUT1(V), referenced to OUT1 0 V.

Front-end role

Scales, buffers, and protects the analog signal before ADC sampling.

To Nucleo ADC

0–3.3 V scaled analog signal for ADC sampling and later lift reconstruction.

Design check

Scaling ratio, protection limits, bandwidth, and calibration must be validated before trusted measurement.

Laser controller

LK-GD500

The LK-GD500 is the existing Keyence measurement controller. It converts the laser-head measurement into an analog displacement signal, which is scaled and protected before being sampled by the Nucleo ADC and aligned with encoder angle.

Displacement controller

What this block does

Receives displacement measurement data from the Keyence laser head.
Provides the analog lift/displacement output through OUT1(V) and OUT1 0 V.
Measurement scaling depends on the Keyence measurement range and calibration setup.
Sends the analog output to a front-end board before the Nucleo ADC.
Lets the project reuse accurate existing displacement hardware instead of replacing it.

Interface split

Controller vs front-end: The LK-GD500 handles the laser measurement. The custom front-end board handles voltage scaling and ADC protection.

From laser head

Measured valve/follower displacement from the Keyence laser sensor.

Controller role

Converts the laser measurement into a usable analog output based on the configured measurement range.

To analog front-end

OUT1(V) and OUT1 0 V provide the analog displacement signal before scaling and protection.

Design check

The voltage-to-displacement scaling must be recorded so ADC values can be converted back into lift data.

Sensor head

Keyence LK-G82

The LK-G82 laser head provides the non-contact displacement measurement used to create the lift trace. The key requirement is to align this displacement signal with encoder angle so the run can be analysed as lift versus camshaft position.

Lift measurement

What this block does

Measures valve, follower, or target displacement depending on the test setup.
Sends the laser-head measurement to the LK-GD500 controller.
Requires stable mounting, correct standoff, target alignment, and calibration before trusted testing.
Forms the lift channel used to calculate displacement, velocity, acceleration, and jerk.
Must be mechanically isolated from vibration as much as practical.

Interface split

LK-G82 vs LK-GD500: The LK-G82 measures displacement. The LK-GD500 converts that measurement into the analog signal used by the Nucleo-side data capture system.

Physical input

Moving valve, follower, or test target surface under the laser spot.

Sensor role

Measures displacement without contacting the moving valvetrain component.

To controller

Laser-head signal is sent to the LK-GD500 controller before becoming an analog output.

Design check

Mounting stiffness, target alignment, measurement range, and calibration directly affect lift-data quality.

Safety boundary

Hardwired safety

The dashboard and Nucleo are control and measurement tools, not the primary safety layer. Emergency stop, guarding, interlocks, isolation, and VFD enable/stop behaviour should remain hardwired and validated separately from the browser software.

Safety separation

What this block does

Keeps emergency stop and machine safety functions independent of the PC dashboard.
Ensures a software crash, network fault, or Nucleo fault cannot be the only stop method.
Places the VFD enable/stop behaviour inside a hardwired safety boundary.
Requires real wiring, interlock mapping, isolation checks, and commissioning tests before high-speed operation.
Provides a clear separation between HMI convenience and machine safety.

Safety note

Hardwired protection: Software can support safe operation, but hardwired safety must still protect the machine if the PC, network, or controller fails.

Safety inputs

E-stop, guards, enable conditions, interlocks, isolation checks, and operator intervention.

Safety action

Stop, inhibit, isolate, disable drive enable, or require reset before another run.

Software boundary

The dashboard can request stop commands, but it should not be the only safety mechanism.

Design check

Final commissioning must validate wiring, VFD enable behaviour, E-stop response, grounding, and safe restart conditions.

Communication cable

PC to Nucleo link

The PC is the operator interface. The Nucleo is the machine-side controller. USB is used for programming/debugging, while Ethernet is the planned runtime link for commands, telemetry, and saved data transfer.

USB + Ethernet

Communication role

USB: used for ST-LINK programming, firmware updates, and debugging.
Ethernet: used for runtime commands, live telemetry, and saved run-data transfer.
The Nucleo handles machine-side timing and buffering before sending useful data to the PC dashboard.
Live dashboard data is reduced for responsiveness, while high-speed data is saved for post-run analysis.

USB and Ethernet cables representing the physical communication options between the operator PC and the Nucleo controller — USB is used for development access; Cat6 Ethernet is used as the planned machine communication link.

Runtime data margin

High-speed capture target: Up to 50,000 samples/s from the measurement system.
Estimated data stream: Roughly 10-25 Mb/s after timestamps, packet overhead, status fields, and safety margin.
Ethernet margin: Even a 100 Mb/s controller link provides comfortable margin, so the main challenge is firmware buffering and timing, not cable bandwidth.

Controller wiring

Nucleo to RS485 board

Short controller-side jumper wiring carries UART-level command messages from the Nucleo to the RS485 interface board before the signal is converted for the longer VFD communication run.

UART command link

Wire type and purpose

Carries UART-level VFD command messages out of the Nucleo.
Connects the controller pins to the RS485 board through a short jumper harness.
Should be kept short and routed away from VFD and motor power wiring.
Final pins and message timing will be confirmed during firmware and CubeMX setup.

Short jumper wire harness used between the Nucleo controller and RS485 transceiver board — Short jumper wire harness representing the controller-side UART command link between the Nucleo and RS485 transceiver board.

Wire details

Wire type: Short low-voltage jumper wiring from Nucleo pins to the RS485 transceiver board.
Signal carried: TX/RX command messages and reference ground as required by the final interface wiring.
Design note: Keep this link short, documented, and physically separated from drive power wiring.

Drive communication

RS485 board to VFD

This cable run carries the RS485 differential command signal from the transceiver board into the VFD communication terminals for Modbus-style speed control and status messages.

RS485 field wiring

Wire type and purpose

Carries the differential A/B pair from the RS485 board to the VFD terminals.
Represents the practical cable run between the low-voltage control electronics and the drive.
Should be routed away from VFD output and motor power wiring where possible.
Final termination, shielding, and grounding approach should be confirmed during commissioning.

Twisted-pair RS485 cable used between the RS485 transceiver board and VFD communication terminals — Twisted-pair RS485 cable representing the command link between the RS485 transceiver board and the VFD communication terminals.

Wire details

Wire type: Twisted-pair RS485 cable.
Signal carried: Differential RS485 A/B command and status communication.
Design note: Use the VFD manual to confirm terminal assignment, biasing, termination, and Modbus settings.

Motor power wiring

VFD to motor

The VFD output is the high-power motor-drive connection. It is separate from the low-voltage controller, encoder, and laser measurement wiring.

Three-phase drive output

Wire type and purpose

Carries controlled three-phase output from the VFD to the drive motor.
Belongs to the power side of the rig rather than the low-voltage DAQ wiring.
Needs appropriate cable rating, enclosure routing, grounding, and safe isolation practice.
Measured encoder RPM is used to verify the actual rotating speed rather than trusting the command alone.

Wire details

Wire type: Motor-rated three-phase power wiring from VFD output to motor terminals.
Signal carried: Controlled motor drive power, not measurement data.
Design note: Route and isolate this separately from ADC, encoder, and communication wiring.

Mechanical drive path

Motor to output shaft

This connection represents the physical belt and shaft path between the drive motor and the output shaft being measured. It is not a data cable, but it is a critical part of the system because the encoder feedback must describe the real rotating shaft, not just the motor command.

Mechanical drive transfer

Connection type and purpose

Transfers rotation from the motor through the belt and output-shaft hardware.
Represents the mechanical plant that the VFD command ultimately drives.
Needs correct alignment, tension, guarding, and high-speed mechanical safety practice.
Measured encoder feedback is used because the mechanical output can differ from the commanded drive behaviour.

Connection details

Connection type: Mechanical belt and shaft drive path.
Behaviour carried: Rotational speed, torque, belt dynamics, and output-shaft motion.
Design note: Treat this as the physical plant being controlled and measured, not as a software-only signal.

Mechanical measurement reference

Crankshaft to encoder

This connection represents the encoder being mechanically referenced to the crankshaft so the dashboard can calculate measured RPM and cam angle from the actual rotating hardware.

Angle measurement reference

Connection type and purpose

Ties the encoder measurement to the real crankshaft position.
Makes shaft angle and RPM feedback independent of the commanded VFD target.
The crankshaft rotates at 2x camshaft speed, so this ratio must be handled when aligning lift data to camshaft angle.
Requires careful concentric alignment and secure mounting for high-speed operation.
Allows laser lift samples to be plotted against continuous camshaft angle.

Connection details

Connection type: Mechanical encoder reference to the crankshaft.
Measurement carried: True shaft position, RPM, and index reference through the encoder.
Design note: Mounting alignment and speed rating matter because eccentricity, slip, or overspeed would corrupt the angle reference.

Encoder cable

Encoder to RS422 receiver

The encoder feedback cable carries differential A/B/Z position signals from the crankshaft encoder to the RS422 receiver board.

Differential feedback cable

Wire type and purpose

Carries A+/A-, B+/B-, and Z+/Z- differential encoder signals.
Provides the raw feedback used for true RPM, continuous angle tracking, and index reference.
Differential signalling improves noise tolerance for the high-speed rotating measurement path.
Shielding, strain relief, grounding, and connector security matter because the shaft can operate at high RPM.

Wire details

Wire type: Shielded differential encoder cable.
Signal carried: A+/A-, B+/B-, Z+/Z-, supply, and ground as required by the encoder.
Design note: Protect this feedback cable from VFD noise and mechanical strain.

Timer input wiring

RS422 receiver to Nucleo

This short wiring run carries MCU-level A, B, and Z signals from the RS422 receiver board into Nucleo timer and index inputs.

MCU timer inputs

Wire type and purpose

Carries level-converted A, B, and Z encoder signals to the Nucleo.
Feeds timer inputs used for quadrature counting, RPM calculation, and index capture.
Needs clean edges and a common reference so the firmware can count reliably.
Pin mapping and interrupt or timer configuration will be finalised during firmware setup.

Multi-wire logic harness representing the RS422 receiver board outputs connected to Nucleo timer and index inputs — Short multi-wire logic harness representing the MCU-level A, B, Z, power, and reference connections between the RS422 receiver board and Nucleo timer inputs.

Wire details

Wire type: Short multi-wire 3.3 V logic harness from RS422 receiver outputs to Nucleo pins.
Signal carried: MCU-level A, B, and Z encoder signals, plus power/reference wiring as required by the receiver board.
Design note: Keep the wiring short and document the exact timer, index, power, and ground pin assignments.

Laser sensor cable

LK-G82 to LK-GD500

The Keyence sensor-head cable carries the laser head measurement connection into the LK-GD500 controller before the displacement signal is converted into an analog output.

Sensor-head connection

Wire type and purpose

Connects the LK-G82 laser head to the LK-GD500 controller.
Keeps the sensor head connected through the intended Keyence controller path.
Supports the displacement measurement that becomes the valve or follower lift channel.
Needs stable routing so sensor alignment and cable movement do not affect measurements.

Wire details

Wire type: Keyence laser-head cable between sensor head and controller.
Signal carried: Laser-head measurement connection into the LK-GD500 controller.
Design note: Route with enough strain relief to protect sensor alignment.

Analog measurement cable

LK-GD500 to analog front-end

This analog cable carries the LK-GD500 displacement output into the scaling board so the laser measurement can be sampled safely by the Nucleo ADC.

0-10 V lift signal

Wire type and purpose

Carries the LK-GD500 OUT1(V) analog output and reference return.
Represents the measured lift or displacement before it is scaled to the Nucleo ADC range.
Should be shielded and routed away from VFD and motor power wiring.
Calibration is needed so voltage maps correctly to displacement.

Two-wire analog cable representing the LK-GD500 0-10 V output connection to the analog front-end scaling board — Two-wire analog connection representing the LK-GD500 OUT1 voltage output and reference return before the signal is scaled down for the Nucleo ADC.

Wire details

Wire type: Two-conductor analog signal wiring, preferably shielded for the final installation.
Signal carried: LK-GD500 OUT1(V) 0-10 V displacement output and OUT1 0 V reference return.
Design note: Keep analog routing clean and away from VFD/motor wiring because this signal becomes the lift trace.

ADC input wiring

Analog front-end to Nucleo

This connection carries the protected and scaled 0-3.3 V laser signal from the analog front-end board into a Nucleo ADC input.

Scaled ADC signal

Wire type and purpose

Carries the scaled laser displacement signal after voltage conditioning.
Feeds the Nucleo ADC channel used for lift sampling.
Needs a clean analog ground reference and short wiring to reduce noise pickup.
ADC scaling, sampling rate, and calibration need bench validation before real captures.

Two-wire analog ADC connection representing the 0-3.3 V signal from the analog front-end board to the Nucleo ADC input — Two-wire analog ADC connection representing the scaled 0-3.3 V lift signal and reference return from the front-end board into the Nucleo ADC input.

Wire details

Wire type: Short two-conductor analog ADC wiring from the scaling board to the Nucleo.
Signal carried: Scaled 0-3.3 V analog displacement signal plus analog reference return.
Design note: Bench-test with a multimeter or oscilloscope before connecting to the Nucleo ADC input.

Safety wiring

E-stop to VFD safety enable

The e-stop and safety boundary should act on the drive side of the machine, not just on the browser dashboard or Nucleo software. This path represents a hardwired stop / enable / inhibit connection to the VFD safety or enable circuit.

Hardwired drive inhibit

Wire type and purpose

Routes the emergency stop / safety boundary to the VFD or drive-enable side of the system.
Keeps the stop function independent of browser crashes, network faults, or Nucleo firmware bugs.
Can be separately commissioned and tested before allowing software-controlled runs.
The Nucleo may later monitor safety status, but it should not be the only thing enforcing the stop.

Wire details

Wire type: Hardwired safety / enable / inhibit wiring to the VFD safety or enable circuit.
Signal carried: Emergency stop, drive inhibit, enable, reset, or guard conditions as confirmed during commissioning.
Design note: Treat this as the safety boundary. Software may command runs, but it should not be the only layer that can stop the drive.

Project visuals

The main visuals are split between the operator software already working in simulation and the real mechanical context for fitting encoder hardware to the existing shaft area.

PC program visuals

Screenshots from the local browser dashboard showing run programming, live RPM visualisation, uploaded RPM traces, recording windows, and controller capacity modelling.

Spintron local browser dashboard showing the program run sequence table above the run visualiser, with RPM steps, ramp and hold timing, recording settings, sample rate, desired RPM trace, and recording windows — **Program run sequence and visualiser** Local browser dashboard showing programmed RPM steps, ramp and hold timing, per-step recording settings, sample-rate selection, desired RPM trace, recording windows, and live actual-RPM feedback.

Spintron dashboard run visualiser mid run showing desired RPM in blue, actual RPM in green, three recording windows, ramp and hold sections, and final ramp down to zero — **Run visualiser with recording windows** Mid-run screenshot showing three programmed RPM stages, each ramp and hold section, cyan recording windows, the final ramp down to 0 RPM, and actual encoder RPM feedback in green against the desired blue profile.

Uploaded RPM profile mode Uploaded-run mode after loading an RPM-over-time file, showing the replayed profile, recording windows, desired RPM trace, and actual-RPM feedback inside the same run visualiser workflow.

Spintron Nucleo capacity visualiser mid run at 50,000 points per second showing estimated controller load, Ethernet bandwidth, buffer use, VFD Modbus schedule, safety status overhead, and remaining capacity — **Capacity visualiser** Nucleo capacity visualiser mid-run at 50,000 points per second, showing estimated controller load, Ethernet bandwidth, buffer use, VFD Modbus schedule, safety/status overhead, and remaining capacity.

Mechanical and CAD visuals

CAD and real-machine visuals showing the shaft area, encoder mounting concept, surrounding geometry, and clearance constraints for the physical sensing hardware.

CAD overview of the Spintron encoder mounting concept aligned to the shaft rotational axis with surrounding objects simplified for context — **Encoder mount CAD overview** CAD overview of the encoder mounting concept. The mount is designed around shaft-axis alignment and adjustable encoder positioning so the encoder can be centred accurately for high-speed RPM measurement.

Real motor and shaft area of the Spintron test rig before the encoder mounting hardware is installed — **Real machine area** Physical motor and shaft area the encoder mount is being designed around. The new mount is not installed yet. This photo shows the surrounding space, shaft location, belt drive, and clearance constraints.

Close-up CAD view from the back of the Spintron encoder mount showing encoder body, connector pins, back plate, shaft, and surrounding bracket geometry — **Encoder back detail CAD** Opposite-side CAD close-up showing the encoder body, connector pins, back plate, shaft connection, and nearby bracket geometry used to check clearance and mounting access.

My contribution

Designed the control-system architecture connecting an HMI-style dashboard, microcontroller interface, VFD, encoder, and laser measurement path.
Built the operator dashboard prototype for run setup, telemetry, recording windows, uploaded RPM traces, and data review.
Planned electrical signal paths and documentation for encoder, laser, VFD, shielding, isolation, and protected inputs.
Produced CAD and mounting concepts for fitting sensing hardware to the existing machine geometry.

Results and current status

The project produced a clear three-part system design: a working local browser dashboard in simulation mode, a Nucleo-based electrical / microcontroller architecture for connecting the PC to the VFD, encoder, and Keyence laser, and physical CAD work for fitting sensing hardware to the existing machine. It meets the objective at design and software-prototype level by showing how the machine could be controlled, monitored, logged, and analysed from one integrated program.

The simulation side is already developed enough to test the operator workflow, run planning, uploaded RPM traces, recording windows, high-speed capture model, and post-run analysis approach. The software also separates high-rate saved samples from lower-rate live preview data and includes data-processing tools so lift, velocity, acceleration, and jerk can be reviewed without simply amplifying noise. STM32 firmware, real hardware communication, physical commissioning, calibration, and measured performance validation remain the next major steps.

Technical details

Objective, requirements, and project scope

The objective was to create an all-in-one system that could let an operator control the camshaft test machine from another room, program RPM runs, monitor the machine live, and capture useful valve-lift data. The machine already had the Keyence laser measurement hardware available. The missing piece was an integrated control and data-acquisition approach that could bring the VFD, encoder, laser, microcontroller, and computer program together.

Design requirements

Create an all-in-one computer program that could operate the machine remotely from another room.
Control motor speed through the VFD while using encoder feedback as the true shaft RPM and angular-position reference.
Use the existing Keyence laser measurement system to capture valve or follower lift data.
Add a microcontroller layer between the PC and machine hardware so the VFD, encoder, and laser could be coordinated from one interface.
Synchronise laser displacement and encoder angle so valve lift can be analysed against camshaft position.
Measure the existing physical setup and design mounts that fit the current machine rather than assuming a clean-sheet rig.
Provide run programming, live visualisation, logging, and post-run analysis tools for angle, velocity, acceleration, and jerk.
Process measured data carefully so smoothing reduces noise without hiding useful camshaft behaviour.

Three-part scope

Computer program: All-in-one operator software for remote machine control, program runs, live visualisation, recording windows, data logging, and post-run camshaft analysis.
Electrical / microcontroller: Nucleo-based interface between the PC and machine hardware, coordinating VFD control, encoder angle/RPM feedback, and the existing Keyence laser measurement system.
Physical CAD / mounts: Measured the current rig, modelled the surrounding setup, and designed encoder mounting hardware that would fit the existing machine and align accurately to the shaft axis.

Dashboard workflow

The dashboard is the operator-facing workflow for setting up runs, monitoring the machine at a low live update rate, and opening saved high-speed data for analysis after the run.

Dashboard features

Run programming: Build a sequence from start run through multiple RPM steps to end run, with target RPM, ramp time, hold time, and recording settings per step.
Recording windows: Enable high-speed capture only where useful, then move the start/end bars or the whole shaded window inside the run visualiser.
RPM source modes: Use programmed ramp/hold steps or upload a CSV/TXT RPM trace so the rig can replay a real-world speed profile.
Live run visualiser: Show desired RPM, simulated encoder feedback, current-time marker, ramp/hold behaviour, and capture windows on one time-based plot.
Analysis viewer: Inspect cam lift versus continuous camshaft angle, plus derived velocity, acceleration, and jerk from the recorded lift trace.
Capacity model: Estimate controller load, Ethernet bandwidth, buffer use, VFD polling, safety/status overhead, and remaining capacity during a run.

Dashboard workflow

Connect to the machine from the computer interface, with the Nucleo acting as the hardware layer between the PC and VFD, encoder, and laser.
Create a programmed RPM sequence or upload a time-versus-RPM trace, such as a logged race profile.
Set target RPM, ramp time, hold time, sample rate, trigger RPM, recording duration, and which steps should capture high-speed data.
Preview the full run as a time-based RPM curve, including desired RPM, actual feedback, current run position, and recording windows.
Run the sequence, monitor live values, and keep the browser responsive through decimated dashboard updates.
Open the full-page analysis viewer after the run to inspect lift, velocity, acceleration, and jerk against camshaft angle.

Software implementation and simulation status

The current program is a local browser dashboard built primarily as a single-file HTML/CSS/JavaScript application. In simulation mode it can run by itself in the browser on the Lenovo PC. Real-hardware mode has been started through a Python WebSocket bridge scaffold, but the STM32 firmware and end-to-end hardware communication still need to be implemented and validated.

App type: Local browser dashboard / browser UI running on the machine PC, not a packaged desktop application.
Frontend: Single-file HTML/CSS/JavaScript dashboard built with vanilla JavaScript rather than a large frontend framework.
Visualisation: Browser-based canvas / SVG / DOM-style plotting for the run visualiser, live feedback, capacity model, and full-page analysis viewer.
Bridge scaffold: Python WebSocket bridge started for future real-hardware mode, with the dashboard designed to connect locally at ws://127.0.0.1:8765.
Firmware state: STM32 / NUCLEO firmware is not built yet. The dashboard currently models the controller behaviour and expected hardware messages.
Hardware references: Dashboard updated around NUCLEO-H753ZI, RS422 encoder receiver board, protected 0-10 V to 0-3.3 V laser front-end, LK-GD500 0-10 V output, and VFD calibration data.

Working in simulation

Program run planner with start/end run states, RPM steps, ramp times, hold times, per-step recording enable, trigger RPM, and recording duration.
Run visualiser showing desired RPM, simulated actual RPM from encoder-style feedback, a live time marker, ramp/hold sections, and final ramp-down behaviour.
Draggable recording windows where the left/right bars can be adjusted independently or moved together by dragging the middle of the window.
Uploaded RPM trace mode for loading CSV/TXT RPM-over-time files and replaying race-style speed profiles in the dashboard.
Full-page data viewer for cam lift versus continuous multi-revolution camshaft angle, with derived velocity, acceleration, and jerk.
Smoothing, windowing, zoom/pan-style analysis tools, separate recording selection, and high-speed saved capture modelling up to 50,000 points per second.
Capacity and bandwidth visualiser for Ethernet throughput, decimated 50-100 pps live display, controller load, capture buffering, and VFD communication overhead.
VFD frequency calibration table based on measured Hz/RPM points.

Implementation status

Working in simulation: Run planning, live visualisation, uploaded RPM traces, recording windows, logged-data model, full-page analysis, smoothing controls, capacity model, and VFD calibration table.
Partly started: Real-hardware toggle, Python WebSocket bridge structure, telemetry message handling, and command payload format for programmed or uploaded runs.
Still to build: STM32 firmware, real Ethernet streaming, encoder timer capture, ADC/DMA laser sampling, VFD Modbus register handling, safety/interlock I/O mapping, CubeMX pin map, and end-to-end hardware capture.

Electrical and microcontroller integration

The electrical / microcontroller section was developed because the test rig needed one control pathway rather than separate disconnected systems. The Nucleo sits between the computer and the machine hardware: the PC provides the operator interface, while the Nucleo handles the machine-facing signals for the VFD, encoder, and Keyence laser measurement path.

The core technical challenge is synchronisation. RPM and cam angle need to come from the encoder, valve lift comes from the Keyence laser, and the run state comes from the programmed VFD/RPM sequence. Those streams have to line up so the saved data can be analysed as cam lift versus camshaft angle rather than as unrelated live readings.

Hardware integration plan

Already available: PC, Keyence LK-G82 laser head, LK-GD500 controller, Keyence laser cable, and VFD.
Controller to add: NUCLEO-H753ZI board used as the machine-interface controller between the PC, VFD, encoder, and laser measurement path.
Encoder chain: US Digital H6-1024-IE-D encoder into a 26C32 / RS422-style incremental encoder receiver board, then into Nucleo timer / index inputs.
Laser chain: LK-GD500 OUT1(V) and OUT1 0V through shielded analog cable into a high-speed 0-10 V to 0-3.3 V laser ADC front-end, then into the Nucleo ADC.
VFD chain: Nucleo UART/GPIO into a TTL/UART-to-RS485 interface board, then RS485 A/B wiring to the VFD control terminals for Modbus-style control.
Power and wiring: Dedicated 5 V DIN-rail supply for encoder/interface power, shielded analog cabling, short low-voltage wiring, RS485 twisted pair, and termination where required.

Assembly sequence

Connect the PC to the Nucleo over USB for programming/debugging and over Ethernet for programmed runs, telemetry, and recorded data transfer.
Wire the encoder through the shielded encoder cable and RS422 receiver board so the Nucleo reads true shaft RPM, angle, and index reference.
Route the Keyence LK-GD500 analog output through a fast protected ADC front-end instead of wiring the 0-10 V output directly to the microcontroller.
Wire the RS485 interface board between the Nucleo and VFD so the computer program can command speed through the microcontroller path.
Keep emergency stop, guarding, VFD enable/safety, and motor isolation as hardwired safety functions rather than relying on software control.

I/O and signal summary

VFD command: RS485 / Modbus-style command path planned from the Nucleo through an interface board to the VFD control terminals.
Encoder A/B/Z: Differential encoder signal through an RS422 receiver board into timer and index inputs for RPM and cam angle.
Keyence laser: LK-GD500 0-10 V analog output scaled and protected before entering a Nucleo ADC channel.
Dashboard telemetry: Controller status, measured RPM, run state, sample rate, capture state, and capacity estimates returned to the local HMI.
High-speed samples: Time, target RPM, measured RPM, cam angle, lift, and derived values saved separately from the low-rate live display.
Safety signals: E-stop, guarding, motor isolation, and VFD enable treated as hardwired machine safety functions.

Run state model

Idle Machine at standstill, dashboard ready, run profile not active.
Armed Run profile loaded, recording windows checked, controller ready for command sequence.
Ramping VFD target changes while measured encoder RPM is monitored against the desired profile.
Hold Target speed held long enough for stable measurement or recording trigger conditions.
Record High-speed encoder and laser capture active inside the selected recording window.
Ramp down Commanded speed returns to zero and the VFD is brought back to standstill.
Review Saved data is opened for lift, velocity, acceleration, jerk, and cam-angle analysis.
Fault Abnormal state intended to stop the run and require operator review before continuing.

Measurement and sampling model

Encoder resolution: US Digital H6-1024-IE-D incremental encoder, 1024 CPR, 4096 counts per revolution in x4 decoding, about 0.088 degrees per count.
Speed-rating check: The H6 encoder is rated to 10,000 rpm mechanically, so the final mounting shaft speed must be checked before commissioning.
Laser path: Keyence LK-GD500 OUT1(V) configured as 0-10 V, scaled through a fast protected front-end for the Nucleo ADC rather than a slow PLC-style converter.
Saved sample rows: Each saved row is intended to contain time, target RPM, measured RPM, cam angle, laser lift, derived values, VFD telemetry, sample rate, and encoder count.
Capture rates: Dashboard model supports saved capture rates from 1,000 pps through 50,000 pps for maximum-detail laser and encoder captures.
Live preview: The browser display is decimated to roughly 50-100 points per second, while saved run data remains separate from the live preview.

Physical CAD, data processing, and additional visuals

The physical work started with measuring the current machine setup and producing CAD drawings of the surrounding hardware. The encoder mount was then designed around the real motor and shaft area, rather than as a generic bracket. The mount needed to align with the shaft rotational axis and allow the encoder position to be adjusted so it could be centred accurately.

That mechanical alignment matters because the shaft can rotate at very high speed, with target operation up to 13,000 RPM. Eccentricity, misalignment, connector access, cable routing, clearance to existing parts, mounting stiffness, and installation practicality all had to be considered before the sensing hardware could be trusted.

The analysis target is cam lift versus camshaft angle, not just live RPM. Each high-speed capture needs laser displacement and encoder angle in the same timestamped sample row so the recorded data can be plotted and differentiated into velocity, acceleration, and jerk.

Lift trace: Use synchronised laser displacement and encoder angle to visualise valve lift against continuous camshaft angle.
Derived motion: Calculate velocity, acceleration, and jerk so the cam profile can be assessed beyond a simple lift curve.
Smoothing validation: Test smoothing settings to reduce measurement noise without over-smoothing, adding false behaviour, or hiding useful camshaft characteristics.
Analysis purpose: Make the recorded data useful for understanding camshaft behaviour, not just for proving that the rig collected numbers.

Future improvements

Write the STM32 / NUCLEO firmware for encoder timer capture, ADC/DMA laser sampling, real-time buffering, command handling, and telemetry streaming.
Complete the real Ethernet / serial communication path between the local browser dashboard, Python WebSocket bridge, and microcontroller.
Implement and validate VFD Modbus command/register handling, real safety/interlock I/O mapping, and the confirmed STM32CubeMX pin map.
Build and document the physical rig wiring, protection, shielding, and isolation layout.
Refine the encoder mounting CAD, then validate alignment, stiffness, clearance, and adjustability before high-speed testing.
Validate encoder capture, RPM calculation, Keyence laser displacement capture, and sample synchronisation accuracy.
Bench-test the 0-10 V to 0-3.3 V laser ADC front-end with a multimeter/oscilloscope before connecting it to the Nucleo ADC.
Validate smoothing and derivative calculations against known or trusted camshaft data so analysis does not over-smooth or distort important behaviour.
Run controlled tests to evaluate repeatability, noise, speed stability, and measurement uncertainty.
Add real test photos, calibration plots, dashboard screenshots, measured run data, and safety/test procedure documentation when publicly shareable.