Inside the LMD
control system.

The panel has three working areas. The left column shows operating authority and system health. The centre explains the current process state. The right rail keeps manual baselines and the selected automatic sources in view.

This arrangement answers practical questions: Is deposition happening? Which height measurement is being used? Is the data current? Is the software only observing, or is an adjustment allowed to reach the machine?

The stop request in the GUI is a supervisory action. Machine interlocks, motion authority and the safety-rated stopping function remain with the machine controller.

Put the toolpath and camera views beside each other.

The process viewer connects the programmed deposition path to the current machine position and the optical measurements. On the left, the G-code path and position marker sit over a spatial map of raw stand-off observations. On the right, the coaxial melt-pool view shows the deposition region, while the triangulation camera exposes the feature used to estimate nozzle-to-surface distance for height control.

Seeing these together helps an engineer relate a change in the camera image to a particular part of the path. The viewer is read-only: closing it does not interrupt acquisition or control.

I built a three-agent workflow around experiments. The user can explain what they want to investigate, which physical systems are connected and why the experiment matters. The agents connect that conversation to preparation, approved execution and analysis.

Make the procedure accessible to someone new to the setup.

The aim is to reduce how much specialist software knowledge a user needs before conducting an experiment. Someone learning the equipment can describe a goal and be guided through the missing details, instead of already knowing every sensor interface, launch command and analysis script.

The agents coordinate the experiment; the supervisory controller still governs which machine actions are available. User approval does not bypass calibration, commissioning limits or machine interlocks. Physical preparation and operation still require the appropriate equipment training.

I chose Robot Operating System 2 (ROS 2) as the integration layer so that people could develop sensors, algorithms and machine interfaces independently. Each component publishes a defined message. The rest of the system can consume that message without taking over the component's internal implementation.

The central engineering problem is alignment. Cameras and machine interfaces update at different times. The backend uses timestamped machine history to associate an optical measurement with the relevant position and pass. It also tracks uncertainty, so a delayed or ambiguous sample does not silently become a precise point on a process map.

A connected sensor still needs calibration, units, timing information and a valid operating range. This is what makes modular integration useful in practice: every module has an explicit responsibility, including how it reports missing or unreliable data.

Height-T estimates stand-off from a camera view. The setup workflow connects image coordinates to physical references and makes the assumptions visible to the person commissioning the sensor.

The operator establishes the physical reference, waits for the measurement to settle, then captures a short numeric window. Approved reference windows can be reviewed and saved in a calibration receipt. The software does not choose or verify the physical reference on the operator's behalf.

Keep image-processing choices visible.

The engineering panel exposes thresholding, morphology, image geometry, the nozzle-axis corridor and the measurement strip. These settings define where the detector looks and what kind of feature it accepts.

This matters when illumination, reflections or deposition geometry change. A numerical output can look plausible even when the detector is following the wrong feature. The setup makes it possible to inspect the measurement logic alongside the camera image.

Preserve the reasons a sample was rejected.

Feature limits and diagnostics help distinguish an accepted measurement from an optical disturbance. The interface exposes checks for image clipping, bright regions, competing peaks and feature shape, with an optional diagnostic overlay.

The software also considers freshness and abrupt changes. Raw observations remain useful for investigation even when they are unsuitable for automatic correction. Keeping both the value and its validity state is essential for understanding a run afterwards.

The architecture separates measurement, interpretation, proposed action and the final machine-facing command. That separation makes it possible to follow a control decision from the sensor data to the adjustment sent to the machine.

Three timescales for three different problems.

Immediate stand-off correction. The fast control path calculates a bounded speed adjustment from accepted height data and a configured operating envelope. Hysteresis and rate limits constrain its response. Stale or rejected measurements remove automatic authority rather than leaving an old correction in charge.

Memory of the previous pass. The spatial path associates measurements with regions of the build. Its purpose is to prepare a correction when the nozzle revisits a region on a later pass. Uncertain pass identity or alignment prevents that map from silently influencing control.

Slower powder adaptation. Powder transport has a delay. The supervisory design therefore separates the requested setting, machine readback and estimated material arrival. Its decisions use longer evidence windows instead of reacting to every camera sample.

Keep the melt pool stable throughout the build.

Melt-pool feedback helps manage heat input and temperature as deposition progresses. The aim is a pool with a consistent size, shape and behaviour along the toolpath. Camera measurements describe how the pool is changing and guide adjustments to laser power, travel speed or powder feed. These variables influence the balance between energy input and added material, so the controller coordinates their response within the selected process limits.

A single regulation layer combines the allowed contributions. Commands carry identity, expiry and bounds, and the interface checks readback. ROS 2 coordinates this supervisory layer; the CNC or robot controller continues to execute motion and enforce the machine's own interlocks.

My control-system work began on a three-axis CNC LMD machine and was then adapted for a KUKA robot and the wide-track BreitbahnDED machine. That work spans Exafuse and the ZESS research environment at Ruhr University Bochum.

The transferable part is the structure: sensor messages, measurement interpretation, control proposals, operator views and build records. Machine adapters translate equipment-specific signals into that common structure. Job profiles supply the relevant calibration, timing and operating limits.

A new machine still needs its own engineering work. I need to establish which interfaces are available, what the signals actually mean, how quickly they update and how a permitted command changes the process. Different sensors can then be introduced through the same message contracts, with their own calibration and validity checks.

A live dashboard answers what is happening now. An engineering record must also explain what happened, which configuration was in use and why a particular action was proposed or rejected.

The data architecture separates the live control path from operator views and storage. Local history and ROS recording retain measurements, state and decisions. A run package brings these together with the relevant toolpath, effective settings and logs. A saved hash inventory lets the recorded files be checked for later changes.

In parallel, asynchronous telemetry passes through RabbitMQ into InfluxDB for Grafana dashboards and comparison. Storage and dashboard updates are kept outside the control callback path. Simulation and production records carry distinct identifiers.

At company level, the operations software I developed connects quotations, costing, scheduling and manufacturing records. Each order has a print ID linking planning, production monitoring and quality documentation. That wider workflow gives the control-system record a place in the history of the part.

Monitoring supports process investigation and quality review. Final part acceptance still depends on the required inspection, testing and engineering judgement.

The wider research includes heat-transfer and deposition simulation, physics-informed bead models, parameter studies and experimental comparison. These tools help me investigate process behaviour before machine trials.

The runtime simulator serves a different purpose: exercising interfaces, sensor faults, delays and controller behaviour in a controlled environment. It is not a validated prediction of the physical process. Likewise, the supervisory system reads an existing toolpath for context; toolpath development is a separate part of my engineering work.

This distinction is useful during development. A software interface test, a successful monitoring run and a physical closed-loop trial answer different questions. Each provides evidence for the next stage.

My contribution

I led the system architecture and development, the selection and interpretation of sensor data, and the integration of machine interfaces, software and manufacturing workflows. I also coordinated contributors working on sensors and algorithms. This work forms part of my doctoral research and my R&D role at Exafuse.

For the 2024 Duisburg bridge components, my responsibility covered process monitoring and control that enabled unattended builds, together with the project schedule. The planning, monitoring and control methods from that work informed later projects. The broader goal is an operator workflow that carries the process knowledge in the system, while keeping its measurements and decisions open to inspection.