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

Created on 3 Jan 2018 · 30Comments · Source: MarlinFirmware/Marlin

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!

Source

mamama1

Most helpful comment

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.

teemuatlut on 3 Jan 2018

👍2

All 30 comments

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).

AnHardt on 3 Jan 2018

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

mamama1 on 3 Jan 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 on 3 Jan 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...

mamama1 on 3 Jan 2018

G28 XY
G4 S1
G28 Z

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

teemuatlut on 3 Jan 2018

👍2

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 on 3 Jan 2018

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

mamama1 on 4 Jan 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

galluslongus on 4 Jan 2018

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

mamama1 on 4 Jan 2018

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

@mamama1 Mine are by Watterott.

teemuatlut on 4 Jan 2018

👍1

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)...

mamama1 on 4 Jan 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...

teemuatlut on 4 Jan 2018

👍1

@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.

mamama1 on 4 Jan 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.

galluslongus on 6 Jan 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

migeorge on 17 Jan 2018

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

mamama1 on 17 Jan 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??

delboy711 on 20 Jan 2018

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

migeorge on 20 Jan 2018

@delboy711 did you do all the soldering like described here?
https://github.com/MarlinFirmware/Marlin/issues/8480#issuecomment-350824499

mamama1 on 20 Jan 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.

delboy711 on 20 Jan 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.

mamama1 on 20 Jan 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

ghirotre on 27 Jan 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 on 14 Feb 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.

thinkyhead on 14 Feb 2018

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