[BUG] Axes reversed with FT_MOTION and INPUT_SHAPING_{X,Y} enabled #25635
Comments
|
Interesting… The new |
|
You are correct, thanks. I'll try them individually and see how it behaves. |
|
Since the last commit, i tested Input Shaping without FT Motion and no issues. |
|
I have a patch to properly apply the |
|
I can confirm that on a Robin Nano. |
|
I merged the patch linked above so this issue should be solved. |
|
(((((It works fine on MKS SKR 3 Board but )))) <<<<< Incorrect statement.. Various scenarios: //#define FT_MOTION Z direction is as usual.. #define FT_MOTION Z direction is inverted (TMC2208) #define FT_MOTION Z direction is "correct" (TMC2208) And Yes disabling Quick Home works. |
|
That was not a good idea. Trying to determine the frequency I turned FT motion off via gcode. |
|
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. |
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. |
|
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. |
|
Yes the skr3 works ok. 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... |
This comment was marked as outdated.
This comment was marked as outdated.
|
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! |
|
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. |
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 #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;
#endifIf you see weird Z direction behavior, there are two things that we can try.
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 I have to get down with testing and fixing up |
|
Each time I tried the bugfix the Z direction was backwardswith the FTM enabled and worked fine with no FTM enabled in the firmware. |
|
increasing FTM_STEPPERCMD_BUFF_SIZE to 3000 (from 1000) produces this behaviour: |
|
I have applied this: TERN_(HAS_Z_AXIS, Z_DIR_WRITE(INVERT_DIR(Z, !z_dir))); |
|
Also now that I was able to test it directly: |
|
Be indulgent, this is my first post . in Fixes the motion bug with multi stepper axis but sensorless homing and Z homing with BLTouch don't work. |
|
To get sensorless homing and Z homing with BLTouch, i disable FT_MOTION during homing and voilà. in then in this piece of code and at last after add Now sensorless homing works fine and Z homing with BLTouch too |
|
At Last, to get bed levelling working with BLTouch, in Didn't test G31, G32 and G33 |
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. |
|
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: #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;
#endifby: #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;
#endifand in all the: #if ENABLED(FT_MOTION)
fxdTiCtrl.cfg_mode = FTM_DEFAULT_MODE;
#endifby: #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();
#endifall working fine now ! |
|
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 :) |
|
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:
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 |
|
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.
|
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:
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. |
|
With the last bugfix-2.1.x code |
|
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. |
|
I made some changes in the previous patch to make use of APPLY_DIR and APPLY_STEP in Suggested ChangesFirst modify /**
* 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."
#endifIn #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)
#endifby #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)
#endifthen replace the code in 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_stepperThe changes needed in |
|
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. |
@cbagwell — We'll have to review the 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 |
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. |
|
@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. |
|
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 Since this issue is resolved, we can continue discussion on those two other PRs. |
|
@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 |
|
@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. |
|
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. |
Did you test the latest
bugfix-2.1.xcode?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:
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
Configuration.handConfiguration_adv.h.Additional information & file uploads
No response
The text was updated successfully, but these errors were encountered: