Posted on

Duet WiFi/Eth – Use M584 to autolevel or sync Z-axis using 2 or more motors

I originally planned to use 3 seperate Z-motors for my BeTrue3D Printer project back last christmas, but since I’m using some special hollow Nema 17 and bespoke 1204 Ballscrews + top-fixing blocks the price would be like $100 for one extra motor on the Z-axis.

The money was just one concern. One which I could have overcome (by waiting some) if I wanted to, but it would also cause the printer to be much deeper without giving me larger printing area, and so it wouldn’t fit on my desk.. which was a primary requirment!

A rather big issue was how the RepRapFirmware at the time did not support this form for autolevel and there was no date for when it might be available.

Anyway, here’s a blog-post about it. I’ll at some later date make some youtube video to show how it works, so stay tuned! 🙂

  1. Independent Z-Motors
  2. Is this autolevel?
    1. Autocompensation
    2. Autolevel
  3. My usage of 2x Z-motors
    1. What am I going to do here exactly?
    2. Why? Is it even needed?
    3. How is this going to work in practice?
  4. Motor remapping for dual Z
    1. Physical Drive Connection
    2. Use M584 to remap the drives
    3. Configure Drives
    4. Endstop setup
  5. Example setup for non-duex user
  6. New Homing files

1) Independent Z Motors

It all ended up with me using 2 independent Z-motors.

I started out driving both from the same Z-driver but installed a limit-switch at each motor, which would be at Z-max, and planned how to trigger them using identical screws on both sides, mounted down through a threadded m3 hole in the Z-gantry for just this purpose.

The screws can of course be turned some, if fineadjustment is needed. I used some Loctite Threadlocker (open UK Ebay) to make sure it didn’t rattle loose.

2) Is this autolevel?

You might ask if this is autolevel by now, as it looks completely different than what you are used to see with a probe or sensor or similar..

Autocompensation

We normally see some sort of sensor near the hotend, which probes places around the bed and then compensate according to how uneven the printbed is.

This sort of automation is more correctly called autocompensation as it can compensate for various erros, most often just for a non-flat printbed though.

The compensation for non-flat surface is achieved by compensating for these errors by gradually, over the first xx layers flattening out the area on which it is printing. Ie, some areas are printed with a thicker layer than on others. After xx layers it can start printing normally

There are more to this, and different methods to compensate for non-square frame and axes etc, but this is beyond this blog-post

Autolevel

Autolevel on the other hand is when one or more sensors determine the posistion of the printbed and by using 2 or more motors makes it completely level compared to the XY axes.

You would want to use 3 or more motors to make most out of this Autolevel function.

A short note on using Autolevel: functions with RepRapFirmware: The M320 autolevel gcode is not currently implemented in the firmware, and seems it’s not going to be either, as the current functions G29-G32 is fullfilling the same functions more or less. Currently only Repetier firmware is making use of the M320-322 gcodes.

3) My usage of 2x Z-motors

As I talked about previously I selected to only use 2 Z-motors and the function to use these for Autolevelfunctions were recently made available in the RepRapFirmware via the M584: Set drive mapping, so now I’m in business!

In all fairness, the M584 has been around for some time, but I’ve been waiting for a finished sort of system for autolevel, which, as it turns out (see note above) is not going to be implemented, so here I am!

What am I going to do here exactly?

I’m going to home my Z-axis to Z-max and make each motor make use of it’s own endstop in order to make sure each end of the Z-axis is synchronized.

Why? Is it even needed?

In my optics, yes! Asolutely. Any machine using more than 1 z-screw should have this implemented.

Problem with multiple independent z-motors, yes, and even multiple axes driven by a single belt, is that one or more of the axes might get turned a bit. It can happen if you accidentially push on the plate or turn the screw, if you happens to move the z faster than it likes and one motor or screw skips a step or belt etc.

It might also be that your axes aren’t 100% to begin with, so you need to synch them up before each print, which you can do with this method.

How is this going to work in practice?

I’m going to use 2 different drivers for my Z-motors and use the associated Endstop connectors for these drivers as well. This is accomplished by using the M584 to define virtual axes.

It means we include both Z-motors in the original Z and then make a virtual axis for one of these motors in order for them to be able to move as one, but also make use of each motors’ own limit switch in order to make sure they are synchronized.

Motor remapping for dual Z

Before we get down to using M854, we need to use the M569 to define/check our physical setup.

Physical Drive Connection

My setup/explanation:
  • Drive 0-1 as X and Y, which are standard.
  • Drive 2 as left motor, which is normal Z
  • Drive 3 as Right Z-motor, which is normal Extruder0
  • Drive 4 – Standard Extruder1 – I am not using this, as all my extruders are on Duex5
  • Drive 5-9 – My extruders on Duex5


; Define Drives
; Physical Drive connection
M569 P0 S1 ; Drive 0 X
M569 P1 S0 ; Drive 1 Y
M569 P2 S0 ; Left z-motor (original Z)
M569 P3 S0 ; Right z-motor (Ex0)
; M569 P4 S0 ; EX1 - unused
M569 P5 S1 ; Extruder0 - Physical Tool 0
M569 P6 S1 ; Extruder1 - Physical Tool 1
M569 P7 S1 ; Extruder2 - Physical Tool 2
M569 P8 S1 ; Extruder3 - Physical Tool 3
M569 P9 S1 ; Extruder4 - Physical Tool 4

Use M584 to remap the drives

To make this all work, we need to tell the controller how we have conencted our physical connectors:

How to do this:
  • We are starting the new line, which we place under our M569 section above, by issuing the M584 gcode.
  • Then simply go through and use the definitions we made above.
  • X0 – Using Driver 0 as X
  • Y1 – Using Driver 1 as Y
  • Z2:3 – This is the new part, where we define that we are using both Driver 2 and 3 for our Z. This means both are used when hitting the move Z buttons.
  • U3 – We assign driveletter U to our second Z motor, using Drive 3.
    • When using virtual drivenumbers we can’t just come up with some random letters.
    • As of firmware 1.19, we can use UVWABC letters – in that order!
  • E5:6:7:8:9 – Defines how all drivers on the Duex5 are Extruders.
  • P3 – This defines the number of visible axes in our GUI, starting from the first, meaning the visible ones are: XYZ, while the 4th axis U is not shown up in the GUI.
    • You might want to have U visible at first in order to verify your new setup.

; Motor remapping for dual Z
M584 X0 Y1 Z2:3 U3 E5:6:7:8:9 P3 ; Driver 0 For X, 1 for Y, Z=2:3 U=3, Extruder 5-9

Configure Drives

Next step is to configure our machine to use 2 drivers instead of just 1 and to add the new U drive to our Drives configurations.

What you need to do now, is setup microstepping, steps/mm and all other such settings as if you have 2x Z-drives and 1x U-drive

Endstop Setup

Last item in our config.g we need to change is the Endstop configuration. Contrary to above, we do not define a second Z here (As we only have 1 z endstop), but instead just add the U endstop. It’s important that Z and U homes to same end; in this case at Z-max.

Example configuration for non-duex users

This section is a cleaned up section for all the non-duex owners, so you don’t have to sit and sort out my Duex5 config.

Just use the explanations for the Configure Drivers and Endstop Setup just above here.

Explanation:
  • Drive 0-1 as X and Y, which are standard.
  • Drive 2 as 1st Z-motor, which is normal Z
  • Drive 3 as Extruder0
  • Drive 4 as 2nd Z-motor – this is normally Extruder1


; Define Drives
; Physical Drive connection
M569 P0 S1 ; Drive 0 X
M569 P1 S0 ; Drive 1 Y
M569 P2 S0 ; 1st z-motor (original Z)
M569 P3 S0 ; Extruder0
M569 P4 S0 ; 2nd Z-motor - Normally used as Extruder 1

 

  • X0 – Using Driver 0 as X
  • Y1 – Using Driver 1 as Y
  • Z2:4 – This is the new part, where we define that we are using both Driver 2 and 4 for our Z.
    • This means both are used when hitting the move Z buttons.
  • U4 – We assign driveletter U to our second Z motor, using Drive 4.
    • When using virtual drivenumbers we can’t just come up with some random letters.
    • As of firmware 1.19, we can use UVWABC letters – in that order!
  • E3 – Defines Extruder0 as our extruder.
  • P3 – This defines the number of visible axes in our GUI, starting from the first, meaning the visible ones are: XYZ, while the 4th axis U is not shown up in the GUI.
    • You might want to have U visible at first in order to verify your new setup.

And the code to copy/paste:

; Motor remapping for dual Z
M584 X0 Y1 Z2:4 U4 E3 P3 ; Driver 0 For X, 1 for Y, Z=2:4 U=4, Extruder 3

New Homing files

It’s important we remember to create new/modify our homing files to match our new setup.

In particular we need a new Homez.g and a modified Homeall.g.


And the code for easy copy/paste:

G91 ; Relative mode
M584 Z2 ; Split Z into 2 (Z+U)
G1 Z250 U250 F2000 S1 ; Move up to 250mm in the +Z direction. S1 to stop if endstop is triggered
G1 Z-2 U-2 F600 S2 ; Move 2mm in the -Z direction - (I'm not sure what S2 is for?)
G1 Z3 U3 F100 S1 ; Move slowly 3mm in the +Z direction, stopping at the homing switch
M584 Z2:4 ; Join U to Z again (pay attention to drive numbers used)
G1 Z-5 F3000 ; Move back again 5mm in the -Z direction
G90 ; Back to absolute mode

You need to update your Homeall.g files accordingly as well.

Leave a Reply

Your email address will not be published. Required fields are marked *

*