In-Situ Spectrometer Integration & Hardware Validation

Role

Systems Integration Intern

Organisation

A*STAR Advanced Remanufacturing and Technology Centre (ARTC)

Period

Sep 2022 – Apr 2023

Tech Stack

Optomechanics, Sensor Integration, Python, EPL Network Analysis

Spectrometer Hardware Integration on EOS M 290

The Challenge: Optomechatronic Instrumentation

To evaluate how the elemental composition of metal powder could be determined during a live print, we needed to capture the optical spectrum from plasma emissions when the powder was excited by a laser.

This required integrating a Compact Spectrometer-Firefly4000 directly into a commercial EOS M 290 closed-system 3D printer. The core engineering challenge was twofold: designing the physical optical routing to capture the plume, and establishing a digital handshake to trigger the sensor only when the machine's moving components were completely stationary.

Phase 1: Optomechanical Routing & Alignment

Before collecting data, the physical sensor hardware needed to be robustly integrated into the harsh environment of the printer chamber.

Spectrometer and fiber optic cable positioning

Optomechanical Integration: Visual representation of the spectrometer's position, routing the fibre optic patchcord through a 13mm machine port to capture internal plasma emissions.

Phase 2: System Synchronization via Telemetry

The spectrometer must only collect data when the building platform and recoater blade are strictly stationary to ensure accurate readings. Because the EOS M 290 is a proprietary "black-box" machine, there was no direct software trigger available.

To solve this controls problem, we bypassed the software restrictions by hardware tapping the machine's Industrial PC (IPC). By eavesdropping on the internal Ethernet Powerlink (EPL) V2 network, we could capture the real-time communications between the IPC and the internal servomotors/stepper motors. We monitored a live titanium print job over 30.6 hours, capturing over 337 files and millions of packets for analysis.

Phase 3: Hardware Validation & Data Pipelines

With the raw network traffic captured, I engineered a Python data pipeline to parse the hex strings, downsample the massive dataset to optimize processing (reducing to 8,279 alternate rows), and graph the electrical signals against machine epoch time.

3x4 grid of packet nodes graphed over time

Data Visualization: Python scripts utilizing Matplotlib to map 12 extracted packet nodes, revealing distinct cyclical saw-tooth patterns in the hardware network traffic.

To validate our findings, I cross-referenced the distinct cyclical patterns in the packet graphs against known InfluxDB telemetry data (tracking recoater speed, dispenser position, and filter pressure).

InfluxDB data tracking EOS M 290 parameters

System Telemetry: InfluxDB tracking key parameters of the EOS M 290 statuses. The outlines of these states were used to match similarities with the decoded packets.

Recoater blade position and speed

Hardware Kinematics: The isolated position and speed of the recoater blade during the print job, used to successfully cross-reference and validate the network data.

This analysis successfully proved that "Node ID 2" perfectly correlated with the physical position and speed of the recoater blade. Deciphering this signal established the crucial baseline needed to automatically trigger the Firefly4000 spectrometer exactly when the physical hardware was in the correct, stationary state.

Project Resources

Project Report Cover
PDF

Project Report

Detailed documentation of the sensor mounting, optical routing, and hardware validation data.

Project Poster Preview
PDF

Summary Poster

Visual presentation of the spectrometer integration methodology and final analysis results.