[BUG] All movement is jerky, accelleration and deacceleration seem ignored?

[Voxel3DPrinting]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

Hi,
Since changing to 2.1.1 bugfix today, all movement (during printing, probing, homing and manual) is around 80% at full speed, and then suddenly around 20% extremely slow. It is not slowing down equally as it should. (see video attached)

Why is it doing this? it seems like the acceleration/deacceleration (at 650mm/s2) and Jerk (8) are just ignored

Bug Timeline

Since changing to 2.1 bugfix, downloaded 11/09

Expected behavior

Movement is accelerated and deaccelerated
Movement speed ;
0% - 10% - 30% - 60% - 80% - 90% -100% - 100% - 100% - 100% - 100% - 100% - 90% - 80% - 60% - 30 - 10% - 0%

Actual behavior

Movement is very quick and then suddenly very slow
Movement speed ;
0% - 100% - 100% - 100% - 100% - 100% -100% - 100% - 100% - 100% - 100% - 100% - 10% - 10% - 10% - 10% - 10% - 0%

Steps to Reproduce

It reproduces in any movement actually. I enabled S curve acceleration which may interfere, default acceleration is 650, classic jerk 8.0

Version of Marlin Firmware

2.1.x bugfix

Printer model

Xinkebot Orca 3

Electronics

Bigtreetech Octopus V1.1 with BTT TMC2209 V1.1

Add-ons

Euclid probe

Bed Leveling

ABL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

OctoPrint

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Configuration.zip
Video 1; https://youtu.be/Ea9HVhRH3wQ
Video 2; https://youtu.be/YVkGa_kAWV4
Video 3; https://youtu.be/HOyGOI--WwI

[EvilGremlin]

forgot to reset EEPROM?

[Voxel3DPrinting]

forgot to reset EEPROM?

nope, did that.

To add; I just extracted a clean/stock version of the same bugfix and only changed the essentials (board type, E amount an dual X carriage) after that the issue was gone.
Therefore I think that the issue is indeed caused by a setting in my original marlin setup (which is attached)

Also; the issue persist on all X, Y and Z movements, E not tested

[EvilGremlin]

might be related to #24552

[EvilGremlin]

try this https://github.com/EvilGremlin/Marlin/tree/bf2.1-octopustest

[Voxel3DPrinting]

@EvilGremlin Thanks, I will try it this afternoon. Is this a version for a newer platformio-something?

Do you need me to change all the settings according to my printer again? or just the essential stuff?

[Voxel3DPrinting]

try this https://github.com/EvilGremlin/Marlin/tree/bf2.1-octopustest

Hi Gremlin,
I tried your firmware, but am getting compiling errors. Any idea?

Configuration.zip

[renzaaa]

Same problem.

[ellensp]

@renzaaa how about attaching your configs so we can find a commonality?

[renzaaa]

So, the problem solved after disabled #define S_CURVE_ACCELERATION.
But why S_CURVE_ACCELERATION causes this bug?

[Voxel3DPrinting]

I changed to the stable 2.1.1 release and have enabled S_CURVE_ACCELERATION. It does not have the jerky movement but does have a few issues now with my macro's.

Maybe new marlin is getting to demanding for the chipset?

[renzaaa]

I changed to the stable 2.1.1 release and have enabled S_CURVE_ACCELERATION. It does not have the jerky movement but does have a few issues now with my macro's.

Maybe new marlin is getting to demanding for the chipset?

I think that something wrong with Minor planner optimization in 2.1.1-bugfix.
In the stable version no changes made with Minor planner optimization.

[Voxel3DPrinting]

Can be indeed. I have the 2.1.1 working somewhat stable now.

Only issue left that I have now is with the macros, I have multiple macros, with not more than 150 characters (max set to 350). But it only executes the first 8 lines....

[XDA-Bam]

@Voxel3DPrinting As far as I can see, you did not specify DEFAULT_MAX_ACCELERATION for your second extruder. If that is the case, please also check for other values that might be missing for that extruder.

[Voxel3DPrinting]

Hi,
For now, I changed back to 2.0.9.3, which I have somewhat working, since at this moment I am dependant on the machine for work and school...
However, I do have an issue now where my Binlinear bed levelling is consistently too low on the left side of the bed, and too high on the right side of the bed. Note; I can feel that it indeed is compensating, Euclid probe with 0.008mm accuracy at M48, It is doing this both in printing and G26 validation.

Is this a known issue? or do you have articles I can refer to?

[Voxel3DPrinting]

Similar issue as found here for example https://3dprinting.stackexchange.com/questions/15910/bltouch-does-not-compensate-for-bed-level-correctly#comment30103_15910