Duet 0.8.5 : switches off with Stepper limit hit ?
Hi all ,
I found one issue on the Duet 0.8.5 , not sure if tjis is the right place for the thread , otherwise move it please.
(I got my wifi end last week, but still use the 0.8.5 yet.)
I had my print bed runnig too tied and noticed that the Duet switches just off from time to time when moving the bed. (I use an old ATX PS from Pc with an 21 W 12V bulb on 5 Volt aw minimum load)
I assumed the stepper current plays a role and increased from 1500 mA to 1900 mA, but still the same behaviour. I rembered I tightened the printbed guides and loose them again a bit and the Duet did not switch off.
I thought the stepper current limitation works different and asume this behaviour is unwanted.
Did anyone noticed similar things ?
More than 1500mA is a lot for the A4988 stepper drivers, I really wouldn't go higher than 1200mA without extra cooling. If you do not use dedicate cooling of the Duet PCB, the stepper driver will probably overheat and shut down due to its thermal protection.
But that doesn't really explain why your entire Duet shuts down - it may be a good idea to check the wiring around your heated bed again.
Public, what exactly do you mean when you say that the Duet switches off?
Witch switching off, I mean the whole Duet 0.8.5 goes off, just like no power supplied by the ATX PS. I need to restore the power via the in switch.
I use the softswitch Functionality from the duet for the power supply to be able to switch the duet off via web interface.
may be the voltage drops than and switches the ATX off.
I have heatsinks in the drivers (delivered by T3dP3d) and a ~80 mm fan blowing in the PCB and heatsink from the top.
I suspect that the ATX PSU is cutting out due to over voltage on the 5V rail. You may need a greater load on 5V.
Dougal1957 last edited by
You also need to cool the underside of the Board and not just the top as this is where the Stepper drivers Heatsinking actually is there is little point in adding Heatsinks to the Chips themselves
I don't think it's due to the drivers. Are you controlling your ATX power supply using the Duet?
Have a look at Nophead's Mendel90 power supply resistor mods for an idea about adding dummy loads to your power supply.
Thanks all for the valuable feedback.
I will go and replace the bulb "resistor" by a normal one.
I just wanted to raise this point here for the case somebody else suffer similar behavior.
Especially as the PSU works properly until the point I had tightened the rods too hard and
all works again fine after loosen the rods a bit.
I have added a 10 Ohm load resistor to the 5 V rail and putthe 21W car bulb on the 12V rail.
Still having issues the DUET 0.8.5 is switching off. Unregulary during a print but mostly reproduceable when rerunning the
homing all makro together with bed heating.
My bed is heated with 230V using some china SSR. I meassured x and y coordinates when the duet switches of and it looks
like the y coordniate (~ 16,6 cm) is the point where the failure appears.
It might be possible that the cable to the print bed is faulty, but just a broken calbe should make the duet to switch off ?
If the isolation of the 230 V is faulty I would expect the circuit breaker or the house current failure switch will cut power of the room.
I have two more scenarios I want to test.
- Cut off the 230 V supply and have the duet bed heating active ( edit : tested and same issue)
- change the 5 V ATX PS lead from the Duet to a switch , which will override if the duet ATX on has isuses, but if there
is any shortage in the cabling, would that than blow up the duet ?
Over all I can test the same scenario with the Duet Wifi (still have not tested my ordered one) and check if this one switches off also.
Any other case I can test ?
edit : So I tested also having 230 V switched off, I removed the print bed thermistor from the duet and still the duet switches off at nearly the same coordiantes
x ~15.4 cm and y ~ 16.6 cm. As this coordiantes seems to be reproducable (when running homming all continously) I would remove the PS from the faulty part list.
May be I make a special Gcode file moving only x several times and moving only y several times to see if this is related to just one axis.
Try shorting the PS_ON pin to ground so that the Duet can't turn the power supply off. This will not harm the Duet.
I insalled a on/off switch parallel to my push button. But I can not reproduce the switch off condition any more ? .
It sounds more and more like a broken / bad cabling somewhere.
Sorry for being so long quiet, had some issues to reproduce the error again.
I added a switch to the PS_ON signal to gnd (same contacts I use with a push button to start the duet0.8.5 with power)
It seems to work fine, I home all and no issue pops up with permant switched on, now I tested again with the push button and
also no more powering off
I tested for some days now and had only 2 times the board switched off with the push button way.
Today I was printing with using the permanent switch and again, (this time at the beginning of the print , when homing all) the print stopped. This time the board seems to stay switched on (or may be was switched on so fast, that it was not noticeable) at the same location of the print head. The webinterface lost connection to the duet with Ajax timeout.
I could reconnect via the webinterface and it looks like all was reset like a switch on status.
Something is going wrong here
See below what I could get from the Firmware diagonse function (it is saying power up 2 minutes and 40 seconds ago) :
–-------------- ----------------- ----------
Used output buffers: 5 of 32 (8 max)
Program static ram used: 45208
Dynamic ram used: 40344
Recycled dynamic ram: 464
Current stack ram used: 2712
Maximum stack ram used: 4196
Never used ram: 8092
Last reset 00:02:40 ago, cause: power up
Last software reset code & available RAM: 0x0003, 6332
Spinning module during software reset: GCodes
Error status: 0
Bed probe heights: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Free file entries: 10
Longest block write time: 0.0ms
Slowest main loop (seconds): 0.006195; fastest: 0.000183
MaxReps: 0, StepErrors: 0
Heater 1: I-accumulator = -107.2
Move available? no
Stack pointer: 0 of 5
macro is idle
http is doing "M122"
telnet is idle
serial is idle
aux is idle
file is idle
Free connections: 15 of 16
Free transactions: 23 of 24
HTTP sessions: 1 of 8
FTP connections: 0, state 0
Telnet connections: 0, state 0
15:51:58M32 Simply3D/Test/Endstueck mit Support v1.3a.gcode
File Simply3D/Test/Endstueck mit Support v1.3a.gcode selected for printing
15:42:13Bed equation fits points [10.0, 20.0, 1.219] [460.0, 20.0, 1.165] [260.0, 250.0, 1.096]
15:41:18M32 Simply3D/Test/Endstueck mit Support v1.3a-slic3r in 0.2.gcode
File Simply3D/Test/Endstueck mit Support v1.3a-slic3r in 0.2.gcode selected for printing
15:36:15Bed equation fits points [10.0, 20.0, 1.059] [460.0, 20.0, 0.972] [260.0, 250.0, 0.903]
The diagnostics include this:
Last reset 00:02:40 ago, cause: power up
If the 2min 40sec is the time since the print stopped, then this means the power to the Duet was lost briefly.
From the diagnostic output, I think the same.
Whatis iritating, it seems to be nearly allway the same position of the print head and bed.
I would expect if the power supply is faulty, thatthe position will vary …
I will swap the power suply with a different ATX one and see what will hapen.
A strange issue, thanks for your ideas.
Could there be a wire that was shorting at that point causing the power supply to trip?
That would be also my expectation.
The moving wires are the heatbed, but this runs over a SSR and I do not think a short circuit would cause this behaviour over the SSR.
I removed also the bed Thermistor (but did not heat then the bed) and still the issue.
So could be the wires running from top to the printhead carrier. I renewed already the connector to the IR probe, as this looked a bit suspicious.
As it looks as I'm the only one having this issue, it mustbe something with my build ?.
I will be next week on vacation and afterwards I replace the Duet 0.8.5 by the Duet Wifi. Lets see if this changes anything in this behaviour.
It is a pitty that the error occours only from time to time, making trouble shooting much harder.
I will report how it goes.