When we buy a new laser cutting or welding system, most of the discussion is understandably about what the machine can do today.
How fast will it cut or weld? What tolerances can it hold? What materials can it process? How much production can we get through it?
But there is another question that may not become important until years later:
Will we still be able to support the software that keeps this machine running?
I have been on both sides of this problem, working with the software used to build machines and later trying to support machines after the original people, computers, and software environments were no longer available.
It is a real lifecycle issue, and I think we need to consider it when the machine is purchased rather than waiting until something goes wrong ten years later.
Laser Machines Can Stay in Production a Long Time
Fifteen years is not an unreasonable life to consider for industrial laser equipment.
Mazak has a LegacyLink support program specifically for laser machines 10 years and older.[1] TRUMPF says it has installed thousands of 3D laser cutting systems for hot-formed components since 2011 and that more than 99% of those systems remain in use.[2]
That doesn’t mean every laser machine will or should run for 15 or 20 years. Technology changes, production requirements change, and sometimes replacing a machine simply makes economic sense.
But it does demonstrate something important:
The machine may remain useful much longer than the original software-support environment surrounding it.
During 10 or 15 years, a lot can change.
People leave companies. Integrators get acquired. Small OEMs go out of business. Engineering laptops disappear. Operating systems become obsolete. Software goes through multiple revisions. Licenses and hardware keys get misplaced. Passwords are forgotten.
And sometimes nobody can find the actual editable source project.
The machine might still be mechanically sound and capable of making good parts, but a relatively small controls problem can suddenly become a major production problem.
“We’ll Just Call the Guy Who Programmed It”
This is probably one of the worst long-term support plans—and one of the most common.
It works fine for the first few years.
Then the programmer changes jobs.
Or retires.
Or the integrator isn’t around anymore.
Or the person answering the phone today wasn’t involved when the machine was built twelve years ago.
The problem isn’t necessarily that anyone did anything wrong.
Ten or fifteen years is simply a long time in the software and automation world.
The machine needs a support strategy that doesn’t depend entirely on one individual’s continued availability.
This Is One Reason PLCs Work So Well in Large Plants
Walk through a large manufacturing plant, and you will probably find PLCs controlling a significant percentage of the equipment.
There are many reasons for that: reliability, industrial hardware, deterministic control, extensive I/O capabilities, and long product histories.
But I think maintainability is equally important.
Suppose a plant has standardized on Allen-Bradley ControlLogix.
Its controls engineers probably already have Studio 5000. They understand the programming environment. They may stock replacement hardware. They have standards for naming tags and organizing programs. They know how to go online and troubleshoot an interlock.
A Siemens plant may have the same infrastructure built around TIA Portal.
The person who originally programmed the machine does not necessarily have to be available.
The plant has built an ecosystem around the controller.
That is an enormous advantage.
It is also why a smart machine buyer should be very careful about accepting a machine where the OEM completely locks the customer out of the controls.
The presence of a PLC doesn’t guarantee maintainability. Major PLC platforms provide legitimate mechanisms for protecting portions of programs and intellectual property.[3][4]
The buyer still needs to understand what they will—and will not—be able to access.
But This Is Not an Argument That Every Laser Machine Needs a PLC
This is where I think an important distinction needs to be made.
The goal is not to specify a PLC. The goal is to specify a maintainable machine.
A standalone precision laser cutting or welding machine may have motion requirements that make an advanced motion controller a better choice as the primary machine controller.
And a modern motion controller does not necessarily have to be limited to commanding motors.
ACS Motion Control’s SPiiPlus platform is a good example.
SPiiPlus can execute ACSPL+ application programs, manage machine logic and I/O, communicate with EtherCAT devices, perform the high-performance coordinated motion required by a precision laser system, and use GSP for G-code execution. GSP and ACSPL+ can also be combined so that machine functions and I/O are coordinated with the part program and motion.[5]
That means a standalone laser cutter does not necessarily need:
PLC + motion controller + CNC + multiple programming environments
simply because that is the traditional way of doing things.
Depending on the machine, one capable motion controller may be able to perform many of those functions.
And that doesn’t automatically make the machine harder to maintain.
A Motion Controller Can Be Maintainable Too
This is where software tools and application design become important.
ACS provides MMI Application Studio as part of its SPiiPlus development environment, along with programming, configuration, diagnostic, and simulation tools.[6]
The ACS development software is available as a free download.
That matters more than it might initially appear.
A maintenance engineer doesn’t have to justify purchasing another expensive development-seat license simply to obtain the engineering environment needed to connect to the controller and investigate a problem.
With MMI Application Studio, a technician or engineer can examine programs, variables, I/O, motion status, EtherCAT devices, faults, and other machine information.
The diagnostic and scope tools can go considerably deeper when necessary.
ACS also provides a SPiiPlus controller simulator that can execute ACSPL+ programs and emulate machine operation without the physical controller. ACS specifically describes development, debugging, and support applications for the simulator.[7]
Does this mean every maintenance technician will immediately understand a complicated SPiiPlus application?
Of course not.
But the same is true of a poorly written PLC program.
Which brings us to what I think is the more important issue.
The Controller Isn’t What Makes a Machine Maintainable
You can build an impossible-to-maintain machine with one of the most popular PLCs in the world.
You can also build a very maintainable machine around a specialized motion controller.
The difference is often how the software is designed.
For example, I would much rather troubleshoot a well-structured motion-control application with meaningful variable names, documented functions, organized machine states, clear alarms, and good diagnostics than a 15-year-old PLC program consisting of hundreds of poorly documented rungs written by five different programmers.
The logo on the controller doesn’t fix bad software architecture.
Some basic practices can make an enormous difference years later:
- Organize software into understandable machine functions rather than one massive sequence.
- Use meaningful names for variables, I/O, and devices.
- Explain why unusual things are done, not merely what each line of code does.
- Build useful alarms and diagnostics into the machine from the beginning.
- Separate reusable machine functions from the individual part or process sequence where practical.
- Maintain revision-controlled backups.
- Record controller firmware, software versions, and required development tools.
- Document network and fieldbus configurations.
- Preserve HMI, robot, vision, and motion projects along with the PLC or controller project.
And most importantly:
Design the software assuming that someone who didn’t write it will eventually have to troubleshoot it.
Because over a 15-year machine life, that is very likely to happen.
Source Code Is Only Part of the Problem
People sometimes say, “We have a backup,” and assume the problem is solved.
Maybe.
But what exactly is in that backup?
Can you edit it?
Does it contain the comments and symbolic information?
Do you have the HMI project?
What about the robot program?
Motion configuration?
Safety program?
Drive parameters?
Vision recipes?
Industrial PC application?
Does the backup require a software version nobody has anymore?
Does it require a license or dongle sitting in a drawer somewhere?
And has anyone ever actually tried restoring it?
A backup that has never been tested is really just a hope that you have a backup.
For a valuable production machine, I think recovery deserves more attention than copying a few files onto the plant network.
The OEM Has Rights Too
There is another side to this discussion.
I don’t believe buying a machine necessarily means the customer should receive unrestricted access to every piece of technology the OEM has developed.
An OEM may have spent years developing a special calibration method, motion algorithm, process-control routine, or other software that creates real competitive value.
Protecting that intellectual property is reasonable.
Modern control platforms recognize this need. Rockwell Automation provides source protection that can restrict access to selected Logix routines and Add-On Instructions, while Siemens provides know-how protection for selected PLC blocks.[3][4]
The mistake, in my opinion, is treating the entire machine as proprietary simply because one portion contains valuable IP.
There is a big difference between:
“You can’t see the internal algorithm in this proprietary process function.”
and:
“You can’t troubleshoot why the coolant pump won’t start without calling us.”
A well-designed architecture can often protect the first while still allowing the customer to handle the second.
That is a much healthier long-term relationship between an OEM and its customer.
There Is Also a Risk in Giving Everyone Unlimited Access
I’ve seen this side of the issue too.
An OEM provides the source code.
Someone at the plant changes it.
There is no revision control.
Someone else makes another change six months later.
Nobody updates the drawings or documentation.
Eventually the machine develops a problem, and the original builder gets called.
The programmer opens the project and discovers that the machine no longer contains the software they originally delivered.
That isn’t a good support strategy either.
Access needs to come with change control.
At minimum, I would want the original commissioned version preserved, production changes documented, and current backups maintained.
If an outside integrator makes a modification, keep a record of what was changed and why.
That isn’t bureaucracy for bureaucracy’s sake.
Five years later, it can save hours—or days—of troubleshooting.
What Should a Machine Buyer Ask Before Purchase?
If I were specifying a laser cutting, laser welding, or other automated machine that I expected to operate for the next 10 to 15 years, I would include software support in the purchasing specification.
I would want clear answers to questions such as:
- What controllers are being used?
- What software is required to troubleshoot them?
- What development software does the customer need to purchase, if any?
- What source projects will be delivered?
- Which portions of the software are protected?
- Who will possess the passwords or protection keys?
- Will the customer receive the HMI, motion, robot, and vision projects where applicable?
- Are drive and fieldbus configurations backed up?
- What happens if the controller or industrial PC has to be replaced?
- Can another qualified engineer service the machine?
- How will software revisions be controlled?
- What happens to proprietary source code if the OEM is acquired or goes out of business?
- Has a machine recovery procedure actually been tested?
Those are much easier questions to answer before issuing the purchase order than ten years after the machine arrives.
Design the Software Life Along With the Mechanical Life
We routinely think about the mechanical life of a machine.
We size bearings.
We select motors.
We consider cable flex life.
We think about replaceable wear components.
We stock spare sensors and drives.
Maybe we need to give the software side the same lifecycle consideration.
A 15-year-old laser machine probably won’t contain every electronic component that was installed when it was new.
Controllers may change.
PCs may be replaced.
Drives may become obsolete.
Operating systems will certainly change.
That’s normal.
What shouldn’t be normal is discovering that a mechanically useful and expensive machine has become difficult to support because nobody knows where the source code is or how to connect to the controller.
PLCs have been very successful in large plants partly because they fit into an established long-term maintenance infrastructure.
A standalone precision laser machine can achieve the same objective with an advanced motion controller such as SPiiPlus if the architecture, software, documentation, and access are designed for maintainability.
So perhaps the question we should ask isn’t:
“Does this machine use a PLC?”
Or:
“Who wrote the software?”
The better question is:
“If the person who wrote this software is gone ten years from now, can somebody else keep this machine running?”
If the answer is no, I think we have identified a machine-design problem before the machine has even shipped.
For those of you maintaining older laser or automated equipment: what has caused the biggest long-term software problem—obsolete hardware, missing source code, passwords, development software, undocumented changes, or something else?
#ManufacturingWithLight #LaserCutting #LaserWelding #IndustrialAutomation #ControlsEngineering #MachineMaintenance #MotionControl
References
[1] Mazak Optonics — LegacyLink Support program intended for older Mazak laser machines, including equipment ten years and older. https://www.mazakoptonics.com/moc-en/mpower/LegacyLink/
[2] TRUMPF — 3D Laser Cutting Systems for Hot Forming TRUMPF discusses its installed base of 3D laser cutting systems and the continuing operation of systems installed since 2011. https://www.trumpf.com/en_US/landing-pages/global/sales/hot-forming/
[3] Rockwell Automation — Logix Source Protection Documentation covering source protection for routines and Add-On Instructions in Studio 5000 Logix Designer. https://www.rockwellautomation.com/en-us/docs/studio-5000-logix-designer/38-01/contents-ditamap/studio-5000-logix-designer/source-protection.html
[4] Siemens — TIA Portal Know-How Protection Siemens documentation covering protection of PLC program blocks within TIA Portal. https://cache.industry.siemens.com/dl/files/999/109773999/att_1356334/v1/109773999_TIA_Add-In_Know_How_Protect_TIA18_19_en.pdf
[5] ACS Motion Control — GSP and ACSPL+ ACS documentation describing how GSP and ACSPL+ can be used together within a SPiiPlus machine-control application. https://www.acsmotioncontrol.com/KC/Content/SW/SW_GSP/Document/GSP_and_ACSPL.htm
[6] ACS Motion Control — MMI Application Studio / SPiiPlus Development Environment Information on ACS development, configuration, programming, and diagnostic tools for SPiiPlus controllers. https://acsmotioncontrol.com/capabilities/application-development/mmi-application-studio/
[7] ACS Motion Control — SPiiPlus Controller Simulator ACS description of its controller simulator for application development, debugging, testing, and remote support. https://acsmotioncontrol.com/posts/accelerate-development-with-the-spiiplus-controller-simulator/