Posted on 2 Comments

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.

Posted on 2 Comments

Duet WiFi/Eth – PID tuning hotend

Since I just changed my old cartridge for a 24v 80w heater on my 5way Diamond hotend and used High Temperature Liquid Gasket Silicone as a sealant on the heatsinks and the Diamond nozzle itself, as is clearly evident on the photo, I need to do a new PID tuning, which is a good starting point for writing a short blog-post on doing just that.

  1. Gcodes used
  2. Prepare for PID tuning
  3. PID-tune hotend heater
    1. Parameters
    2. Heater to tune
    3. Power
    4. Target Temperature
  4. Parameters to use and store in config.g
    1. New PID-Tuning
    2. I’ll add this in my Heaters/Hotend section
  5. Debug – Failing to tune?
    1. Temperature was not reached
    2. Starting temperature is not stable
    3. Over-powered and a fire risk

1) Gcodes used

  • For the actual PID tuning, we are going to use M303
  • M307 H1 to display the parameters we garnered from the PID tuning.
  • Finally you could use M500 to store the parameters in a config-override.g file, which matches the old school Eeprom M500, and overrule the settings in config.g file.
    • I personally have an aversion to this sort of having configurations stored in different places. Especailly for core parameters that shouldn’t change.
    • In my opinion it just leads to confusion as people tends to forget they have anything stored in the override file and can’t figure out why the printer doesn’t accept the new parameters written in the config.g file.

2) Prepare for PID tuning

I prefer to put my hotend close to the heated bed, heat the bed to my most used temperature and then turn on the object-cooling fans at maximum before doing a hotend PID-tuning.

Why you might ask?

I prefer to similuate actual printing situation to get a PID tuning that most closely matches the actual usage scenarios of my printer.

3) PID-tune hotend heater

Parameters

Hnnn heater number
Pnnn PWM to use, 0 to 1 (you should normally use 1 i.e. full power)
Snnn target temperature

Heater to tune
To actually do a PID tuning we need to use the M303 command followed by H1 to denote the heater used, which is the first heater.

If you PID tune your bed, it is H0 by default.

Power
Next we need to define the amount of power we feed our heater cartridge. This is denoted by P followed by a number like P1 for 100% power and P0.5 for 50% power.

RepRapFirmware used to be very, very restrictive regarding power setting. I had to put it at P0.1 (10%) to do a succesfull tuning in january, but His time I could run it at P1 (100%).

Target temperature
Finally we need to define target temperature using S followed by temperatures in celcius like S220 for 220c. Target the temperature you use the most. So 200ish for PLA if that is what you print, or 240 or something like that, if you mostly print ABS.

It means I’ll tune my to 200c at full power like this (mine failed when target was 220):
M303 H1 P1 S200

Sequence is from the bottom and upwards

4) Parameters to use and store in config.g

As mentioned above I’m not a fan of using the M500 to store in config-override.g method, so I’ll get the result from the PID tuning using M307 H1 and put it into my config.g file.

It all seems a bit confusing to be sure

Lets look at the top line, which is the one we are going to be using:
Heater 1 model: gain 188.4, time constant 121.7, dead time 1.4, max PWM 0.50, mode: PID

This translates into:

  • M307 H1 for Heater 1
  • A188,4 for Again
  • C121.7 for Constant
  • D1.4 for Dead time
  • and S0.5 for max PWM

* Default is PID for hotend, so we don’t need to write parameter for this.
* Default for BED is Bang-Bang method, so you’d have to add B0 in the end, to force it to use PID.

M307 H1 A188.4, C121.7, D1.4 S0.5

I honestly do not know why it puts max power at 50%, so i’ll put it at S1 (100%) and use the new parameters to do a new PID tuning like this:

M307 H1 A188.4, C121.7, D1.4 S1

4.1) New PID-Tuning

Saving config.g with the above parameters I’ll run a new PID-tuning target at 220c like so:

M303 H1 P1 S220

I ended up with new parameters with full power on my heater:
Heater 1 model: gain 375.3, time constant 125.9, dead time 3.8, max PWM 1.00, mode: PID

This translates into:

  • M375.3 H1 for Heater 1
  • A125.9 for Again
  • C125.9 for Constant
  • D3.8for Dead time
  • and S0.5 for max PWM

Which means we are going to add this line to our config.g file.

M307 H1 A375.3, C125.9, D3.8 S1

4.2) I’ll add this in my Heaters/Hotend section.

So, this is ho my Hotend section turned out looking 🙂

5) Debug – Failing to tune?

There are different reasons why it migh fail to tune.

Temperature was not reached

Auto tune cancelled because target temperature was not reached Heater 1 switched off

Solution: Try using a lower temperature. It might fail if it took too long to reach the target temperature.

Starting temperature is not stable

Auto tune cancelled because starting temperature is not stable

Solution: You need to wait for temperature to get almost back to room temperature before trying again.

Over-powered and a fire risk

Warning: Heater 1 appears to be over-powered and a fire risk if left on at full power, its temperature is predicted to reach XXXc

Solution: Lower the value of the P parameter, which is the current you feed your heater during testing