I think the stepper drivers are shutting down when I home the Z axis.

Is the Z axis driver getting extremely hot? perhaps it’s triggering temp shutoff. Especially at 1amp. Grasping at straws, really. But, it may need active cooling at that amperage. I use H as a Z slave so I don’t have to power both steppers off of one driver.

I noticed you pressed down a bunch of times after hitting the mark, that might cause it to be spending time trying to move beyond the point. I think the current implementation needs you to go back up that same amount, which ‘seems’ like a block.

So this morning I’ve just tried this config. It’s different in two ways.

  1. I flipped the sign of the travel to negative, and the ‘home_speed_’ values to positive.

  2. I set the ‘offset_’ values to 18cm (2cm less than the size of the printer), in case it was hitting a ‘soft’ end stop.

I’m seeing the same thing. x and y home work fine and as described in the wiki:

  • They go to the end stop
  • They back off a bit and go back slower
  • They go to the offset - which with my latest config is a couple of centimetres short, as configured and expected

For the z homing the first two happen. But while it’s on its way to the offset_z (I.e back towards the bed, away from the z1 end stop), it again stops at this strange magic number of 60mm. Because I’ve set the offset_z to nearly the full height, I don’t think its’s the issue @Elias_Bakken suggested.

Because it’s always that exact distance from the end stop I’m skeptical it’s the driver overheating, as even if I’ve moved the z-axis up and down a bit first (heating up the driver), it always still stops after that distance.

What’s the next step here please? Do I have a broken cape or board?

Git hash: https://github.com/marcosscriven/3dmodels/blob/61df324853892b15c3969f1f2371157200a20fc9/redeem/mendel90.cfg

Pasted here for ease of ref:

[System]

[Geometry]

Cartesian XY

axis_config = 0

Set the total length each axis can travel [meters]

travel_x = -0.20
travel_y = -0.20
travel_z = -0.20

Define the origin in relation to the endstops [meters]

offset_x = -0.18
offset_y = -0.18
offset_z = -0.18

[Steppers]
microstepping_x = 8
microstepping_y = 8
microstepping_z = 8
microstepping_e = 8

Drivers are rated 1.5 max. Z needs more as two in series.

current_x = 0.5
current_y = 0.5
current_z = 1.0
current_e = 0.6

steps_pr_mm_x = 4
steps_pr_mm_y = 4
steps_pr_mm_z = 200
steps_pr_mm_e = 33.4

Only one extruder

in_use_h = False

[Heaters]

Epcos 100 K

temp_chart_E = B57560G104F

Epcos 100 K

temp_chart_HBP = B57560G104F

[Endstops]
end_stop_X1_stops = x_ccw

Normally you’d use Y1 - but seems to be broken on mine

end_stop_Y2_stops = y_ccw
end_stop_Z1_stops = z_ccw

[Homing]

Homing speed for the steppers in m/s

home_speed_x = 0.02
home_speed_y = 0.02
home_speed_z = 0.001

home_x = 0.00
home_y = 0.00
home_z = 0.00

[Planner]

Max speed for the steppers in m/s

max_speed_x = 0.1
max_speed_y = 0.1
max_speed_z = 0.001
max_speed_e = 0.1

I’ve also just been experimenting with G1 Z movements - and it’s always this 60mm limit, in either direction.

Here’s an example:

  1. Homed z (when it was just a few cm from the end stop). That again stopped on its way to offset_z at the 60mm mark

  2. Checking the printer position, it thinks it’s at z=0 (I.e that it’s at home). But in reality it still has another 12cm to go to match the configured 18cm offset_z

  3. Next I issue G1 Z-70, and it moves towards the bed 60mm before again stopping. Getting the position shows the software thinks z=-0.07, even though it again has only moved 60mm.

I’ve tried this multiple times (E.g while the z-driver is still warm from previous tries), and it’s always the same. It seems it’s not really a z homing issue, but an issue moving more than 60mm in either direction on the z axis.

Here’s debug log while homing z. Looks like a problem with ‘Stepper watchdog timeout’

(Also copied to http://paste.ubuntu.com/16727240/ )

May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG Executing G28 from buffered G28 Z0
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG homing [‘Z’]
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG endstop active mask = 0b111111
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG homing internal [‘Z’]
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG Doing homing for Z
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG Search: {‘Z’: 0.2} at 0.001 m/s, 0.5 m/s^2
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG Backoff to: {‘Z’: -0.01}
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG Fine search: {‘Z’: 0.012}
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG Center: {‘Z’: 0.18}
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG Enabling stepper Y
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG Enabling stepper X
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG Enabling stepper Z
May 27 07:34:49 kamikaze redeem[311]: 05-27 07:34 root DEBUG Enabling stepper E
May 27 07:34:58 kamikaze systemd-timesyncd[198]: interval/delta/delay/jitter/drift 64s/-0.003s/0.048s/0.001s/+0ppm
May 27 07:35:12 kamikaze redeem[311]: 05-27 07:35 root DEBUG Poking watchdog
May 27 07:35:42 kamikaze redeem[311]: 05-27 07:35 root DEBUG Poking watchdog
May 27 07:35:42 kamikaze rsyslogd-2007: action ‘action 17’ suspended, next retry is Fri May 27 07:36:12 2016 [try http://www.rsyslog.com/e/2007 ]
May 27 07:35:48 kamikaze redeem[311]: 05-27 07:35 root INFO End Stop Z1 hit!
May 27 07:35:48 kamikaze redeem[311]: 05-27 07:35 root DEBUG Coarse search done!
May 27 07:36:02 kamikaze systemd-timesyncd[198]: interval/delta/delay/jitter/drift 128s/-0.003s/0.046s/0.003s/-12ppm
May 27 07:36:08 kamikaze redeem[311]: 05-27 07:36 root INFO End Stop Z1 hit!
May 27 07:36:08 kamikaze redeem[311]: 05-27 07:36 root DEBUG endstop active mask = 0b111111
May 27 07:36:08 kamikaze redeem[311]: 05-27 07:36 root DEBUG Home: {‘Z’: 0.0}
May 27 07:36:12 kamikaze redeem[311]: 05-27 07:36 root DEBUG Poking watchdog
May 27 07:36:12 kamikaze rsyslogd-2007: action ‘action 17’ suspended, next retry is Fri May 27 07:36:42 2016 [try http://www.rsyslog.com/e/2007 ]
May 27 07:36:42 kamikaze redeem[311]: 05-27 07:36 root DEBUG Poking watchdog
May 27 07:36:42 kamikaze rsyslogd-2007: action ‘action 17’ suspended, next retry is Fri May 27 07:37:12 2016 [try http://www.rsyslog.com/e/2007 ]
May 27 07:37:08 kamikaze redeem[311]: 05-27 07:37 root DEBUG Stepper watchdog timeout
May 27 07:37:08 kamikaze redeem[311]: 05-27 07:37 root DEBUG Disabling stepper Y
May 27 07:37:08 kamikaze redeem[311]: 05-27 07:37 root DEBUG Disabling stepper X
May 27 07:37:08 kamikaze redeem[311]: 05-27 07:37 root DEBUG Disabling stepper Z
May 27 07:37:08 kamikaze redeem[311]: 05-27 07:37 root DEBUG Disabling stepper E
May 27 07:37:12 kamikaze redeem[311]: 05-27 07:37 root DEBUG Poking watchdog
May 27 07:37:12 kamikaze rsyslogd-2007: action ‘action 17’ suspended, next retry is Fri May 27 07:37:42 2016 [try http://www.rsyslog.com/e/2007 ]

Poking around here - I see the timeout stops the motors: https://bitbucket.org/intelligentagent/redeem/src/de9d0728f1c3c0a331c3b8134ea6e1921a3025cd/redeem/StepperWatchdog.py?at=master&fileviewer=file-view-default#StepperWatchdog.py-80

Ok - nearly fixed I think. Just to confirm I set my home_speed_x to just 0.01 as well, and homing x shows the same timeout issue. So it looks like I’m just the first replicape owner with a z axis that’s too slow :slight_smile:

Doesn’t seem to be documented here: http://wiki.thing-printer.com/index.php?title=Redeem

But I see the timeout is configurable here: https://bitbucket.org/intelligentagent/redeem/src/de9d0728f1c3c0a331c3b8134ea6e1921a3025cd/redeem/Redeem.py?at=master&fileviewer=file-view-default#Redeem.py-515

I see here this is where the stepper watchdog should be reset: https://bitbucket.org/intelligentagent/redeem/src/de9d0728f1c3c0a331c3b8134ea6e1921a3025cd/redeem/Printer.py?at=master&fileviewer=file-view-default#Printer.py-131

Maybe timeout could be calculated as a function of travel_ and home or max speed, instead of fixed? EDIT Or at least a warning in the logs if your timeout is less than the biggest move possible on that axis. I’ll add an issue to the repo.

So I just watched in relief as my z axis glided gracefully out of its 60mm cage: https://github.com/marcosscriven/3dmodels/commit/2cf121a5a691a7523340cc6947682b40d3410bee