Why late defects are especially expensive in 3D printing

A metal part can take many hours or several days to build. If a defect becomes obvious only in the final layers, the manufacturer loses more than powder or wire: the printer, operator, energy, downstream heat treatment and a slot in the production schedule have already been consumed. The machine has faithfully followed its program throughout; nobody simply told it that it could stop trying.

Industrial printers already leave a rich digital trail: temperature, power, speed, vibration, atmosphere conditions, material-feed parameters and images of each layer. AI is not supposed to “predict the destiny of a part.” Its job is to identify a combination of signals after which the probability of failure becomes high enough to justify an inspection or stop.

Italian company BitBang and competence centre BI-REX described such an experiment within the FFplus programme. According to their report, they built a SaaS platform for failure prediction in additive manufacturing by combining time-series data with layer images. Experiments and training ran on the Leonardo supercomputer, with a reported consumption of roughly 14,000 GPU hours.

It is important to separate the documented architecture from commercial expectations. The existence of the platform, the data types and the compute environment are described in the official FFplus case study. The stated 20–30% reduction in failed prints, pricing of about €10,000 per year and up to €40,000 in additional services are project-participant estimates, not an independent audit across every machine type. For another manufacturer, they are inputs for its own economic model, not a ready-made budget line.

What a useful pipeline looks like

A production system is not one “magic model.” It is a chain of less glamorous but testable components:

  • collection of printer telemetry and peripheral sensor data;
  • synchronisation by timestamp and layer number;
  • a camera with fixed viewpoint, stable lighting and image-quality checks;
  • a time-series model for abnormal dynamics;
  • computer vision for layer defects;
  • fusion of model scores into one risk signal;
  • an escalation rule: continue, request inspection or stop;
  • a log of the recommendation, actual outcome and operator action.

The case study mentions pretrained Chronos time-series models and GAN-based approaches for image analysis. Amazon Science's open repository confirms that Chronos turns numerical series into token sequences and produces probabilistic forecasts; its code is available under Apache-2.0. This makes the stack reproducible for experiments, but it does not automatically turn a general forecasting model into a defect detector for a particular printer.

The critical integration sits between the model and production management. A prediction must be linked to the work order, material, print profile, powder batch, control-program version and layer identifier. Otherwise, the attractive risk chart remains a separate screen that operators open approximately never—usually just after the third urgent phone call.

Data required for a pilot

A pilot does not need “all factory data.” It needs comparable print histories. The minimum observation is one build with its outcome:

  • job parameters and geometric features of the part;
  • material and feedstock batch;
  • telemetry on a shared timeline;
  • layer images or quality maps;
  • equipment events and operator interventions;
  • inspection result: accepted part, defect type and detection layer;
  • cost of lost material, machine time and rework.

Labelling is usually the weak point. A record saying “print failed” is not enough. The model must distinguish porosity, warping, feed interruption, preparation errors, a faulty sensor and a defect that cannot be observed during the process. If these causes are mixed together, AI will diligently predict the general mood of the production day.

Two stages are sufficient to begin. The first is offline analysis of completed jobs, testing whether available signals contain early information about defects. The second is shadow mode on live production: the model emits a risk score but does not control the machine. Operators mark whether an alert was useful while the team counts false stops and missed defects.

Where the model should run

FFplus used HPC to train and compare models, but a manufacturer does not need a supercomputer next to every printer. Production inference is governed by latency, network reliability and data-governance requirements.

A pragmatic design is:

  • training and heavy experimentation on rented GPUs or at a dedicated computing centre;
  • a compact time-series model and vision model on a local server or industrial edge node;
  • raw images remain on premises when they contain sensitive process information;
  • a central system receives aggregated features, model versions and decision logs;
  • machine shutdown is controlled by a separate deterministic rule and, initially, human confirmation.

Local inference reduces network dependency and avoids exposing process parameters. However, “local” does not remove the need for MLOps. Models and features must be versioned, drift must be monitored, events must be retained and rollback must be fast. A model without a version is no longer an assistant; it is factory folklore.

The main risk is not only a miss but an incorrect stop

Missing a defect in an expensive build is serious, but an overly sensitive system is costly too. If it stops good jobs, the manufacturer loses capacity, feedstock and operator trust. Accuracy alone is therefore inadequate.

At minimum, measure:

  • the share of defects detected before the economically significant point;
  • average machine hours and kilograms of material saved per alert;
  • false stops per 100 builds;
  • performance by defect type and machine;
  • time from alert to decision;
  • the share of warnings that led to a clear operator action.

Risk thresholds should reflect the cost of errors. For a short build with inexpensive feedstock, the business can tolerate more missed cases and avoid unnecessary shutdowns. For a week-long titanium build, a late alert is much more expensive. One universal threshold for every printer is convenient mainly for slide decks.

Pilot economics without airborne promises

A model calculation should start with a single production line. Suppose it runs 40 long builds per month, four end in failure, and the average loss across material, machine time and rework is RUB 250,000. Current losses are about RUB 1 million per month.

If a shadow pilot shows that the system could safely interrupt half of the failed jobs after only 30% of their resources have been consumed, the potentially avoided loss is roughly RUB 350,000 per month. False stops, camera and sensor maintenance, compute, integration and engineering effort must then be deducted. This is an illustrative calculation with explicit assumptions, not a promise that BitBang's result transfers to another factory.

The useful economic unit is not “cost per prediction.” It is cost per avoided machine hour or kilogram of material. That connects the model to what the manufacturer actually pays for.

A six-to-eight-week pilot

1. Select one printer, one material and one repeatable part class.
2. Collect 50–100 completed builds, or explicitly record the uncertainty of a smaller sample.
3. Synchronise telemetry, images and inspection outcomes at layer level.
4. Build simple rules and a baseline first; a complex neural model must beat them on held-out jobs.
5. Run in shadow mode without automatic shutdown.
6. Define the acceptable number of false alerts and the avoided-loss formula in advance.
7. After the pilot, decide whether an edge deployment, external service or post-shift analytics is justified.

What counts as success

A pilot is not successful merely because a chart separates red dots from blue ones. It needs a reproducible early signal, an actionable operator response and positive economics after false stops are included.

The BitBang case demonstrates a sensible pattern: heavy training can move to powerful infrastructure while the product is built around machine-specific data and an operator-friendly workflow. For an SME, the first step is far smaller than 14,000 GPU hours: one line, one failure mode and a shadow deployment. Let Vnutrik learn to raise a hand at the right time before anyone lets the intern near the emergency-stop button.