Problem with high temperature in the drivers

Gixxerfast

@arisoy As a long shot, are you tuning the steppers for stealhchop somewhere in you print start or homing sequence?

Do you have something like this somewhere (M17)?

; enables motors and wait for driver tuning
M17
G4 P200

It's a long shot but ...

Arisoy

@gixxerfast

@gixxerfast said in Problem with high temperature in the drivers:

are you tuning the steppers for stealhchop somewhere in you print start or homing sequence?

I don't know... Where can i check this?

I check for M17 in my config.g in all homing.g files and in the gcode and i didn't found any. Is there somewhere else i have to check.

Gixxerfast

@arisoy Well it was a long shot

When I started with the Duets i "borrowed" a configuration that had that M17 in the middle of the config.g and I didn't understand better so I didn't remove it. I very nearly cooked my motors and drivers. The whole room smelled hot flux.

In your slicer, do you have a custom startup sequence there? How does that look?

.

Arisoy

@gixxerfast I have only one line in my startup sequence and it's this one :

START_PRINT EXTRUDER_TEMP=[first_layer_temperature] BED_TEMP=[first_layer_bed_temperature]

I didn't add this line, it was there at the begining.

And it gives me an error when i import the gcode but i don't think it's the problem.

Arisoy

No one can help me? As i said the problem occured when i load and start a gcode.

The drives are in error even before they move.

While the bed&hotend are warming up the errors start to appear.

But when i warm them up in manual or when i move in manuel i have no problem at all.

Baenwort

This is a new one for me as the earlier steps have hit on all the causes I've seen before. I think we will have to wait for one of the experts like @Phaedrux or someone to give some ideas.

markz

I took a quick look at your gcode file and it's very hard to believe you have it set correctly for your printer.

To begin with, the gcode file reprograms the entire printer dynamics... strangely. This line:

M203 X500 Y500 Z10 E60 I0; sets maximum feedrates, mm/min

sets the maximum feedrate for Z to 10mm/min which is so slow you probably can't see it move and the others are similarly very slow. I'd recommend you look at your slicer settings and not have it set printer dynamics.

Also your slicer is sprinkling this line

M204 P4000

through the code which I don't understand. It's resetting the print acceleration? Finally, it sets the temperatures I think a little strangely in that it starts heating up the head at the same time as the bed.

With all that said - the one time I got "high temperature reported by driver" was when I did a lousy crimp job and one of my motor wires was only sometimes connected.

dc42

@arisoy there is a problem with your GCode file, although I don't know whether it is causing this issue. In this extract:

G10 P0 S205 ; set temperature
;TYPE:Custom
START_PRINT EXTRUDER_TEMP=205 BED_TEMP=68
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
; Filament gcode
SET_GCODE_OFFSET Z=0
SET_PRESSURE_ADVANCE ADVANCE=0.05
G10 P0 S205 ; set temperature
M116 ; wait for temperature to be reached
M190 S68 ; set bed temperature and wait for it to be reached

there are 3 lines that are obviously meant to be comments, but don't have the leading semicolon. They are the lines starting START_PRINT, SET_GCODE and SET_PRESSURE. Perhaps these lines come from the start GCode that you have configured in the slicer; or perhaps they are generated for Prusa printers. So:

In Printer Settings/General, change G-code flavor to "RepRapFirmware". I also recommend that you select "Use relative E distance".
In Printer Settings/Custom G-code check whether those 3 lines are present, and if so then add a leading semicolon to mark them as comments.
Re-slice the file and try printing again.

Arisoy

@dc42 Thanks everything works fine now

dc42

@arisoy thanks for confirming that. I will try running your original file on a Duet 3 Mini to see if I can identify exactly what happened. You are not the first person to report this type of problem, so I want to get to the bottom of it.

dc42

@arisoy I have tested that file under RRF 3.4beta7. If I have the drivers in spreadCycle mode, it works. However, if I have them in stealthChop mode and I start the file without doing the correct stealthChop tuning procedure first, then the drivers provide excessive current to the motors. So I suspect that the issue was caused by lack of stealthChop tuning in the homing files.