[BUG] [bf2_6axis_dev12] Move axis through menu gives different speeds depending on the axis about marlin

[DerAndere1]

What display config?

[hobiseven]

See below, in the independent move axis menu
Motion > Move Axis > Move I
For example.
I is way slower than Y.
J is actually faster the I, but displacement is super small. H

[DerAndere1]

I have no clue about the display-related code. Never had a serious look at it (I don't use a dedicated display but connect to a laptop). Maybe someone else knows how to fix it?

[hobiseven]

@DerAndere1 ; After fixing the IJK steps calculation, this is still broken. I will fix this now.

[hobiseven]

Ok, found the issue, at least something obviously wrong : Acceleration is correct for X, but incorrect for J. Note, this is also possibly impacting all movements.

To reproduce, simply request an axis moove through the moove menu, and request 10mm. For X, we have 80 steps per mm > 800 steps requested overall. The steps requested is correctly calculated in stepper.cpp for X,I and J.
Result :
X mooves by 1/4 turn, and my X stepper is 200 steps per turn > 50 steps done.
Y mooves by 1/2 turn, and my X stepper is 100 steps per turn > 50 steps done.
I mooves by 1/4 turn, and my I stepper is 200 steps per turn > 50 steps done but at very slow speed
J mooves by a very small amount very fast. Trying to go back to original position only works 1 time out of 2. the second time, axis direction is inverted.

Issue can be seen in stepper.cpp, line 1877

// Compute the acceleration and deceleration points
accelerate_until = current_block->accelerate_until << oversampling;
decelerate_after = current_block->decelerate_after << oversampling;

For X
Accelerate_until = 400
decelerate_after = 400
For I
Accelerate_until = 0
decelerate_after = 800
For J
Accelerate_until = 0
decelerate_after = 800

After a bit of followup in the code, the mistake is not in stepper.cpp, but is in the planner, passing wrong parameters.... More to come!
Luckily, the STM32 allows hardware breakpoint on the target. Now way to find that on an AVR platform, unless you have the code developped in Atmel IDE + debug probe.

[hobiseven]

Update : For short Gcode files, all works perfectly. The attached file, much longer, still shows difference on J axis. I think this is the same root cause as the difference seen in the displacement issued by the menus. Gcode attached as a reference. Same Naca 43012 profile cut at the same time on both XY and IJ.
Would be great is @DerAndere1 you could play this file in your AVR board, even on Marlin 119, to check wether the issue is a porting issue, or a missing code issue.

43012.zip
Output on ARM , M114 at the end :

Send: M114
Recv: echo:M114
Recv: X:0.35 Y:0.00 Z:0.00 I:0.35 J:-1.42 E:0.00 Count X:28 Y:0 Z:0 I:14 J:-57
Recv: ok

The output should be exactly the same X /I and Y/J.

Let me check the acceleration and deceleration calculation. There seems to be quite a lot of 6 axis code missing from motion.cpp... more to come

[hobiseven]

This is fixed. Definition of manual feedrates ware missing for I, J and K axes for LCDs using ULTIPANEL, EXTENSIBLE_UI.
See commit https://github.com/hobiseven/Marlin/commit/efde6ca2a6abb3e05f3f909bc1d65dbbe0a2ece8