The end is nigh for G-code

For all the cutting-edge technology touted to entice more young people into manufacturing, much of the sector remains mired in the past. In some cases, it’s the very distant past, going all the way back to the origins of engineering.

However, the majority of the modern manufacturing landscape is rooted in the middle of the 20^th century, which included significant refinements in assembly as well as the beginnings of robotics and computer numerical control (CNC). Robotics has certainly come a long way since the days of the Unimate, but when it comes to machine control, manufacturing is arguably still stuck in the 1950s.

A lot of that can be attributed to G-code: a terse, line-by-line instruction format that tells machine tools where to move, how fast to travel and, in some cases, what auxiliary functions to perform. It’s lasted an eternity for a programming language, even surviving the transition from punched tape to modern digital controllers. But that legacy is also its greatest weakness: G-code was developed when the available computing power was a fraction of what it is today. Without that technical constraint, it may be time to reassess whether G-code is still the best option for machine tool control.

“The people who wrote G-code wanted to separate real-time controllers from high-level controllers,” explains Jake Read, who recently completed a doctorate focusing on machine control at MIT’s Center for Bits and Atoms. “It sounds like a good idea, but the high-level controllers really need to know the physics going on in the machine. G-code is a one-way pipe, so the machines can’t send you back any other code.”

Read’s thesis proposes a different approach: model-based control that combines machine dynamics, process physics and planning in a common computational framework. Rather than asking a programmer to manually translate manufacturing intent into a collection of speeds, feeds, and other settings, the idea is to reason from physical models and respond to changing conditions during production. In some circles, this is known as moving from imperative to declarative programming.

According to Read, this could make machine tools faster and easier to program, as well as making it easier to preserve the kind of hands-on, shop-floor knowledge that’s usually difficult to document or transfer.

The black box between code and motion

Decades of manufacturing have demonstrated that G-code is more than up to the task of producing excellent parts. Skilled machinists and CNC programmers routinely deliver tight tolerances, high surface quality and efficient cycle times with conventional CAM systems and CNC controls.

The issue is the amount of process knowledge required to get there.

“It’s really difficult to tell, when you have a machine, what is it actually going to do when you send it a G-code command,” Read says. That’s because a hidden configuration layer connects the controller to the motors, drives and the mechanical structure. Users may know the command they issued, but not necessarily how a specific controller will interpolate, accelerate, decelerate or compensate as it executes that command.

This sort of abstraction works in software when interfaces and execution environments are sufficiently standardized, but machine tools can vary substantially in their motor characteristics, structural stiffness, kinematics, tuning parameters, friction, backlash, and numerous other physical idiosyncrasies.

As a result, even seemingly identical G-code files can run differently on different machines. “You can pick the same parameters on two different machines and they’ll behave very differently because not only is the physics different in both machines, but the controller is different in both machines,” Read says.

This is what makes machine programming more akin to an art form than one might think. Experienced programmers can start with CAM-generated values, run a part, listen for chatter or observe tool wear, and then revise the program and try again. While this works, especially when you have capable operators, the process tends to be slow and costly, especially for high-mix, low-volume production, where there may be little opportunity to amortize your setup and tuning across thousands of parts.

From parameters to physics

Model-based control aims to replace at least some of the trial-and-error in machining with explicit physical reasoning.

Today’s controllers commonly rely on heuristic limits, such as a maximum acceleration for each axis, or a maximum velocity and predefined rules for following the requested path. In contrast, Read’s model-based controller incorporates a representation of how the machine and process behave over time. This enables it to calculate the likely consequences of a command and choose actions that balance objectives and constraints.

This idea should be familiar to anyone with experience in robotics programming, where a robot’s controller can model how applying torque at a joint changes its leg’s position, velocity and contact forces. Read’s argument is that machining centers, 3D printers, laser cutters, waterjet systems, and other such tools should receive the same treatment.

Consider electric motors, where the available torque varies with speed. In such cases, a controller that treats acceleration as a single, static number would be leaving performance on the table. A model-based system can account for this changing torque-speed relationship, along with the machine’s inertia and the process load, to use the available operating envelope more fully.

Read tested this idea on a CNC mill and reported a 17.5% reduction in cycle time for an industrial-scale machining test. The result is promising, though he grants that the experiment needs broader validation on more hardware and a wider range of machining conditions. Still, the potential gains extend beyond the cycle times. In machining, cutting force, spindle behavior, tool engagement, vibration, and heat all affect the quality of the final part. In all of these cases, the effects are dynamic and interact with motion planning.

The same applies to additive manufacturing (AM). In fused deposition modeling (FDM), for example, material flow and temperature depend on the time the molten filament spends in the hot end. Read describes one FDM finding: after a printer has been operating slowly, the polymer in its hot end may be especially hot. As a consequence, the machine is briefly able to extrude at unusually high flow rates before the colder incoming filament changes the flow rate and requires it to slow down.

“There’s these little corners of dynamic state space where, when you have these things coupled and depending on all the dynamical states, you can go very quickly for a brief moment,” Read explains. “In machining, the motion system has no idea whether or not it’s cutting, but when you’re not cutting, obviously you can accelerate a lot more, and when you are cutting you can decelerate faster because the cutting force is helping your motors to stop.”

In the case of FDM, a conventional system would handle flow limits as a fixed feed-forward restriction, whereas a model-based controller can allow the extrusion process to influence the motion system in real time. Read frames this issue with the conventional approach  like this: “You can’t have the extruder say to the motion system, ‘I can’t extrude at this rate, please slow down,’” he says. “You can’t feed the process physics back into the motion physics.”

Beyond visual simulation

One might wonder whether model-based control actually offers an advantage over traditional G-code once you factor in modern CAM tools, such as simulations for toolpath verification and collision detection. While Read acknowledges how valuable these tools can be, he also distinguishes between geometric simulation and physical simulation.

Most established packages are good at geometric verification, using the expected positions of the machine, cutting tool, and stock to help identify potential collisions. Some specialized tools can also estimate cutting forces, resonance frequencies and temperature distributions with high accuracy. What these generally don’t do, according to Read, is model all of these process effects together at the time scales required for real control.

“There’s the geometry that tells you where the part and the cutting tool are, and that’s obviously really important,” Read says. “But underneath that are the cutting forces—chatter frequency, noise generation, dynamic loading—and there’s also the motion dynamics and kinematics in the machine. Those simulations won’t be able to tell you how much cutting force is required or at what frequency the structure is resonating.”

In Read’s view, a useful next-generation simulation would model the system as it operates, potentially resolving behavior at 100-microsecond intervals, but that’s computationally demanding. Read’s solution is to parallelize most of the controller computation and run it on a GPU. But milling is particularly challenging because a useful model must track the evolving relationship between the tool and workpiece geometry while also calculating process forces and machine motion.

It’s for this reason that Read has focused much of his work on FDM, where the geometric problems are simpler even though the thermal and flow dynamics remain complex. In any event, the ultimate goal is not a better virtual animation of manufacturing, but a controller that can make better decisions before and during production.

On machining expertise and expert machinists

The prospect of more intelligent machine control can invite familiar fears. One might worry that this sort of automation will replace skilled operators, or that machine recommendations will replace human judgments. But Read sees the potential in model-based control for immediate quality-of-life improvements for programmers and operators.

“There’s a much simpler step that’s probably a lot more valuable and productive,” he says. “And that’s making machine programming in a framework where the machine tells you about the physics that are going on inside it and you program it in terms of those physics. So, instead of working through abstract parameters, you interact directly with the machine, basically telling it how to exploit the physics that are available.”

A machinist setting up a roughing operation, for example, might express an intention in terms of allowable cutting force or tool-life tradeoffs, rather than selecting a precise feed rate and hoping it maps appropriately to a particular machine. “You should be able to say, ‘When you’re making this roughing pass, I want you to use 90% of the available cutting force in the hardware,’” Reed says. The operator could then specify a lighter cut for the finishing pass, with software translating that intent into machine-specific actions while showing predicted effects on force, cycle time, tool life, and quality.

Done right, this could shorten the journey from machining novice to expert programmer, a challenge Read is very familiar with after visiting small- and medium-sized enterprises where there’s often only one expert (usually on the verge of retiring) who understands the nuances of every machine. “It takes years to get good at CNC programming,” he says.

Indeed, not understanding the constraints of machining is a common machinist complaint  regarding engineers. When designers lack visibility into the cost consequences of seemingly minor geometry decisions, the friction between design and manufacturing can escalate quickly. If a fillet is placed in an inaccessible location, requiring a new setup orientation, an additional tool or a more complex fixture, that adds to the machining cost. Read’s hope is that process-aware models could provide feedback earlier, when part geometry is still easy to change without incurring additional expenses.

The interoperability issue

Even after so many years, the CNC ecosystem remains fragmented, with CAM vendors, controller manufacturers, machine builders, drive suppliers and end users each controlling a portion of the tech stack.

G-code is standardized in principle, but interoperability can still be a challenge. For example, CAM vendors have to maintain post-processors that can translate generic toolpaths into the dialects, kinematics, and conventions required by specific controls and machines, resulting in a persistent integration burden.

“Each machine is its own beast,” Read says. “So even though there are standards, they don’t work the same way that something like network standards work, because in that case it’s all just computing. I see this as an economic partitioning problem.”

G-code originally separated computational tasks because real-time control was expensive and limited, and higher-level planning was complex and slow. Modern embedded processors have changed that equation. “The amount of computing you can put on a limit switch for 10 cents is orders of magnitude bigger than the amount of computing we could fit in a room when G-code was invented,” Read says.

As is often the case, there are several ways this sort of radical shift in technological foundations can play out. It might begin with smarter CAM software that improves toolpaths without directly controlling hardware. Or there could be a new class of open or model-aware controllers. Or we could see model-based control built into vertically integrated machine platforms that combine the hardware, control, and programming software.

Obviously, that last option would be the most disruptive. But Read points to the pace of machine-tool development in Shenzhen, where he saw young workers programming and running dozens of CNC machines, combining operational familiarity with control knowledge in ways that are less common in North America. “If the major controller suppliers don’t try to [implement model-based controls], someone in Shenzhen will,” he predicts.

A common language for manufacturing

Perhaps the most exciting part of Read’s proposal is its potential for unification. The same physics models could inform machine design, low-level motor control, and high-level CAM planning.

Today, these tasks are typically under the purview of different tools and different working assumptions: machine designers use spreadsheets and component specifications; controller engineers use simplified dynamic models; CAM programmers use process knowledge and vendor libraries. Each of these groups is solving part of the same problem, but often with incompatible representations.

Read envisions a common set of control algorithms that would enable communication in a shared language of force, torque, thermal behavior, geometry, velocity, and constraint. The idea isn’t to eliminate specialization, but to make the handoffs between these groups more transparent and permit improvements in one layer to inform the others.

“The low-level and high-level control can be much more intimately connected,” Read says. That connection could in turn allow a machine to operate closer to its physical limits without requiring operators to gamble on aggressive settings.

G-code isn’t going to vanish overnight. It’s embedded in decades of equipment, post-processors, training materials, and shop-floor practice. But that was also true of punched tape, proprietary CAD formats, and isolated industrial networks.

The end of G-code, if it comes, may not look like a sudden replacement of one language with another. It may instead arrive as a gradual shift in what machine programming means: less a sequence of static instructions, and more a continuous conversation between engineering intent on the one side and machine tool physics on the other.

For more information, check out Read’s thesis on GitHub.

The post The end is nigh for G-code appeared first on Engineering.com.