Syncing Z Motors



  • Hi Folks,

    Having trouble switching my D-Bot to running the z motors off of separate drivers - Z and assigning U to E1. I have a motor that likes to go out of sync when the power is off, so I have added another optical endstop. The stop is identical to the one that has been working on the z-axis and all of the lights are showing correctly for triggered\not triggered.

    I can move the U-motor individually from the web console as it should. Moving the Z moves both Z and U as it should. The homing files are where it falls apart.

    I have used https://www.duet3d.com/forum/thread.php?id=2786 as my guide, but it doesn't seem to work. When I home Z, it will only move the z motor while the U motor stays stationary. I have created a homeu.g that also does not move anything as it should.

    Relevant Files:

    Config:

    ; General preferences
    M111 S0 ; Debugging off
    G21 ; Work in millimetres
    G90 ; Send absolute coordinates…
    M83 ; ...but relative extruder moves
    M555 P2 ; Set firmware compatibility to look like Marlin
    ; Automatic saving after power loss is not enabled

    M667 S1 ; Select CoreXY mode
    M208 X0 Y0 Z0 S1 ; Set axis minima
    M208 X270 Y270 Z270 S0 ; Set axis maxima

    ; Drives
    M569 P0 S1 ; Drive 0 goes forwards
    M569 P1 S1 ; Drive 1 goes forwards
    M569 P2 S1 ; Drive 2 goes forwards
    M569 P3 S0 ; Drive 3 goes backwards
    M569 P4 S1 ; 2nd Z-motor - Normally used as Extruder 1

    ; Motor Remapping

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

    M350 X16 Y16 Z16:16 U16 E16 I1 ; Configure microstepping with interpolation
    M92 X100 Y100 Z400:400 U400 E484 ; Set steps per mm
    M566 X900 Y900 Z12:12 U12 E1200 ; Set maximum instantaneous speed changes (mm/min)

    M203 X6000 Y6000 Z180:180 U180 E3600 ; Set maximum speeds (mm/min)
    M201 X1200 Y1200 Z10:10 U10 E1000 ; Set accelerations (mm/s^2)
    M906 X800 Y800 Z800:800 U800 E800 I60 ; Set motor currents (mA) and motor idle factor in per cent

    M84 S30 ; Set idle timeout

    ; Endstops
    M574 Y2 S0 ; Set active low endstops
    M574 X1 Z1 U1 S1 ; Set active high endstops
    M558 P0 H5 F120 T6000 ; Set Z probe type to switch and the dive height + speeds
    G31 P600 X0 Y0 Z1 ; Set Z probe trigger value, offset and trigger height
    M557 X15:255 Y15:255 S20 ; Define mesh grid

    ; Heaters
    M305 P0 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 0
    M143 H0 S120 ; Set temperature limit for heater 0 to 120C
    M305 P1 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 1
    M143 H1 S280 ; Set temperature limit for heater 1 to 280C

    ; Tools
    M563 P0 D0 H1 ; Define tool 0
    G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets
    G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C

    ; Network
    M550 PRevisionist ; Set machine name
    M552 S1 ; Enable network

    M586 P0 S1 ; Enable HTTP
    M586 P1 S0 ; Disable FTP
    M586 P2 S0 ; Disable Telnet

    ; Fans
    M106 P0 S0 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
    M106 P1 S1 I0 F500 H1 T45 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
    M106 P2 S0 I0 F500 H-1 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned off

    ; probes

    ;M558 P8 I01 R0. 4 F300 X0 Y0 Z0
    ;G31 X0 Y0 Z-0.1 P100
    ; Custom settings are not configured

    ; pressure advance
    M572 D0 S0.1

    Homez.g:

    ;dual home

    G91 ; Relative mode

    M584 Z2; Split Z into 2 (Z+U)

    G1 U-275 Z-275 F1800 S1 ; Move up to 250mm in the -Z direction. S1 to stop if endstop is triggered

    M584 Z2:4 ; Join U to Z again (pay attention to drive numbers used)

    G90 ; Back to absolute mode
    G92 Z1

    I have also tried changing to G1 U-275 F1800 S1 to see if just the U motor moves. It does not. However, it does perfrom the G92 Z1 still.

    Anything obvious jump out as to what I am doing wrong?

    -Nate


  • administrators

    Your M208 commands must come after the M584 command and have U values in them too.



  • Thanks David. Added the max\mins and shuffled around the M208. Still nothing happening.

    Here is how the config.g looks at the top now:

    ; General preferences
    M111 S0 ; Debugging off
    G21 ; Work in millimetres
    G90 ; Send absolute coordinates…
    M83 ; ...but relative extruder moves
    M555 P2 ; Set firmware compatibility to look like Marlin
    ; Automatic saving after power loss is not enabled

    M667 S1 ; Select CoreXY mode

    ; Drives
    M569 P0 S1 ; Drive 0 goes forwards
    M569 P1 S1 ; Drive 1 goes forwards
    M569 P2 S1 ; Drive 2 goes forwards
    M569 P3 S0 ; Drive 3 goes backwards
    M569 P4 S1 ; 2nd Z-motor - Normally used as Extruder 1

    ; Motor Remapping

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

    M208 X0 Y0 Z0 U0 S1 ; Set axis minima
    M208 X270 Y270 Z270 U270 S0 ; Set axis maxima

    M350 X16 Y16 Z16:16 U16 E16 I1 ; Configure microstepping with interpolation
    M92 X100 Y100 Z400:400 U400 E484 ; Set steps per mm
    M566 X900 Y900 Z12:12 U12 E1200 ; Set maximum instantaneous speed changes (mm/min)

    I figure I will work in the homeu.g file first to try and crack that nut. Am I correct in thinking that if I can get that to work, it should be working in home z? Here is the homeu.g:

    ; homeu.g
    ; called to home the U axis
    ;

    G91 ; relative positioning
    G1 Z5 F6000 ; lift Z relative to current position
    G1 S1 U-275 F1800 ; move U down until the switch triggers
    G90
    G92 U1 ; set U position to trigger height

    All lines work and appear to execute except for G1 S1 U-275 F1800.



  • I don't think you can have drive 4 assigned to both Z and U. I have a CoreXY with two gantries and for "normal" printing the left motor of each gantry is mapped to X and the two right hand motors are both mapped to Y. But I home each gantry individually and when I do that, it becomes a CoreXYUV. What I do is assign U and V to drives 10 and 11 so my M584 looks like this

    M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3; U and V are additional axes used only for homing. Made invisible by using P3

    Then at the start of my homing files, I remap the U and V axes like this

    M584 X0 U3 Y1 V4 P5; temporarily map drives to U and V axes

    and at the end of homing remap them like this

    M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3;

    HTH


  • administrators

    Which firmware version are you using? I have a feeling that older firmware versions don't support additional axes in CoreXY mode.



  • I've only had the machine going for a week-ish and think I am on the most current.

    Firmware Name: RepRapFirmware for Duet WiFi
    Firmware Electronics: Duet WiFi 1.0
    Firmware Version: 1.20 (2017-12-23)
    WiFi Server Version: 1.20
    Web Interface Version: 1.20

    It's weird. I can move the U axis with the web interface buttons or by sending G1 commands in the g-code console through the web interface and it moves correctly. Put it in the homeing files and it falls to pieces. Perhaps something is happening with the limit switch that it thinks it is triggering immediately. Will have to investigate the hardware side when I get a chance. Anyone want to volunteer for some childcare duties?



  • Ian, I think I played around with remapping similar to that but I shall give it another go!

    @deckingman:

    I don't think you can have drive 4 assigned to both Z and U. I have a CoreXY with two gantries and for "normal" printing the left motor of each gantry is mapped to X and the two right hand motors are both mapped to Y. But I home each gantry individually and when I do that, it becomes a CoreXYUV. What I do is assign U and V to drives 10 and 11 so my M584 looks like this

    M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3; U and V are additional axes used only for homing. Made invisible by using P3

    Then at the start of my homing files, I remap the U and V axes like this

    M584 X0 U3 Y1 V4 P5; temporarily map drives to U and V axes

    and at the end of homing remap them like this

    M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3;

    HTH


  • administrators

    @birrelln:

    I've only had the machine going for a week-ish and think I am on the most current.

    Firmware Name: RepRapFirmware for Duet WiFi
    Firmware Electronics: Duet WiFi 1.0
    Firmware Version: 1.20 (2017-12-23)
    WiFi Server Version: 1.20
    Web Interface Version: 1.20

    It's weird. I can move the U axis with the web interface buttons or by sending G1 commands in the g-code console through the web interface and it moves correctly. Put it in the homeing files and it falls to pieces. Perhaps something is happening with the limit switch that it thinks it is triggering immediately. Will have to investigate the hardware side when I get a chance. Anyone want to volunteer for some childcare duties?

    Please confirm that you have the U endstop switch connected to the E0 endstop input.

    If so, try this:

    • Send G91 (relative mode)
    • Test the U axis with small G1 S2 movements, e.g. G1 S2 U1 should move U 1mm one way, and G1 S2 U-1 should move it the other way
    • If that works, try again with S2 instead of S2. provided that the U homing switch is not triggered, it should do the same.


  • I had the limit switch plugged into the E1 endstop input. In between Lego duties, I moved it over to the E0 endstop input and it may be working! Home U moves the U motor.

    I know that I am new to the system, but this is not intuitive to me, If the second Z motor is plugged into the E1 motor port, why does its endstop switch have to be in the E0 endstop port?

    Thanks for all the help! David, you are incredibly responsive and one of the main reasons I went with the Duet. Keep up the incredible work.



  • Well, to put this to rest for future visitors, things have been working absolutely beautifully for the past week. Changing the z endstop from mechanical to optical was an awesome improvement, and adding another optical stop to the other z motor even more so. Gone is the tape measure to make sure each side of the z-platform is at the same height - the duet does it all now!

    It is so ridiculously easy to tweak things in the duet firmware that I can't imagine doing it any other way now. Need to tweak how far one motor moves after triggering one of the z endstops? Just edit the file from your mobile device and hit home z again to see the immediate changes.

    All I need to do now is to figure out how to reset baby-stepping to zero using Gcode…


  • administrators

    @birrelln:

    All I need to do now is to figure out how to reset baby-stepping to zero using Gcode…

    The 1.21RC1 release has an absolute mode (R0) in the M290 command that allows you to do that.


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.