How to make driver of E1 for motor Z2 on RAMPS 1.4?

[Nicolayka]

Help please!

// A single Z stepper driver is usually used to drive 2 stepper motors.
// Uncomment this option to use a separate stepper driver for each Z axis motor.
// The next unused E driver will be assigned to the second Z stepper.
#define Z_DUAL_STEPPER_DRIVERS

#ifdef Z_DUAL_STEPPER_DRIVERS
  #undef EXTRUDERS
  #define EXTRUDERS 1
#endif

[thinkyhead]

// A single Z stepper driver is usually used to drive 2 stepper motors.
// Uncomment this option to use a separate stepper driver for each Z axis motor.
// The next unused E driver will be assigned to the second Z stepper.
//#define Z_DUAL_STEPPER_DRIVERS

#if ENABLED(Z_DUAL_STEPPER_DRIVERS)

  // Z_DUAL_ENDSTOPS is a feature to enable the use of 2 endstops for both Z steppers - Let's call them Z stepper and Z2 stepper.
  // That way the machine is capable to align the bed during home, since both Z steppers are homed.
  // There is also an implementation of M666 (software endstops adjustment) to this feature.
  // After Z homing, this adjustment is applied to just one of the steppers in order to align the bed.
  // One just need to home the Z axis and measure the distance difference between both Z axis and apply the math: Z adjust = Z - Z2.
  // If the Z stepper axis is closer to the bed, the measure Z > Z2 (yes, it is.. think about it) and the Z adjust would be positive.
  // Play a little bit with small adjustments (0.5mm) and check the behaviour.
  // The M119 (endstops report) will start reporting the Z2 Endstop as well.

  //#define Z_DUAL_ENDSTOPS

  #if ENABLED(Z_DUAL_ENDSTOPS)
    #define Z2_USE_ENDSTOP _XMAX_
    #define Z_DUAL_ENDSTOPS_ADJUSTMENT  0  // use M666 command to determine/test this value
  #endif

#endif // Z_DUAL_STEPPER_DRIVERS

You've enabled the option, and are doing great so far.

What is your specific question?

[Nicolayka]

Tried to enable the "#define Z_DUAL_STEPPER_DRIVERS", from which the second motor is operating, but he has mad speed.

[thinkyhead]

Has he the same micro-stepping jumpers installed for both stepper drivers (Z and E1)?

[linux01d]

I have MKS Base v1.5 with 5 drivers on my Sunhokey Prusa i4 (clone of prusa i3). I have the same problem with Marlin 1.1.0 (branch «1.1.x»), one motor turns much more faster than another «original» z-axis, being connected to «Z-mot » port. The same hw works very well with Marlin 1.0.0, I've changed firmware several times and ensured that it's software/configuration problem, no stepping motor adjustment needed. But I don't have any idea how to fix it.

[Bob-the-Kuhn]

I just tried Marlin-bugfix-1.1.x from yesterday and my dual Z is working correctly.

Did you transfer your machine specific items to the config files that came with 1.1.0 ? If you just dropped in the ones from RC8 and older can get strange results (and a lot of compiler errors).

If your config files are up to date then please post them here. Just ZIP them up and drop them on your reply.

[linux01d]

Yes, I cooked it from the scratch :) One-by-one, taking care about deprecated parameters. Also, I can upload ZIP, if it still needed :) Thanks!

[linux01d]

I just tried Marlin bugfix-1.1.x (c262ea92e00b9bc8e8935f46e4dc6fd0e4066486) with this configuration. Still the same, it doesn't work :(

[Bob-the-Kuhn]

Z_DUAL_STEPPER_DRIVERS needs to be enabled in configuration_adv.h

[linux01d]

Z_DUAL_STEPPER_DRIVERS needs to be enabled in configuration_adv.h

Here it is, I suppose. Am I wrong?

[Bob-the-Kuhn]

Correct

[linux01d]

Should I open different issue for my case?

[Bob-the-Kuhn]

No need to open another issue.

Is your dual Z working properly?

[linux01d]

Is your dual Z working properly?

Nope.

[Bob-the-Kuhn]

Time for some sanity checks.

Please send a photo of how the Z2 motor is attached to the controller.

Disconnect the two Z motors from the belts/screws so the motors can turn freely.

• Do both motors turn in the same direction at the same speed?
• Swap the cables for the two Z motors AT THE CONTROLLER. Do both motors turn in the same direction at the same speed?

[linux01d]

Please send a photo of how the Z2 motor is attached to the controller.

Connected to E1-mot port.

Disconnect the two Z motors from the belts/screws so the motors can turn freely.

Do both motors turn in the same direction at the same speed?

Same direction, but different speed.

Swap the cables for the two Z motors AT THE CONTROLLER. Do both motors turn in the same direction at the same speed?

Same direction, different speed.

Video

[linux01d]

MKS Base v1.5

[Bob-the-Kuhn]

Marlin 1.0.? works Marlin 1.1.? Z motors spin at different speeds in same direction bugfix-1.1.x Z motors spin at different speeds in same direction

You've definitely got me scratching my head.

Here's a long shot. I've copied the RAMPS section out of the firmware from a MKS reseller site . See if it's better behaved with this file when using bugfix-1.1.x pins_RAMPS.zip

[linux01d]

I have spare board MKS Base v1.5 and can make more photos at any time (just ask), but don't have motors for experiments, I'll have to use my printer.

[Bob-the-Kuhn]

Before I kick this up to more experienced people, lets see if we can better identify when things went wrong.

Please try Marlin RC8. Unfortunately it means you'll have to translate the config files as names and options have changed between RC8 & 1.1.x.

[Bob-the-Kuhn]

I realized today that in the video that the one Z motor was running a lot faster with 1.1.x than with 1.0.x.

I can't figure out why that's happening. I used your configuration files, downloaded it and printed out a list of the pins and the functions assigned to them. Z_STEP and E1_STEP have no other functions assigned to those pins.

Besides trying RC8 I'd also like you to try the following with bugfix-1.1.x:

#define DEFAULT_AXIS_STEPS_PER_UNIT   { 80.4, 80.4, 400*1.010, 400*1.010 }
#define DEFAULT_AXIS_STEPS_PER_UNIT   { 80, 80, 404, 96 }

Please also see if it's the Z or the E1 channel that's spinning too fast. Just unplug one & see if the other is spinning at the normal or the fast speed.

[Bob-the-Kuhn]

@thinkyhead , @Roxy-3D - I'm out of ideas on this one. A fresh perspective is needed.

He's running dual Z drivers on a MKS Base v1.5 controller and seeing the following:

• Marlin 1.0.? - both Z steppers rotate properly
• Marlin 1.1.0 - one Z stepper rotates much faster than the other, the other is rotating at the 1.0.? speed
• Marlin bugfix-1.1.x - same problem as Marlin 1.1.0
• When I issue M43 I, there are no extra functions assigned to the Z and the E1/Z2 pins.
• The speed issue follows the channel. Swapping stepper cables moves the extra speed to the other stepper.

Since it's an MKS product we can't get a schematic for it. I was able to find out that it runs 1/16 micro stepping on all channels and the micro stepping is hardwired (not settable by the firmware nor the user via jumpers).

The driver ICs are soldered to the board.

There's not an obvious firmware reason why they'd rotate at different speeds since both step pins are written with the same macro.

The only thing I can think of that the firmware change might have affected is the step pulse width to the controller chips. Usually if the pulse is too narrow then we'd be losing steps. We could set the step pulse width to 100uS and see if that fixes it.

Maybe there's some marginal hardware.

• If the stepper current is too low then we'd be losing steps, not gaining them. Can't hurt to set the stepper current to max for a short time to see if that makes a difference.
• Signal interference between cables?

Another really far out idea would be to play with the pin assignments and see if we can find a pair of channels that rotate at the same speed.

[linux01d]

In the video at 2:36 you can notice how easy the motor stops by hand, with a simple touch, the torque is minimal there. On 1.0.x torque is high enough, I can't block it even with three fingers when it connected to the axis rod.

[linux01d]

@Bob-the-Kuhn, I'll try your seggestions ASAP.

[Bob-the-Kuhn]

A lot faster (4x-10x?) with little torque.

I was just looking through the A4988 data sheet and it'll try to recover from an over current event every 20-40uS. I wonder if this is why there are apparently more steps than should be.

The over current threshold is dependent on the Vref setting. Increasing Vref might actually be a solution. Maybe the pot has some corrosion/dirt in it. Going back and forth between the extremes a few times is usually enough to clear the corrosion/dirt out.

You can also try setting MINIMUM_STEPPER_PULSE to 10. 1 is the minimum for that chip. Don't know what the pulse width is when it's set to zero.

If turning the current up and setting MINIMUM_STEPPER_PULSE to 10 doesn't help then you could try moving the logical stepper channels to different sockets. The ZIP file contains pins_RAMPS.h files with that done. Save your current pins_RAMPS.h file and then drop in one out of the ZIP file. All you need to do is swap the cables pins_RAMPS.h.swapped.zip

[linux01d]

Hmmm, I'm sorry, but I didn't mentioned yet, that I used Marlin 1.0.0 provided by Sunhokey. May be their engineers modified some settings elsewhere excepting Configuration.h and Configuration_adv.h. Marlin firmware 1.0.x by Sunhokey.

[Bob-the-Kuhn]

It's possible. Digging it out would be a challenge.

Time to call it a night.

Talk to you tomorrow.

[Bob-the-Kuhn]

Status?

[Roxy-3D]

@Roxy-3D - I'm out of ideas on this one. A fresh perspective is needed. He's running dual Z drivers on a MKS Base v1.5 controller and seeing the following:

I'm sorry. I apologize. The way I read emails and issues caused me to miss this one. I didn't read this issue even though you flagged me on it.

The Dual Z-Motors is an example of Marlin code where I know the functionality is there but I've never used it or looked at it... (You do remember me saying: Nobody can even know 1/2 the details of the Marlin code base???) But if you want, I'll start digging in and we can bounce ideas back and forth.

[Bob-the-Kuhn]

My best guess is this is a hardware issue. Either the default stepper pulse width is marginal for the stepper IC or the current limit needs to be set higher.

[Roxy-3D]

or the current limit needs to be set higher.

I always assume this first. I turn the power up so I can just barely hold the stepper motor. A lot of times, that fixes the problem.

[thinkyhead]

I'm not sure where pulse width would affect torque. It should have no effect on holding torque, at any rate….

@linux01d Next, try swapping the stepper drivers and see if the problem still appears on the same stepper motor.

[Bob-the-Kuhn]

They're soldered to the board.

[Bob-the-Kuhn]

He's swapped stepper cables at the controller. The problem moved to the other stepper so the problem stays with the channel.

[Grogyan]

It does sound like one of the stepper drivers us going into thermal shutdown. Suggest calibrating the Vref for both drivers so that they are equal

[linux01d]

Status?

I'm on a long-time business trip right now. I'll be back only 22.06 and I'll be able to make tests from 24.06.

Suggest calibrating the Vref for both drivers so that they are equal

They are equal. I've adjusted them with voltmeter. 0.9v on potentiometers is enough and works fine under Marlin 1.0.x.

[linux01d]

It does sound like one of the stepper drivers us going into thermal shutdown.

All drivers has heatsinks and 80mm fan over them. No thermal issues possible, I measured temperature with IR-thermometer, it just 40°C.

[Bob-the-Kuhn]

@linux01d - hope you're not stuck in the hotel room every night. Gets boring really quick especially when you don't speak the language.

[thinkyhead]

Did you try changing MINIMUM_STEPPER_PULSE and see no effect? It's meant to add extra time, but only if extra time is needed. So, apart from being precise, it depends on having a correct estimate of the number of cycles that is already eaten up by code between the start and end of a pulse. The more steppers the Stepper::isr has to process, the more likely it is that the proper amount of delay is being applied already. Also, if other steppers are behaving properly then chances are there's enough delay, and MINIMUM_STEPPER_PULSE won't have any effect.

Still, it can be revealing to mess with MINIMUM_STEPPER_PULSE to see whether it does have any effect. This might help rule out the length of pulses as being involved, or show at least how changing stepper pulse length might affect steppers — not just the problem one. The low range would be 9 or 10ms, and the higher range around 15. If you set it to 20 or more you'll hit a point of failure.

Anyway, the code pertaining to pulsing the Z2 stepper is indeed unchanged from the code in earlier versions of Marlin. Without knowing some obvious difference it's a tricky problem to narrow down.

[Roxy-3D]

The other thing I do when a motor loses position is turn the acceleration and max feed rate way down. That may not be the problem, but it usually helps me isolate the problem.

[linux01d]

I'm still alive and I'm going to try your suggestions at weekend. Thanks for patience!

[linux01d]

MINIMUM_STEPPER_PULSE=10 with original pins_RAMPS.h doesn't help. MINIMUM_STEPPER_PULSE=15 with original pins_RAMPS.h doesn't help.

---

MINIMUM_STEPPER_PULSE=0 with "pins_RAMPS.h.swapped E0 & E1" works, axis Z is ok. Problem moved to extruder (as expected, cause cables swapped).

---

MINIMUM_STEPPER_PULSE=0 with "pins_RAMPS.h.swapped Z & E0", axis Z is NO ok, one motor (on channel E1) turns much faster.

[linux01d]

I have spare MKS Base v1.5. Is there a sense to try it?

[FHeilmann]

I checked the PIN assignments of the Sunhokey fork against the latest Marlin, they are identical so we can assume that the MKS1.5 at least as far as steppers go, is wired up like a MKS1.3.

before you attempt the solution below: Can you tell which of the Z-Steppers is turning too fast? (The one connected to Z or the one connected to E1?)

edit: just saw you already tried that, sorry.

If it is the stepper connected to E1, you can maybe try to check for a hardware issue by making the following changes to pins_RAMPS.h:

Change:

#define Z_STEP_PIN         46
#define Z_DIR_PIN          48
#define Z_ENABLE_PIN       62
#define Z_CS_PIN           40

#define E0_STEP_PIN        26
#define E0_DIR_PIN         28
#define E0_ENABLE_PIN      24
#define E0_CS_PIN          42

#define E1_STEP_PIN        36
#define E1_DIR_PIN         34
#define E1_ENABLE_PIN      30
#define E1_CS_PIN          44

to

#define Z_STEP_PIN         46
#define Z_DIR_PIN          48
#define Z_ENABLE_PIN       62
#define Z_CS_PIN           40

#define E1_STEP_PIN        26
#define E1_DIR_PIN         28
#define E1_ENABLE_PIN      24
#define E1_CS_PIN          42

#define E0_STEP_PIN        36
#define E0_DIR_PIN         34
#define E0_ENABLE_PIN      30
#define E0_CS_PIN          44

and plug your Z-steppers into the sockets labeled Z and E0 and the extruder-stepper into the socket labeled E1.

This change will move the second Z motor to another driver, so if everything works after this change, your E1 stepper driver is faulty. If the problem still persists, it is a software issue.

[linux01d]

define Z_STEP_PIN 46

define Z_DIR_PIN 48

define Z_ENABLE_PIN 62

define Z_CS_PIN 40

define E1_STEP_PIN 26

define E1_DIR_PIN 28

define E1_ENABLE_PIN 24

define E1_CS_PIN 42

define E0_STEP_PIN 36

define E0_DIR_PIN 34

define E0_ENABLE_PIN 30

define E0_CS_PIN 44

I've tried this on BOTH CONTROLLERS I have :) They works without difference, but:

1. Swapped E0 and E1 brings Z-axis work ok, but extruder turns much faster, than should to.
2. Marlin v1.0.1 hacked by chinese Sunhokey works fine without issues.

I ensured with this experiment that both controllers are ok, but E1 port had to be tuned some other way as Sunhokey do.

Any ideas here?

[linux01d]

ping :)

[linux01d]

I think that MKS Base v1.5 needs special customization for E1 in case of Z2 usage.

[linux01d]

:(

[disco22522]

I'm trying to use the dual z motor function, where e1 is the other stepper driver. I have RAMPS 1.4 with mega2560. Both of the motors work, but only if one or the other is plugged into the z-axis pins. Uncommenting #define Z_DUAL_STEPPER_DRIVERS does not seem to work, and defining the pins in pins.h with "36, 34, 30" for step, dir, enable, does not work.

[fiveangle]

1. Swapped E0 and E1 brings Z-axis work ok, but extruder turns much faster, than should to.
2. Marlin v1.0.1 hacked by chinese Sunhokey works fine without issues.

Schematic of MKS Base shows it has MCU-addressable microsteping for the A4988 but I don't see any config for this in the pins file. Looks like someone needs to fix the MKS base pins file to support it:

Schematic (converted from xps on RRW) (3 files merged).pdf

Then set microsteps in Configuration_adv.h:

// Microstep setting (Only functional when stepper driver microstep pins are connected to MCU.
#define MICROSTEP_MODES {16,16,16,16,16} // [1,2,4,8,16]

Although it's probably worth checking with a VOM if the step config pins are actually tied to the MCU on your board, or if they're just hard-soldered:

A4988 Datasheet

Where is the source for the original Marlin that was on it you said was working ?

-=dave

[linux01d]

Where is the source for the original Marlin that was on it you said was working ?

This comment.