Syncing Z Motors

[dc42]

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

[birrelln]

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.

[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

[dc42]

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

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

[birrelln]

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

[dc42]

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

[birrelln]

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.

[birrelln]

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…

[dc42]

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