[FluidNC PR#1567] Added a jog_acceleration_divisor config under axes to decrease acceleration when jogging

#1 – MitchBradley 于 2025-09-30

Is this primarily useful for continuous “jog while button held”, or is it also useful for jog-by-increment? I would think that the latter is better with fast acceleration.

#2 – Gerporgl 于 2025-09-30

I found that it was useful for both, at least in my case. I use the CYD dial, and when jogging by 1mm increments with the dial for example I found that the max acceleration was doing a lot of vibration which were unnecessary I thought in my case. And if you turn the jog wheel very fast, by increments of 0.1mm for example, I also find it is a lot smoother to move with slower accelerations, and quieter, and at the end, if you move the wheel a lot and very fast, the speed will accelerate to the max speed anyway. So if you want to move fast it still allow you to do it.

It was less of a problem with UGS, since it does not jog the same way the FluidDial does.

At first I was trying to see if I can smooth the algorithm in the FuildDial code, by doing slower moves then gradually faster… but then that didn’t provide the result I was hoping.

I find it a lot smoother to jog compared to my default 2000 acceleration. At least on my small steel CNC which is a bit heavy and shaky on my wooden table. It is much quieter to use while positioning, probing and just preparing, and it seems less stressful for the hardware.

#3 – bdring 于 2025-09-30

We have heard someone else requesting the opposite. They want a slower acceleration during G1/G2/G3 moves (under cutting load).

Note: Some people use G0 for jogging. Does this affect both jogging and G0? I suggest not. You generally want fastest rapids when running jobs.

We could probably allow less than 1.0 to allow this (rename to it jog_acceleration). like 0.001x to 2.00x

Also, we tend to use “percent” for multipliers like this. jogaccelerationpercent. We should determine what makes the most sense.

We could probably allow per axis settings. The value you saw in the code is determined by what can be achieved at the move angle.

#4 – Gerporgl 于 2025-09-30

> We have heard someone else requesting the opposite. They want a slower acceleration during G1/G2/G3 moves (under cutting load).

> Note: Some people use G0 for jogging. Does this affect both jogging and G0? I suggest not. You generally want fastest rapids when running jobs.

No it doesn’t affect G0, I reused a flag in the planner (is_jog) that seems to be only for real jog commands. I also agree it should not affect G0.

> We could probably allow less than 1.0 to allow this (rename to it jog_acceleration). like 0.001x to 2.00x

Totally makes sense, I agree. I wasn’t sure at first if we should allow faster, I thought some people may have different use cases. I’ll make the change.

Do you think 2.00x is enough? I know it may be risky to allow too much if a mistake is made perhaps…

> Also, we tend to use “percent” for multipliers like this. jogaccelerationpercent. We should determine what makes the most sense.

Yes, also makes sense, this is the kind of feedback I was looking for about that setting.

> We could probably allow per axis settings. The value you saw in the code is determined by what can be achieved at the move angle.

I see. I may have misinterpreted the code, I thought the function limitaccelerationbyaxismaximum was looking for the maximum of all axis in the config, but that seemed strange.

I’ll take a look at all of that and commit new changes when I get a chance.

#5 – MitchBradley 于 2025-09-30

On by default at the FluidNC level would potentially break one or more of the approximately one million senders that people use.

It would, though, be possible to have WebUI 2 and/or 3 default to auto-reporting.

#6 – Gerporgl 于 2025-10-01

Alright, I’ve made the change.