tapani
March 1, 2025, 6:39pm
1
I tried to search for this for 5 minutes but didn’t find anything… Has anyone seen dynamic/variable acceleration for FluidNC or any other platform?
What I mean is, changing the acceleration of the machine from G-code to better suite different things → lower values for finishing passes.
Tapani:
or any other platform
For Marlin, M201 can be used
Also investigate M204…
Not sure if FluidNC has the same capability.
azab2c
March 1, 2025, 7:57pm
3
Are you wanting to change speed (feedrate), or do you need to modify acceleration for a job that is actively cutting? By telling the machine to override the g-code by going 10% faster for example? If so, Klipper, Marlin and FluidNC all support this in their own way for speed, but, I don’t know about live acceleration rate changes. FluidNC has Speed and Feed Overrides | Wiki.js . fwiw I tried asking ChatGPT , it’s responses are not 100% accurate, but it’s perspective is helpful.
Or, are you wanting to configure specific speeds when defining your toolpaths using an app like EstlCam which lets you configure different rates for individual operations if you want. Maybe additional tool definitions would be required with different sets of feed rates, even though the same physical router bit is being used.
1 Like
jeyeager
March 1, 2025, 8:01pm
4
It might be possible in FluidNC but it’s not supported.
You can make changes like executing $ commands to change the acceleration defined in the config. That doesn’t work with all settings though.
But like I said, it’s not supported.
opened 10:04AM - 23 Feb 25 UTC
closed 05:59AM - 24 Feb 25 UTC
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](https://github.com/user-attachments/files/18932013/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.
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<GcodeMeta> addCommand(String command, int line) throws GcodeParserException {
statsProcessor.processCommand(command, state);
List<GcodeMeta> 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<GcodeMeta> 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<GcodeMeta> 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<GcodeMeta> 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 Like
vicious1
March 2, 2025, 12:36am
5
Dang, I spend enough time dialing in feed and speeds, I would not want to play with accelerations as well.
tapani
March 2, 2025, 7:35pm
6
It’s probably just better to lower the acceleration for all movements. But the idea came to me while I was looking at some copper parts that I made. The surface finish was really quite good on edges, better than I was expecting, except for some chatter marks that were exactly like ringing in 3D prints. Only present for the distance that it takes the machine to accelerate.
Corners are tricky, typically you are taking 75+ stepover compared to the regular 10-40% on the rest of the cut.