[BUG] Axes reversed with FT_MOTION and INPUT_SHAPING_{X,Y} enabled

[sshockley]

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

Yes, and the problem still exists.

Bug Description

I have an Ender 3 Pro with a BTT SKR E3 v2.0. I wanted to toy with the new input shaping and fixed-time motion features.

Compiled Bugfix-2.1.x downloaded yesterday with both enabled, and flashed to my board. Tried to home, X axis crashed on right stop. Checked, all four axes were reversed.

Recompiled firmware with these lines commented out with no other changes:

#define FT_MOTION
#define INPUT_SHAPING_X
#define INPUT_SHAPING_Y

Flashed and tested and all four axes turn in the correct direction.

Configs.zip

Bug Timeline

New issue

Expected behavior

Auto Home from menu should move carriage left, move the bed back, then move to center and find the bed height with bltouch.

G0 X10 from Octoprint terminal should move carriage right

Actual behavior

Auto home moved carriage right until it crashed into the end and I powered off.

G0 X10 moved the carriage left.

Steps to Reproduce

Compile bugfix-2.1.x with attached configs

Version of Marlin Firmware

bugfix-2.1.x

Printer model

Creality Ender 3 Pro

Electronics

SKR E3 v2.0

Add-ons

bltouch

Bed Leveling

ABL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

OctoPrint

Don't forget to include

• [X] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

[thinkyhead]

Interesting… The new FT_MOTION feature has not been widely tested yet. It is generally disabled by default. It sounds like you didn't try INPUT_SHAPING_X/Y by itself, or FT_MOTION by itself to see which one was relevant. Can you do some more testing to see what's going on there, with M493 S0 versus M493 S1, etc.? It's certainly possible that the FT_MOTION implementation is not taking into account Marlin's ability to specify DIR states, or it is just getting them backward. So I will look into that first.

[sshockley]

You are correct, thanks. I'll try them individually and see how it behaves.

[RV-from-be]

Since the last commit, i tested Input Shaping without FT Motion and no issues.

[thinkyhead]

I have a patch to properly apply the INVERT_*_DIR settings to FT_MOTION. I'll do another pass to make sure other related settings are also being applied appropriately. I will merge that pretty soon.

[ahmetcemturan]

I can confirm that on a Robin Nano.
All works fine if FT is disabled. I have this problem on my X and Y drives (TMC2209) , Z had correct direction. Endstops function was inverted. Neither directions nor endstops fı-unctionality could be inverted from the configuration. (Havent tried inverting Z though as it was correct) Attached the working configs: Marlin.zip

[thinkyhead]

I merged the patch linked above so this issue should be solved.

[ahmetcemturan]

(((((It works fine on MKS SKR 3 Board but )))) <<<<< Incorrect statement.. misbehaves on Robin Nano: (on the MKS, FT Motion works way better than IS btw.)

Configuration_adv.zip

Various scenarios:

---

//#define FT_MOTION

define INPUT_SHAPING_X

define INPUT_SHAPING_Y

define INVERT_Z_DIR true

Z direction is as usual.. Works OK

---

define FT_MOTION

//#define INPUT_SHAPING_X //#define INPUT_SHAPING_Y

define INVERT_Z_DIR true

Z direction is inverted (TMC2208) Separate Homing of X ok Separate Homing of Y ok Full Homing Moves diagonally to origin and if it hits Y first it will stop homing and move to Z homing position (which does not work because wrong dir..) İf it hits X first it will also Home Y and then move to Z position

---

define FT_MOTION

//#define INPUT_SHAPING_X //#define INPUT_SHAPING_Y

define INVERT_Z_DIR false

Z direction is "correct" (TMC2208) Separate Homing of X ok Separate Homing of Y ok Full Homing Moves diagonally to origin and if it hits Y first it will stop homing and move to Z homing position (which does not work because wrong dir..) İf it hits X first it will also Home Y and then move to Z position

And Yes disabling Quick Home works.
I will try to print something and report back...

[ahmetcemturan]

That was not a good idea. Trying to determine the frequency I turned FT motion off via gcode.
After that apparantly Z went in the opposite direction, rammed the nozzle int th printbed, breaking the heatbreak and shorting the heater and thermistor, resulting in a fried board... :(

[thinkyhead]

Agh, I hate when that happens. This new code was written by academics to a specific piece of hardware and is bound to be rough. You have been brave to test it. What kind of board do you have? Let's see if we can get it repaired or help to get you a new one.

[thinkyhead]

It works fine on MKS SKR 3 Board but misbehaves on Robin Nano: (on the MKS, FT Motion works way better than IS btw.)

So, all directions and homing work perfectly on the SKR 3? That is interesting. It almost sounds like two different firmware versions. I will re-check to see that Z dir inverting is being correctly applied. I really thought I got all the axes in that patch.

I'm not sure why quick-homing behaves strangely, with Y hitting first preventing X from homing next. Is sensorless homing involved? We haven't messed with quick homing in a long time and it should be stable, so I wonder if there is a crossed signal.

[izzymoren0]

hi, i can just confirm that FT_MOTION causes problems.

ive just fetched the newest marlin with the FT_MOTION implementation (i used ZV shaper before) and enabled it for my SKR Mini v2 - now my Z is going in the wrong direction for homing (BLTouch Z-Safe Homing). Ive disabled ZV-Shaper and LA for that, to try only that new implementation.

after recompiling without FT_MOTION and using ZV_Shaper and LA again, all is fine as before.

[ahmetcemturan]

Yes the skr3 works ok.
The only problem I have is that when running repetier server the movement sometimes starts to get jerky. Same gcode on sd card works fine.

Well the board Inshorted was a Robin Nano 1.2 but I am in Turkey, so quite difficult for you to help me.

But pls pls pls have this FT motion working as soon as possible. It is definetly a game changer.. I couldn't believe my eyes on the results of the prusa clone...

[sshockley]

Just as an update, I think my SKR E3 v2.0 board is now broken as well, although mine wasn't from crashing. When I print from PrusaSlicer, after the bed and nozzle heat up and it tries to do an XYZ home (G28) the board reboots. If I disable USE_WATCHDOG the board just hangs.

I tried flashing an old 2.0.6 bin file from 2020 and it was similar; after heating one of the steppers makes a buzzing/ringing sound (848 hz according to my phone) and the printer doesn't move and says:

Homing failed
PRINTER HALTED
Please Reset

Oddly, if I trigger homing from the menu (any version) it works OK.

I don't want anyone to buy me a board or anything, although if you have ideas on how to fix it I'll give it a shot. I'm no stranger to blowing out boards, I've replaced the fan MOSFETs on this board and I blew out the USB port (and a Pi 2) on an SKR E3 v1.2.

Is it possible that something in FT_MOTION (or INPUT_SHAPING) does something my board didn't like? Does this sound like some other weakness in these boards and it's a coincidence?

Gcode that triggers this reset/error is below. Thanks!

M110 N0
M73 P0 R71
M73 Q0 S71
M201 X1000 Y1000 Z100 E5000
M203 X0 Y0 Z0 E0
M204 P500 R1000 T500
M205 X0.00 Y0.00 Z0.00 E0.00
M205 S0 T0
M107
G90
M83
M104 S240
M190 S70
G28

[sshockley]

Please ignore my previous comment, I must have have some configuration wrong somewhere. If I find which setting caused it I'll update. Back to testing!

[sshockley]

I can confirm that enabling FT_MOTION (no other changes) also causes the Z axis to move in the wrong direction when homing. I'll try flipping INVERT_Z_DIR to true and see if it works then.

Okay, flipping INVERT_Z_DIR makes Z go in the right direction, but after the bed/nozzle heats and it issues a G28 the printer doesn't do anything. It holds the temperature, the console is responsive, but it never homes.

Update: Okay, this was user error. Somehow in the printer profile in PrusaSlicer I had set all the acceleration to 0. So, the printer would home, it was just reeealy slow. I started a print and got sidetracked, and turned around and the carriage was in a different spot.

So I still haven't gotten FT_MOTION to actually print. I'll do some more testing and put that in a different message though.

Sorry for all the noise.

[thinkyhead]

now my Z is going in the wrong direction for homing

I'd like to have others check on this behavior. In the original code provided by Ulendo there's a difference with Z in that it has an opposite consideration of FT_BIT_DIR_Z compared to the other axes, and I haven't changed that. This difference might only be due to the way that Ulendo's test machines were set up. The relevant code is in stepper.cpp around line 3468:

    #if HAS_Z_AXIS
      // Z is handled differently to update the stepper
      // counts (needed by Marlin for bed level probing).
      const bool z_dir = !TEST(command, FT_BIT_DIR_Z),
                z_step = TEST(command, FT_BIT_STEP_Z);
    #endif

…which is followed by…

      TERN_(HAS_Z_AXIS, Z_DIR_WRITE(INVERT_DIR(Z, z_dir)));

…and then…

    #if HAS_Z_AXIS
      // Update step counts
      if (z_step) count_position.z += z_dir ? -1 : 1;
    #endif

If you see weird Z direction behavior, there are two things that we can try.

• Change the original reckoning of z_dir:

    const bool z_dir = TEST(command, FT_BIT_DIR_Z),
              z_step = TEST(command, FT_BIT_STEP_Z);

• OR, only change how that z_dir is being applied to the direction:

    TERN_(HAS_Z_AXIS, Z_DIR_WRITE(INVERT_DIR(Z, !z_dir)));

I suspect that they simply had a machine with its Z plug reversed, but I can ask them to look into it for confirmation.

As for that count_position.z update, I suspect that count_position should also be getting updated for all the other axes in fxdTiCtrl_stepper because various features depend on it, not to mention that the regular motion system depends on it, so that if you turn off Fixed-Time Motion with M493 S0 subsequent moves will work properly. To test whether I'm correct about that, you can do some short moves after M493 S1 and then some short moves after M493 S0 to see whether motion proceeds in the right direction.

I have to get down with testing and fixing up G34 tonight, but I will get into testing Fixed-Time motion and recent updates to stepper.cpp over the next few days. With any luck we can get Marlin 2.1.3 released just in time for RMRRF.

[PendulumPit]

Each time I tried the bugfix the Z direction was backwardswith the FTM enabled and worked fine with no FTM enabled in the firmware.

[ahmetcemturan]

increasing FTM_STEPPERCMD_BUFF_SIZE to 3000 (from 1000) produces this behaviour: If You try to home directly after bootup, homing directions are reversed. If You first move the axis and then home the homing direction is correct,
This is the SKR 3 board with bedslinger printer..

[ahmetcemturan]

I have applied this: TERN_(HAS_Z_AXIS, Z_DIR_WRITE(INVERT_DIR(Z, !z_dir))); now I can turn on and off FTM without z direction being reversed. (and I think what I said about it being correct on the skr 3 is wrong)

[ahmetcemturan]

Also now that I was able to test it directly:
The print becomes very slow when printing over USB (Printrun and Repetier). Same G-code with SD-Card M493 S1 - prints ok no bogging down. Same Gcode with M493 S0 -prints ok no bogging down. Same G-Code over USB with M493 S1 (even with Baudrate set to 1000000) - slows down Of course all above valid for small segments. I have tried to increase the buffers but seems to have any effect. Configuration_adv.zip

[narno2202]

Be indulgent, this is my first post . With the original code, on my machine with multi stepper Y (2 steppers) and Z (3 steppers), only one motor by axis rotate. The issue is fixed with the following code.

in stepper.cpp replace code with :

#if ENABLED(FT_MOTION)

  // Set stepper I/O for fixed time controller.
  void Stepper::fxdTiCtrl_stepper(const bool applyDir, const ft_command_t command) {

    USING_TIMED_PULSE();

    if (applyDir) {
      TERN_(HAS_X_AXIS, X_DIR_WRITE(INVERT_DIR(X, TEST(command, FT_BIT_DIR_X))));
      #if HAS_X2_ENABLE && DISABLED(DUAL_X_CARRIAGE)
        #if ENABLED(INVERT_X2_VS_X_DIR)
           X2_DIR_WRITE(INVERT_DIR(X, !TEST(command, FT_BIT_DIR_X)));
        #else
          X2_DIR_WRITE(INVERT_DIR(X, TEST(command, FT_BIT_DIR_X)));
        #endif
      #endif
      #if HAS_Y_AXIS
        Y_DIR_WRITE(INVERT_DIR(Y, TEST(command, FT_BIT_DIR_Y)));
        #if HAS_Y2_ENABLE
          #if ENABLED(INVERT_Y2_VS_Y_DIR)
           Y2_DIR_WRITE(INVERT_DIR(Y, !TEST(command, FT_BIT_DIR_Y)));
          #else
            Y2_DIR_WRITE(INVERT_DIR(Y, TEST(command, FT_BIT_DIR_Y)));
          #endif
        #endif
      #endif
      #if HAS_Z_AXIS
        Z_DIR_WRITE(INVERT_DIR(Z, TEST(command, FT_BIT_DIR_Z)));
        #if HAS_Z2_ENABLE
          #if ENABLED(NVERT_Z2_VS_Z_DIR)        
            Z2_DIR_WRITE(INVERT_DIR(Z, !TEST(command, FT_BIT_DIR_Z)));
          #else
            Z2_DIR_WRITE(INVERT_DIR(Z, TEST(command, FT_BIT_DIR_Z)));
          #endif
        #endif
        #if HAS_Z3_ENABLE
          #if ENABLED(INVERT_Z3_VS_Z_DIR)        
            Z3_DIR_WRITE(INVERT_DIR(Z, !TEST(command, FT_BIT_DIR_Z)));
          #else
            Z3_DIR_WRITE(INVERT_DIR(Z, TEST(command, FT_BIT_DIR_Z)));
          #endif
        #endif
         #if HAS_Z4_ENABLE
          #if ENABLED(INVERT_Z4_VS_Z_DIR)        
            Z4_DIR_WRITE(INVERT_DIR(Z, !TEST(command, FT_BIT_DIR_Z)));
          #else
            Z4_DIR_WRITE(INVERT_DIR(Z, TEST(command, FT_BIT_DIR_Z)));
          #endif
        #endif
      #endif
      TERN_(HAS_EXTRUDERS, E0_DIR_WRITE(INVERT_DIR(E0, TEST(command, FT_BIT_DIR_E))));
      DIR_WAIT_AFTER();
    }

    TERN_(HAS_X_AXIS, X_STEP_WRITE(TEST(command, FT_BIT_STEP_X)));
    #if HAS_X2_ENABLE && DISABLED(DUAL_X_CARRIAGE)
        X2_STEP_WRITE(TEST(command, FT_BIT_STEP_X));
    #endif
    #if HAS_Y_AXIS
      Y_STEP_WRITE(TEST(command, FT_BIT_STEP_Y));
      #if HAS_Y2_ENABLE
        Y2_STEP_WRITE(TEST(command, FT_BIT_STEP_Y));
      #endif
    #endif
    #if HAS_Z_AXIS
      Z_STEP_WRITE(TEST(command, FT_BIT_STEP_Z));
      #if HAS_Z2_ENABLE
        Z2_STEP_WRITE(TEST(command, FT_BIT_STEP_Z));
      #endif
      #if HAS_Z3_ENABLE
        Z3_STEP_WRITE(TEST(command, FT_BIT_STEP_Z));
      #endif
      #if HAS_Z4_ENABLE
        Z4_STEP_WRITE(TEST(command, FT_BIT_STEP_Z));
      #endif
    #endif
    TERN_(HAS_EXTRUDERS, E0_STEP_WRITE(TEST(command, FT_BIT_STEP_E)));

    START_TIMED_PULSE();

    #if HAS_Z_AXIS
      // Update step counts
      if (TEST(command, FT_BIT_STEP_Z)) count_position.z += TEST(command, FT_BIT_DIR_Z) ? -1 : 1;
    #endif

    AWAIT_HIGH_PULSE();

    X_STEP_WRITE(0);
    #if HAS_X2_ENABLE && DISABLED(DUAL_X_CARRIAGE)
        X2_STEP_WRITE(0);
    #endif
    #if HAS_Y_AXIS
      Y_STEP_WRITE(0);
      #if HAS_Y2_ENABLE
        Y2_STEP_WRITE(0);
      #endif
    #endif
    #if HAS_Z_AXIS
      Z_STEP_WRITE(0);
      #if HAS_Z2_ENABLE
        Z2_STEP_WRITE(0);
      #endif
      #if HAS_Z3_ENABLE
        Z3_STEP_WRITE(0);
      #endif
      #if HAS_Z4_ENABLE
        Z4_STEP_WRITE(0);
      #endif
    #endif
    TERN_(HAS_EXTRUDERS, E0_STEP_WRITE(0));

  } // Stepper::fxdTiCtrl_stepper

Fixes the motion bug with multi stepper axis but sensorless homing and Z homing with BLTouch don't work.

[narno2202]

To get sensorless homing and Z homing with BLTouch, i disable FT_MOTION during homing and voilà.

in motion.cpp add after #include "../inc/MarlinConfig.h"

#if ENABLED(FT_MOTION)
  #include "ft_motion.h"
#endif

then in void homeaxis(const AxisEnum axis) add after

#define _ANDCANT(N) && !_CAN_HOME(N)
      if (true MAIN_AXIS_MAP(_ANDCANT)) return;
    #endif

this piece of code

//Disable FT_MOTION mode if FT_MOTION is enabled
    #if ENABLED(FT_MOTION)
      fxdTiCtrl.cfg_mode = ftMotionMode_DISABLED;
    #endif

and at last after

// Clear retracted status if homing the Z axis
    #if ENABLED(FWRETRACT)
      if (axis == Z_AXIS) fwretract.current_hop = 0.0;
    #endif

add

//Restore FT_MOTION mode if FT_MOTION is enabled
    #if ENABLED(FT_MOTION)
      fxdTiCtrl.cfg_mode = FTM_DEFAULT_MODE;
    #endif

Now sensorless homing works fine and Z homing with BLTouch too

[narno2202]

At Last, to get bed levelling working with BLTouch, in gcode.cpp change G29 and G30 :

if HAS_LEVELING
        case 29:
          //Disable FT_MOTION mode if FT_MOTION is enabled
          #if ENABLED(FT_MOTION)
            fxdTiCtrl.cfg_mode = ftMotionMode_DISABLED;
          #endif                                              // G29: Bed leveling calibration
          TERN(G29_RETRY_AND_RECOVER, G29_with_retry, G29)();
          #if ENABLED(FT_MOTION)
            fxdTiCtrl.cfg_mode = FTM_DEFAULT_MODE;
          #endif
          break;
      #endif

      #if HAS_BED_PROBE
        case 30: 
          //Disable FT_MOTION mode if FT_MOTION is enabled
          #if ENABLED(FT_MOTION)
            fxdTiCtrl.cfg_mode = ftMotionMode_DISABLED;
          #endif   
          G30();
          #if ENABLED(FT_MOTION)#
            fxdTiCtrl.cfg_mode = FTM_DEFAULT_MODE;
          #endif
          break;                                    // G30: Single Z probe

Didn't test G31, G32 and G33 Should do the trick for G34

#if ANY(Z_MULTI_ENDSTOPS, Z_STEPPER_AUTO_ALIGN, MECHANICAL_GANTRY_CALIBRATION)
        case 34: 
        //Disable FT_MOTION mode if FT_MOTION is enabled
          #if ENABLED(FT_MOTION)
            fxdTiCtrl.cfg_mode = ftMotionMode_DISABLED;
          #endif   
          G34();
          #if ENABLED(FT_MOTION)
            fxdTiCtrl.cfg_mode = FTM_DEFAULT_MODE;
          #endif
          break;                                    // G34: Z Stepper automatic alignment using probe
      #endif

[SpannMagoo]

Agh, I hate when that happens. This new code was written by academics to a specific piece of hardware and is bound to be rough. You have been brave to test it. What kind of board do you have? Let's see if we can get it repaired or help to get you a new one.

This should come out of Marlin tbh. FTM is not ready to even be in a bugfix.

[ahmetcemturan]

This should come out of Marlin tbh. FTM is not ready to even be in a bugfix.

Noooo. When you get it working (even partly) it's a dream.

[RV-from-be]

Despite the proposed fix which allows to have the correct direction of the Z axis. It does not solve another problem. If the FT Motion is activated, we see that current_position.z in planner is not correct. Let's take an example. Home Z is done. Position 0 is therefore known. If I raise the Z axis by 10mm, during this movement, current position z displays 0 to -10mm. Once the value is reached, the displayed position is indeed 10mm. This has an unfortunate consequence. Printing is then impossible, especially if the Home is made with a probe. Whereas if FT motion is deactivated (still applying the proposed fix), everything returns to normal! moreover I noticed different operations according to the models of motherboards. I fear that it is almost impossible to have a correct operation regardless of the card fitted to the printer.

EDIT : I fixed this behaviour by: I replace in stepper.cpp:

    #if HAS_Z_AXIS
      // Update step counts
      if (TEST(command, FT_BIT_STEP_Z)) count_position.z += TEST(command, FT_BIT_DIR_Z) ? -1 : 1;
    #endif

by:

    #if HAS_Z_AXIS
      // Update step counts
      if (TEST(command, FT_BIT_STEP_Z)) count_position.z += (!TEST(command, FT_BIT_DIR_Z)) ? -1 : 1;
    #endif

and in all the:

          #if ENABLED(FT_MOTION)
            fxdTiCtrl.cfg_mode = FTM_DEFAULT_MODE;
          #endif

by:

         #if ENABLED(FT_MOTION)
           fxdTiCtrl.cfg_mode = FTM_DEFAULT_MODE;
           if (WITHIN(fxdTiCtrl.cfg_mode, 10U, 19U)) {
             fxdTiCtrl.updateShapingN(fxdTiCtrl.cfg_baseFreq[0] OPTARG(HAS_Y_AXIS, fxdTiCtrl.cfg_baseFreq[1]));
             fxdTiCtrl.updateShapingA();
           }
           fxdTiCtrl.reset();
         #endif

all working fine now !

[narno2202]

With the previous fix all was fine on my machine ((MKS Monster8, 1 X stepper, 2 Y steppers, 3 Z steppers and BLTouch, sensorless homing). I test the new code and all is still fine : motion, sensorless homming, Z homing, bed levelling and printing. great Job :)

[cbagwell]

I updated to latest bugfix-2.1.x and tested FT_MOTION for the first time on Ender 3 Pro with SKR Mini E3 V3 and CR-Touch. It happened to be a couple hours after a submission that removed an inversion of Z axis in FT_MOTION. So my experience is likely different than thread to date.

I tested all axis before homing and they all went correct direction. I then homed and it worked fine as well. So far so good. I then ran G29 and although it moved find to 1st position to probe and lowered correctly and stopped at roughly 0, I got a probe failure. I have it setup to probe 2 times btw and it never attempted the 2nd probe.

I enabled probe debug and if I reading it correctly it looks like after it correctly probed to zero somehow it thought Z jumped to 22 or though it need to move to 22 and ~12 is the max it should ever move to based on my configs.

log output:

```prolog Send: G29 V4 Recv: >>> G29 X145.0000 Y156.5000 Z12.3600 Recv: Machine Type: Cartesian Recv: Probe: BLTOUCH Recv: Probe Offset X-32.0000 Y-41.5000 Z-2.3600 (Left-Front & Below Nozzle) Recv: Auto Bed Leveling: BILINEAR (disabled) Recv: Recv: G29 Auto Bed Leveling Recv: remember_feedrate_scaling_off: fr=25.0000 100% Recv: Preheating hotend (120) and bed (60) [...] Recv: //action:notification Ender-3 Sprite Pro SKR Mini E3 V3 BLTouch Ready. Recv: Wait for bed heating... Recv: //action:notification Bed Heating... [...] Recv: //action:notification Ender-3 Sprite Pro SKR Mini E3 V3 BLTouch Ready. Recv: //action:notification Ender-3 Sprite Pro SKR Mini E3 V3 BLTouch Ready. Recv: >>> set_bed_leveling_enabled X145.0000 Y156.5000 Z12.3600 Recv: <<< set_bed_leveling_enabled X145.0000 Y156.5000 Z12.3600 Recv: do_z_clearance(10.0000 [12.3600 to 12.3600], 0) Recv: reset_bed_level Recv: >>> set_bed_leveling_enabled X145.0000 Y156.5000 Z12.3600 Recv: <<< set_bed_leveling_enabled X145.0000 Y156.5000 Z12.3600 Recv: Probing mesh point 1/25. Recv: //action:notification Probing Point 1/25 Recv: >>> Probe::probe_at_point X145.0000 Y156.5000 Z12.3600 Recv: ...(5.0000, 5.0000, raise, 4, probe_relative) Recv: current_position= X145.0000 Y156.5000 Z12.3600 : Recv: Move to probe-relative point Recv: >>> do_blocking_move_to X145.0000 Y156.5000 Z12.3600 Recv: > X37.0000 Y46.5000 Z12.3600 [...] Recv: <<< do_blocking_move_to X37.0000 Y46.5000 Z12.3600 Recv: current_position= X37.0000 Y46.5000 Z12.3600 : Probe::set_deployed Recv: deploy=1 no_return=0 Recv: Raise Z to 10.0000 Recv: do_z_clearance(10.0000 [12.3600 to 12.3600], 0) Recv: >>> Probe::probe_specific_action X37.0000 Y46.5000 Z12.3600 Recv: BLTouch DEPLOY requested Recv: BLTouch from 90 to 10 Recv: BLTouch from 10 to 60 Recv: bltouch.deploy_proc() end Recv: <<< Probe::probe_specific_action X37.0000 Y46.5000 Z12.3600 Recv: >>> do_blocking_move_to X37.0000 Y46.5000 Z12.3600 Recv: > X37.0000 Y46.5000 Z12.3600 Recv: <<< do_blocking_move_to X37.0000 Y46.5000 Z12.3600 Recv: >>> Probe::run_z_probe X37.0000 Y46.5000 Z12.3600 Recv: Probe Low Point: 0.3600 Recv: FAST> try_to_probe(..., 0.3600, 10.0000, ...) Recv: >>> Probe::probe_down_to_z X37.0000 Y46.5000 Z12.3600 Recv: do_blocking_move_to_z(0.3600, 10.0000) Recv: >>> do_blocking_move_to X37.0000 Y46.5000 Z12.3600 Recv: > X37.0000 Y46.5000 Z0.3600 [...] Recv: <<< do_blocking_move_to X37.0000 Y46.5000 Z0.3600 Recv: current_position= X37.0000 Y46.5000 Z22.5050 : sync_plan_position Recv: <<< Probe::probe_down_to_z X37.0000 Y46.5000 Z22.5050 Recv: Probe fail! - Triggered early (above 4.3600mm) Recv: <<< Probe::run_z_probe X37.0000 Y46.5000 Z22.5050 Recv: current_position= X37.0000 Y46.5000 Z22.5050 : Probe::set_deployed Recv: deploy=0 no_return=0 Recv: Raise Z to 10.0000 Recv: do_z_clearance(10.0000 [22.5050 to 12.3600], 0) Recv: >>> Probe::probe_specific_action X37.0000 Y46.5000 Z22.5050 Recv: BLTouch STOW requested Recv: BLTouch from 60 to 90 Recv: bltouch.stow_proc() end Recv: <<< Probe::probe_specific_action X37.0000 Y46.5000 Z22.5050 Recv: >>> do_blocking_move_to X37.0000 Y46.5000 Z22.5050 Recv: > X37.0000 Y46.5000 Z22.5050 Recv: <<< do_blocking_move_to X37.0000 Y46.5000 Z22.5050 Recv: //action:notification Probing Failed Recv: Error:Probing Failed ```

[cbagwell]

I tried reverting the recent commit that took off the NOT from !z_dir and all that did was cause my Z direction to be inverted and I could no longer home. @RV-from-be you had some additional fixes but I couldn't find where that code would go in recent bugfix-2.1.x branch. Would I still need to apply it somewhere?

For now I decided to ignore the probing failure and move to testing prints. I did this by editing the gcode from Cura to turn off FT_MOTION right before print and enable right after the G29 command. When I print I notice my steppers are noisy like spreadcycle is disabled. Also, the prints seem to have some kind of Z issue around the middle of cube (print is about 3mm to short) and sometimes under extrusion issues.

Here is the same gcode file printed 3 times. From left to right: FT_MOTION with linear advance enabled, FT_MOTION with linear advanced disabled, and FT_MOTION disabled and using INPUT_SHAPING.

[thinkyhead]

EDIT : I fixed this behaviour by:

Thanks for pointing out your fixes @RV-from-be. It's been a long week with other priorities, but I will be getting back to #25719 over the next few days.

I see that the DIR bits for FT Motion are the opposite of the historical Marlin standard:

• FTMotion: 0 = Reverse (LOW), 1 = Forward (HIGH)
• Marlin: 1 = Reverse (LOW), 0 = Forward (HIGH)

Of course, the LOW/HIGH states are the default for non-inverted axes.

It seems to me that the FTMotion standard is better, as the state could be directly applied on non-inverted axes. But anyway, I'll keep that in mind as I continue work on that PR. In the meantime, we could push your patches as an interim solution, along with a sanity check to ensure that FT Motion is only enabled on machines with 3 single-stepper axes and a single extruder.

[narno2202]

With the last bugfix-2.1.x code 53d06be, after bypassing the sanity check for a multistepper axis printer, there is a built failure : in class FxdTiCtrl static void init(); must be declared public to fix it. After applying the previous fix in stepper.c and in motion.c, all the axis motions are OK, sensorless homing works fine, there is no need to patch gcode.c for bed leveling. Monster8 V1.0 board, 1 X axis stepper, 2 Y axis steppers, 3 Z axis steppers, BL Touch, INPUT_SHAPING enabled, FT_MOTION enabled

[cbagwell]

I'm had same results as @narno2202 after upgrading again. Need to make init() public to compile but afterwards probing is now working with FT_MOTION. I did get a reboot in middle of my first probe attempt but 2nd attempt worked and I could complete a print.

Quality wise, the print still looks same as my above picture. Bottom layer looks good and everything looks good until about 8mm into 20mm calicube. I then get extrusion issues and the cube is squished for about 3 mm. My ABL fade height is set for 10mm and is only thing I can think of that might trigger this issue.

[narno2202]

I made some changes in the previous patch to make use of APPLY_DIR and APPLY_STEP in stepper.cpp. I hope behavior is the same and allows for other people multistepper axis and sensorless homing. Perhpas this code could be useful in future FT_MOTION PR.

Suggested Changes

First modify `SanityCheck.h` : ```cpp /** * Fixed-Time Motion limitations */ #if ENABLED(FT_MOTION) && (NUM_AXES > 3 || E_STEPPERS > 1 || ANY(DUAL_X_CARRIAGE, HAS_MULTI_EXTRUDER, MIXING_EXTRUDER)) #error "FT_MOTION is currently limited to machines with 3 linear axes and a single extruder." #endif ``` In `stepper.cpp` replace ```cpp #if HAS_DUAL_X_STEPPERS ... #elif HAS_Z_AXIS #define Z_APPLY_DIR(v,Q) Z_DIR_WRITE(v) #define Z_APPLY_STEP(v,Q) Z_STEP_WRITE(v) #endif ``` by ```cpp #if HAS_DUAL_X_STEPPERS #define X_APPLY_DIR(v,Q) do{ X_DIR_WRITE(v); TERN(INVERT_X2_VS_X_DIR, X2_DIR_WRITE(INVERT_DIR(X, !v)), X2_DIR_WRITE(INVERT_DIR(X, v))); }while(0) #if ENABLED(X_DUAL_ENDSTOPS) #define X_APPLY_STEP(v,Q) DUAL_ENDSTOP_APPLY_STEP(X,v) #else #define X_APPLY_STEP(v,Q) do{ X_STEP_WRITE(v); X2_STEP_WRITE(v); }while(0) #endif #elif ENABLED(DUAL_X_CARRIAGE) #define X_APPLY_DIR(v,ALWAYS) do{ \ if (extruder_duplication_enabled || ALWAYS) { X_DIR_WRITE(v); X2_DIR_WRITE((v) ^ idex_mirrored_mode); } \ else if (last_moved_extruder) X2_DIR_WRITE(v); else X_DIR_WRITE(v); \ }while(0) #define X_APPLY_STEP(v,ALWAYS) do{ \ if (extruder_duplication_enabled || ALWAYS) { X_STEP_WRITE(v); X2_STEP_WRITE(v); } \ else if (last_moved_extruder) X2_STEP_WRITE(v); else X_STEP_WRITE(v); \ }while(0) #else #define X_APPLY_DIR(v,Q) X_DIR_WRITE(v) #define X_APPLY_STEP(v,Q) X_STEP_WRITE(v) #endif #if HAS_DUAL_Y_STEPPERS #define Y_APPLY_DIR(v,Q) do{ Y_DIR_WRITE(v); TERN(INVERT_Y2_VS_Y_DIR, Y2_DIR_WRITE(INVERT_DIR(Y, !v)), Y2_DIR_WRITE(INVERT_DIR(Y, v))); }while(0) #if ENABLED(Y_DUAL_ENDSTOPS) #define Y_APPLY_STEP(v,Q) DUAL_ENDSTOP_APPLY_STEP(Y,v) #else #define Y_APPLY_STEP(v,Q) do{ Y_STEP_WRITE(v); Y2_STEP_WRITE(v); }while(0) #endif #elif HAS_Y_AXIS #define Y_APPLY_DIR(v,Q) Y_DIR_WRITE(v) #define Y_APPLY_STEP(v,Q) Y_STEP_WRITE(v) #endif #if NUM_Z_STEPPERS == 4 #define Z_APPLY_DIR(v,Q) do{ Z_DIR_WRITE(v); TERN(INVERT_Z2_VS_Z_DIR, Z2_DIR_WRITE(INVERT_DIR(Z, !v)), Z2_DIR_WRITE(INVERT_DIR(Z, v))); \ TERN(INVERT_Z3_VS_Z_DIR, Z3_DIR_WRITE(INVERT_DIR(Z, !v)), Z3_DIR_WRITE(INVERT_DIR(Z, v))); \ TERN(INVERT_Z4_VS_Z_DIR, Z4_DIR_WRITE(INVERT_DIR(Z, !v)), Z4_DIR_WRITE(INVERT_DIR(Z, v))); }while(0) #if ENABLED(Z_MULTI_ENDSTOPS) #define Z_APPLY_STEP(v,Q) QUAD_ENDSTOP_APPLY_STEP(Z,v) #elif ENABLED(Z_STEPPER_AUTO_ALIGN) #define Z_APPLY_STEP(v,Q) QUAD_SEPARATE_APPLY_STEP(Z,v) #else #define Z_APPLY_STEP(v,Q) do{ Z_STEP_WRITE(v); Z2_STEP_WRITE(v); Z3_STEP_WRITE(v); Z4_STEP_WRITE(v); }while(0) #endif #elif NUM_Z_STEPPERS == 3 #define Z_APPLY_DIR(v,Q) do{ Z_DIR_WRITE(v); TERN(INVERT_Z2_VS_Z_DIR, Z2_DIR_WRITE(INVERT_DIR(Z, !v)), Z2_DIR_WRITE(INVERT_DIR(Z, v))); \ TERN(INVERT_Z3_VS_Z_DIR, Z3_DIR_WRITE(INVERT_DIR(Z, !v)), Z3_DIR_WRITE(INVERT_DIR(Z, v))); }while(0) #if ENABLED(Z_MULTI_ENDSTOPS) #define Z_APPLY_STEP(v,Q) TRIPLE_ENDSTOP_APPLY_STEP(Z,v) #elif ENABLED(Z_STEPPER_AUTO_ALIGN) #define Z_APPLY_STEP(v,Q) TRIPLE_SEPARATE_APPLY_STEP(Z,v) #else #define Z_APPLY_STEP(v,Q) do{ Z_STEP_WRITE(v); Z2_STEP_WRITE(v); Z3_STEP_WRITE(v); }while(0) #endif #elif NUM_Z_STEPPERS == 2 #define Z_APPLY_DIR(v,Q) do{ Z_DIR_WRITE(v); TERN(INVERT_Z2_VS_Z_DIR, Z2_DIR_WRITE(INVERT_DIR(Z, !v)), Z2_DIR_WRITE(INVERT_DIR(Z, v))); }while(0) #if ENABLED(Z_MULTI_ENDSTOPS) #define Z_APPLY_STEP(v,Q) DUAL_ENDSTOP_APPLY_STEP(Z,v) #elif ENABLED(Z_STEPPER_AUTO_ALIGN) #define Z_APPLY_STEP(v,Q) DUAL_SEPARATE_APPLY_STEP(Z,v) #else #define Z_APPLY_STEP(v,Q) do{ Z_STEP_WRITE(v); Z2_STEP_WRITE(v); }while(0) #endif #elif HAS_Z_AXIS #define Z_APPLY_DIR(v,Q) Z_DIR_WRITE(v) #define Z_APPLY_STEP(v,Q) Z_STEP_WRITE(v) #endif ``` then replace the code in `void Stepper::fxdTiCtrl_stepper(const bool applyDir, const ft_command_t command)` by ```cpp void Stepper::fxdTiCtrl_stepper(const bool applyDir, const ft_command_t command) { USING_TIMED_PULSE(); if (applyDir) { X_APPLY_DIR(INVERT_DIR(X, TEST(command, FT_BIT_DIR_X)), false); Y_APPLY_DIR(INVERT_DIR(Y, TEST(command, FT_BIT_DIR_Y)), false); Z_APPLY_DIR(INVERT_DIR(Z, TEST(command, FT_BIT_DIR_Z)), false); E0_APPLY_DIR(INVERT_DIR(E0, TEST(command, FT_BIT_DIR_E))); DIR_WAIT_AFTER(); } X_APPLY_STEP(TEST(command, FT_BIT_STEP_X), false); Y_APPLY_STEP(TEST(command, FT_BIT_STEP_Y), false); Z_APPLY_STEP((TEST(command, FT_BIT_STEP_Z)), false); E0_STEP_WRITE(TEST(command, FT_BIT_STEP_E)); START_TIMED_PULSE(); if (TEST(command, FT_BIT_STEP_Z)) count_position.z += TEST(command, FT_BIT_DIR_Z) ? 1 : -1; AWAIT_HIGH_PULSE(); X_APPLY_STEP(0, false); Y_APPLY_STEP(0, false); Z_APPLY_STEP(0, false); E0_STEP_WRITE(0); } // Stepper::fxdTiCtrl_stepper ```

The changes needed in motion.cpp are the same as in the previous fix

[cbagwell]

Ignore my comment about rebooting while probing as it seems not related to FT_MOTION. Something about 2023/05/06 upgrade is causing my machine to reboot occasionally even without FT_MOTION. Reverting to 2023/04/30 resolves that issue.

[thinkyhead]

I then get extrusion issues and the cube is squished for about 3 mm

@cbagwell — We'll have to review the FT_MOTION code to see how it interacts with the leveling system. Do you find that it works perfectly well with leveling disabled? Or with the fade turned off?

In relation to my comment above one of the things I am doing is to make the direction bits agree between FT Motion and the standard Planner. I have applied this change as part of

[thinkyhead]

I made some changes in the previous patch to make use of APPLY_DIR and APPLY_STEP in stepper.cpp.

These changes are already a part of #25719 — which is also reversing the meaning of FT Motion DIR flags, extending the functionality to axes IJKUVW, and making other adjustments to generalize the feature.

[cbagwell]

@thinkyhead Disabling ABL definitely improved the quality of the print and the dimensional accuracy of cube's Z is much closer to correct so that is at least part of the issue. I still get an unexpected glitch around 8mm but now at least the quality soon recovers.

Here is updated picture. Left is FT_MOTION with ABL and is ~3 to short, middle is FT_MOTION with ABL disabled and less than 1mm to short, right is input shaping. Sorry I changed to a hard to see filament. It looks a bit better in person except there is bit of under extrusion going on.

[thinkyhead]

Gradual changes are being applied in PR #25791 to reconcile the DIR bits and use axis indirection, similar to the changes suggested above by @narno2202. Seems like it will be a good step before committing to the larger PR #25719 that refactors FT_MOTION in a much bigger way.

Since this issue is resolved, we can continue discussion on those two other PRs.

[thinkyhead]

@cbagwell — You should give the original Ulendo code a try too, just to see how badly we've broken things in our integration efforts. Their branch is based on Marlin 2.1.1. Note that it only deals with a Cartesian that they used for testing, so you may have to tweak some things to get all the axes moving in the correct directions (or not). Their original branch is at https://github.com/S2AUlendo/MarlinCollaborative

[cbagwell]

@thinkyhead I just now tried the S2AUlendo repo with great success on my Ender 3 Pro with SKR Mini E3 V3. I used a stock config for that combo and no code modifications needs except figuring out the missing FTM #defines in config files. Things went so much like my normal prints that I thought I must have done something wrong but I confirmed it was responding with "ok" to my M950 (which their branch uses to enable).

In this test, my steppers sounded exactly like original Marlin so whatever is making my X/Y/Z so noisy with FT_MOTION on bugfix-2.1.x is likely also the cause of quality issues. I also wonder if jerk is not working because my Z layer changes seem very shaky.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.