Marlin: 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.

[fiveangle]

Okay, I only looked at it for a second earlier and saw MS1/MS2 on the sch. but on closer inspection, it appears they've earmarked 5/15, 92/93 for X_MS1/2, Y_MS1/2 only (not Z, E0, E1) but as they have no config for those pins in the release, I suspect the microstepping was scrapped entirely and all A4982 are hard-wired for 16 micro steps by pulling both MS1/2 high:

so that was just a wild goose chase.

Are you 100% confident you defaulted the EEPROM contents after upgrade ? Marlin should detect if it's not the expected layout and default it to the compiled defaults, but not everything always goes to plan.

If that doesn't resolve I'm having a hard time beleiving this works on the old Marlin (I couldn't see any of the videos or earlier files as they all come up deleted).

Regardless, if swapping E0 and E1 makes your Z work, then it sounds like you're golden and you just need to re-calibrate your extruder steps/mm setting so it's not spining so fast.

-=dave

[disco22522]

You have to go into Marlin with Arduino, go to pins_ramps.h and type out the pins for "Z2" as E1 pins. This wasn't readily apparent to me even in some guides so I hope this helps someone getting theirs to work.

[NiftyMaker]

Hey @linux01d, did you solved it? I'm having the same issue...

[thinkyhead]

You have to go into Marlin with Arduino, go to pins_ramps.h and type out the pins for "Z2" as E1 pins. This wasn't readily apparent to me…

For future reference, people, you don't have to edit any pins files for this feature. Just set Z_DUAL_STEPPER_DRIVERS and your next unused set of E pins will be auto-assigned to your Z2 pins. Done.

[psycha0s]

I tried to flash the latest Marlin 1.1.8 to my Sunhokey Prusa i4 and encountered the same issue. I spent 2 days analyzing what's going on and found that the ms2 pin on E1 stepper's driver is pulled down:

Thus, according to the A4982 datasheet, it works in a "Half Step" mode.

It seems that it is initialized wrong somewhere. The codebase is tremendously hard to read because of the insane preprocessor usage, so I couldn't find the exact place where it happens, but I think I was able to make a rough workaround. I just switched the appropriate pin to the output mode and set it to the high state. The patch is here, but please, try it at your own risk. I haven't tested it enough.

--- ./stepper.original.cpp  Mon Dec 25 07:52:04 2017
+++ ./stepper.cpp   Thu Dec 28 20:56:28 2017
@@ -1102,14 +1102,18 @@
   #endif
   #if HAS_E3_STEP
     E_AXIS_INIT(3);
   #endif
   #if HAS_E4_STEP
     E_AXIS_INIT(4);
   #endif
+  
+   SET_OUTPUT(4);
+   OUT_WRITE(4, HIGH);
+

   // waveform generation = 0100 = CTC
   SET_WGM(1, CTC_OCRnA);

   // output mode = 00 (disconnected)
   SET_COMA(1, NORMAL);

[fiveangle]

@phantom-code - pins for all boards are contained in pins.h:

#elif MB(MKS_BASE)
  #include "pins_MKS_BASE.h"          // ATmega1280, ATmega2560

pins_MKS_BASE.h has only these changes from pins_RAMPS.h:

#if HOTENDS > 2 || E_STEPPERS > 2
  #error "MKS BASE 1.0 supports up to 2 hotends / E-steppers. Comment out this line to continue."
#endif

#define BOARD_NAME "MKS BASE 1.0"

//
// Heaters / Fans
//
// Power outputs EFBF or EFBE
#define MOSFET_D_PIN 7

#define CASE_LIGHT_PIN            2

//
// M3/M4/M5 - Spindle/Laser Control
//
#define SPINDLE_LASER_PWM_PIN     2  // MUST BE HARDWARE PWM
#define SPINDLE_LASER_ENABLE_PIN 15  // Pin should have a pullup!
#define SPINDLE_DIR_PIN          19

#include "pins_RAMPS.h"

RAMPS has no HW support for MS1/MS2 driver microstep config:

//
// Steppers
//
#define X_STEP_PIN         54
#define X_DIR_PIN          55
#define X_ENABLE_PIN       38
#define X_CS_PIN           53

#define Y_STEP_PIN         60
#define Y_DIR_PIN          61
#define Y_ENABLE_PIN       56
#define Y_CS_PIN           49

#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

As I mentioned in my post above, I found no code in the MKS marlin fork that detailed the MS1/MS2 pin connections for the extruder drivers (nor for X & Y, which do appear in the sch) so I suspected they had both tied high (as I found on a later MKS sch diagram above).

If you found MS1 and/or MS2 for the extruder drivers (or any of the drivers) configurable via pins on the MCU, then all that should be required is to determine which connect to each, and add the logic in pins_MKS_BASE.h above for the [axis]_[ms pin]_PIN (e.g. E1_MS1_PIN). Example from pins_MINIRAMBO.h:

// Microstepping pins - Mapping not from fastio.h (?)
#define X_MS1_PIN          40
#define X_MS2_PIN          41
#define Y_MS1_PIN          69
#define Y_MS2_PIN          39
#define Z_MS1_PIN          68
#define Z_MS2_PIN          67
#define E0_MS1_PIN         65
#define E0_MS2_PIN         66

This would be a big plus for many users who are struggling to attain required speed at 16/th microstepping on all axis. PINS_DEBUGGING feature may be useful for identifying which pins are connected to the respective MS1/MS2 of each driver.

-=dave

[psycha0s]

@fiveangle yes, I realized the same thing: there are no MS1/MS2 pin definitions in pins_RAMPS.h nor in pins_MKS13.h. And during my investigation I found that they are tied high and at the same time they are connected to the MCU. So, if the MCU doesn't touch them, we get the 1/16 step mode. I just took the PG5 (OC0B) pin (it's connected to the MS2 input of the E1 stepper driver) and switched it to get the right mode. I put my patch here in hope it can be useful for people who have this issue. Maybe someone familiar with Marlin codebase will be able to find the reason that causes the issue or even add the microstepping support for MKS boards.
PS: I think I can try to find all required pin numbers and report back.

[fiveangle]

If you find the pins, it would be easy to add the config

-=dave

[psycha0s]

So, I took the schematic from this comment and correlated GPIO pin names with DIO#_PIN definitions from the fastio1280.h file

Judging by this information we should have the following:

#define X_MS1_PIN 5
#define X_MS2_PIN 6

#define Y_MS1_PIN 59
#define Y_MS2_PIN 58

#define Z_MS1_PIN 22
#define Z_MS2_PIN 39

#define E0_MS1_PIN 63
#define E0_MS2_PIN 64

#define E1_MS1_PIN 57
#define E1_MS2_PIN 4

I'm going to test it tomorrow and report the result.

[kwijatkowski]

In my case second stepper is not spinning at all. Will try to use your pins map. Thank you :)

[kwijatkowski]

Copy pasted this table to pins_RAMPS.h Second stepper started to shake a little bit, but nothing more. Looks like you are on track ;)

[psycha0s]

So, I just added the definitions from my previous comment to the pins_RAMPS.h file and my axis steppers work fine. Z steppers are synchronized, everything looks good. I haven't tried to print anything yet because I have a little issue with my nozzle, but this is a different story.
PS: I'm using Sunhokey Prusa i4 with MKS 1.5.

[kwijatkowski]

Did you introduce any other modifications to code? Is this #define Z_DUAL_STEPPER_DRIVERS and pin map all I need?

[psycha0s]

These are the only files I changed

[fiveangle]

@phantom-code - can you make the changes in the appropriate pins file ? (pins_MKS_BASE.h I presume) and confirm that works (no changes to pins_RAMPS.h since this is not for the RAMPS), then submit a PR so it will be fixed for everyone ?

-=dave

[psycha0s]

@fiveangle honestly, choosing the right file is a bit confusing. There are two possible variants in boards.h for me:

#define BOARD_MKS_BASE          40    // MKS BASE 1.0
#define BOARD_MKS_13            47    // MKS v1.3 or 1.4 (maybe higher)

My motherboard is called "MKS Base V1.5", so logically it matches both variants. I use BOARD_MKS_13 right now, thus I think I should rather change the pins_MKS_13.h header.

[fiveangle]

My motherboard is called "MKS Base V1.5", so logically it matches both variants.

¿ qué ?

In pins_MKS_13.h:

#define BOARD_NAME "MKS > v1.3"

1.5 != 1.0 && 1.5 > 1.3 so I think it really only matches pins_MKS_13.h so that is where the changes should go, especially since you're already using that board definition.

The pins_MKS_BASE.h I don't see how it even works at all as it has pin 2 assigned to two different functions:

#define CASE_LIGHT_PIN            2

//
// M3/M4/M5 - Spindle/Laser Control
//
#define SPINDLE_LASER_PWM_PIN     2  // MUST BE HARDWARE PWM

I would leave pins_MKS_BASE.h alone and allowed to die it's lonely death, as I doubt there are any reasonable number of boards out there actually using it (which is why it's pretty much empty of any features, broken, and yet no one is complaining).

-=dave

[psycha0s]

@fiveangle

¿ qué ?

Well, it's "MKS Base" and it's "> v1.3" at the same time.

Alright, I'll change pins_MKS_13.h, test it, and make a PR if everything's good.

[mamama1]

wth was going on here :D i'm one step away from connecting my second Z motor to E1 on an MKS Gen 1.4 board, which also matches to pins_MKS_13.h.

what are your tests saying, @phantom-code?

[psycha0s]

@mamama1 I'll test it a little bit later today

[mamama1]

I'll report shortly if it even applies to MKS Gen 1.4

[mamama1]

@phantom-code nope, issue does not exist with Marlin 1.1.8 and MKS GEN 1.4.
Z Steppers are at Z and E1 and I have enabled Z_DUAL_STEPPER_DRIVERS.

[fiveangle]

@phantom-code - I see what you mean now about the pins confusion as for some reason I swear pins_MKS_13.h referenced "_MKS Base_" within it when I quickly looked at it (for versions 1.3 and higher). But I saw a PR #9008 merged for pins_MKS_BASE.hfor microstepping pins (which is what you are also working on) and so reviewed both (more than the 5s as before ;) and realize the pins_MKS_13.h is actually for MKS Gen (why it's not pins_MKS_Gen.h is a mystery, since "MKS_13" means little more than nothing 🤷‍♂️ . Regardless, from your picture above, you have the _MKS Base_

_MKS Base_:

http://reprap.org/wiki/MKS_BASE_1.0

Not:

_MKS Gen_:

BTW- It appears there are separate pages for MKS_GEN vs MKS_GEN_V1.1 - and they appear to be identical boards ? :

http://reprap.org/wiki/MKS_GEN
http://reprap.org/wiki/MKS_GEN_V1.1

Back to your work, PR #9008 by @karkla for pins_MKS_BASE.h adds this:

+/* Microstepping pins (reverse engineered at V1.4 - due to closed source schematics)
 +// Some new batches have the HR4982 (Heroic) instead of the A4982 (Allegro) as stepper driver. While most of the functionality is similar, the HR variant obviously doesn't work with diode smoothers (no fast decay)
 +// But the Heroic has a 128 µStepping mode where the A4982 is doing quarter steps (MS1=L / MS2=H). To achieve comfortable tests with the M350/M351 commands, the following definitions have to made:
 +// Example: M350 X4 Y4 ; Set X and Y Axis to quarterstep Mode to achieve MS1=0 and MS2=1
 +// A new board with a HR4982 will now perform 128 µSteps per Fullstep
 +// XSTEP,YSTEP ... must be adapted with M92 accordingly (128/16 => multiply by factor 8).
 +*/
 +#define X_MS1_PIN           5   // Digital 3  / Pin 5   / PE3
 +#define X_MS2_PIN           6   // Digital 6  / Pin 14  / PH3      
 +#define Y_MS1_PIN           59  // Analog 5   / Pin 92  / PF5
 +#define Y_MS2_PIN           58  // Analog 4   / Pin 93  / PF4
 +#define Z_MS1_PIN           22  // Digital 22 / Pin 78  / PA0
 +#define Z_MS2_PIN           39  // Digital 39 / Pin 70  / PG2
 +#define E0_MS1_PIN          63  // Analog 9   / Pin 86  / PK1
 +#define E0_MS2_PIN          64  // Analog 10  / Pin 87  / PK2
 +#define E1_MS1_PIN          57  // Analog 3   / Pin 93  / PF3
 +#define E1_MS2_PIN          4   // Digital 4  / Pin 1   / PG5

Which matches yours above:

#define X_MS1_PIN 5
#define X_MS2_PIN 6

#define Y_MS1_PIN 59
#define Y_MS2_PIN 58

#define Z_MS1_PIN 22
#define Z_MS2_PIN 39

#define E0_MS1_PIN 63
#define E0_MS2_PIN 64

#define E1_MS1_PIN 57
#define E1_MS2_PIN 4

So unless there are more pin updates you wanted to add, can you review that the latest bugfix resolves for you ? This would be defining board as MKS BASE with no changes to pins_MKS_BASE.hor pins_RAMPS.h that are in bugfix branch.

-=dave

[psycha0s]

@fiveangle I discovered a weird issue: my printer works fine by itself, but it seems like my Z steppers work at different speeds when my printer controlled by RepeiterHost.

[AnHardt]

Compare Marlins configuration with RepetierHosts and your slicers configuration.

[kizill]

@phantom-code I have the same issue in repetier host, and i found that if i connect to printer with terminal and send M350 it replies with
```MS1,MS2 Pins
X: 11
Y: 11
Z: 11
E0: 11
E1: 11
ok

And it replies with 

MS1,MS2 Pins
X: 11
Y: 11
Z: 11
E0: 11
E1: 10
ok
And if i send `M350 S16` from Repetier everything works OK again. **update** There is a pin collision, we both set#define POWER_SUPPLY 1in Configuration.h and it causes#define PS_ON_PIN 4``` in pins_MKS_13.h

[fiveangle]

I never understood why POWER_SUPPLY was defaulted to "1" in Configuration.h, since hardly anyone has a firmware-controlled power supply. Given this issue, perhaps it's high time someone submits a PR to change it to "0" ?

[psycha0s]

@fiveangle I cloned Marlin from the 1.1.x-bugfix branch and changed my configuration:

#define MOTHERBOARD BOARD_MKS_BASE
#define POWER_SUPPLY 0

Everything looks good for me. Z steppers work synchronously standalone and when controlled from RepeiterHost. I still have some extrusion issues (not related to this one) thus I can't make a full printing test.

[webhive]

@phantom-code Thank you! This fix work well on my Sunhokey Prusa I4. I had custom updated Marlin 1.1.3 which was work well until I updated it today to 1.1.8 and got the same issue - Z axis motors rotated with different speed. Wasted lot of time until found your solution.

[psycha0s]

@webhive I'm glad it helped. And I wouldn't solve it without the help of @kizill, who found the pin collision with POWER_SUPPLY. So, thank you @kizill!

[webhive]

Agree! God bless @kizill ! :)

[NiftyMaker]

And what if I do have an ATX PSU? Does it matter if I change that value to 0?

Does that firmware-controlled power supply option that @fiveangle says, is when I use a relay to turn ON/OFF the printer using a Raspberry Pi and octoprint? I'm planning to upgrade my electronics with a relay to do that...

[fiveangle]

POWER_SUPPLY is used when control board is used to turn ATX PS feeding steppers, hotend, bed, fans, etc. on/off. Using ATX PS on/off via RPi/OP happens upstream of control board so is completely independent of POWER_SUPPLY feature of Marlin.

[Jalofah]

Hello
For my part I try to do the opposite.
I want to get my NEMA17 on 1/4.

they are programmed on 1/16.
After replacing the belts with lead screws I need to pass X Y on 1/4 step.

MKS BASE V1.5

Do you know how to do it?

[thinkyhead]

If you have an MKS BASE with Heroic HR4982 stepper drivers then you would first set your MOTHERBOARD to BOARD_MKS_BASE_HEROIC. With these drivers you can only set 1x, 8x, 16x, or 128x micro-stepping. To set 8x on X and Y axes the command would be M350 X8 Y8.

[Jalofah]

Thanks man
I have Allegro driver
how to modify microstepping directly in marlin?

[Jalofah]

i have MKS BAS V1.4 Allegro 4982

[thinkyhead]

how to modify microstepping directly in marlin?

RAMPS boards have jumpers that can be set up for various amounts of micro-stepping, and some boards have digital control. Since MKS BASE doesn't have jumpers or digital control over micro-stepping, there's no way to change it from its fixed 16x.

[psycha0s]

@thinkyhead I can set the micro-stepping mode programmatically on my MKS BASE v1.5.

[Jalofah]

@code fantôme
can you tell me how to modify on the program MKS BASE v1.5?

[thinkyhead]

@phantom-code — Please share your pins file. None of ours define the micro-stepping CS pins. (We're only supporting up to MKS BASE 1.4.)

[psycha0s]

@thinkyhead you cut out these pin definitions from the bugfix-1.1.x branch yourself. See this commit, file pins_MKS_BASE.h. Maybe they should be defined in another file, I don't know. We discussed micro-stepping pins for MKS BASE 1.5 earlier in this thread and I was able to change them programmatically before I solved my issue. I don't need custom values now and use the default ones (16 micro-steps).

[thinkyhead]

Yes, I also was the one who added them in the first place. Whomever was my helpful authority on MKS BASE at the time didn't seem to know about different board versions. So… please help! Which versions of the MKS BASE board has them and which don't?

[psycha0s]

Well, I cant tell about other boards but the MKS BASE v1.5 that I have can control its microstepping pins.

[thinkyhead]

@phantom-code — Can you tell what kind of stepper drivers are on your board?
Are they A4982 or are they HR4982?

[psycha0s]

@thinkyhead honestly, I don't remember. I glued radiators on top of them so it's pretty hard to see.

[thinkyhead]

@phantom-code — The reason I ask is because we now have a MOTHERBOARD named BOARD_MKS_BASE_HEROIC that defines the needed micro-stepping pins and proper HIGH/LOW combinations used to set them. For Heroic HR4982 steppers the only allowed values are:

M350 S1    ; 1x micro-stepping
M350 S8    ; 8x micro-stepping
M350 S16   ; 16x micro-stepping
M350 S128  ; 128x micro-stepping

And for other drivers the allowed values are:

M350 S1    ; 1x micro-stepping
M350 S2    ; 2x micro-stepping
M350 S4    ; 4x micro-stepping
M350 S8    ; 8x micro-stepping
M350 S16   ; 16x micro-stepping

If you find that M351 S1 X0 plus M351 S2 X1 sets X micro-stepping to 128x (in testing, G1 X... will move less far) then you have Heroic drivers. If that same combination sets X micro-stepping to 4x (in testing, G1 X... will move farther) then you have non-Heroic drivers.

If you find that you have HR4982 drivers, then you should set MOTHERBOARD to BOARD_MKS_BASE_HEROIC. And if you find that you have non-Heroic stepper drivers, then we will need to add a new board, BOARD_MKS_BASE_15.

[psycha0s]

@thinkyhead I'm pretty sure I have A4982 drivers. I'm not an electronics engineer, just a programmer. When I was investigating my issue, I used the datasheet from the A4982. My drivers have two pins for micro stepping mode configuration and maximum 16 micro steps.

[thinkyhead]

Thanks for the update. In that case I guess we'll add MKS_BASE_15 for a board that has digital micro-stepping, but not the HR drivers.

[Ghenghis]

for marlin 1.1.9 - does this work on MKS Gen L board, setting Z_DUAL_STEPPER_DRIVERS using E1 as Z2?

[thinkyhead]

It works the same way on all boards.

[github-actions[bot]]

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.