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.

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

TMC2130 sensorless homing - Y axis not moving back to the center of the bed during first homing after power on #9018

Open
mamama1 opened this issue Jan 3, 2018 · 28 comments

Comments

Projects
None yet
10 participants
@mamama1
Copy link

commented Jan 3, 2018

Hi!

I have finished connecting everything together and I completed the first tests.

However, when I say G28 right after power on and X and Y homed, X and Y should move back to the safe Z Homing Positition (Z_SAFE_HOMING and Z_SAFE_HOMING_X_POINT and Z_SAFE_HOMING_Y_POINT are defined) but Y doesn't.

The video shows that Y stays at home instead of going to the center of the bed. This appearently only happens when homing the first time right after power on. When I home again after that, all axes move as they should.

So what happens:

  • I say G28
  • Z moves up a bit
  • X moves to Home
  • Y moves to Home
  • X moves to the middle of the bed
  • Y SHOULD move back to the middle of the bed (but doesn't if it is the first homing after power on)
  • Z moves to Home

When that happened, Marlin thinks that X and Y are at the middle of the bed (coordinates say so) but Y is still in home position.

Because Marlin thinks that e.g. Y is at, say, 100, but it is at home position in fact, I can ram the axis totaly into the axis limit.

  • TMC2130 for X and Y (Sensorless Homing, SPI Mode)
  • Two TMC2208 for both Z Steppers in Legacy mode, Marlin is not aware of them, didn't define "HAVE_TMC2208", UART not connected
  • A4988 for the Extruder
  • MKS GEN 1.4 Board
  • Marlin 1.1.8
  • Sensorless Homing Sensitivity: 8 for X and Y

Idea anyone? Can this even be Marlin related? The Steppers don't even make a noise when they stand still instead of moving to the center so no losing steps there...

Video and config can be downloaded here: https://owncloud.ne-mail.net/s/1ECB97ZC4ZZDyrE

Thanks!

@AnHardt

This comment has been minimized.

Copy link
Contributor

commented Jan 3, 2018

If the stallguard-endstops act as min- and max-endstops at the same time it needs to reset the endstop condition before the move in the other direction can happen.
What ends the stallguard-endstop-condition? That has to be done to move into the other direction (if acting as min and max endstop).

@mamama1

This comment has been minimized.

Copy link
Author

commented Jan 3, 2018

where do i define if they are used as min and max endstops? and why does immediate move or rehoming work?

@mamama1

This comment has been minimized.

Copy link
Author

commented Jan 3, 2018

@AnHardt how can I define if stallguard is being used as min AND max endstop?
i have to correct my opening issue, this only seems to happen on the Y axis and only when I'm homing for the first time after powering on the printer.
Y Axis has the chinese fystec TMC2130 driver but I did the following modifications to it, which should make it working just as the watterott ones:

  • soldered spi pins to top and connected them to the board
  • soldered diag1 pin to top and connected it to the board
  • soldered the pins on the bottom just as described in here
  • removed the resistor/bridge which is also highlighted in the picture in the link above

i will get new watterott tmc2130 next week so i can then test if it is related to the chinese driver.
however, is there any way of live tracking whats happening in the software to maybe get a clue why the axis isn't moving?
or do you have any other idea?

thanks!

@mamama1

This comment has been minimized.

Copy link
Author

commented Jan 3, 2018

@teemuatlut maybe you have an idea? or anyone? i really don't know what to do right now than wait for the watterott drivers...

@teemuatlut

This comment has been minimized.

Copy link
Member

commented Jan 3, 2018

I look at your video and you have the same exact problem I have. But now that I know it's just not my machine I can look into it further and see if there are in fact steps produced.
I've noticed that it only occurs when I've just powered up the machine so my workaround for now has been to edit the start gcode as such:

G28 XY
G4 S1
G28 Z

For me it's always the Y axis that's not moving.

@mamama1

This comment has been minimized.

Copy link
Author

commented Jan 3, 2018

Hi

I am sorry, I forgot to update the issue. It is also only Y for me and also only directly during the first homing after powering on.
I was kind of tired yesterday so I seemed to mix things up a bit.

So it seems we both have exact the same problem. Let me know if there is ANYTHING I can do or test for you to get rid of this issue.

However I'm glad that it only happens once for you so I can now hope again that this or anything similar will occur mid-print which I was really afraid of.

@mamama1

This comment has been minimized.

Copy link
Author

commented Jan 3, 2018

@teemuatlut do you have the chinese TMC2130 Fysetc or other chinese drivers or do you have the drivers from watterott?

@galluslongus

This comment has been minimized.

Copy link

commented Jan 4, 2018

Heyho, i do have exakt the same „Problem“ that my y axis don’t go to the center of the bed during first homing. I have Watterott 2130 stepper in x and y axis, running in spi mode and silent mode.
I don’t have max endstopp declared, just min endstopp, running x and y as soft endstopp.
Ramps, Marlin 1.1.8, x,y 2130, z,e 4988

@mamama1 mamama1 changed the title TMC2130 sensorless homing - axis sometimes not moving back to the center of the bed TMC2130 sensorless homing - Y axis not moving back to the center of the bed during first homing after power on Jan 4, 2018

@mamama1

This comment has been minimized.

Copy link
Author

commented Jan 4, 2018

I have edited the issue and the title to match my newest findings.

@teemuatlut

This comment has been minimized.

Copy link
Member

commented Jan 4, 2018

@galluslongus Good to know there are more. Please try the workaround until I can find a fix.

@mamama1 Mine are by Watterott.

@mamama1

This comment has been minimized.

Copy link
Author

commented Jan 4, 2018

maybe we can try help you finding a workaround? where to start? I can edit the firmware, i can try various code fixes, read serial debug messages (if there would be any)...

@teemuatlut

This comment has been minimized.

Copy link
Member

commented Jan 4, 2018

This is the workaround that has been working reliably for me for some time.

My plan was to probe the Y step pin with an oscilloscope to see if there are indeed steps produced when Y should be moving. This would answer my question if the driver is not stepping when it's instructed to or does Marlin for some reason not produce steps when it's supposed to. I would also like to know why it works if I give two G28 commands in a row. What makes the first one fail and the second one succeed. And why it's always just after the initial bootup and not any subsequent ones. Because the safe homing move to the middle of the bed is not even the first move for the Y axis. You could try giving the Y axis some G1 commands back and forth and then do the first homing and see how it goes. Because while it's not the first move, it might be the first in that specific direction...

@mamama1

This comment has been minimized.

Copy link
Author

commented Jan 4, 2018

@teemuatlut yeah that workaround is working for me too, thanks!

as I don't have an oscilloscope (yet), for me it would be easier to put some serial debug messages somewhere, where the steps should be generated... if I'd only knew where...

You could try giving the Y axis some G1 commands back and forth and then do the first homing and see how it goes. Because while it's not the first move, it might be the first in that specific direction...

yeah I did try that and it was a good guess! now pay attention: it doesn't matter which way I move Y prior to the first homing after power on. both directions fix the issue! that was one wtf moment for me!
i also tried moving only X prior to the first homing but that didn't solve the issue.

so conclusion is, if you move Y to any direction prior to the first homing after power on, the issue does not occur.

@galluslongus

This comment has been minimized.

Copy link

commented Jan 6, 2018

I tried G0 Y1, just to move Y a tiny bit, then G28 did what it should. Straight after switching off/on the Printer. So i pushed G0 Y1 before G28 into my start code. Just a quick´n´dirty workaround.

@migeorge

This comment has been minimized.

Copy link

commented Jan 17, 2018

Just wanted to add my 2 cents here, I'm seeing the same behavior with my MKS Gen 1.4

I have Genuine TMC2130s from Filastruder on X, Y, Z, and E0

I'll see if the workaround above works for me also.

Edit: Tested the workaround on my printer and it works nicely

@mamama1

This comment has been minimized.

Copy link
Author

commented Jan 17, 2018

yeah it will work.. glad there's a workaround which is that simple.

@delboy711

This comment has been minimized.

Copy link

commented Jan 20, 2018

I am experiencing a similar problem except that neither X nor Y axis will home, and the workaround does not work for me.
I am using Fysetc TMC2130 on all axis (dual on Z) with a MKS Gen 1.4 board and Marlin 1.1.8.
Drivers are in SPI mode with StealthChop enabled, and I can successfuly move X Y and Z axis with G1 command.
On giving a G28 XY command motors do not move at all apart from a few clicking noises.
On giving G28 Z, X and Y axis moves noisily to centre of bed and Z axis then smoothly homes.

The config file mentions that homing always uses SpreadCycle mode so I tried again with SpreadCycle enabled and none of the motors move in response to a G28.

Thinking the problem is related to SpreadCycle I located the code in Marlin_main.cpp where Stealthchop is disabled prior to homing and commented out the relevant lines in function tmc_sensorless_homing which disabled switching to SpreadCycle during homing.
Now homing works apart from the problem that Stallguard2 does not work and the axis crunch into the endstops.(I did try adjusting StallGuard sensitivity)

Has anyone else found SpreadCycle makes a difference??

@migeorge

This comment has been minimized.

Copy link

commented Jan 20, 2018

@delboy711 The output of M122 might help here, make sure you have TMC_DEBUG enabled first

@mamama1

This comment has been minimized.

Copy link
Author

commented Jan 20, 2018

@delboy711 did you do all the soldering like described here?
#8480 (comment)

@delboy711

This comment has been minimized.

Copy link

commented Jan 20, 2018

@mamama1

Yes. That was it. I knew about the SPI solder pad, but not about the CFG4/5 pads. SpreadCycle is now working, and I can home the axis.

It is still doing something strange in StealthChop. It homes X and Y, but not Z, and then refuses to move again. But it has been a long day and I will examine that in more detail tomorrow.

Thanks for the tip.

@mamama1

This comment has been minimized.

Copy link
Author

commented Jan 20, 2018

that is what this thread is all about.
do this in your start code!to home:
G28 XY
G4 S1
G28 Z

or when homing manually right after powering on, just move the y axis in any direction 1 mm or whatever and then homing will work.

@ghirotre

This comment has been minimized.

Copy link

commented Jan 27, 2018

Hi, I have the same problem.
TMC2130 on x and y, dvr on z and e, and stallguard active.
When go home the first time the y it is not move(for the z safe, it is ok for y) .
I have notice another problem (i think it is the same) when i go home only the Y axis (only when i power
up the printer) if in the repetier host move the Y to -50 (repetier use relative position for the manual movement) the axis go in the opposite direction (+50).
I have a possible implementation:
it is possibile to add a possibility to select with a command gcode a single axis move in spreadcycle or in stealchop, now in the firmware i can only go all my driver in same mode.
Another possibility i think it is to have a gcode to change the all setting(pre write on firmware) for the printer. Like a normal mode (with 2000 acceleration, jerk 15, spreadcycle) and silent mode (with 1000 acceleration, jerk 10, stealchop)
Thanks and sorry for my poor english.
Congratulations for your super firmware

@thinkyhead

This comment has been minimized.

Copy link
Member

commented Feb 14, 2018

Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch to see if we fixed this issue. If the problem has been solved then we can close it. If you still see the bad behavior we should investigate further.

@thinkyhead

This comment has been minimized.

Copy link
Member

commented Feb 14, 2018

it is possibile to add a possibility to select with a command gcode a single axis move in spreadcycle or in stealthchop? Now in the firmware i can only go all my driver in same mode.

It is not possible at this time.

@BenBlv

This comment has been minimized.

Copy link

commented Mar 4, 2018

Same here.
The latest version didn't fixed it.

@boelle

This comment has been minimized.

Copy link
Contributor

commented Feb 19, 2019

@mamama1 @BenBlv is it still an issue?

@boelle

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2019

@thinkyhead i think we can close this one

@mamama1

This comment has been minimized.

Copy link
Author

commented Mar 6, 2019

i have implemented this workaround: #9018 (comment)

and didn't bother to try without it ever since. so don't actually know if it is fixed now but it might be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.