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

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

I have a Mendel90 which has two NEMA17 steppers (x16 microstepping) in series (E.g. to one single connection on the 'cape) for the Z axis. The fabulous folks on the IRC channel tactfully pointed out I had a too low current to drive two z motors, and a much too high speed. Having sorted that out, homing Z seemed to work.

Now however I’m trying to get ‘0’ to mean the bed, so set home_z = -0.190 - hoping that would be roughly 1cm off the bed (E.g 1cm less than the roughly 20cm build height), so I could measure it more precisely.

Here’s what happens:

  1. The z-axis moves up towards my z endstop
  2. Hits the end stop then pulls back
  3. Moves back up to the end stop (usually this is slower, but I’m already going slow)
  4. Then starts moving down towards the bed (as I wanted). However, it only moves about 6cm before stopping, and Octoprint just stops responding. I see no Redeem errors in /var/log/syslog. Without restarting redeem or octoprint, it does after a few minutes begin responding again.

The z driver is very hot to the touch, so wondering if this is what’s happening? Certainly the steps/mm for z is right (Easy with an M6 rod - 1mm pitch, 200 rotations).

Question is what do I do? I’ve taken the current down to 1.0 (remember that’s for two motors), and when it was too low, one of them didn’t turn, causing the other to attempt to bend the x-carriage!

Here’s my full config:

[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.00
offset_y = 0.00
offset_z = 0.00

Stepper e is ext 1, h is ext 2 [In powers of 2, so ‘4’ is 2^4 = 16]

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

Drivers are rather 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_speed_e = 0.02

home_x = -0.10
home_y = -0.10
home_z = -0.190

[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

Set your home_* values to 0 until you are done with the end stop config.
Also, not related to this, the microstepping table is no longer 2^n like with Rev A. http://wiki.thing-printer.com/index.php?title=Redeem#Steppers

Also of interest is the note on homing: http://wiki.thing-printer.com/index.php?title=Redeem#Geometry

Thanks @Elias_Bakken - Believe it or not, I did RTFM :slight_smile: In fact, that exact section!
Upon second reading though I see that ‘travel_*’ is important no only for its magnitude but sign. It seems to be a mixture of two concepts to me. On the one has it specifies how large the build area is, and implies something has gone wrong if you’ve travelled more than this. To me that just seems like a safety feature?

But its sign seems to specify what direction is up/down, left/right etc.

Yes, no need to search further than necessary in case it has been configured wrong.

It seems this is unintuitive for many people, though, so perhaps it would need some more attention.

Seems to me you have it almost right except for the home_z stuff.

Hah - so now I’m really confused :slight_smile: Your first response said to leave the home_ values, but now you seem to say I’ve got it right except these? Sorry if I’m being dim. I do really think there’s something not working, as even when I don’t touch home_z, if the z axis is too far from the top, it doesn’t reach the end stop and stops without any messages, and stops responding for a few minutes.

Depending on your redeem version, the home_* values are either set to 0 in default.cfg or implicitly defined by the soft end stops. Either way, set them to 0 explicitly and then work on them only after homing is working right.

I’m using this version: Redeem initializing 1.2.2~Predator

When I import my config I see:

May 26 17:38:08 kamikaze octoprint[319]: 2016-05-26 17:38:08,977 - root - WARNING - Unknown option in file: travel_x in Geometry
May 26 17:38:08 kamikaze octoprint[319]: 2016-05-26 17:38:08,983 - root - WARNING - Unknown option in file: travel_y in Geometry
May 26 17:38:08 kamikaze octoprint[319]: 2016-05-26 17:38:08,988 - root - WARNING - Unknown option in file: travel_z in Geometry
May 26 17:38:09 kamikaze octoprint[319]: 2016-05-26 17:38:09,000 - octoprint.plugins.redeem - INFO - Renaming /tmp/octoprint-file-upload-hIVpTt.tmp to /etc/redeem/mendel90.cfg
May 26 17:38:09 kamikaze octoprint[319]: 2016-05-26 17:38:09,058 - octoprint.plugins.redeem - ERROR - get_profiles

But in every config example I see the travel_* options are in [Geometry]

Yes, that is the reason why I advocate having explicit values defined in default.cfg instead of letting them be defined by the soft end stops as is currently the implementation. So automatic checking can be performed.

here’s my exact config, pls can you tell me where I’m going wrong?

[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

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

Drivers are rather 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

[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_speed_e = 0.02

home_x = 0
home_y = 0
home_z = 0

[Probe]

Define the origin in relation to the endstops [meters]

offset_x = 0.00
offset_y = 0.00
offset_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

[Heaters]

Epcos 100 K

temp_chart_E = B57560G104F

Epcos 100 K

temp_chart_HBP = B57560G104F

Hi Marcos, here’s my local config for my prusa i3 which looks to be very similar to the mendel90. May be useful for reference.

http://files.mrzood.com/2020-i3-local.cfg

Thanks @Chris_Romey - I downloaded and imported your config (not to use it, but just to check the Redeem logs), and I still see warnings:

May 26 18:20:02 kamikaze octoprint[328]: 2016-05-26 18:20:02,094 - root - WARNING - Unknown option in file: offset_x in Geometry
May 26 18:20:02 kamikaze octoprint[328]: 2016-05-26 18:20:02,099 - root - WARNING - Unknown option in file: offset_y in Geometry
May 26 18:20:02 kamikaze octoprint[328]: 2016-05-26 18:20:02,103 - root - WARNING - Unknown option in file: offset_z in Geometry
May 26 18:20:02 kamikaze octoprint[328]: 2016-05-26 18:20:02,107 - root - WARNING - Unknown option in file: travel_y in Geometry
May 26 18:20:02 kamikaze octoprint[328]: 2016-05-26 18:20:02,110 - root - WARNING - Unknown option in file: travel_x in Geometry
May 26 18:20:02 kamikaze octoprint[328]: 2016-05-26 18:20:02,115 - root - WARNING - Unknown option in file: travel_z in Geometry

That’s with your config!

Are you not seeing issues when you import your config, in /var/log/syslog ?

So I think the log errors are a red herring (I only started looking anyway, because of issues). I’ve put my config into GitHub:

https://github.com/marcosscriven/3dmodels/blob/4e4de568de522c786c64ee6141ed2d8acadeefa2/redeem/mendel90.cfg

With that config - x and y homing works great. Z has some VERY WEIRD behaviour. If it’s my fault, please tell me why.

If (and only if) the z axis is within 60mm of the end stop, homing works. If not, it seems to only travel the 60mm before stopping. Then, a few minutes later, without any further input, starts again, going away from the z axis.

Another quirk. If I’ve successfully homed z (and as you can see, I’m explicitly, for now, setting home_* and offeset_* to 0), and I issue G1 Z-70.0, it will only travel 60mm before stopping.

There’s a 60mm (or very near) limit in my z-axis somewhere. Nothing in the logs to suggest anything’s gone wrong, but Redeem stops responding for a few minutes.

Marcos, I do not get those errors.

Did you symlink one of the printer profiles as printer.cfg?

@Chris_Romey @Elias_Bakken - Here’s a video, because I just can’t see what in my config would explain this behaviour. Sorry in advance it’s a bit rambling: https://www.youtube.com/watch?v=GynoB4rfrm0

Goeland86 on IRC has suggested trying Redeem develop branch directly from the Bitbucket repo, which I’ll try when I get a chance.

First of all, I would say that z=0 should be close to the bed, so add some offset to the z. My best guess for why it stops at 60 is perhaps a soft end stop preventing it from going further down.

Hrm… Shouldn’t need the dev branch. The thing that’s throwing me off is your homing position values. I would consider where your endstops are as home 200,200,200 rather than 0,0,0. But I digress.

I agree with you both - the aim is for z=0 to be the bed. But I thought the guidance was to get the end stops / homing working first. I’m clear on how to use the offset_z - but not even getting back to the z stop if more than 60mm away seems bizarre. Also, the same setup for x and y is fine - with z its not.