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 enabledM667 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 centM84 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 networkM586 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.1Homez.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 Z1I 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
-
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 enabledM667 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 maximaM350 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 heightAll 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
-
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.20It'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!
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
-
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.20It'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…
-
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.
