[BUG] FT_MOTION Homing and Moving Axes

[benjaminshewan]

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

Yes, and the problem still exists.

Bug Description

FT_MOTION on a CoreXY printer with A and B motors, and 4 Z-Steppers. When FT_MOTION is enabled (time-based motion) the printer will not home. The print head will hit the x-axis limit switch and keep moving in the x-direction while moving to home the y axis. The y-axis does the same thing, crashing into the y-limit switch. The printer will not home the z-axis using the safe z-home coordinates.

Selecting other input shaping modes cause motors to freeze - no motion occurs in X or Y axes.

Bug Timeline

Dec. 18, 2023 to Jan. 14, 2024

Expected behavior

x-axis homes, y-axis homes, z-axis homes

Actual behavior

X and y axis crash into limit switches, z axis prevented from safe homing

Steps to Reproduce

1. Start Printer
2. Enable FT_Motion Shaping - Fixed-Time Motion Mode set to "ON" from MOTION menu
3. Select "Auto-Home" from motion menu

Version of Marlin Firmware

Bugfix-2.1.x

Printer model

Corexy, Voron

Electronics

BTT Octopus V1.1

LCD/Controller

FYSETC_MINI_12864_2_1

Other add-ons

No response

Bed Leveling

UBL Bilinear mesh

Your Slicer

Cura

Host Software

None

Don't forget to include

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

Additional information & file uploads

Shewan-1-14-24.zip

[benjaminshewan]

@ahmetcemturan I have read through your open issue requests. I appreciate you posting your notes because it looks like you are also running a CoreXY printer. I would be curious if you have you found a build that works well with FT_Motion?

[narno2202]

@benjaminshewan , increase FTM_STEPPERCMD_BUFF_SIZE to 10 000 (like in our initial test), if it's ok, then you can try to find the lowest values that give you the best results (not mandatory as you have enough RAM). If not , increase FTM_STEPPER_FS and FTM_STEPPERCMD_BUFF_SIZE .

[benjaminshewan]

Thank you @narno2202 for the swift reply. I tried out an FTM_STEPPERCMD_BUFF_SIZE of 10 000 with an FTM_STEPPER_FS of 40000. This did not work.
Then I tried an FTM_STEPPERCMD_BUFF_SIZE of 20 000 and an FTM_STEPPER_FS of 60 000. With this configuration I was able to move the axes with FTM enabled, but homing does not work. I tried other shaping modes for movement, but they do not work.
I will have more time in one week to try more values for these variables - used ram is sitting at 37% so I have some room to play.

[ahmetcemturan]

@ahmetcemturan I have read through your open issue requests. I appreciate you posting your notes because it looks like you are also running a CoreXY printer. I would be curious if you have you found a build that works well with FT_Motion?

Actually it is mentioned in one of the recent closed ones about homing. It is the one from November 30 I think..

[ahmetcemturan]

#26592 (comment)

[ahmetcemturan]

Note that adjusting the A and B values via Gcode does not work when S1 but works when S10. You can then switch back to S1 and the set values remain, without error.

[narno2202]

@ahmetcemturan , to set shaping frequencies , you need a valid shaping mode : S10 to S17.

Regarding the homing issue, @danbrianwhite has a coreXY and FT_MOTION works. We all have TMC2209 and STM32 motherboards, the only difference is the MCU. I think that the problem comes from some timing issues. Try increasing MINIMUM_STEPPER_POST_DIR_DELAY to 100 in Conditionals_adv.h (TMC family datasheet).

[benjaminshewan]

@ahmetcemturan Thank you for linking the post, I must have missed it along the way. I appreciate the heads up about selecting a shaping mode before changing A and B.

@narno2202 I will try this update and post my results when complete.

[benjaminshewan]

@narno2202 I made the recommended updates to the firmware. I can now move the X and Y axes using any shaping mode!! Sadly, homing is still not functional.

default FTM shaping mode S10
MINIMUM_STEPPER_POST_DIR_DELAY is set to 100 (tested 200 with same homing results)
FTM_STEPPERCMD_BUFF_SIZE tested at 20 000 and 30 000
FTM_STEPPER_FS tested at 60 000 and 80 000

When I disable FTM the limit switches trigger when homing the printer.

When FTM is enabled the x and y limit switches can be triggered and tested with m119. During homing the limit switches seem like they are ignored. I tried manually triggering the x limit switch and motion does not stop.

I am not experienced enough with Marlin to understand how a timing could prevent the limit switch from triggering when homing. Are there other timing settings for the tmc2209 drivers I can adjust that may alleviate this issue? If not, would a work around be to disable shaping when homing in my start gcode, and then enable it again before printing?

[ahmetcemturan]

Not directly related but: Do you use Linear Advance of the FT Motion?If yes, what is your K?

[narno2202]

@benjaminshewan , good news for moving axes. You could also uncomment #define EDGE_STEPPING in Configuration_adv.h. I try to add CoreXY logic from standard motion in void Stepper::ftMotion_stepper(). You could test the changes : https://github.com/narno2202/Marlin/tree/FT_MOTION_CoreXY

[ahmetcemturan]

Marlin.zip
Not homing when S10. But its different than the main branch: It sounds as if the step rate is too high and fully skipping steps.

[narno2202]

@ahmetcemturan , thank's for feedback. I remove this part of code. Looking in previous code, I realize that there is perhaps a missing axis_did_move.reset() in void Stepper::ftMotion_blockQueueUpdate(). The repo has been updated.

[ahmetcemturan]

It displays the same behaviour as previous.
Axes move
Homing: if x is triggered first moves towards Y endstop but ignores it then..

[narno2202]

@ahmetcemturan , @benjaminshewan , I disable FT_MOTION in G28 : homing when the printer is a Core...
It was the case in the past for sensorles homing. Please give feedback.

[ahmetcemturan]

Disabling FT works. I am using regular endstops.
Note that my printer Sapphire uses y max as endstop for homing.

[narno2202]

I look again the old code and I find another issue for homing. I test the updated repo in the Simulator, homing and motion are fine for standard printer, homing and printing seem also fine for CoreXY (simulator not designed for, but it helps).

[benjaminshewan]

@narno2202 Disabling FT_Motion in G28 works. I was able to find values for A and B, and I am running some preliminary calibration prints using ZV and ZVD. If there is no further testing needed, I think we can close this bug request.

@ahmetcemturan I found that the linear advance value I was using before FT_Motion was too large. I have settled on K=0.000006. I know it seems too small to make a difference, but based on your post two weeks ago I am testing very small decimal values and it is working. With m900 shaping I was using a value between 0.1 and 0.02.

[ahmetcemturan]

Hi Benjamin,
Thanks for the confirmation of the small value of K. I started to doubt myself.

Question: disbling FT in G28 you mean using the latest commit from narno2202? Or just changing start Gcode?

[narno2202]

@benjaminshewan , @ahmetcemturan , have you tested the last commit?

[ahmetcemturan]

Yes, not workşng for me. Actually commented on the commit page

[Weresk]

I have exactly the same error as the author, but on Ender 3 printer...

[narno2202]

@Weresk , what is your config? On my side , I can't confirm homing failure with a XYZE printer.

[Weresk]

@Weresk , what is your config? On my side , I can't confirm homing failure with a XYZE printer.

Configuration_adv.zip

[Weresk]

@narno2202 If I set M400 before M493 S17 D0 P1 K0 printing starts.

[benjaminshewan]

@ahmetcemturan I have not tested the new commit. I disabled FT_Motion in G28. This seems like a work around for now. I do plan on testing Narno2202's commit when I get some time this week.

@narno2202 I have not had a chance to test the new commit, but I plan to this week. I should have time this Friday evening at the latest. I will let you know my results.

[narno2202]

@Weresk, just for testing, in a Terminal : M493 S1 (FT_MOTION enabled without shaping, don't enable linear advance if K factor is 0 -> useless). After that what are the results of single axe homing and individual axe motion?

[narno2202]

I reviewed most of the past code and found no obvious reason for homing failure with a core printer.
I belive that the error arises fromendstops.update()when stepper.motor_direction() is called. The value returned seems to be not valid for a Core printer as last_direction_bits is not set correctly for this kind of printer in ftMotion_stepper().
@thinkyhead , I need your confirmation.

[thinkyhead]

@narno2202 — For Core kinematics we have extra flags in the AxisBits type (hx, hy, hz) which should be used for tracking the axis directions separately from the stepper directions.

[benjaminshewan]

@narno2202 I tried your build and homing does work! The only issue I have had with disabling FT_MOTION in G28 is at the end of my prints.

The printer gets to the last few commands and stops. By adding an M400 command the printer finishes the commands, but it does not home. I have tried tweaking my "End Gcode" commands without any improvement. I was wondering if anyone else has seen this issue?

[ahmetcemturan]

You are disabling FT Motion via G-Code... İs that correct?

…

On Sat, 27 Jan 2024, 07:02 Benjamin Shewan, ***@***.***> wrote: @narno2202 <https://github.com/narno2202> I tried your build and homing does work! The only issue I have had with disabling FT_MOTION in G28 is at the end of my prints. The printer gets to the last few commands and stops. By adding an M400 command the printer finishes the commands, but it does not home. I have tried tweaking my "End Gcode" commands without any improvement. I was wondering if anyone else has seen this issue? — Reply to this email directly, view it on GitHub <#26683 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFWG4RZLKLRCCOTTSLPNWTYQR34FAVCNFSM6AAAAABB2LA5NKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJSHE3DONBXGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[narno2202]

@ahmetcemturan , @benjaminshewan , could you please test this file. Just replace stepper.cpp in Marlin bugfix with the provided file.
stepper.zip

[ahmetcemturan]

M493 S10 A48.00 B48.00 D0 F0.00 H0.00 P1 K0.00
Homing Worked fine with the stepper.zip
Not printed anything yet...

[narno2202]

Great, thank you.

[Weresk]

@Weresk, just for testing, in a Terminal : M493 S1 (FT_MOTION enabled without shaping, don't enable linear advance if K factor is 0 -> useless). After that what are the results of single axe homing and individual axe motion?

Yes the same thing: doesn't see limit switches

[benjaminshewan]

@ahmetcemturan I WAS disabling FT_MOTION via the G28 command. The new stepper.cpp file from eliminates the need for disabling ft_motion in G28.cpp.

@narno2202 The new stepper.cpp file works! I no longer need to have a modified G28 file and the printer homes appropriately. This also fixed the printer not homing at the end of the print.

[classicrocker883]

is this a mistake regarding endstops?
in src/module/stepper.cpp:
under void Stepper::ftMotion_stepper() - line ~3540

 // Check endstops on every step
-IF_DISABLED(ENDSTOP_INTERRUPTS_FEATURE, endstops.update());
+TERN_(ENDSTOP_INTERRUPTS_FEATURE, endstops.update());

should this be enabled rather than disabled?

[narno2202]

@classicrocker883 . No, this is the right way as endstops are not managed the same with an interrupt capable pin.

[bmourit]

in stepper.cpp in the block_phase_isr there is this:

      // If the endstop is already pressed, endstop interrupts won't invoke
      // endstop_triggered and the move will grind. So check here for a
      // triggered endstop, which marks the block for discard on the next ISR.
      endstops.update();

I dont see any other checks happening for the ENDSTOP_INTERRUPTS_FEATURE flag, so wouldn't this mean endstop polling was always being used outside of FT_MOTION? If so, the Interrupts feature would seem to be broken. This would explain the grinding happening with homing and FT_MOTION enabled.

[InsanityAutomation]

The polling with interrupts on is only a fallback for if a new move is sent while its already engaged. It causes the moved the be dropped immediately. The interrupt only fires on the rising edge. That added check pre-dates FT Motion in the general code, but if there is a path in FT Motion that prevents this from being called, an equivalency would be needed there. The only grind condition it would allow though is new move towards endstop with endstop already triggered.

[bmourit]

Great. Thanks for that info. I am only getting the grinding while homing, so I'm not sure if that is something that would fit that condition on not. This is on cartesian printer, not CoreXY fwiw.

Edit: Looking at the Ulendo pdf about this feature, I see the following:
With fixed-time-control enabled, the stock pulse phase isr() and block phase isr() are no longer called

So it appears this is skipped. But perhaps this has already been addressed.

[ahmetcemturan]

Has @narno2202 's fix not been merged into Main branch already? I downloaded the latest Bugfix and again I can not home correctly when FT motion is enabled..
(Not correct as in, COREXY, Robin Nano 1.2,
Homes X,
Skips to Home Y (does not make any attempt)
Homes Z without moving to the Center of the Printbed... (but registers the stop, An inductive probe btw.)

I also noticed that the latest bugfix Homes well on a Cartesian (SKR3) but has trouble during Bed leveling.

[ahmetcemturan]

My current workaround for this is using replacements in Repetier.
Regular Expression: ^G28$|^G28 (.)|G29|G29 (.)

G-Code to Execute:
G4 P150
M493 S0
G4 P150
@0 @1 ;First and second find
;G28 @1
G4 P150
M493 S10
G4 P150

I am putting this here as it took me some time to figure it out and would like to help others...
Also I use:
^M900 K(\d.?\d*) and M493 K@1
this way I can use Linear advance calibration tools already existing..

[thisiskeithb]

Has @narno2202 's fix not been merged into Main branch already? I downloaded the latest Bugfix and again I can not home correctly when FT motion is enabled..

No, #26720 is still open/pending:

[ahmetcemturan]

Do You want me to investigate the bed leveling behaviour further or is that already mentioned somewhere?

[thinkyhead]

Do you want me to investigate the bed leveling behaviour further or is that already mentioned somewhere?

As FT_MOTION is now getting merged for wider testing, let's post new bug reports so the reported behaviors are based on the latest code, and we'll go from there in continuing to patch up this promising new motion system.

[github-actions]

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.