[FluidNC Issue#1456] Feature: Dynamically Adjusting Acceleration in CNC Motion (G0 vs. G1/G2/G3) About GRBL HAL

Issue #1456 | 状态: 已关闭 | 作者: mikeoverbay | 创建时间: 2025-02-23

标签: enhancement

All changes that I had AI make are in this file.
It should handle everything. I can’t test. I don’t have a esp32 yet. Its on its way.

GcoldeParser.txt

Machine Context

Any machine.

Feature Description

I’ve been working on dynamically adjusting motor acceleration based on whether a CNC machine is executing rapid (G0) or linear (G1, G2, G3) moves. My goal is to optimize motion by changing acceleration time (t) in the equation:
a = (v – u) / t
where:
u = initial velocity
v = target velocity
t = time to reach target velocity
Why This Matters
Line moves (G1, G2, G3) can handle much faster acceleration because the feed rate is typically 1/2 to 1/10 of rapid speeds—sometimes greatly less when cutting alloys. Since the mass is already in motion, the force required for acceleration is minimal.
I’ve done the the math using chatGPT 03-mini-high. The theory looks solid to me based on the charts.

!Image

The file that needs changed is here.
https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-core/src/com/willwinder/universalgcodesender/gcode/GcodeParser.java

If we can insert a command to change the accel for all axis, this would work as long as the original values are saved so they can be restored in the even of a Estop or Cancel.
I’d like to work on a way to calculate optimal accel based on the mass of the axis moving.
I think this could greatly speed up contouring by removing a lot of the slow down /speed up from fixed acceleration.

Some code changes to GcodeParser.java.
It is untested and created with chatGPT 03-mini-high. I don’t want to type..
We need a way to read the value of the 3 accel settings and save them in case of program early termination so they can be restored. (should work in the .txt i attached?)

Some thing is is buggy with code blocks here.


public List addCommand(String command, int line) throws GcodeParserException {

        statsProcessor.processCommand(command, state);

        List results = new ArrayList<>();
        // --- Process FluidNC $ Commands for Acceleration Control ---

        String trimmedCommand = command.trim().toUpperCase();

        if (trimmedCommand.startsWith("G0") || trimmedCommand.startsWith("G1")) {

            // Ensure that the original settings have been stored.

            if (!originalSettingsStored) {

                // Optionally, you might call loadOriginalSettings() automatically.

                // For now, we assume the settings are loaded before processing begins.

                throw new GcodeParserException("Original settings not loaded. Call loadOriginalSettings() first.");

            }
            int param120, param121, param122;

            if (trimmedCommand.startsWith("G0")) {

                // For rapid moves, use the stored base values (fixed).

                param120 = baseParam120;

                param121 = baseParam121;

                param122 = baseAccel;

            } else {

                // For feed moves (G1), scale the stored values by tFactor.

                param120 = (int) (baseParam120 * tFactor);

                param121 = (int) (baseParam121 * tFactor);

                param122 = (int) (baseAccel    * tFactor);

            }

            // Build the $ commands.

            String cmd120 = "$120=" + param120;

            String cmd121 = "$121=" + param121;

            String cmd122 = "$122=" + param122;
            // Process each of these commands sequentially.

            Collection meta120 = GcodeParserUtils.processCommand(cmd120, line, state, true);

            if (meta120 != null) {

                for (GcodeMeta meta : meta120) {

                    if (meta.point != null) {

                        results.add(meta);

                    }

                    if (meta.state != null) {

                        state = meta.state;

                        statsProcessor.processCommand(cmd120, state);

                    }

                }

            }
            Collection meta121 = GcodeParserUtils.processCommand(cmd121, line, state, true);

            if (meta121 != null) {

                for (GcodeMeta meta : meta121) {

                    if (meta.point != null) {

                        results.add(meta);

                    }

                    if (meta.state != null) {

                        state = meta.state;

                        statsProcessor.processCommand(cmd121, state);

                    }

                }

            }

Collection meta122 = GcodeParserUtils.processCommand(cmd122, line, state, true); if (meta122 != null) { for (GcodeMeta meta : meta122) { if (meta.point != null) { results.add(meta); } if (meta.state != null) { state = meta.state; statsProcessor.processCommand(cmd122, state); } } } }

Other Approaches

none

How I Can Help

I can’t

#1 – breiler 于 2025-02-23

Your request in other words: “Please split up the settings for acceleration on rapid moves (G0) and cutting moves (G1, G2, G3)”.

That ChatGPT nonsense does not help anyone.

#2 – mikeoverbay 于 2025-02-23

> Your request in other words: “Please split up the settings for acceleration on rapid moves (G0) and cutting moves (G1, G2, G3)”.
>
> That ChatGPT nonsense does not help anyone.

I shortened it up…
Did you bother to look at the charts?
It’s actually pretty fascinating.
If you know your mass, you can calculate optimal accel for given next t based on current t.
I have been studying this for a couple of days to explore the variables and if the impact is worth the effort.
My issue is I don’t know java for shit. Give me C im good to go. I was hoping for input.

#3 – MitchBradley 于 2025-02-23

Stepper motors are not constant-force devices. Their torque decreases with speed.

#4 – mikeoverbay 于 2025-02-23

Yes. I am aware of this. I looked at curves of nema 34 and nema 23 motors.
I don’t think it will effect changing the accel setting. It would be useful to looking the variance of motor bands and sizes.
If we could find a good average, we could plug that in to the equations to stop the risk of skipping?
Introduce Q as torque. O3 is amazing at doing hard math.
I’ll think about this.
When I get my controller, I’ll hook it up to my gantry and see if I can get fluidNC to build.

#5 – MitchBradley 于 2025-02-23

Realistically, we FluidNC developers are probably not going to do anything about this. People have enough trouble tuning with fixed acceleration. We are unlikely to add the extra configuration complexity, incurring the support costs of documenting it and helping people who don’t understand it, in exchange for the modest performance improvements that might result. The motion planning is ridiculously complicated already; making it more complicated is not on our radar unless the gains would be compelling. You might think they are; my best guess is that they are not., across the range of machines and use cases that we support.

Feel free to continue you investigation, with the understanding that, in order for us to deploy your changes, the bar for proving the value is very high. Furthermore, since you are focused on changing UGS, which represents a fraction of the many UIs that are used with FluidNC, any changes to UGS will apply to a minority of FluidNC users. With that in mind, perhaps it would be better to move this discussion to a different forum, perhaps one specific to UGS.

As a further consideration, your idea of sending $ commands for reconfiguration in the middle of GCode sequences is problematic. It is not a common situation and we do not support it. It might happen to work, but we cannot guarantee that it will always do what you expect. Some configuration things cannot be changed on-the-fly, and when they do work, they can have timing implications that interact badly with the execution of GCode. Configuration is intended to be done infrequently, typically once at startup.

#6 – breiler 于 2025-02-24

As one of the developers on UGS, I will probably not spend time on this experiment. But the approach that you have come up with (changing the settings while streaming the gcode) can easily be done with a script or a search and replace it in the gcode file.

#7 – mikeoverbay 于 2025-02-24

Thank you!
This is what I wanted to hear.
I will do some experimenting on my own.
If I see that it does what I am hoping, I will get back to you folks.
Thank for all the hard work!
It’s a fantastic bit of coding!

#8 – mikeoverbay 于 2025-02-24

> As one of the developers on UGS, I will probably not spend time on this experiment. But the approach that you have come up with (changing the settings while streaming the gcode) can easily be done with a script or a search and replace it in the gcode file.

Thank you for the work. If I do see some usefulness for this idea, I will hack a script plugin together, if it can be done that way.
Ideally, it would be better just for the motion planner to handle it. I think It’s worth studying so I’ll continue.
Thank you for the hard work!

#9 – mikeoverbay 于 2025-02-24

It wont work.. I checked the source code.
// NOTE: The max junction speed is a fixed value, since machine acceleration limits cannot be
// changed dynamically during operation nor can the line move geometry. This must be kept in
// memory in the event of a feedrate override changing the nominal speeds of blocks, which can
// change the overall maximum entry speed conditions of all blocks.

#10 – bdring 于 2025-02-24

A higher acceleration increases jerk. I would think you want a lower jerk when cutting. Jerk causes stress in machines than can affect cut quality.

Larger machines use s-curve acceleration with a jerk parameter. Some day we may implement that, but it would require a lot of work, so it is not a priority at this time.

BTW: Those curves don’t make any sense to me. NewtonChat said: F=MA. There is no t.

#11 – mikeoverbay 于 2025-02-25

T is the time constant to get to speed.
All I know is that uping accel, it runs smoother during YZ contouring but rapid, it wants to move and stop to fast from to low of speed or a dead stop. Once its in motion , it can handle much faster accel as long as the deferential is too great.
This may not be a issue with the much faster planning the ESP32 affords. I haven’t test on that chip.

原始Issue: https://github.com/bdring/FluidNC/issues/1456

Machine Context

Feature Description

Other Approaches

How I Can Help

评论 (11)