My apologies DC42 I was testing the wrong motor when I was testing for continuity. There was a bad connection on the wires. Im just doing an actual test print now. I think im good. Thank you yet again for pointing me in the right direction

Did you get a warranty replacement board, or was it out of warranty? It should be possible to repair the fault.

Duet wifi

See my reply in that thread.

Yes, with 2 standard 2-pin jumpers; so that pin 1 is connected to pin 2, and pin 3 is connected to pin 4.

Depending on the leadscrew pitch/lead you use, perhaps motor stall detection would be suitable?

If you do want to use multiple Z endstops, see https://www.duet3d.com/forum/thread.php?pid=10946#p10946 and subsequent posts in that thread.

It's normal for the endstop to show as hit when you unplug it when using S1.

What I suspect is happening is that the endstop is marginal when run from 3.3V. When not triggered, it is pulling the endstop input low enough to light the LED but not low enough to be registered reliably as triggered by the processor. The remedy is to reduce the IR LED series resistor on the endstop board as I describe at https://duet3d.com/wiki/Connecting_endstop_switches#3.3V-compatible_optical_endstop. If the series resistor is an SMD type, you may find it easier to solder another one on top (so in parallel) rather than replace the existing one.

Thank you for your help.

Glad you figured it out TimVukman.
I wasn't trying to hijack you thread, I thought maybe our problems were related.
I guess not.

I figured out my problem as well, maybe this will help someone else.

When I formatted to Fat32, there was 16MB of space being left unallocated. That would screw the Duet up and wouldn't read the SD card correctly. It could see it mounted in slot zero, but that is it.

What I did to fix the SD card was run DiskPart, select and clean that drive, then create a primary partition.
Then formatted to Fat32 and was good to go.

Interesting, I assumed SG 1023 was not normal because I haven't see it go that high. It is a measure of the maximum motor load that was detected since you last ran M122.

The gauge of wire should be appropriate to the current that the bed heater draws (to prevent the cable overheating) and the length of the cable (so that you don't have too much voltage drop in the cable). So it's hard to generalise.

Having said that, 14AWG is rated at approx. 24A single core or 15A 2 or 3 core, and has a resistance of 8.5 milliohms per metre. So it's an appropriate choice for many 3D printers.

BTW there is a video on Maker's Muse about why the negative output from the PSU should be linked to ground.

Oh cool, good! Just sitting in a long meeting with laptop in hand, haha.

Yes that's the correct one.

@eca77:

I read the guide, but I'm not sure if that is also the way to direct the Duet to use the E1 controller for the second Z-axis not just for the leveling feature.
I just got back to the machine after about a year of letting it sit due to time constraints (new baby and college). Now I want to get it running again with the change.

Yes that is also the way to drive multiple Z motors from separate drivers. Look up M584 in the gcodes wiki page.

The links for the main board are on github, links for each main board iteration are on here:

https://duet3d.com/wiki/Hardware_overview#Version_History

The Ethernet module is here:

https://github.com/T3P3/Duet/blob/master/Duet2/EthernetModule/DuetEthernet_Schematic.pdf

The Auto Bed Compensation runs G32, which in turn runs bed.g. It is up to you to make sure that the probe points in bed.g are reachable by the Z probe, allowing for the offset of the Z probe from the head.

On a Cartesian or CoreXY system, you should use mesh bed compensation. You can still use the bed.g file for implementing leadscrew levelling if you have multiple independent Z motors, or the manual bed leveling assistant if you don't.

The VIN label is for the connector, the screw terminal, consisting of a + (VIN) and - (GND). With the limited space on the board for silkscreen the + is slightly obscured by the terminal (but we did put it on the bottom as well).

Anyway it sounds like you wired it correctly by following the wiring diagram and the silkscreen on the bottom: VIN = +'ve, GND = -'ve

Ok swapped wires from X axis to Y axis and problem moved with the wires so checked them all and of course one of my connections wasnt so good. Anyways X and Y work like a charm. Now when i try to home the Z axis I get this error:
Error: Invalid servo index 5 in M280 command
Error: Z probe already triggered at start of probing move

Never mind got it figured out with the BL Touch

BL touch goes through the testing part when I fire up the printer deploying and retracting the probe. Its way up off of the bed so it doesnt trigger to early. Not sure where to go from here.