@engikeneer

Sleep and reset like this:

Anyways, abandoned hooking it up to the extruder and am just using it with the third Z motor. Sings a little more, but seems to be working now?

Of course, that is after trial and error (mostly error!) to get the auto bed levelling working. I was using auto levelling with two motors previously and had two optical endstops to get the first Z home to make sure the sides were roughly level (thanks poor choice in lead screws). This involved splitting the axis into U. I mistakenly went down that path with the third motor and and split to V and created a homev.g.

I didn't find it anywhere, but it seems the home all button from the web interface calls homeu.g and homev.g after the homeall.g. Took me quite a while to figure this out, but after stripping my config of u and v and deleting the homeu.g and homev.g, things seem to be working.

I would love to know why it didn't play nice with the one extruder motor, but I really can't figure out what was different.

I haven't updated firmware in a long time. Still on an early 2 and need to jump to three.

Oh, and thanks for the link to the boards. I like how the banggood one takes power for the motor.

@engikeneer

Sleep and reset like this:

Anyways, abandoned hooking it up to the extruder and am just using it with the third Z motor. Sings a little more, but seems to be working now?

Of course, that is after trial and error (mostly error!) to get the auto bed levelling working. I was using auto levelling with two motors previously and had two optical endstops to get the first Z home to make sure the sides were roughly level (thanks poor choice in lead screws). This involved splitting the axis into U. I mistakenly went down that path with the third motor and and split to V and created a homev.g.

I didn't find it anywhere, but it seems the home all button from the web interface calls homeu.g and homev.g after the homeall.g. Took me quite a while to figure this out, but after stripping my config of u and v and deleting the homeu.g and homev.g, things seem to be working.

I would love to know why it didn't play nice with the one extruder motor, but I really can't figure out what was different.

I haven't updated firmware in a long time. Still on an early 2 and need to jump to three.

Oh, and thanks for the link to the boards. I like how the banggood one takes power for the motor.

Oh, I have jumpered sleep and reset together. Should I be doing this?

Hi Folks,

Working towards adding a third independent z-screw to my d-bot and hooked up an external A4988 to test it out. I have set it up in config as an extruder for T1 as I think I will eventually use it for the extruder and use the old E0 for the third z.

This is all on a solderless breadboard for proof of concept. Microstepping is set to 16 by jumping the 3 MS pins to 3.3v. Capacitor is between motor ground and 24V.

After two hours of little action, I realized my A4988 driver board was bad (doh). Scrounging around I found one that worked.

Everything works fine when connected to the motor that will be the new Z. It works perfect connected to an identical motor to the one in my knockoff Titan Aero. Motors step when called, turn off when done, and have great holding torque.

However, when I plug it into the working Titan Aero on the machine, things fall apart. When I call it, it spins and does not turn off unless I emergency restart. Sort of jittery too. I thought maybe I had the phases wired wrong, so I did verify that the pairs were where I though, and they were.

When I plug this extruder motor back in to the E0 on the Duet Wifi, and go back to T0, everything works like it always did.

I think I may just try using this external driver with the third z motor since it seemed to work with that one to see if it works. But it is bugging the heck out of me that it doesn't want to play nice with the Titan Aero.

Maybe I will try plugging the new Z motor into the E0 port to see what happens when the current print is finished...

Anyone have any ideas what is going on?

I have been using the Engineer PA-09 crimpers for the molex connectors and have had 0 issues. No cutting or snips or other pliers needed. Does take two crimps as Allen mentioned - crimp the insulation and then crimp then then contacts.

That ratchet one looks easier on the pocket book though…

Nate

These are bootlace ferrules for any power connections using stranded wire. They may or may not work depending on your gauge of wire. Crimper is reasonable from Amazon. Uninsulated ferrules are great for connecting wires without solder!

Nate

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…

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.

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

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?

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.