Is the endstop switch on the right?

MasterPIC on 2 May 2018

No, on the left

ikarisan on 2 May 2018

Does the x axis Moving to the right occur when you are z homing? The reason I ask, I had the same issue before I went back to release form4/27. I would x and y home perfectly then do a z home and the axis would fly across to the right. I went back to the down load from 4/27 and all is fine

pmbroth on 2 May 2018

Sometimes it happens…

See if it helps to do a re-flash of the latest code followed by M502, M500.

thinkyhead on 3 May 2018

@thinkyhead I will try it.

After printing five same GCODE files over the last two hours, the 6th printout leat into an endles X move and I had to press reset to "_save_ the belt".

ikarisan on 4 May 2018

Printing from host or from SD?

Since we don't see this issue in our setups, please ZIP up your Configuration.h and Configuration_adv.h files (as requested in the Issue template) and drop them into your next reply. We'll check them over and see if anything is amiss.

thinkyhead on 8 May 2018

Hi!
After a reflash to the newest version and resetting the EEPROM the error has not occurred again for the last 4 prints. But nevertheless here is my configuration. :)

Configuration.zip

ikarisan on 8 May 2018

The configuration seems ok on first inspection. Let us know if the issue reappears.

thinkyhead on 10 May 2018

It happend again!

Like last times, I wasn't sitting right next to the printer. But from the sound the printer made, I'd say it happened right after executing G28. The motor started and four second later the X carriage hit the right side of the frame while the printer was still trying to move on. I suspect the printer never tried to move to the left limit switch first, because the bed is still at the front.

This is my starting code:

M190 S[bed0_temperature]; 
G4 S30; wait 30s
G28;
M420 L0 S1;
M109 S[extruder0_temperature]; Heat nozzle
M900 K0.17; Linear Advance

This is the end position.. only held up by the BLTouch holder at the back. :(
Now I have to align and level bed and sensor again :( :( :(

img_20180511_164240

ikarisan on 11 May 2018

Since no one else is experiencing this issue, and since it occurs at random, it implies that it's an issue with your hardware and possibly your serial connectivity. When there are bugs in Marlin they tend to be 100% repeatable, not random.

Check all your wiring, and make sure all plugs are tight.

thinkyhead on 14 May 2018

I will investigate the problem in more detail. I suspect that the problem does not occur at the first print after power-on, but at the second print.

ikarisan on 14 May 2018

Maybe it's worth checking endstop state. I'm thinking about a wrong endstop detection (while homing).

MasterPIC on 14 May 2018

@MasterPIC Hmmmm... that makes sense. If Marlin thinks that X already hit the left endstops it would move to the right to release the switch. But why should it move >220mm to the right and not just the few mm defined in X_HOME_BUMP_MM?

ikarisan on 14 May 2018

Another issue popped up that might be related to this report.

I've had this problem more often in the last few weeks, but I haven't thought about it. Sometimes my extruder motor is running the wrong direction. Instead of feeding the filament into the nozzle it pulls it out! The filament just fell out of the extruder while printing the prime line. O.o

A few seconds ago I reinserted the filament and restart the print... extruder runs the wrong direction!
After resetting the printer everything works as expected.

Seems to be the same problem as with the X motor... from time to time the direction seems to be reversed. O.o No such problem occurs during printing!

ikarisan on 14 May 2018

I'm not sure but it's possible that X_HOME_BUMP_MM is measured from the endstop opening (so that a bad switch locked in closed state will make the printer moving the extruder endless...).
As for the wrong extrusion direction, please be sure the script properly sets relative or absolute extrusion position and manages the extruder accordingly...

MasterPIC on 15 May 2018

@MasterPIC I added these lines to my start code:

G21 ; set units to millimeters
G90 ; use absolute positioning
M82 ; absolute extrusion mode

Although my end code already contains

G90 ;absolute positioning

ikarisan on 15 May 2018

When switching to absolute coordinates I think you should reset the extruder position (G92 E0) before the script command used for prime line since you don't know current extruder position...
I think the slicer will send the extruder position to relative mode or in any case reset it, but you should check the slicer configuration and the generated gcode to figure out if something is to be fixed.

MasterPIC on 15 May 2018

Sorry.. this is my complete start code for now:

G21 ; set units to millimeters
G90 ; use absolute positioning
M82 ; absolute extrusion mode

M190 S[bed0_temperature]; warm up the bed and wait for it
M104 S[extruder0_temperature]; Heat nozzle but don't wait
G4 S30; wait 30s

G28;
M420 L0 S1;

M109 S[extruder0_temperature]; Heat nozzle and wait
M900 K0.12; Linear Advance

G92 E0
G1 X1 Y1 Z0.1 F1200
G1 X200 E20 F600
G1 Z1 F6000
G92 E0

I don't know what my slicer (S3D) ist doing but I think it is okay, since I had no serious problems over the last 12 month.

ikarisan on 15 May 2018

Aaaaargh.... After homing with G28 I executed G28 again and the X axis instantly moved to the right :(
To exclude defective limit switches I used the TMCs sonsorless homing feature.

@thinkyhead : Please look at my video at https://www.youtube.com/watch?v=3QqvpDmoe9I
At 0:00 I executed G28 and everything works fine. And at second 0:26 I executed G28 again. Without sensorless homing the carriage would try to move on and on... :/

ikarisan on 16 May 2018

B.T.W. the same happens if I select "Auto home" from the LCD menu twice! The first time it homes fine.... the second time I select "auto home" it rams the extruder into the printer's frame! :(

I have captured the issues on the second video:

https://www.youtube.com/watch?v=eEnSVbaQTKE

ikarisan on 16 May 2018

Okay, I re-initialized the EEPROM via the LCD, reset it by executing M502 and reflashed the newest GIT version. Than the first thing I did was executing "G28" and everything worked as expected. Than I executed G28 again... the X axis moved to the right side, again! :(

In my opinion this needs to be tagged as "potential bug" and not as "question". :/ :(

ikarisan on 17 May 2018

Just to make sure, if you execute an M119 after the first G28 do any of the endstops show as triggered?

ManuelMcLure on 18 May 2018

After reset

M119
SENDING:M119
Reporting endstop status
x_min: open
y_min: open
z_min: open

After first G28

M119
SENDING:M119
Reporting endstop status
x_min: open
y_min: open
z_min: open

ikarisan on 18 May 2018

@ManuelMcLure For that reason I switched from mechanical endstops to "sensorless homing".

ikarisan on 18 May 2018

Those seem like the correct return values from M119. I was wondering if sensorless homing might be incorrectly setting some form of false endstop value (I haven't looked at the code to see if that's even a possibility).

ManuelMcLure on 18 May 2018

It might make sense to enable DEBUG_LEVELING_FEATURE since that prints out some stuff when homing is in progress. You'll also have to send a M111 S32 to enable the debug output.

ManuelMcLure on 18 May 2018

These are the results:

FIRST G28
=============================

>>> G28
SENDING:G28
>>> gcode_G28
Machine Type: Cartesian
Probe: BLTOUCH
Probe Offset X:20 Y:52 Z:-1.55 (Right-Back & Below Nozzle)
Auto Bed Leveling: UBL (enabled)
Z Fade: 10.00
UBL Adjustment Z+0.284 (+0.284)
  current_position=(1.00, 1.00, 0.28) : setup_for_endstop_or_probe_move
> endstops.enable(true)
>>> homeaxis(X)
Home 1 Fast:
>>> do_homing_move(X, -373.50, 0.00 [70.00])
  current_position=(0.00, 1.00, 0.28) : sync_plan_position
<<< do_homing_move(X)
>>> set_axis_is_at_home(X)
For X axis:
 home_offset = 1.00
 position_shift = 0.00
 soft_endstop_min = -29.00
 soft_endstop_max = 220.00
> home_offset[X] = 1.00
  current_position=(-29.00, 1.00, 0.28) :
<<< set_axis_is_at_home(X)
  current_position=(-29.00, 1.00, 0.28) : sync_plan_position
  current_position=(-29.00, 1.00, 0.28) : > AFTER set_axis_is_at_home
<<< homeaxis(X)
>>> homeaxis(Y)
Home 1 Fast:
>>> do_homing_move(Y, -330.00, 0.00 [70.00])
  current_position=(-29.00, 0.00, 0.28) : sync_plan_position
<<< do_homing_move(Y)
>>> set_axis_is_at_home(Y)
For Y axis:
 home_offset = 1.00
 position_shift = 0.00
 soft_endstop_min = 0.00
 soft_endstop_max = 220.00
> home_offset[Y] = 1.00
  current_position=(-29.00, 0.00, 0.28) :
<<< set_axis_is_at_home(Y)
  current_position=(-29.00, 0.00, 0.28) : sync_plan_position
  current_position=(-29.00, 0.00, 0.28) : > AFTER set_axis_is_at_home
<<< homeaxis(Y)
Z_SAFE_HOMING >>>
  current_position=(-29.00, 0.00, 0.28) : sync_plan_position
  destination=(90.00, 58.00, 0.28) : Z_SAFE_HOMING
>>> do_blocking_move_to(91.00, 59.00, 0.28)
<<< do_blocking_move_to
>>> homeaxis(Z)
  current_position=(90.00, 58.00, 0.28) : set_probe_deployed
deploy: 1
>>> do_blocking_move_to(91.00, 59.00, 0.28)
<<< do_blocking_move_to
Home 1 Fast:
>>> do_homing_move(Z, -315.00, 0.00 [4.00])
set_bltouch_deployed(1)
  current_position=(90.00, 58.00, 0.00) : sync_plan_position
set_bltouch_deployed(0)
<<< do_homing_move(Z)
Move Away:
>>> do_homing_move(Z, 10.00, 4.00 [4.00])
  current_position=(90.00, 58.00, 0.00) : sync_plan_position
<<< do_homing_move(Z)
Home 2 Slow:
>>> do_homing_move(Z, -20.00, 2.00 [2.00])
set_bltouch_deployed(1)
  current_position=(90.00, 58.00, 0.00) : sync_plan_position
set_bltouch_deployed(0)
<<< do_homing_move(Z)
>>> set_axis_is_at_home(Z)
For Z axis:
 home_offset = 0.00
 position_shift = 0.00
 soft_endstop_min = 0.00
 soft_endstop_max = 210.00
*** Z HOMED WITH PROBE (Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) ***
> zprobe_zoffset = -1.55
> home_offset[Z] = 0.00
  current_position=(90.00, 58.00, 1.55) :
<<< set_axis_is_at_home(Z)
  current_position=(90.00, 58.00, 1.55) : sync_plan_position
  current_position=(90.00, 58.00, 1.55) : > AFTER set_axis_is_at_home
  current_position=(90.00, 58.00, 1.55) : set_probe_deployed
deploy: 0
do_probe_raise(10.00)
>>> do_blocking_move_to(91.00, 59.00, 11.55)
<<< do_blocking_move_to
>>> do_blocking_move_to(91.00, 59.00, 11.55)
<<< do_blocking_move_to
<<< homeaxis(Z)
<<< Z_SAFE_HOMING
>>> do_blocking_move_to(91.00, 59.00, 15.00)
<<< do_blocking_move_to
  current_position=(90.00, 58.00, 15.00) : sync_plan_position
  current_position=(90.00, 58.00, 14.99) : clean_up_after_endstop_or_probe_move
<<< gcode_G28



SECOND G28 => moves to the right!
============================
SENDING:G28
>>> gcode_G28
Machine Type: Cartesian
Probe: BLTOUCH
Probe Offset X:20 Y:52 Z:-1.55 (Right-Back & Below Nozzle)
Auto Bed Leveling: UBL (enabled)
Z Fade: 10.00
UBL Adjustment Z+0.012 ( 0.000)
  current_position=(90.00, 58.00, 15.00) : setup_for_endstop_or_probe_move
> endstops.enable(true)
>>> homeaxis(X)
Home 1 Fast:
>>> do_homing_move(X, -373.50, 0.00 [70.00])
  current_position=(0.00, 58.00, 15.00) : sync_plan_position
<<< do_homing_move(X)
>>> set_axis_is_at_home(X)
For X axis:
 home_offset = 1.00
 position_shift = 0.00
 soft_endstop_min = -29.00
 soft_endstop_max = 220.00
> home_offset[X] = 1.00
  current_position=(-29.00, 58.00, 15.00) :
<<< set_axis_is_at_home(X)
  current_position=(-29.00, 58.00, 15.00) : sync_plan_position
  current_position=(-29.00, 58.00, 15.00) : > AFTER set_axis_is_at_home
<<< homeaxis(X)
>>> homeaxis(Y)
Home 1 Fast:
>>> do_homing_move(Y, -330.00, 0.00 [70.00])
  current_position=(-29.00, 0.00, 15.00) : sync_plan_position
<<< do_homing_move(Y)
>>> set_axis_is_at_home(Y)
For Y axis:
 home_offset = 1.00
 position_shift = 0.00
 soft_endstop_min = 0.00
 soft_endstop_max = 220.00
> home_offset[Y] = 1.00
  current_position=(-29.00, 0.00, 15.00) :
<<< set_axis_is_at_home(Y)
  current_position=(-29.00, 0.00, 15.00) : sync_plan_position
  current_position=(-29.00, 0.00, 15.00) : > AFTER set_axis_is_at_home
<<< homeaxis(Y)
Z_SAFE_HOMING >>>
  current_position=(-29.00, 0.00, 15.00) : sync_plan_position
  destination=(90.00, 58.00, 15.00) : Z_SAFE_HOMING
>>> do_blocking_move_to(91.00, 59.00, 15.00)

[pressed reset before carriage reaches the right side]

ikarisan on 18 May 2018

That's... unexpected. I would have expected the second G28 to be making the crazy motion when it does the do_homing_move(X), not when it's trying to move the nozzle into the middle of the bed for Z_SAFE_HOMING. If I'm interpreting the data correctly, it looks like for the second G28 the do_homing_move(X) and do_homing_move(Y) are not actually doing anything and the do_blocking_move_to() for Z_SAFE_HOMING is going nuts.

ManuelMcLure on 18 May 2018

👍1

Next strange behaviour:

The first "G28 X Y" homes both axis as expected.
Second, third, fourth... "G28 X Y" homes both axis again fine every time.
After that I call "G28 Z" and the printer homes the nozzle in the middle of the bed.

Now it begins!
1) I call "G28 X Y" again, the printer does exactly: Nothing!
2) I call "G28 Z" afterwards, the X axis moves to the right.

See the attached TXT files for the debug output!

splitted_G28_commands.txt

ikarisan on 18 May 2018

That sort of matches what I determined from your output. It's interesting that it only happens after homing Z, though.

I wonder if this is BLTouch related. I noticed in your videos that the BLTouch remained glowing red after the first Z home until it was ready to try a second Z home (after moving to the X endstop). I don't have a BLTouch myself so I'm not familiar with the way the LED is supposed to operate so I don't know if this is normal.

ManuelMcLure on 18 May 2018

@ManuelMcLure The red LED means that the probing pin is retracted.

ikarisan on 18 May 2018

OK - so that's probably not relevant. I can't see anything obvious in the code but I'll keep looking.

ManuelMcLure on 18 May 2018

Thank you very much!

ikarisan on 18 May 2018

I'll also test this on my own AM8 when I get home. I'm using RAMPS 1.4 and A4988 drivers with an inductive sensor - if it reproduces with my setup it will eliminate some variables, and if it doesn't it will eliminate others.

ManuelMcLure on 18 May 2018

This does not reproduce on my AM8. At this point I'm at a loss. My guess is that this is TMC2130 related.

ManuelMcLure on 19 May 2018

This is odd. I updated my initial post and added some hardware information.

Do you use the latest bugfix-1.1.x version?

ikarisan on 19 May 2018

I'm using a bugfix-1.1.x that's about 4 days old.

ManuelMcLure on 19 May 2018

Any chance you have some extra A4988s lying around and could do a test with all A4988s? That would either implicate or rule out a TMC2130 issue.

ManuelMcLure on 19 May 2018

@ManuelMcLure It kept bothering me, so I just modified my printer. :)

After setting up an A4988 for X, Y and E the homing works as expected! So you are maybe right that it is an TMC2130 issue!

@teemuatlut Do you have any idea why the repeated homing works with A4988 drivers but not with TMC2130s? The print itself works fine. Only the homing is faulty. I am using version 2.3.0 of the TMC2130 library. Could there be a connection to the layershift problem?

ikarisan on 19 May 2018

Hmmmm... I did some tests last evening. For this I built my printer in an open wiring from spare parts (only the electronic and the motors). The test setup is configured as follows:

MKS Gen 1.4
X/Y: TMC2130 (SPI) [same drivers as used before on the real printer!]
Z: A4988
X, Y and Z are using simple mechanical end switches
Same Marlin version as on my real printer
Same configuration, expect the configured BL-Touch. I undefined #BLTOUCH and instead, I defined a fixed sensor (to be able to activate UBL) that I simulated by the mechanical switch.
UBL is enabled and a 0.0 mesh is stored to slot 0 and 1
Z offset is set to the same values as on the real printer.

Now, the only difference between the test setup and the real printer is the BL-Touch sensor.
In this configuration I can call G28 again and again and it seems that my steppers are moving to the right directions.. always! So, I tried it again with disabled UBL and it still works.

Summary:

DOES NOT WORK (on the real printer)

TMC2130 on X,Y
A4988 on Z
BL-Touch as Z endstop

WORKS (on the real printer)

A4988 on X,Y
A4988 on Z
BL-Touch as Z endstop

WORKS (in test environment)

TMC2130 on X,Y
A4988 on Z
Mechanical switch as Z endstop

Unfortunately I don't have a second BL-Touch Sensor to use it with the test setup.

ikarisan on 22 May 2018

I'm just thinking that somehow when using TMC2130, even without sensorless homing, they are causing Marlin to see triggered X endstops. Is there any wiring of the TMC2130s to the endstop switches that could cause them to make Marlin think the X endstop is triggered?

Between each G28, do M119 to see what the endstops read.

Are you moving the carriage away from the endstops before each G28 test? I suppose with Safe homing the carriage is probably at the middle of the bed on each test…

And what happens if you do G1 Z20 before each test of G28? Does that make any difference?

thinkyhead on 22 May 2018

@thinkyhead Without sensorless homing there are no wrings between the TMCs and the endstop switches or the corresponding connectors on the board.

Before the first G28 the XY position is unknown (depends on the last print). After the first G28 the carriage is at the middle of the bed.

I will try "M119" and "G1 Z20" tonight (CET). But for that I have to rebuild everything again.

ikarisan on 22 May 2018

👍1

Okay, rebuilt the printer to its old state. I can reproduce my issue very easily:

1) Reset the printer (X is somewhere between 0 and 220)
2) Execute "G1 X10" (or "G1 X-10") => X moves 10mm to the right/left
3) Execute "G28" => Y homes and X moves to the right

Before and after "G1 X10" all endstops are open!

If I move Y instead of X between a reset and G28 the Y axis moves to the wrong direction!!
See: https://youtu.be/8wnmZKRGVMc

ikarisan on 22 May 2018

Oh, and a "G1 Z20" before the first G28 (after a reset) has no influence on the behaviour. G28 works well after that. So it must be related to X/Y movements before/in/between G28.

Even after I have completely cleared the EEPROM with the Arduino sample sketch the issue still exists.

ikarisan on 22 May 2018

Some TMC debugs for the wrong Y movement:

1) After reset

>>>>M122
SENDING:M122
             X        Y
Enabled     false   false
Set current 800 800
RMS current 795 795
MAX current 1121    1121
Run current 25/31   25/31
Hold current    12/31   12/31
CS actual       12/31   12/31
PWM scale   0   0
vsense      1=.18   1=.18
stealthChop false   false
msteps      16  16
tstep       1048575 1048575
pwm
threshold       0   0
[mm/s]      -   -
OT prewarn  false   false
OT prewarn has
been triggered  false   false
off time        5   5
blank time  24  24
hysteresis
-end        2   2
-start      3   3
Stallguard thrs 2   2
DRVSTATUS   X   Y
stallguard
sg_result       331 231
fsactive
stst        X   X
olb     X   X
ola     X   X
s2gb
s2ga
otpw
ot
Driver registers:   X = 0xE0:0C:01:4B
    Y = 0xE0:0C:00:E7

>>>M119
SENDING:M119
Reporting endstop status
x_min: open
y_min: open
z_min: open


2) Moving Y 10mm to the front (G1 Y10)

>>>G1 Y10
SENDING:G1 Y10
>>>M122
SENDING:M122
        X   Y
Enabled     false   true
Set current 800 800
RMS current 795 795
MAX current 1121    1121
Run current 25/31   25/31
Hold current    12/31   12/31
CS actual       12/31   12/31
PWM scale   0   0
vsense      1=.18   1=.18
stealthChop false   false
msteps      16  16
tstep       1048575 1048575
pwm
threshold       0   0
[mm/s]      -   -
OT prewarn  false   false
OT prewarn has
been triggered  false   false
off time        5   5
blank time  24  24
hysteresis
-end        2   2
-start      3   3
Stallguard thrs 2   2
DRVSTATUS   X   Y
stallguard          X
sg_result       331 410
fsactive
stst        X   X
olb     X
ola     X
s2gb
s2ga
otpw
ot
Driver registers:   X = 0xE0:0C:01:4B
    Y = 0x81:0C:01:AB

>>>M119
SENDING:M119
Reporting endstop status
x_min: open
y_min: open
z_min: open

3) Homing (Y moves to the wrong direction)

>>>G28
SENDING:G28
>>>M122
SENDING:M122
        X   Y
Enabled     true    true
Set current 800 800
RMS current 795 795
MAX current 1121    1121
Run current 25/31   25/31
Hold current    12/31   12/31
CS actual       12/31   12/31
PWM scale   0   0
vsense      1=.18   1=.18
stealthChop false   false
msteps      16  16
tstep       1048575 1048575
pwm
threshold       0   0
[mm/s]      -   -
OT prewarn  false   false
OT prewarn has
been triggered  false   false
off time        5   5
blank time  24  24
hysteresis
-end        2   2
-start      3   3
Stallguard thrs 2   2
DRVSTATUS   X   Y
stallguard      X   X
sg_result       393 409
fsactive
stst        X   X
olb
ola
s2gb
s2ga
otpw
ot
Driver registers:   X = 0x81:0C:01:A4
    Y = 0x81:0C:01:8F


>>>M119
SENDING:M119
Reporting endstop status
x_min: open
y_min: open
z_min: open

ikarisan on 22 May 2018

As a last option, I have now replaced the board. Same problem. :(

ikarisan on 22 May 2018

Hey, I found the cause!

@thinkyhead
The problem only appears if I DISABLE StealthChop!

Flashed Marlin with "#define STEALTHCHOP" and the homing works fine every time.
As soon as I comment out the entry, the problem reappears!

ikarisan on 22 May 2018

@teemuatlut @ejtagle — What do you make of this?? ☝️☝️
SpreadCycle mode is causing steppers to do some strange things.

thinkyhead on 24 May 2018

👍1

Hi Guys
Just to confirm that I've just encountered a similar problem this very evening after disabling StealthChop. The printer is a Tevo Tornado modified with MKS Gen L1.0 board and TMC2130 drivers, running Marlin latest, v 1.1.8 ("2017-12-25 12:00). Glad it wasn't just me! So back to StealthChop it seems until somehow this nasty little bug can be tracked down and fixed. Cheers, Ron.

kiwironnie on 4 Jun 2018

@thinkyhead : What i´d do is to dump the registers used to detect stall and the stall signal itself.
Maybe when the drivers enter SpreadCycle , the stall signal is not being updated (at all, or just the update is delayed enough to fool Marlin into thinking that the motor is still stalled ("homed").
I don´t have those drivers to test, but it is my humble guess the problem is related to that...

ejtagle on 4 Jun 2018

Found another way to reproduce the issue sometimes!

1) You need a graphics display for the following
2) Power on the printer by just using the power supply (no USB to make sure the TMC2130 is initialized correctly)
3) Use display and home all axis
4) Power down the printer
5) Power the printer on again
6) Use the display to home all axis.

Now, sometimes the result is:
1) The X axis moves a 1mm to the right
2) The Y axis moves to the endstop
3) The X axis moves to the right untill it will be stopped by the frame

ikarisan on 5 Jun 2018

I replaced the TMC2130 drivers with TMC2208 ones. Homing works fine every time. So maybe it is an TMC2130 library specific issue or something with the SPI interface.

ikarisan on 9 Jun 2018

👍1

I replaced the TMC2130 drivers with TMC2208 ones. Homing works fine every time.

That's interesting.

@teemuatlut — Is there something about the TMC2130 (maybe initialization) that the TMC2208 libraries do (or don't do) which would lead to better behavior here? What is it that we've determined can cause steppers to go the wrong direction? I would assume that the DIR pin is being set incorrectly, but could something else cause a stepper on a TMC2130 to spin the wrong way?

thinkyhead on 9 Jun 2018

Is there any new evidence?
After changing from TMC2130 to TMC2208 I have printed 36 parts for my new HyperCube Evolution WITHOUT any motion related issue!

ikarisan on 17 Jun 2018

Hi, I just wanted to add that I have the same problem with a MKS1.4 board and 4 TMC2130 in SPI and sensorless endstop, I had to disable Stealthshop because it was skipping steps, than I have to power down the printer everytime before printing from an SD card or I get the behaviour describe here, in my case the screen shows X 68 Y 107 when the head goes to the right. If you want some more infos I can provide them, thanks.

Franks3dShop on 18 Jun 2018

👍1

Maybe it has something to do with the SPI communication. Somewhen the last three days I have seen an osciloscope screenshot that showed some initialization issues... as far as I can remember.

ikarisan on 18 Jun 2018

On my part, I use a software SPI for the TMC2130 the hardware SPI bus was not working for the TMC2130 at the same time as the SD_Card reader.

So for theTMC2130 Software SPI Iuse pins: MOSI=66, MISO=44, TMC_SW_SCK=64

Franks3dShop on 19 Jun 2018

With the latest bugfix 1.1.x, when I issue a G28 it does the X and Y sensorless endstop homing, but it does not go to the middle of the bed as it should with Z_SAFE_HOMING enable it stays at 0 X 0 Y goes up than down, it show 68 X 101 Y but it never moved to that position, here is a detailed login of the G28 if that can help:

Marlin bugfix-1.1.x

echo: Last Updated: 2018-01-20 | Author: Haribo by Frank, 17-june-2018
echo:Compiled: Jun 19 2018
echo: Free Memory: 2461  PlannerBufferBytes: 1264
echo:V55 stored settings retrieved (683 bytes; crc 35805)
echo:  G21    ; (mm)
echo:  M149 C ; Units in Celsius

echo:Filament settings: Disabled
echo:  M200 D1.75
echo:  M200 D0
echo:Steps per unit:
echo:  M92 X99.53 Y99.53 Z399.50 E150.80
echo:Maximum feedrates (units/s):
echo:  M203 X200.00 Y200.00 Z3.00 E60.00
echo:Maximum Acceleration (units/s2):
echo:  M201 X3000 Y3000 Z100 E10000
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P500.00 R1500.00 T3000.00
echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
echo:  M205 B20000 S0.00 T0.00 X10.00 Y10.00 Z0.20 E2.50
echo:Home offset:
echo:  M206 X0.00 Y0.00 Z0.00
echo:Auto Bed Leveling:
echo:  M420 S0 Z0.00
echo:Material heatup parameters:
echo:  M145 S0 H205 B70 F0
echo:  M145 S1 H240 B80 F0
echo:PID settings:
echo:  M301 P22.20 I1.08 D114.00
echo:  M304 P10.00 I0.02 D305.40
echo:Z-Probe Offset (mm):
echo:  M851 Z-2.98
echo:Stepper driver current:
echo:  M906 X800 Y800 Z800
  M906 T0 E800

echo:Sensorless homing threshold:
echo:  M914 X2 Y2
echo:DEBUG:LEVELING
ok
>>> gcode_G28
Machine Type: Cartesian
Probe: BLTOUCH
Probe Offset X:39 Y:6 Z:-2.98 (Right-Back & Below Nozzle)
Auto Bed Leveling: BILINEAR (disabled)

set_bltouch_deployed(0)
  current_position=(0.00, 0.00, 0.00) : setup_for_endstop_or_probe_move
> endstops.enable(true)
Raise Z (before homing) to 5.00
>>> do_blocking_move_to(0.00, 0.00, 5.00)
echo:busy: processing
<<< do_blocking_move_to
>>> homeaxis(X)
Home 1 Fast:
>>> do_homing_move(X, -349.50, [50.00])
  current_position=(0.00, 0.00, 5.00) : sync_plan_position
echo:busy: processing
echo:busy: processing
<<< do_homing_move(X)
>>> set_axis_is_at_home(X)
For X axis:
 home_offset = 0.00
 position_shift = 0.00
 soft_endstop_min = -18.00
 soft_endstop_max = 215.00
> home_offset[X] = 0.00
  current_position=(-18.00, 0.00, 5.00) : 
<<< set_axis_is_at_home(X)
  current_position=(-18.00, 0.00, 5.00) : sync_plan_position
  current_position=(-18.00, 0.00, 5.00) : > AFTER set_axis_is_at_home
<<< homeaxis(X)
>>> homeaxis(Y)
Home 1 Fast:
>>> do_homing_move(Y, -328.50, [50.00])
  current_position=(-18.00, 0.00, 5.00) : sync_plan_position
echo:busy: processing
<<< do_homing_move(Y)
>>> set_axis_is_at_home(Y)
For Y axis:
 home_offset = 0.00
 position_shift = 0.00
 soft_endstop_min = -4.00
 soft_endstop_max = 215.00
> home_offset[Y] = 0.00
  current_position=(-18.00, -4.00, 5.00) : 
<<< set_axis_is_at_home(Y)
  current_position=(-18.00, -4.00, 5.00) : sync_plan_position
  current_position=(-18.00, -4.00, 5.00) : > AFTER set_axis_is_at_home
<<< homeaxis(Y)
Z_SAFE_HOMING >>>
  current_position=(-18.00, -4.00, 5.00) : sync_plan_position
  destination=(68.00, 101.00, 5.00) : Z_SAFE_HOMING
>>> do_blocking_move_to(68.00, 101.00, 5.00)
<<< do_blocking_move_to
>>> homeaxis(Z)
  current_position=(68.00, 101.00, 5.00) : set_probe_deployed
deploy: 1
do_probe_raise(10.00)
>>> do_blocking_move_to(68.00, 101.00, 12.98)
echo:busy: processing
echo:busy: processing
<<< do_blocking_move_to
>>> do_blocking_move_to(68.00, 101.00, 12.98)
<<< do_blocking_move_to
Home 1 Fast:
>>> do_homing_move(Z, -300.00, [4.00])
set_bltouch_deployed(1)
  current_position=(68.00, 101.00, 0.00) : sync_plan_position

Franks3dShop on 19 Jun 2018

Following this issue for a while now. An update from Marlin developers on plans for resolution would be useful. Don't know how this works exactly with Marlin development, but it would be helpful to know if this bug (and it clearly is one) is being address or not. Thanks, Ron.

kiwironnie on 7 Jul 2018

Hi, I since have switched to 2th of july build, and transfered to the MOSI MOSO and SCK hardware SPI, disabled SDCard (I use Octoprint) and I have no problem now...

Franks3dShop on 7 Jul 2018

🎉1

Original issue resolved. If there are any new problems related to homing, please post a new issue about it.

thinkyhead on 7 Jul 2018

So does that mean that the TMC2130 SPI homing problem has been fixed in the 2nd July Marlin build?
A definitive answer would be helpful, particularly as the problem is potentially damaging enough to the rig not to want to try switching off stealthchop again until there is some certainty that it has. Cheers, Ron

kiwironnie on 7 Jul 2018

For my part what changed:

I have new Waterrott 1.1 drivers (the others blew up they were too cheap).
Replaced the board (MKS 1.4) it went with the drivers.
Moved back to the hardware SPI.
Disabled SDCard.

And homing works now, Stealthshop is OFF.

And I will add a MAX7219 8x8 leds display, since it looks cool and is already on my other printer.

Franks3dShop on 7 Jul 2018

👍1

Good to hear that Stealthchop off is working for somebody. However it sounds pretty hit and miss. What exactly has changed in the hardware setup / Marlin version that works that fixes the root cause of the problem? Is there an understanding of the likely root cause? Until that's clear it doesn't make sense to close this problem report. Or am I missing something?

kiwironnie on 8 Jul 2018

I realize that this issue is closed, but I can add on to it a bit. I have an ender 3 running a source version of Marlin with the BLTOUCH sensor added on. I had this issue after using the serial monitor to set my Z offset. After setting it, any attempt to auto-home (both with the serial monitor and with the LCD on the printer) caused the X axis to ram into the right side of the printer (opposite of the limit switch).

I've done some testing and I think I've narrowed it down. I only have this issue if I set the offset using M851 Z through the serial monitor. If I use the printer to set the probe offset normally then I have no issues, even after save/load/reset. Hopefully this helps!

This is Marlin version 1.1.9 from 2018-08-01

kuzai on 26 Oct 2018

This is most likely similear to some issues recently fixed in 2.0, please test the current 2.0.x bugfix branch and confirm if this still exists.

InsanityAutomation on 26 Oct 2018

Will do, thanks! I'll report back in a bit if that solves the problem

kuzai on 26 Oct 2018

Hi,
I'm currently getting this issue using the latest 2.0.x bugfix with my Anet A8.
For the last 10+ prints it was homing to the left and now it suddenly changed.

I'm not in a place to get a new board and drivers. I do plan on getting them in the future. However I was wondering if their is a quick fix for this.

SachiKaur on 8 Jun 2020

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[bot] on 7 Aug 2020

Marlin: [bugfix-1.1.x] After a second G28 the X-axis always moves to the right instead of to the left!

All 69 comments

After reset

After first G28

DOES NOT WORK (on the real printer)

WORKS (on the real printer)

WORKS (in test environment)

Related issues