Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[BUG] Z Stealthchop is destroying baby steps #16617

Closed
emaayan opened this issue Jan 20, 2020 · 96 comments
Closed

[BUG] Z Stealthchop is destroying baby steps #16617

emaayan opened this issue Jan 20, 2020 · 96 comments
Labels
A: LPC176x Bug: Confirmed ! C: LCD & Controllers C: Motion F: Trinamic stale-closing-soon T: HAL & APIs Topic related to the HAL and internal APIs.

Comments

@emaayan
Copy link

emaayan commented Jan 20, 2020 •
edited
Loading

Bug Description

when StealthChop for z is enabled trying to do babystepping doesn't work, initially the motor will move just a little then it will stop moving completely and even after the build it won't move at all unless reset

My Configurations

this is marlin build 2.0.x from 18.01.2020

Marlin.zip

Steps to Reproduce

  1. enable z stealthchop and babystepping
  2. start a print , during pring adjust the knob on the z-offset

Expected behavior:
z axis moving according the knob

Actual behavior:
z axis stops moving after a few turns and is completely disabled afterwords

Additional Information

hardware is tmc 2208 skr 1.4
@boelle boelle changed the title Z Stealthchop is destroying baby steps [BUG] Z Stealthchop is destroying baby steps Jan 20, 2020
@thinkyhead
Copy link
Member

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

@MarlinFirmware MarlinFirmware deleted a comment from boelle Jan 20, 2020
@emaayan
Copy link
Author

emaayan commented Jan 20, 2020

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

this w as tested on a firmware from the 18th..

@emaayan
Copy link
Author

emaayan commented Jan 20, 2020

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

this w as tested on a firmware from the 18th..

i've updated the bug when i said 18 i mean from the 18th this month as in marlin 2.0.x

@thinkyhead
Copy link
Member

This issue is confirmed. For now the solution is to lower your babystep multiplier setting and re-flash. Try dividing it in half as a starting-point.

@sjasonsmith
Copy link
Contributor

I have been unable to reproduce this. I tried with my original SKR 1.3 configuration, then with several modifications to get closer to the posted configs. I even swapped out my 2208 for the specific module I was using to test shutdowns with linear advance.

During my tests I had visible Z activity due to bed leveling, and also tested in vase mode to allow testing during continuous Z movement.

I'm out of ideas to get it to happen on my machine. My goal was to reproduce the issue, the do a mixed-signal capture of the motor outputs and the step pulses at the same time. My hypothesis is that prior to shutdown, we will see two step pulses unreasonably close together just before the motors turn off.

@sjasonsmith
Copy link
Contributor

Can somebody experiencing this issue post an STL and sliced gcode that you can reproduce it with? Maybe there is capability used in the file (Z-hop maybe?) that behaves poorly along with babystepping.

@emaayan
Copy link
Author

emaayan commented Jan 22, 2020

Can somebody experiencing this issue post an STL and sliced gcode that you can reproduce it with? Maybe there is capability used in the file (Z-hop maybe?) that behaves poorly along with babystepping.

perhaps it's an issue with 1.4? i don't think it's related to a specific g-code i have several of them

@InsanityAutomation
Copy link
Contributor

Mine hasn't made it here from China yet unfortunately....

@sjasonsmith
Copy link
Contributor

I also have a 1.4 on the way, I doubt that is the issue. The 1.3 and 1.4 just aren't that different. It has also been seen on the TH3D EZBoard.

@emaayan, can you confirm that your 1.4 is the non-turbo version? I know that is what your config says, but perhaps things could misbehave if your board has an LPC1769 (turbo) and you build for LPC1768 (non-turbo).

@sjasonsmith
Copy link
Contributor

i don't think it's related to a specific g-code i have several of them

Your slicer is undoubtedly configured differently than mine, so having a file known to cause issues on your printer might help reproduce it on mine.

@emaayan
Copy link
Author

emaayan commented Jan 22, 2020 via email

@boelle
Copy link
Contributor

boelle commented Jan 30, 2020

a lot of updates and fixing has happend in the last week, is the problem still there?

@thinkyhead
Copy link
Member

thinkyhead commented Feb 1, 2020 •
edited
Loading

i have pure g-code that also causes this happen…

@emaayan — If the issue is still occurring, that G-code would be good to check out. Did you ever try reducing the babystep multiplier on your machine, and what value made it work? And, what is your Z steps-per-mm value?

@houseofbugs
Copy link
Contributor

houseofbugs commented Feb 1, 2020 •
edited
Loading

Dropping steps/mm from 800 to 400 (by halving the driver step rate from 1/16 to 1/8) does not show the issue. That is what we did for 800steps/mm machines with the TMC drivers. Have not had an issue since. So there is something going on (maybe driver timings being too quick) when the steps/mm are higher than 400 steps/mm.

You can still run interpolated mode on the TMC driver and there is nothing of value lost running at 1/8 vs 1/16 until the cause of the drivers shutting down when steps on Z are higher than 400steps/mm.

@rado79
Copy link
Contributor

rado79 commented Feb 1, 2020 •
edited by thinkyhead
Loading

maybe similar experience today - in my start script i do a prime-nozzle-line, i normaly do babystepping while this line is printing,

G1 X5 Y15
G1 Z0.2
G1 X250 E20 F800
G1 Z10

always successful

today i was to late - after last line in startscript G1 Z10, Cura does a diagonal move (XYZ) to startpoint of skirt, i used babystepping while this move was done. That crashed the Z axis completely.

abort the print, do G28: X home ok, Y home ok, Z home - travel to Z-safe-homing-point, no Z move.
killed message - reset printer

@emaayan
Copy link
Author

emaayan commented Feb 1, 2020 via email

@emaayan
Copy link
Author

emaayan commented Feb 1, 2020 via email

@emaayan
Copy link
Author

emaayan commented Feb 1, 2020 via email •
edited by thinkyhead
Loading

@Mysel07
Copy link

Mysel07 commented Feb 4, 2020

I have similar problem. Babystepping not working after G28, just not move to down. Move to up is OK. The number on the LCD is changing, but the Z-axis motors just twitch.
I just turned on function #define BABYSTEP_WITHOUT_HOMING, and I used Babystepping function before G28 immediately after switching on printer, and Babystepping is completely OK.
I mean, problem is about G28 - homing.
I have SKR 1.3 and TMC2209

  • stealtchop is ON or OFF (the same prob),
  • steps per mm 400 / 16steps mode

@Mysel07
Copy link

Mysel07 commented Feb 4, 2020

I just tried:
Change the value of BABYSTEP_MULTIPLICATOR 1-20
TMC2209 steps mode 4,8,16 and steps per mm 100-400
... still the same problem

@rado79
Copy link
Contributor

rado79 commented Feb 4, 2020 •
edited by thinkyhead
Loading

today it happend again on a different printer. i did babystepping while a Z move was done.
Z axis no more action - had to reset printer.
SKR 1.3 TMC2208/2209, bugfix on both printers updated once a week (not same day).

Configuration.zip
Configuration_adv.zip

@thinkyhead
Copy link
Member

thinkyhead commented Feb 5, 2020 •
edited
Loading

The original issue reminds me that stealthChop has to be on for this failure to occur.

If you find that BABYSTEPPING works with stealthChop turned off, then perhaps it will make sense to turn off stealthChop as a general strategy to ensure good baby-stepping. I'm speculating that maybe the small pulses injected at unusual intervals are not something that stealthChop quite knows how to manage, so the driver itself is going to sleep.

The thing is, Marlin doesn't do anything differently when stealthChop is on or off, so perhaps these SKR boards have some kind of flaw or addition that can't handle out-of-time pulses when stealthChop is enabled.

@sjasonsmith
Copy link
Contributor

That won't help the many people that use 2208s in standalone mode, though. Obscene delays surrounding babystepping might be the only option there. I guess standalone users are probably mostly on 8-bit boards, which might not exhibit the same issue (I'm unsure on this).

extremely sensitive to pulses against the current direction of motion, or even in line with it if they come at intervals that imply sudden acceleration

From what I've observed in my traces, they don't seem to have issues when the pulses are spaced out a bit (hundreds of microseconds), even when the direction is alternating with every pulse. It's really only when there are two sudden closely-spaced pulses, whether there is a direction change or not.

@thinkyhead
Copy link
Member

Obscene delays surrounding babystepping might be the only option there.

It has not yet been demonstrated that this would work.

From what I've observed in my traces, they don't seem to have issues when the pulses are spaced out a bit

Easier said than done, unfortunately. The obvious solution is to add a global array that stores the processor tick of the last pulse done on each axis before exiting the ISR, and then add a needed delay in front of any babystep that would be too close to that pulse. We don't know when the next stepper ISR pulse might be, so after every babystep there would need to be a delay corresponding to the worst case.

Because the "obvious" solution adds overhead to every stepper pulse and imposes extra delay on the steppers that are not involved in the babystepping, it is considered a bit of a last resort.

@emaayan
Copy link
Author

emaayan commented Feb 11, 2020 via email

@thinkyhead
Copy link
Member

@emaayan — 32-bit boards. And many more TMC220x drivers.

@thinkyhead thinkyhead mentioned this issue Feb 15, 2020
Closed
@rado79
Copy link
Contributor

rado79 commented Feb 18, 2020 •
edited
Loading

I did some more tests from above after #16857.
//#define INTEGRATED_BABYSTEPPING - babystepping does not do anything - no reaction at all.
#define INTEGRATED_BABYSTEPPING - babystepping doesn´t work, but i noticed that the stepper motors does another noise above/below "BABYSTEP Z: +000.00"

With a G1 Z100 i hear a typical sound from steppermotors depanding on speed during move.
Turning encoder above/below +000.00 sound changes to another stable frequency,
turning back to Z +000.00 sound changes to previous frequency

edit: no driver shutdown

@rado79 rado79 mentioned this issue Feb 18, 2020
Closed
@rado79
Copy link
Contributor

rado79 commented Feb 24, 2020

@thinkyhead in relation to #16941 (comment)
Downloaded todays bugfix 9040394 and did my tests again.
#define INTEGRATED_BABYSTEPPING / #define BABYSTEPPING_EXTRA_DIR_WAIT does the job, no shutdown reproducible.

//#define INTEGRATED_BABYSTEPPING shutdown persits.

@rado79
Copy link
Contributor

rado79 commented Feb 24, 2020

same good news with:
//#define BABYSTEPPING_EXTRA_DIR_WAIT / #define INTEGRATED_BABYSTEPPING - no shutdown reproducible.

@sjasonsmith
Copy link
Contributor

I will need to test again on my setup. I've been very busy with work and was out of town last week, so couldn't continue my earlier testing.

@thinkyhead
Copy link
Member

I'm glad to hear it works with just BABYSTEPPING_EXTRA_DIR_WAIT. The integrated babystepping is still experimental, so I encourage trying some changes to the code wrapped in the option and see if anything changes. I will do more testing in this realm later this week.

@rado79
Copy link
Contributor

rado79 commented Feb 25, 2020

There may be a misunderstanding due to my non-professional english.
It works for me with or without BABYSTEPPING_EXTRA_DIR_WAIT enabled.

Just INTEGRATED_BABYSTEPPING has to be enabled. Otherwise it comes to shutdown.

@thinkyhead
Copy link
Member

Just INTEGRATED_BABYSTEPPING has to be enabled….

Oh, okay! I wasn't aware that INTEGRATED_BABYSTEPPING was working any better than the old technique. I couldn't see any difference in my testing, but I haven't put the scope on it yet.

It will be good to keep testing with bed leveling both on and off, because the extra Z motion can exacerbate the shutdown problem.

@rado79
Copy link
Contributor

rado79 commented Feb 25, 2020

@thinkyhead do you have a proposal for a scope for beginners?
I would be interested to dive into this topic - to gain more experience and maybe help debugging someday.

@thinkyhead
Copy link
Member

do you have a proposal for a scope for beginners?

Play around and have fun. The squiggly lines start to make sense after a while.

@rado79
Copy link
Contributor

rado79 commented Feb 26, 2020

No good news guys, Z driver shutdown persists while using UBL.
Testing babysteps during a single G1 Z100 move has caused shutdowns in the past, now it works (with INTEGRATED_BABYSTEPPING).

@rado79 rado79 mentioned this issue Mar 2, 2020
Closed
@Alphaelectric
Copy link

I found this thread while trying to find a solution for a frustrating ABL problem.
BTT E3 DIP 1.0 with 4x TMC2208 in Stealthchop / BLTouch 3.1 / Prusaslicer 2.1.0

G29 is in the start script and Z-Offset is saved to the EEPROM during first layer.

No following print makes good use of the saved Z-Offset. Consecutive prints run the nozzle into the bed as if ~0.2mm were just subtracted from the Z-offset. Z-Offset adjusted again and saved. Next print, same problem. Working the numbers between -1.7 to -1.6 to -1.5
Upon restarting the machine, first layer is air-printing....

Is it possible that the baby steps needed for proper Z-offset are "killed"?

The print job itself does execute without problem once the first hurdles are taken.

@emaayan
Copy link
Author

emaayan commented Mar 20, 2020 via email

@phazei phazei mentioned this issue Apr 26, 2020
Closed
@phazei
Copy link

phazei commented Apr 26, 2020

@emaayan try what's suggested here: #17323

It helped a similar issue I was having

@emaayan
Copy link
Author

emaayan commented Apr 26, 2020 via email

@interstellarmisfit interstellarmisfit mentioned this issue May 28, 2020
Closed
@boelle
Copy link
Contributor

boelle commented Jun 23, 2020

@emaayan
Please test the bugfix-2.0.x branch to see where it stands.

@github-actions
Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

@onfoot onfoot mentioned this issue Sep 6, 2020
Closed
@github-actions
Copy link

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.

@github-actions github-actions bot locked and limited conversation to collaborators Sep 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
A: LPC176x Bug: Confirmed ! C: LCD & Controllers C: Motion F: Trinamic stale-closing-soon T: HAL & APIs Topic related to the HAL and internal APIs.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
10 participants
@phazei @thinkyhead @boelle @Mysel07 @emaayan @sjasonsmith @houseofbugs @Alphaelectric @InsanityAutomation @rado79