Automation Notes
What If We Standardized the Control System Before Building the Next Laser Machine?
The machine should be custom. The control foundation does not always have to be.
One thing that has bothered me for years in custom machine building is how often we solve the same control problems over and over again.
A company decides to build a new laser cutting, welding, drilling, or micromachining system. The mechanics may genuinely be new. The optics may be different. The laser process may be proprietary. The part handling may be completely application-specific.
But then the controls team starts almost from the beginning too.
How are we going to organize the machine software?
How will we home the axes?
How will G-code work?
How will we handle custom M-codes?
How will the laser interface with the motion?
How will process gas be controlled?
What will the HMI need?
How will alarms work?
How do we support dry run?
How do we back everything up?
What happens five years from now when somebody who didn’t write the software has to troubleshoot the machine?
Those are all legitimate engineering questions.
But on Machine #5, should they still be new questions?
That is the idea I’ve been thinking about:
Build the process-specific machine. Standardize the control foundation underneath it.
The business proposal I developed around this concept describes a pre-engineered ACS Motion Control platform covering CNC motion, EtherCAT configuration, machine states, laser synchronization, G/M-code functions, diagnostics, HMI integration, simulation, version control, backup and lifecycle support.
For an Automation Note, though, I think the bigger idea is more interesting than the business proposal itself.
Custom Machine Does Not Have to Mean Custom Everything
A precision laser machine usually contains several areas where the OEM or manufacturer should absolutely retain freedom.
The machine builder should determine the mechanics.
The process engineer should determine how the laser process works.
The optical architecture, fixturing, automation, part handling, safety system, laser source and application-specific intellectual property may all be unique.
Those are often what differentiates one machine from another.
But underneath those application-specific elements is a surprising amount of common control infrastructure.
For example:
- Machine startup and operating states
- Axis ownership and enabling
- Homing
- EtherCAT device organization
- Jogging and manual operation
- Program loading and execution
- G-code interpretation
- Custom machine commands
- Laser-ready and laser-fault handling
- Process gas functions
- Recipe management
- Fault and alarm management
- HMI communications
- Diagnostic information
- Simulation and dry-run modes
- Software revision information
- Backup and recovery procedures
Those functions may need configuration for a particular machine, but they usually don’t need to be invented again.
That distinction is important.
Standardization does not mean making every laser machine identical.
It means creating a stable foundation so that engineering effort can be spent on what actually makes the new machine different.
Why ACS Makes This Idea Interesting
I’ve worked with ACS Motion Control technology long enough to have watched the platform evolve considerably.
Years ago, I primarily thought of ACS as a very capable precision motion controller.
Today I look at it differently.
SPiiPlus provides the real-time motion and EtherCAT control environment.
GSP provides the G-code/CNC layer.
ACSPL+ provides a real-time programming environment for building machine-specific functions around that CNC.
The development environment provides programming, configuration, Scope, diagnostics and simulation.
And for applications that need it, the LCI can coordinate laser operation with the actual trajectory rather than treating the laser as simply another asynchronous output.
That combination makes it possible to think about ACS not merely as the motion controller inside the machine, but as the foundation of the machine control system itself. The proposal therefore deliberately positions the concept as a reusable laser-control platform rather than simply selling an ACS controller.
That distinction matters.
A laser OEM generally doesn’t wake up in the morning thinking:
I need a better motion controller.
They are thinking:
I need to build a laser machine.
Handing an OEM an advanced controller and a stack of manuals still leaves a substantial amount of engineering between the controller and a production machine.
A standardized control platform tries to close that gap.
I Would Think About the Platform in Three Layers
One useful idea that came out of working through this proposal was separating the system into three levels.
Level 1 — CNC Motion
This is the part most people immediately associate with a CNC.
Read a part program.
Execute coordinated trajectories.
Handle feeds, coordinate systems, contour motion and machine motion.
For laser processing, trajectory quality matters a great deal because the process is happening while the machine is moving.
Level 2 — Machine Control
This is where a CNC alone isn’t enough.
The controller also needs to understand the machine surrounding the path.
That could include:
Process gas.
Focus or height control.
Fixtures.
Extraction.
Axis homing.
Laser readiness.
Machine operating modes.
Fault recovery.
Part recipes.
I/O.
Auxiliary equipment.
Instead of scattering this functionality throughout each new application, much of it could exist as a reusable ACSPL+ machine framework.
GSP and ACSPL+ are particularly useful together here because the G-code program can describe the part and process sequence while reusable controller functions handle what those commands actually require the machine to do. The proposal specifically calls for a standard G-code/custom-M-code foundation and a reusable ACSPL+ machine-control framework.
Level 3 — Laser/Process Synchronization
Not every laser machine requires sophisticated motion-to-laser synchronization.
Sometimes conventional I/O is perfectly adequate.
But some processes depend heavily on exactly where the machine is when the laser fires.
That is where something such as the ACS LCI becomes much more interesting.
The process can potentially be related to position, distance traveled, motion segment, or velocity rather than merely issuing a software command and hoping the timing is close enough.
The standardized platform should therefore make LCI an option when the application benefits from it, rather than forcing it into every machine. That is also how the underlying proposal treats it.
Standard Machine Functions May Be More Valuable Than Standard Screens
It would be easy to look at a standardized control platform and immediately start designing a beautiful HMI.
I don’t think the HMI should be the product.
Screens change.
Customers have different visualization preferences.
Some OEMs may already have their own HMI architecture.
What is much harder to replace—and much more valuable—is the software framework underneath it.
Imagine having well-defined reusable functions such as:
HOME_MACHINE
LOAD_PROGRAM
PROCESS_GAS_ON
PROCESS_GAS_OFF
LASER_ENABLE
LASER_DISABLE
RESET_MACHINE
RUN_DRY
START_PROCESS
Each function has defined inputs, allowed machine states, permissives, completion status, timeout behavior, alarms and recovery behavior.
The HMI simply exposes those capabilities.
The part program can call the appropriate machine functions.
And the actual implementation remains in a tested machine-control layer.
That starts to make the control system feel less like a collection of programs and more like a product.
Machine #2 Is the Real Test
This may be the most important point in the entire idea.
You can spend a lot of money creating a beautiful control system for Machine #1.
That doesn’t necessarily mean you created a reusable platform.
The real test comes when the next machine starts.
Ask:
How much less controls engineering does Machine #2 require?
If the answer is almost none because we have to restructure the application, rewrite the HMI communications, redesign the fault system, and invent another G-code interface, then we probably built another custom integration.
If the answer is:
“We kept the basic framework and added the functions unique to this machine,”
then we may have created a platform.
For machines in the same general family, I would eventually want something like 70–80% of the basic architecture to carry forward. That percentage is a design target from the proposal, not an ACS specification or something I would claim every application can achieve.
But the direction matters more than the exact number.
Machine #2 should be easier.
Machine #5 should be significantly easier.
By Machine #10, the company should not still be debating how alarms are formatted or where the home sequence belongs.
Standardization Also Changes Maintenance
There is another benefit that may be even more important than saving engineering time.
Serviceability.
A custom machine may remain in production for ten, fifteen, or twenty years.
Eventually the original programmer moves on.
The laptop disappears.
The firmware version becomes unclear.
The person troubleshooting the machine doesn’t know which copy of the project is current.
Somebody discovers that the controller backup doesn’t include the HMI project.
Or a failed industrial PC gets replaced, and nobody knows exactly which software versions were installed.
That is not primarily a motion-control problem.
It is a product-lifecycle problem.
A standardized platform should therefore define what gets delivered with every machine:
- Controller source
- Compiled application
- EtherCAT configuration
- Drive and axis parameters
- HMI source where applicable
- Software and firmware versions
- Machine configuration
- Recipe versions
- Backup files
- Recovery instructions
- Known-good restore package
- Change history
The proposal treats this lifecycle package as a core part of the control system, not an afterthought.
I think that’s exactly right.
A machine that runs well today but cannot be restored five years from now is not a well-engineered machine.
Simulation Becomes Much More Useful Too
A standardized architecture also gives simulation more value.
Instead of using a simulator only while developing one machine, you can maintain and test the common control framework independently from the physical machines.
ACS’s Controller Simulator can be used with ACSPL+ programs and G-code, enabling testing of machine logic, program execution, simulated I/O, and fault conditions without the actual machine available. The proposal identifies this as an important benefit for development, regression testing and support.
That could make future software changes much safer.
A common framework can have standard test routines.
Does RESET always return the expected states?
What happens when the laser reports a fault?
What happens if process gas never reaches pressure?
What happens if an EtherCAT device disappears?
Can every supported part program run in dry mode?
Those tests become part of maintaining the platform rather than reinventing commissioning procedures for every machine.
Safety Still Has to Remain Separate
There is one boundary I would not blur.
A standardized machine-control framework is not the machine safety system.
The laser enclosure, access control, E-stops, safety interlocks, STO functions and other safety-related elements still require the proper machine-specific risk assessment and safety architecture.
The proposal deliberately shows an independent safety path separate from the ordinary ACSPL+/G-code application.
That’s important because making the main controller more capable should never become an excuse to mix ordinary process logic with functions that require a safety-rated design.
The standard platform can interact with the safety system.
It shouldn’t replace it.
This Isn’t an Argument That ACS Is Always the Best Choice
There are very capable control platforms from FANUC, Siemens, Beckhoff, Aerotech, Omron and others.
For some machines, one of those platforms may clearly be the better choice.
The proposal itself came to the same conclusion:
“Best controller” is the wrong argument.
What interests me about ACS is a narrower question.
Could ACS become a very strong standard control foundation for custom precision laser machines where high-performance motion, flexible machine programming, G-code and tighter laser synchronization matter?
I think it could.
And I think much of the required technology already exists.
The bigger job is productization.
Software architecture.
Documentation.
Configuration standards.
Diagnostics.
Testing.
Training.
Recovery procedures.
Application support.
And the discipline to avoid turning every customer request into another completely custom control system.
The Question I’d Like Machine Builders to Consider
When you start your next laser machine project, separate what’s truly application-specific from what you’re simply engineering again because that’s how the last project was done.
Your optics may need to be different.
Your mechanics may need to be different.
Your process almost certainly needs to be engineered for the application.
Your machine safety needs to match the actual hazards.
But does your alarm framework really need to be new?
Does your homing architecture?
Your program interface?
Your machine states?
Your diagnostics?
Your backup strategy?
Your G-code integration?
Your laser interface?
Maybe not.
And that leads back to the idea I keep coming to:
Build the process-specific machine. Standardize the control foundation underneath it.
If we can do that well, the payoff isn’t simply that Machine #1 works.
The payoff is that Machine #2 becomes easier to build, easier to commission and easier to support.
And by Machine #10, you’re no longer maintaining ten custom control systems.
You’re maintaining a machine platform.
MWL Automation Notes explores practical control, software, motion and machine-design ideas for manufacturing equipment. The ACS-based standardized control platform described here is an MWL concept under development, not an existing ACS Motion Control product or an announcement of an authorized commercial relationship with ACS.