Short to ground.

dc42

You are right, if the motors are homing OK then the phases must be correct.

Please try firmware 2.02RC7.

How are you cooling the Duet? You are running the Y motor at 1500mA which is close to the maximum, and at that current it will need a lot of cooling. Try 1200mA, that will probably be enough.

Agniusm

@dc42 i am uploading a vid atm. Cooling is done all stock as on ender 3. 24v 40x40x10 fan at the top, vents at the bottom and sides.
High current could be a problem but i would suspect that it wont happen strait away. I will try lowering my currents just to see.
Just to mention i got 2 motors and tested both with the same results.
I also tested it on the clone board with the same outcome

Agniusm

Lowering currents to 1000mA did not help.

Agniusm

@dc42
https://youtu.be/04CG28UY_cI

Agniusm

Firmware upgrade did not help.

dc42

So you only get the errors if you have the heaters on? That sounds like a power issue to me, which is quite likely because your new motors are higher current/lower inductance than the original ones. After the short to ground errors are reported, run M122 and check the count of under voltage events.

Agniusm

M122
Error: short-to-ground reported by driver(s) 1
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 2.02RC7(RTOS) running on Duet Maestro 1.0
Board ID: 08DAM-9F9DA-MWNS8-6J9D6-3SW6P-K51LW
Used output buffers: 3 of 20 (7 max)
=== RTOS ===
Static ram: 19476
Dynamic ram: 97632 of which 0 recycled
Exception stack ram used: 268
Never used ram: 13696
Tasks: NETWORK(ready,672) HEAT(blocked,1300) MAIN(running,3940) IDLE(ready,204)
Owned mutexes:
=== Platform ===
Last reset 00:02:35 ago, cause: power up
Last software reset at 2018-12-23 11:45, reason: User, spinning module GCodes, available RAM 13688 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0400f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 15.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 15.3, current 23.4, max 23.5
Supply voltage: min 0.0, current 24.1, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, read errors 0, write errors 0, ifcount 10, reads 6182, timeouts 0
Driver 1: short-to-ground, read errors 0, write errors 0, ifcount 10, reads 6182, timeouts 0
Driver 2: standstill, read errors 0, write errors 0, ifcount 10, reads 6182, timeouts 0
Driver 3: standstill, read errors 0, write errors 0, ifcount 6, reads 6186, timeouts 0
Driver 4: standstill, read errors 0, write errors 0, ifcount 6, reads 6186, timeouts 0
Driver 5: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 6192
Driver 6: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 6191
Date/time: 2018-12-23 15:40:54
Slowest loop: 5.48ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 238, MinFreeDm: 238, MaxWait: 65062ms, Underruns: 0, 0
Scheduled moves: 22, completed moves: 21
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.5
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 1 in use
Movement lock held by http
http is idle in state(s) 1 5
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
lcd is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 4581228.50ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
=== Filament sensors ===
Extruder 0 sensor: ok

Agniusm

@dc42 What to look in motors? Are the 12-48V suitable on 24V supply? https://www.ebay.com/itm/NEMA-17-Stepper-Motor-Sanyo-Denki-0-9deg-RepRap-3D-Printer-CNC-Mill/232844624116?epid=28018767423&hash=item36369f00f4:g:tlsAAOSw7Kta6En7:rk:3:pf:1&frcectupt=true

I am just lost and out of options. Takes too long to get motors to test and then wait again. Advice on motor would be appreciated.

dc42

The motors you have are suitable, although a rating of about 1.3A would be better than 1.7A. They should not cause short-to-ground error reports, in spread cycle mode at least. Try configuring them in pure spread cycle mode. See M569 on the GCodes wiki page for details.

Also, make quite sure you are running the correct firmware version, by sending M115.

Agniusm

@dc42 setting M569 P1 S0 with D2 parameter fixed the issue. Is there a read on different modes? Did i sacrifice something running in this mode?
Could this be to do with ripples i get with 1.8 degree motors?

dc42

@agniusm said in Short to ground.:

@dc42 setting M569 P1 S0 with D2 parameter fixed the issue. Is there a read on different modes? Did i sacrifice something running in this mode?
Could this be to do with ripples i get with 1.8 degree motors?

The different modes are described in the Trinamic TMC22xx datasheet. In brief, spreadCycle is a mode unique to Trinamic drivers that works well with most motors. With some motors it causes some noise when the motor is idle. This can sometimes be reduce by adjusting (normally reducing) the off-time.

The stealthChop mode is another mode unique to Trinamic drivers. It controls the average voltage applied to the motors to try to use the minimum power needed. A side effect of using minimum power is that it makes the motors even quieter. But it has two disadvantages: (1) it is unreliable at high speeds (and short-to-ground messages are a consequence of this), and (2) if the load suddenly increases (for example, because the nozzle hits a blob on the print) then you are much more likely to get a skipped step.

So my recommendation is to use either spreadCycle mode (reliable, but not the quietest), or to use stealthChop mode with a low crossover speed to spreadCycle (V parameters in M569). When using high current low inductance motors such as yours, ~~stealthChop~~ spreadCycle is probably more suitable.

If you want to use stealthChop, here is something you can try that may help the drivers characterise the motors. Start your homeall.g file with the following:

G91 ; relative mode
G1 S2 X0.01 Y0.01 Z0.01 ; move the motors a tiny bit to apply current to them
G4 P200 ; wait a short while to allow the drivers to calibrate the motor standstill characteristics
G90

then continue with the homing routine.

Agniusm

There is too much fuss around quietness of the printers. I dont mind the noise as i dont like being near them as there are particles released which you dont want to inhale anyway
Thank you for clarification. I am running test print on stock motor with D2 to see if that helps ripple effect.
Cheers

Agniusm

So i have changed to another motor which is 0.9A and all is working good.
I wast to add a blinking led and my led is connected to fan output. I tried infinite loop for macro:
M106 P2 S1;
G4 P600;
M106 P2 S0;
G4 P600;
M98 P/macros/BlinkLED.g
but it reports stack overflow. How can i get this working(or even make it more high tech and fade in and out) as it is a nice future after print is finished when you have so many printers? Thanks

dc42

@agniusm said in Short to ground.:

So i have changed to another motor which is 0.9A and all is working good.
I wast to add a blinking led and my led is connected to fan output. I tried infinite loop for macro:
M106 P2 S1;
G4 P600;
M106 P2 S0;
G4 P600;
M98 P/macros/BlinkLED.g
but it reports stack overflow. How can i get this working(or even make it more high tech and fade in and out) as it is a nice future after print is finished when you have so many printers? Thanks

This is off-topic for this thread. Please start a separate thread for new, unrelated questions.