New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Nicolayka opened this Issue Apr 26, 2017 · 99 comments

Comments

Projects
None yet
@Nicolayka
Copy link

Nicolayka commented Apr 26, 2017

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

@Nicolayka Nicolayka changed the title How to allow dual Z on RAMPS 1.4? How to make driver of E1 for motor Z2 on RAMPS 1.4? Apr 26, 2017

@thinkyhead

This comment has been minimized.

Copy link
Member

thinkyhead commented Apr 26, 2017

// 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

This comment has been minimized.

Copy link

Nicolayka commented Apr 26, 2017

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

@thinkyhead

This comment has been minimized.

Copy link
Member

thinkyhead commented Apr 26, 2017

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

@linux01d

This comment has been minimized.

Copy link

linux01d commented May 11, 2017

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

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 11, 2017

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

This comment has been minimized.

Copy link

linux01d commented May 12, 2017

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

This comment has been minimized.

Copy link

linux01d commented May 15, 2017

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

@Bob-the-Kuhn

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 15, 2017

Z_DUAL_STEPPER_DRIVERS needs to be enabled in configuration_adv.h

@linux01d

This comment has been minimized.

Copy link

linux01d commented May 16, 2017

Z_DUAL_STEPPER_DRIVERS needs to be enabled in configuration_adv.h

Here it is, I suppose.
Am I wrong?

@Bob-the-Kuhn

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 16, 2017

Correct

@linux01d

This comment has been minimized.

Copy link

linux01d commented May 16, 2017

Should I open different issue for my case?

@Bob-the-Kuhn

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 16, 2017

No need to open another issue.

Is your dual Z working properly?

@linux01d

This comment has been minimized.

Copy link

linux01d commented May 16, 2017

Is your dual Z working properly?

Nope.

@Bob-the-Kuhn

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 16, 2017

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

This comment has been minimized.

Copy link

linux01d commented May 24, 2017

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

This comment has been minimized.

Copy link

linux01d commented May 24, 2017

@Bob-the-Kuhn

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 25, 2017

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

This comment has been minimized.

Copy link

linux01d commented May 25, 2017

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

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 25, 2017

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

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 26, 2017

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

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 26, 2017

@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

This comment has been minimized.

Copy link

linux01d commented May 26, 2017

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

This comment has been minimized.

Copy link

linux01d commented May 26, 2017

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

@Bob-the-Kuhn

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 26, 2017

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

This comment has been minimized.

Copy link

linux01d commented May 26, 2017

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

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 26, 2017

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

Time to call it a night.

Talk to you tomorrow.

@Bob-the-Kuhn

This comment has been minimized.

Copy link
Contributor

Bob-the-Kuhn commented May 31, 2017

Status?

@Roxy-3D

This comment has been minimized.

Copy link
Member

Roxy-3D commented May 31, 2017

@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.

@AnHardt

This comment has been minimized.

Copy link
Contributor

AnHardt commented Jan 2, 2018

Compare Marlins configuration with RepetierHosts and your slicers configuration.

@kizill

This comment has been minimized.

Copy link

kizill commented Jan 6, 2018

@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

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 1 in Configuration.h and it causes #define PS_ON_PIN 4 in pins_MKS_13.h

@fiveangle

This comment has been minimized.

Copy link
Contributor

fiveangle commented Jan 6, 2018

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" ?

@phantom-code

This comment has been minimized.

Copy link

phantom-code commented Jan 7, 2018

@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

This comment has been minimized.

Copy link

webhive commented Jan 27, 2018

@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.

@phantom-code

This comment has been minimized.

Copy link

phantom-code commented Jan 27, 2018

@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

This comment has been minimized.

Copy link

webhive commented Jan 27, 2018

Agree! God bless @kizill ! :)

@NiftyMaker

This comment has been minimized.

Copy link

NiftyMaker commented Jan 31, 2018

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

This comment has been minimized.

Copy link
Contributor

fiveangle commented Jan 31, 2018

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.

@thinkyhead thinkyhead closed this Feb 14, 2018

@Jalofah

This comment has been minimized.

Copy link

Jalofah commented Apr 3, 2018

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?

linux01d added a commit to linux01d/Marlin that referenced this issue Apr 5, 2018

linux01d added a commit to linux01d/Marlin that referenced this issue Apr 5, 2018

@thinkyhead

This comment has been minimized.

Copy link
Member

thinkyhead commented Apr 8, 2018

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

This comment has been minimized.

Copy link

Jalofah commented Apr 8, 2018

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

@Jalofah

This comment has been minimized.

Copy link

Jalofah commented Apr 8, 2018

i have MKS BAS V1.4 Allegro 4982

@thinkyhead

This comment has been minimized.

Copy link
Member

thinkyhead commented Apr 9, 2018

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.

@phantom-code

This comment has been minimized.

Copy link

phantom-code commented Apr 9, 2018

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

@Jalofah

This comment has been minimized.

Copy link

Jalofah commented Apr 9, 2018

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

@thinkyhead

This comment has been minimized.

Copy link
Member

thinkyhead commented Apr 10, 2018

@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.)

@phantom-code

This comment has been minimized.

Copy link

phantom-code commented Apr 10, 2018

@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

This comment has been minimized.

Copy link
Member

thinkyhead commented Apr 10, 2018

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?

@phantom-code

This comment has been minimized.

Copy link

phantom-code commented Apr 10, 2018

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

@thinkyhead

This comment has been minimized.

Copy link
Member

thinkyhead commented Apr 12, 2018

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

@phantom-code

This comment has been minimized.

Copy link

phantom-code commented Apr 13, 2018

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

@thinkyhead

This comment has been minimized.

Copy link
Member

thinkyhead commented Apr 14, 2018

@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.

@phantom-code

This comment has been minimized.

Copy link

phantom-code commented Apr 14, 2018

@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

This comment has been minimized.

Copy link
Member

thinkyhead commented Apr 17, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment