From LPBF Distortion to Machine Uptime: This Week in Laser Manufacturing
This week’s stories cover very different parts of manufacturing with light, but I think a common thread runs through them.
Getting a laser process to work is only part of the job. We also have to make it predictable, traceable, maintainable, and useful in production.
This week we look at LPBF distortion compensation, automated medical stent welding, growth in industrial laser applications, and using machine data to improve uptime. We are also introducing a new MWL Product Watch and our first recurring MWL Automation Note.
1. Tackling One of LPBF’s Persistent Problems: Distortion
Oqton was named the winner of this year’s ASTRO-InSPIRE technical challenge, which focused specifically on predicting and compensating for distortion in laser powder bed fusion.
The challenge brought together several major engineering-software companies and was intended to evaluate distortion tools using realistic parts rather than simple test coupons. Oqton applied its approach to LPBF Inconel 718.
Why It Matters
Distortion remains one of those problems that separates a successful additive demonstration from dependable manufacturing.
Printing the geometry is only the beginning. Residual stress, thermal history, supports, orientation, machine parameters, and compensation strategies all affect whether the finished part actually matches the design.
What I like about this challenge is the emphasis on benchmarking the tools using real parts. Better prediction is useful, but ultimately manufacturers need confidence that simulation and compensation can reduce trial-and-error on the shop floor.
Source: TCT Magazine — Oqton named as winner of ASTRO-InSPIRE technical challenge
2. Medical Stent Welding Shows How Much More Is Around the Laser
Han’s Laser recently published an overview of its automated laser welding systems for medical-device manufacturing, including a system designed for welding medical stents and implant frameworks.
The stent system combines CCD vision positioning, coordinated multi-axis motion, stored welding parameter sets, product identification, and production-data recording for MES traceability.
Why It Matters
The laser gets the attention, but this is a good example of how much engineering surrounds the actual weld.
A precision medical welding system also needs motion, vision, fixturing, recipe management, identification, data collection, safety, and a way to reliably reproduce the process from one part to the next.
For high-value or regulated products, the question isn’t simply, “Can the laser make the weld?”
It is also, “Can the complete machine make the same weld again, document what happened, and give the operator enough information to know when something isn’t right?”
That is where automation becomes part of the process, not just a way to move the laser.
Source: Han’s Laser — Laser Welding Solutions for Medical Device Manufacturing
3. IPG Reports 16% Growth in Industrial Solutions
IPG Photonics reported second-quarter 2026 revenue of approximately $279 million, up 11% year over year.
What interested me more was the application mix. IPG reported 16% year-over-year growth in Industrial Solutions, which represented about 85% of company revenue during the quarter. The company attributed that growth to applications including welding, marking, cleaning, and additive manufacturing, with particularly strong demand in battery manufacturing.
Why It Matters
Quarterly results can move around, so I wouldn’t draw too many conclusions from one report.
But I do think the application mix is worth watching.
The industrial laser market is becoming much broader than traditional cutting. Welding, cleaning, marking, additive manufacturing, battery production, and other specialized applications are becoming increasingly important parts of the market.
For machine builders and manufacturers, that means opportunities are expanding not only around the laser source, but around the automation, motion, process development, tooling, inspection, and support systems required to make those applications productive.
Source: IPG Photonics — Second Quarter 2026 Financial Results
4. Machine Data Is Only Useful If Someone Can Act on It
A recent Shop Floor Lasers article looks at Bystronic’s approach to machine service, training, and digital support.
One of the more interesting pieces is eProactive, which continuously collects and analyzes machine-condition information through a cloud-based system. When a potential issue appears, technicians can use that information to begin troubleshooting before the problem develops into unplanned downtime.
The broader service approach also includes operator and maintenance training, machine health checks, documentation, service records, and access to technical support.
Why It Matters
Manufacturers are collecting more machine data than ever.
But collecting data and improving uptime are not the same thing.
Someone still has to understand what the information means and know what action to take.
The useful system is not the one with the most data. It is the one that helps an operator, maintenance technician, engineer, or service organization recognize a developing problem and act on it.
That idea will also become increasingly important as AI tools begin working with machine histories and maintenance information.
Source: Shop Floor Lasers — Uptime By Design
NEW: MWL Product Watch
Starting this week, MWL Product Watch will briefly highlight one product or technology that caught my attention and may be worth a closer look for manufacturers.
The intention is not to turn the newsletter into an advertisement. It is simply another way to point out interesting developments that might otherwise be easy to miss.
TRUMPF X-Blast 2.0
TRUMPF’s X-Blast 2.0 cutting nozzle is designed for high-productivity 3D laser cutting of hot-formed components. Its increased working distance is intended to reduce nozzle collisions and improve process reliability. TRUMPF also says the nozzle can help make compressed-air cutting more practical in these applications when combined with its other process technologies.
Why it caught my attention: It is a good reminder that improving a laser process isn’t always about adding more laser power. Something as seemingly simple as nozzle design and working distance can affect uptime, consumable life, process stability, and ultimately cost per part.
Source: TRUMPF — X-Blast 2.0 and hot-forming laser cutting
Have a product MWL should look at?
If your company manufactures a product related to laser materials processing, additive manufacturing, automation, motion control, laser safety, process monitoring, or advanced manufacturing, send MWL a LinkedIn message with a product link and a short explanation of what makes it interesting.
We select products because we think they’re useful for manufacturers to learn about—not simply because they were submitted. A Product Watch mention should not be considered an MWL endorsement.
MWL Automation Note
The Machine Works. But Is the Automation Maintainable?
A machine can run perfectly and still have poor automation.
The PLC logic may control the process correctly. The HMI may display what the operator needs. The customer may accept the machine and put it into production.
But three, five, or ten years later, another controls engineer or maintenance technician may have to troubleshoot that same machine.
That is often when the difference between working code and maintainable code becomes obvious.
Working Code and Maintainable Code Aren’t Always the Same Thing
Most experienced programmers know what makes a program easier to support.
Clear tag names. Consistent machine states. Useful alarm messages. Reusable structures. Comments where they actually help. Current backups. Revision records. Documentation of field changes.
None of these things make the machine move faster.
But they can make a huge difference when the machine stops at 2:00 in the morning and somebody who didn’t write the original program has to figure out why.
A tag called Axis_X_Ready tells you something.
A tag called B17 probably requires someone to open the program and start tracing logic.
PLCopen’s software-construction guidelines take this idea much further. They include recommendations covering naming conventions, comments, limiting code complexity and global variables, explicit data handling, and consistent coding practices. One recommendation I particularly like is simple: comments should describe the code’s intent.
In other words, don’t write a comment that simply translates the line below it.
Explain why the logic exists.
Make the Machine States Obvious
Another way to make troubleshooting easier is to have a clear machine-state structure.
What does Ready mean?
What conditions have to be true before the machine can enter Automatic?
What is the difference between Stopped, Held, Aborted, Faulted, and Waiting?
These definitions don’t necessarily need to follow a particular standard, but they should be consistent and understandable.
OMAC’s PackML model is one example of what standardization can accomplish. It establishes common machine states and defined behaviors so that machines can have a more consistent structure even when they come from different manufacturers or use different control platforms.
You don’t need to convert every custom laser machine into a PackML machine.
But the underlying lesson is useful:
Define your machine states once, name them clearly, and use them consistently throughout the PLC, HMI, alarms, and diagnostics.
That makes the machine easier for the next programmer to understand—and makes the machine data much more meaningful later.
Create a Small Maintainability Checklist
A full software refactor at the end of a project is probably unrealistic.
A 30-minute maintainability review may not be.
Before releasing a machine, I would at least ask:
- Are the important tags understandable without tracing the entire program?
- Are the major machine and subsystem states clearly defined?
- Are reusable devices—axes, valves, cylinders, lasers, scanners, etc.—structured consistently?
- Do comments explain unusual decisions and why the code works the way it does?
- Can another engineer determine which software revision is actually running in the machine?
- Is there a known-good backup, and does someone know where it is?
- Were the final field changes documented?
That doesn’t eliminate technical debt.
It does keep some of it from becoming a mystery.
The Problem Is Finding the Time
I don’t think most programmers intentionally create difficult-to-maintain machines.
In many cases, they already know exactly where the program could be cleaned up.
The problem is that once the machine works, another deadline arrives.
Production needs it. The customer wants acceptance. The next machine is waiting. The controls engineer has another startup.
The cleanup that everyone knows should happen becomes something to do later.
And later often never comes.
That is how industrial software technical debt builds up—not necessarily because the original programmer didn’t know better, but because getting the machine into production had to come first.
One practical compromise may be to record the debt when you can’t fix it.
If you know a temporary workaround was added during startup, document it.
If a sequence needs to be rewritten later, put it in the revision notes.
If somebody changed an interlock in the field, record what changed and why.
Leaving a note for the next programmer is considerably better than leaving a surprise.
A Backup Is More Than a PLC Upload
This is another area where I think machine builders can do better.
A folder called:
Machine_Final_Backup
isn’t especially helpful when there are four copies of it on three laptops.
A useful machine backup should make it possible to reconstruct the controls environment.
That may include the PLC program, HMI project, motion-control configuration, drive parameters, safety program, robot program, vision configuration, device configuration files, software versions, option or license information, and anything else required to restore the machine.
NIST’s guidance for operational technology recommends maintaining baseline configurations, tracking configuration changes, and keeping backups that include configuration information, installation media, and license keys. It also recommends verifying backup integrity and testing the restoration process.
That last part is important:
A backup you have never tried to restore is really just a file you hope will work.
For a machine builder, a practical rule might be:
Before a major field change: make a backup. After the change works: make another backup and document what changed.
That is simple change management, and it can save hours—or days—later.
Alarms Should Help Someone Do Something
The same thinking applies to alarms.
An alarm that says:
X Axis Servo Not Ready — Check Drive Alarm
gives a technician somewhere to begin.
Machine Fault 37 does not.
ISA’s alarm-management work goes much deeper than alarm wording, but one principle is particularly useful for machine builders: an alarm represents an abnormal condition that requires an operator response.
That raises a useful question when creating an alarm:
What do I expect the operator or technician to do when this appears?
If we can’t answer that, we may not have finished designing the alarm.
I’ll come back to this in next week’s Automation Note.
There May Be Another Reason This Matters
Good automation structure could become even more valuable as AI-assisted maintenance develops.
An AI maintenance tool will have the same basic problem a new technician has:
It needs context.
Clear tag names, meaningful alarms, defined machine states, revision histories, documentation, and event records give both people and future AI tools something useful to work with.
If a machine reports:
Machine_State = 3 Alarm_17 = TRUE B17 = FALSE
somebody—or some future AI system—still has to reverse-engineer what it all means.
Compare that with:
Machine_State = AUTO_RUNNING Laser_Chiller_Flow_OK = FALSE Laser_Enable_Permitted = FALSE
The second example isn’t just easier for AI.
It is easier for the technician standing in front of the machine today.
And that should probably be the first goal.
Next Week
One of the simplest places to start improving maintainability is also one of the most visible:
Alarms.
Next week’s MWL Automation Note will look at what makes a good machine alarm, what information an alarm should contain, and why alarm quality may be one of the easiest ways to make a machine easier to troubleshoot.
References and Further Reading
PLCopen — Software Construction Guidelines: Naming conventions, commenting, coding practices, reusable structures, and software quality for IEC 61131-3 applications. PLCopen Software Construction Guidelines
OMAC — PackML An example of standardizing machine states, behaviors, and data structures to improve consistency, reuse, and troubleshooting. OMAC PackML
NIST — Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3. Includes practical guidance on configuration management, change tracking, backups, restoration, and maintenance records for operational technology. NIST SP 800-82 Rev. 3
ISA — ISA-18 Alarm Management Series Guidance covering alarm design, rationalization, documentation, monitoring, management of change, and alarm systems for discrete and packaged equipment. ISA-18 Series of Standards
Comments
Comments settings
1
Add a comment…
Open Emoji Keyboard
No comments, yet.
Be the first to comment.Start the conversation