[BUG] E0 stepper will not move

[Mrdobie]

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

Yes, and the problem still exists.

Bug Description

btt skr 1.4 turbo, tmc 2209 drivers

Bug Timeline

No response

Expected behavior

all steppers move properly. tryed swapping stepper motor and driver did not work

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

Marlin-2.1.2

Printer model

corexy diy

Electronics

No response

Add-ons

No response

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

OctoPrint

Don't forget to include

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

Additional information & file uploads

Configuration.zip

[classicrocker883]

Try a known good firmware file for your board. is there like a provided firmware you can download from the manufacturer or another source?

I know some changes were made in stepper ISR timing, I think its in the src/module/stepper.h file, but previous older marlin versions have different values, this could be the cause of issue. besides swapping motors, have you tried swapping the wire connectors? such as swapping them directly on the board, perhaps its an issue with the wire instead of the driver.

so i would double check the wiring. then find a good known firmware file to install. otherwise try an older Marlin version.

[pylorak]

I have the same issue on a Voxelab Aquila (TMC2208). Firmware is N32-UBL_ProUI_BLT.bin from here.

The E stepper sometimes moves and sometimes not during the same print job. For example, If I try to print a K-Factor Calibration Pattern, about 1/2-1/3 of the calibration lines are missing due to the E-stepper staying completely still.

@classicrocker883 You just answered while I was posting. I had Alex's firmware previously and it didn't have this problem.

[classicrocker883]

@pylorak so I have a new branch that I've been working on- 2023-March -and will be uploading some new releases as soon as it passes testing. are you able to compile your own? because apparently this is a known current issue I am working on, it doesn't happen to all the boards all the time so its difficult to pinpoint. I do know that the steppers timing has been changed from previous iterations of Marlin, I do not know if it is for better or for worse, but it does seem like these changes are a likely cause as I stated in my previous comment.

using Alexs files as a template for what values and parameters may be changed is what i might do.

[classicrocker883]

https://github.com/MarlinFirmware/Marlin/pull/25557

is this related in anyway? linear advance causing it to "hang"

[classicrocker883]

@thinkyhead hey scott i just wanted to ask why have the ISR values for the steppers changed, and would these different values effect different steppers varying from machine to machine? because in older firmware iterations issues like this with the stepper motors didn't happen, and one of the changes ive seen is the different timing and ISR associated. im no expert so it can be anything else for the issue to happen. or can it be specific to the Ender 3 4.2.2/4.2.7 or voxelab Aquila boards and any other related?

[thinkyhead]

why have the ISR values for the steppers changed, and would these different values effect different steppers varying from machine to machine?

Cycle counts are updated by maintainers when code changes result in different cycle counts. Do you find that previous (larger) values solve some issue for you?

[Mrdobie]

tryed bug fix did not work

[Mrdobie]

checked wiring, stepper motor, eprom. installed a known working board. still no joy

[XDA-Bam]

Since your problem description is very bare bones: When exactly did the problem occur? Did you change anything on the printer (new cables / new board) or the firmware? What was the last working state?

Also: BTT SKR 1.4 has two Z stepper connectors. So connectors are [X], [Y], [Z0], [Z1], [E0], [E1]. Did you maybe connect the E-motor to the Z1-connector on the board? If not, could the cable to the E-motor be broken?

[classicrocker883]

@thinkyhead I have yet to confirm if different previous cycle count values made a difference. it is actually other users who came to me on my MriscocProUI repository, it can be related with Input_Shaping and/or Linear_Advance with one or the other or both enabled. and also board specific to the machine. hopefully i hear back soon or catch anything in my own testing.

but I have noticed something noteworthy... I recently got myself an aftermarket stepper motor, upon plugging it in it started making a weird grinding noise. all the other steppers work fine. I swapped the two inside wires of the connector and it started working like normal. then when i plugged the old stepper in that one started making a grinding noise.

it appears some steppers are made differently than others. this can be a cause of issues. otherwise if it does continue and is software related, my only guess is could do with Cycles or timing (or input_shaping/linear_advance related).

@Mrdobie can you describe the issue some more, or provide a video? because when I experienced this issue, i simply swapped two of the stepper wires and it was fixed, but this had to do with aftermarket steppers, and the problem wasn't just noisy it was much worse... ill try finding a video or make one to show what I mean. so im saying if it is at all like this then the fix may be physical not firmware.

[thinkyhead]

The simplest thing to do to get at the root of stepper code issues is to find the newest version of Marlin where the problem does not exist, and then go through all the stepper changes between that older version and today to pinpoint the breaking change(s). Of course, if you can pick through the history of bugfix-2.1.x using bisection to narrow down the exact date/commit where the problem was introduced, that will bring us to the threshold of a solution. I don't want to roll back all the movement optimizations if we don't have to, but I am certainly willing to roll back as far as we must to get back to reliable motion, even if it is not as optimized.

The strategy in "bisect" is to find a commit from some point in the "distant" past where the feature works. Then you would test a commit from halfway between that date and today…. And then you keep going to the commit half-way in between your "known to work" commit and your "known to be broken" commit until you find the exact date/commit where it broke.

The cool thing about this method is that if you started from a point –say– 256 commits in the past, it would take no more than 8 tests to find the exact commit that broke it.

[classicrocker883]

The simplest thing to do to get at the root of stepper code issues is to find the newest version of Marlin where the problem does not exist, and then go through all the stepper changes between that older version and today to pinpoint the breaking change(s). Of course, if you can pick through the history of bugfix-2.1.x using bisection to narrow down the exact date/commit where the problem was introduced, that will bring us to the threshold of a solution. I don't want to roll back all the movement optimizations if we don't have to, but I am certainly willing to roll back as far as we must to get back to reliable motion, even if it is not as optimized.

The strategy in "bisect" is to find a commit from some point in the "distant" past where the feature works. Then you would test a commit from halfway between that date and today…. And then you keep going to the commit half-way in between your "known to work" commit and your "known to be broken" commit until you find the exact date/commit where it broke.

The cool thing about this method is that if you started from a point –say– 256 commits in the past, it would take no more than 8 tests to find the exact commit that broke it.

this is a great response thank you, and if anyone reading this experiences this kind of issue, please let reply. if you dont know how to go about the next steps, just let me know ill mock up some compilations where you can get started (using the above for reference of course.)

[Mrdobie]

So after 6 resets i used ender5 config 2.1xdebug. I had to comment put use probe to level bed and disable the wrror message it was giving me when i enabled it. After a bunch of calibrations. Machine is running.printed a bunch of small stls. Tryes a large 14 hour print and had a proble. Think bad heater. Looked at temp graph and it looked like a cardiologist output. One step at a time.