Skip to content
Jose RubioES
All work

Case study 16 / 17Deep Learning ML

Machining analytics: 392 cutting programs profiled for improvement

One analytical view of 20 months of machining logs: 392 program profiles and the material waste hidden in thickness returns.

Stack

  • Python
  • Pandas
  • NumPy
  • Matplotlib
  • Seaborn
  • Boto3
  • AWS DynamoDB
  • Jupyter Notebook
  • +6

01 · How it works

  • TodaytoChanged in this work
  • Data flow

What it does

An analytics platform for laser cutting operations that joins machine log files with reference data to show how machining time, material and cutting programs actually perform. It covers 23,354 machining records across 20 months and turns them into 392 program performance profiles and a dashboard for operational monitoring.

Read more

I built the pipeline end to end, from parsing legacy log files to the statistical analysis behind the dashboard.

6 connections· select a part to trace it
  1. Machine log files to ETL + normalization: RTF logs parsed
  2. NoSQL lookup tables to ETL + normalization: program and material data
  3. ETL + normalization to Vectorized analysis: normalized recordschanged
  4. Vectorized analysis to Payback by thickness: material sequences
  5. Vectorized analysis to Dashboard + profiles: per-program profiles
  6. Payback by thickness to Dashboard + profiles: waste patterns

02Results

  • R01Lower is better

    Data processing time (100% = before)

    Before 100%, after 20%, 5× lower. Lower is better.
    Before
    After

What it achieved

  • Visibility: 20 months of machining logs, 23,354 records, in one consistent model
  • Program insight: 392 performance profiles to compare and improve cutting programs
  • Material waste: a thickness-return analysis that shows where waste patterns occur
Read more
  • Processing: about 80 % less time, from vectorised transformations
  • Monitoring: a dashboard for day-to-day operational review

The challenge

The data was never meant to be analysed together. Machine logs came as legacy rich-text files, reference data lived in a NoSQL store, and formats and identifiers differed between them, with gaps along the way. Before any analysis could be trusted, every source had to be normalised and mapped to one model, and missing values filled through lookups and statistical imputation instead of dropped.

Read more

Volume mattered too: row-by-row processing was too slow to iterate on, so the transformations had to be vectorised. The most valuable question, where material is wasted, needed its own method: a sliding-window analysis of thickness returns across the whole history.

What I learned

Most of the value in industrial analytics is earned before the first chart: one data model across machines and systems, and a clear rule for gaps, decide whether anyone trusts the results. Enriching records through lookups and imputation kept the history complete instead of thinning it.

Read more

Vectorising the transformations kept the pipeline fast enough to explore new questions quickly, and the sliding-window view of thickness returns turned raw logs into a finding about waste that operations can act on.

Stack

  • Python
  • Pandas
  • NumPy
  • Matplotlib
  • Seaborn
  • Boto3
  • AWS DynamoDB
  • Jupyter Notebook
  • Scikit-learn
  • SciPy
  • RTF Processing
  • Statistical Analysis
  • Data Visualization
  • Cloud Integration

Skills

  • Data engineering
  • Industrial analytics
  • Statistical analysis
  • ETL design
  • Data visualization
Cover picture for Machining analytics: 392 cutting programs profiled for improvementCover picture for Machining analytics: 392 cutting programs profiled for improvement