Error: Short-to-ground on drivers 1

dc42

It's possible that you damaged the driver by having a short circuit in your stepper motor wiring. So please check your wiring. However, some drivers fail during the first few hours of use for no apparent reason. So please ask RepRapWorld to repair or replace your Duet under warranty.

equanimity8

I looked at the wiring and nothing is wrong to the naked eye.

I did some more tests moving different motors with different drivers. What I discovered is that Z driver moves the motors without issues but when I try to move Y stepper with X driver it displays short-to-ground on driver 1 - previously it was only when I moved Y driver. Now X driver behaves the same way Y driver did before failing. Also, currently X driver is connected to Y stepper with the wiring from X stepper, so the wiring itself shouldn't be the issue. Can the stepper itself cause that?

Update

I played some more with the setup and I made the following observations:

After I power up it takes some time (a minute) to be able to move the motors properly, before that they try to move but appear to not have the torque to do so.
Before the update I was thinking if a stepper motor might be screwing everything up but I checked both steppers more diligently and they appear to behave identically.
When I have X driver connected to X motor and Y driver not connected at all, and I move the X axis via the interface it moves properly, but I can move the same (X) axis by the same value according to the web interface but a shorter distance by using the Y axis movement button from the interface.
I received a Warning Vin under-voltage event (2.9V). Just by looking at it the interface reports a steady 12-12.1V. The power wires are properly secured in the screw-in terminals of both the board and the power supply. The power supply is indeed a chinese copy I had lying around. Additionally, I ran M122 and this was the output:

M122
=== Diagnostics ===
Used output buffers: 3 of 32 (16 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0
Board ID: 08DGM-95BNL-MGPSN-6JTDJ-3SJ6T-12YHZ
Static ram used: 15448
Dynamic ram used: 98976
Recycled dynamic ram: 264
Stack ram used: 1392 current, 5936 maximum
Never used ram: 10448
Last reset 00:02:51 ago, cause: power up
Last software reset at 2018-02-16 13:56, reason: User, spinning module GCodes, available RAM 7912 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 35.8, current 36.1, max 36.3
Supply voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: short-to-ground, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-02-17 16:27:24
Cache data hit count 634789147
Slowest main loop (seconds): 0.155786; fastest: 0.000110
=== Move ===
MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 4, completed moves: 4
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.20
WiFi MAC address 2c:3a:e8:0a:ec:5d
WiFi Vcc 3.42, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 16688
WiFi IP address 192.168.137.28
WiFi signal strength -53dBm, reconnections 0, sleep mode modem
HTTP sessions: 1 of 8
Socket states: 2 0 0 0 0 0 0 0
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)

dc42

Something isn't right with this:

but when I try to move Y stepper with X driver it displays short-to-ground on driver 1

Driver 1 is the Y driver.

equanimity8

Negative, wording is correct despite being a bit ambiguous, I'll try to rephrase.

As CoreXY doesn't have true X and Y axes it has alpha and beta motors working together, which I've seen being addressed as X (left) and Y (right) motors and I have adopted it. What you have quoted is to be read as follows - when I have Y stepper (right stepper/beta motor) connected to X driver on the Duet Wifi and I move the X axis via the web interface I get error short-to-ground on driver 1.

See 3) of my update as I go into bit more detail there.

dc42

If attempting to move the motor connected to the Y motor output causes that error message to appear, that indicates that driver 1 (Y driver) has a shorted mosfet or that there is a short in the external wiring. If it produces that message even with no motor connected to the Y motor output, then it's the driver that is faulty.

equanimity8

Thanks for your input!

Currently, I have the Z and X motors connected to their respective drivers i.e. Y driver is free. When I move Z axis no error appears. When I move X axis the error in driver 1 appears. When I move Y axis the carriage does move although just a short distance and quite slowly. If I'm understanding correctly what you have written, driver 1 (Y) is faulty.

That is unfortunate but I'd rather think forward. I was wondering how can I remap the driver from E1 (which is free since I'm using a single extruder) to move the Y axis. I'm looking at the gcode but I must say its harder for me than I thought.

dc42

Yes, to can use M584 X0 Y4 Z2 E3 in config.g to do that. But you are entitled to have your Duet repaired or replaced under warranty, assuming you have had it for less than 6 months.

equanimity8

Thanks for spelling it out for me, I appreciate your time.
I only wanted to ask if I have to add some gcode to "deactivate" driver 1 (Y) or just add the remapping gcode, connect to the proper driver and go about my merry ways? Also, what should I make of the low voltage error I received earlier? I do have many more questions but I believe I should make use of the search feature.

Also, thank you for bringing that up. I'd rather have a properly functioning board but I wanted to continue with finalizing my config. I did contact RepRapWorld so we'll see that will happen but yes I've had it for less than six months.

dc42

The output MOSFETs won't be enabled on driver 1 if it is never used.

The M584 command must come earlier in config.g than the M906 command, also earlier than the M350 command if you have one.

equanimity8

Thanks for clarifying. I did add that in my ;Drives and I can move all axes without any errors.

I appreciate your help. I'm happy the support of the boards lives up to the expectations. Well done, to you, dc42, sir.

equanimity8

Now, as everything moves correctly I wanted to have my axes home in the correct direction. I flipped Z and it worked as expected. However, when I try to flip Y (drive 4) it goes south somewhere. I added M569 P4 S0 ; Drive 4 goes backwards but in that case when I move X from the interface Y moves in the wrong direction and when I move Y in the interface X moves in the right direction. If I add M569 P4 S1 the interface moves the correct axis and X moves in the right direction and Y moves in the wrong direction.
; Drives
M584 X0 Y4 Z2 E3 ;remap drive Y to drive E1
M569 P0 S1 ; Drive 0 goes forwards
M569 P1 S1 ; Drive 1 goes forwards
M569 P2 S0 ; Drive 2 goes backwards
M569 P3 S1 ; Drive 3 goes forwards
M569 P4 S0 ; Drive 4 goes backwards

dc42

It sounds to me that your printer currently has a left-hand coordinate system. To change it to a right-hand coordinate system, swap over the X and Y motor connections or swap X and Y in the M584 command, then use M569 to get the correct directions.

equanimity8

By a lucky mistake I just read that RRF uses a right-hand origin. Where can I get more info why this is the case and wouldn't it result in mirrored prints?

dc42

All 3D printing assumes a right-hand coordinate system - which means that looking from above, the +Y direction is rotated 90 degrees anticlockwise from the +X direction.

On a CoreXY printer, the usual choice is that looking at the front of the printer, +X is to the right and +Y is away from you.

equanimity8

I think we both are talking about an origin of front/left like here - http://www.makerslide-machines.com/old-web-site/res/z-in-same-time.jpg, do correct me if that's not the case.

I had issues with it but after going out for a walk I now have it working properly with the following, if anybody ever needs it:
; Drives
M584 X0 Y4 Z2 E3 ;remap driver Y to driver E1
M569 P0 S1 ; Drive 0 goes forwards
M569 P1 S1 ; Drive 1 goes forwards
M569 P2 S0 ; Drive 2 goes forwards
M569 P3 S1 ; Drive 3 goes forwards
M569 P4 S1 ; Drive 3 goes forwards

Vlad

This post is deleted!