Hi,
I hope this is the right subforum for my questions.

There seems to be a problem in my configuration, because I am struggling with MCU overheating and Driver Errors, such as "Error: Driver 0.0 error: phase A short to Vin", which do not really make sense.

I am using high-quality Steppers from IGUS and I got this issue for multiple axes, but maily for 0.0. I am not operating a standard 3d printer/CNC, but another system. In my case, the 0.0 stepper is just spinning a disc with nothing attached to it, no friction or similar, just inertia. So, there is absolutely no strain on it.

This error mostly occurs together with the MCU heating up, which I am not sure why it does that. I reach temperatures of 45-50 degrees easily, before it resets or shows an overheating error (EDIT: I just read that the MCU can withstand 85°C? But I get overheating errors at 50 already, is that normal?) I cannot explain why it gets so hot, because the steppers are not even working most of the time. This happens even when it is just sitting there or just spinning the disc around. The currents should never really exceed 1A. Unfortunately, due to NDA I cannot disclose any details on my setup here in the forum, we'd need to move to Email support for that. My suspicion was that somehow the idle currents are very high, but I have tried to set everything properly and reduce the idle current. I operated the Duet from a lab supply for a bit and checked, and the currents do not seem very high at all, like 300mA during Idle. Also, the motors are all cold.
Everything worked perfectly previously, and then suddenly this issue occured. The wiring is correct, the pins are correct, the internal resistance of both stepper circuits are the same.

Here is an extract from my config.g:

; Smart Drivers
M569 P0 S1 D3 ; driver 0.0 goes backward (X axis)
M569 P1 S1 D3 ; driver 0.1 goes forwards (Y axis)
M569 P2 S1 D3 ; driver 0.2 goes forwards (Z axis)
M569 P3 S1 D3 ; driver 0.3 goes forwards (Z axis)

; Axes
M584 X0.0 Y0.1 Z0.2:0.3 ; set axis mapping
M350 X8 Y1 Z2 I1 ; configure microstepping with interpolation
M906 X1000 Y1200 Z1300 I5 T3; set axis driver currents
M917 X5 Y5 Z5; standstill current reduction
M92  X80 Y40 Z80 ; configure steps per mm
M208 X0:200 Y0:190 Z0:60 ; set minimum and maximum axis limits
M566 X900 Y900 Z900 ; set maximum instantaneous speed changes (mm/min)
M203 X1000 Y1000 Z2000 ; set maximum speeds (mm/min)
M201 X500 Y75 Z40 ; set accelerations (mm/s^2)

; Kinematics
M669 K0 ; configure Cartesian kinematics

; Probes
M558 K0 P5 C"io4.in" H15 F1500 T600 ; configure unfiltered digital probe via slot #0
G31 K0 P10 X0 Y0 Z0 ; set Z probe trigger value, offset and trigger height

; Endstops
M574 X1 P"!io0.in" S1 ; configure X axis endstop
M574 Y1 P"io1.in" S1 ; configure Y axis endstop
M574 Z2 P"io3.in+io2.in" S1 ; configure Z axis endstop

And here is the M122 report:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.4.0 (2022-03-15 18:59:15) running on Duet 3 Mini5plus Ethernet (standalone mode)
Board ID: 09WBW-1S8LU-F65J0-409NY-3013Z-HL3RU
Used output buffers: 3 of 40 (27 max)
=== RTOS ===
Static ram: 103684
Dynamic ram: 106056 of which 0 recycled
Never used RAM 29044, free system stack 154 words
Tasks: NETWORK(ready,25.5%,218) ETHERNET(notifyWait,0.2%,568) HEAT(notifyWait,0.0%,358) Move(notifyWait,0.0%,292) CanReceiv(notifyWait,0.0%,942) CanSender(notifyWait,0.0%,356) CanClock(delaying,0.0%,339) TMC(notifyWait,0.6%,105) MAIN(running,72.8%,511) IDLE(ready,0.0%,29) AIN(delaying,0.8%,264), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:25:05 ago, cause: software
Last software reset at 2025-02-12 14:07, reason: User, GCodes spinning, available RAM 28840, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00461000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU revision 3, ADC conversions started 1506042, completed 1506042, timed out 0, errs 0
Step timer max interval 1488
MCU temperature: min 46.8, current 47.2, max 49.9
Supply voltage: min 23.8, current 23.9, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/24/24, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 2, read errors 0, write errors 0, ifcnt 47, reads 62406, writes 1, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 0, ifcnt 41, reads 62407, writes 1, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 2, read errors 0, write errors 0, ifcnt 40, reads 62406, writes 1, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 12, read errors 0, write errors 0, ifcnt 40, reads 62406, writes 1, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 0, ifcnt 29, reads 62407, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2025-02-12 14:32:10
Cache data hit count 2623384019
Slowest loop: 8.45ms; fastest: 0.13ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 3.9ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 3, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 9, completed 9, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Segments left: 0
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
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== CAN ===
Messages queued 10672, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 18), ts 5929/0/0
Tx timeouts 0,0,5929,0,0,4743 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 11.63ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- Ethernet -
State: active
Error counts: 0 0 0 0 0
Socket states: 5 2 2 2 2 2 0 2

As you can see the temperature is very high, and this is even though I had the board idling for about 15 minutes now, not touching anything. I even sent M18 to shut off the motors.

I would be glad for your help, trying to find a solution. I have the same machine built already with the same components, and no issues there.

Cheers
Tobi

@jay_s_uk Thanks!
This is the MCU temperature. I assumed it would be too high, because I had an error, something like "Overheat error", around the 50C and it shut off. Unfortunately, I am not able to replicate it and I do not remember the precise wording.
However, I feel like at around 50C, it randomly reboots or re-runs the config.g (I can tell, because i have a homeall sequence there, and I hear some sound and then the homing sequence starts off. It is all quite mysterious). This is why I thought, it went into overheat error, and then rebooted itself.

I am using a Mini 5 + btw, which according to a document on the duet docs (I cannot post the link because i need " two reputations") might have trouble with temperature readings. I was not able to view the temperature of the motor controllers.

Wiring issue means that the wires itself are somehow broken? I can be sure that the pins are definetly correct.

@infiniteloop Thanks for the hint! Indeed I was not aware of this. You are right that the PCB is mounted in a way that there is very much restricted airflow in the back. I will make some design changes to allow some airflow in the back there. Do I understand correctly that essentially these areas are the heat dissipation zones?

@droftarts This is interesting. You mentioned that always full current is drawn when a motor is running. This sounds like, if I set the current to, lets say, 1A, and I run the motor at various speeds, it should always draw 1A until it goes into idle? I have noticed that the current draw is often significantly lower than what I have set.
I had some previous issues with a motor stalling, and when I measured, I realized that the current draw was only about half of the current I specified in config. I experimented with increasing the current, and I only reached a full current draw when I set it to 2x the rated peak current of the motor.
Is there any relationship between current draw, load, speed or microstepping? What could be the explanation to this?

@dc42 Thanks. How would you define low speeds and high speeds? I see values between 100 and 4000 in the M569 description, but there is no unit. I had made the observation that there was excessive current draw at very LOW speeds, and that it normalized with higher speeds.

@jay_s_uk I wired the colors to be exactly the same

@jay_s_uk

Perhaps I found something interesting.

I turned the board off and let it cool down a bit. The MCU temperature was very low again. Upon turning on and homing everything, I ran a macro which spins my 0.0 stepper really slowly. To monitor the current, it placed my multimeter on the power in. What surprised me is that I saw a current draw of 1.4A, even with the motor spinning super slowly (F100). After just few seconds, I immediately go the driver overheat error again.
I then changed the speed to F500, ran it again and the current was just about 250mA. Now, I did not observe the overheating error.

The question would now be: Why does it draw so much current when spinning very slowly? Is it a microstepping thing?

Also, the board is advertised with 1.4A, peak 2A. I am surprised that it already shuts off at 1.4A then.

@gloomyandy it should be this model https://www.igus.de/product/MOT-AN-S-060-002-042-L-A-AAAO

I just tried to only spin the x-axis again and this happened immediately:

The only thing I can do is emergency stop, so I can even access anything behind all these error messages. The MCU temp is now 54C. The Duet was idling for about half an hour now. The Stepper driver temp is either 0 or 100C

Driver or MCU do not feel very hot, I can touch them with my hands, I would say maybe 30-40C

@jay_s_uk Thanks!
This is the MCU temperature. I assumed it would be too high, because I had an error, something like "Overheat error", around the 50C and it shut off. Unfortunately, I am not able to replicate it and I do not remember the precise wording.
However, I feel like at around 50C, it randomly reboots or re-runs the config.g (I can tell, because i have a homeall sequence there, and I hear some sound and then the homing sequence starts off. It is all quite mysterious). This is why I thought, it went into overheat error, and then rebooted itself.

I am using a Mini 5 + btw, which according to a document on the duet docs (I cannot post the link because i need " two reputations") might have trouble with temperature readings. I was not able to view the temperature of the motor controllers.

Wiring issue means that the wires itself are somehow broken? I can be sure that the pins are definetly correct.

Hi,
I hope this is the right subforum for my questions.

There seems to be a problem in my configuration, because I am struggling with MCU overheating and Driver Errors, such as "Error: Driver 0.0 error: phase A short to Vin", which do not really make sense.

I am using high-quality Steppers from IGUS and I got this issue for multiple axes, but maily for 0.0. I am not operating a standard 3d printer/CNC, but another system. In my case, the 0.0 stepper is just spinning a disc with nothing attached to it, no friction or similar, just inertia. So, there is absolutely no strain on it.

This error mostly occurs together with the MCU heating up, which I am not sure why it does that. I reach temperatures of 45-50 degrees easily, before it resets or shows an overheating error (EDIT: I just read that the MCU can withstand 85°C? But I get overheating errors at 50 already, is that normal?) I cannot explain why it gets so hot, because the steppers are not even working most of the time. This happens even when it is just sitting there or just spinning the disc around. The currents should never really exceed 1A. Unfortunately, due to NDA I cannot disclose any details on my setup here in the forum, we'd need to move to Email support for that. My suspicion was that somehow the idle currents are very high, but I have tried to set everything properly and reduce the idle current. I operated the Duet from a lab supply for a bit and checked, and the currents do not seem very high at all, like 300mA during Idle. Also, the motors are all cold.
Everything worked perfectly previously, and then suddenly this issue occured. The wiring is correct, the pins are correct, the internal resistance of both stepper circuits are the same.

Here is an extract from my config.g:

; Smart Drivers
M569 P0 S1 D3 ; driver 0.0 goes backward (X axis)
M569 P1 S1 D3 ; driver 0.1 goes forwards (Y axis)
M569 P2 S1 D3 ; driver 0.2 goes forwards (Z axis)
M569 P3 S1 D3 ; driver 0.3 goes forwards (Z axis)

; Axes
M584 X0.0 Y0.1 Z0.2:0.3 ; set axis mapping
M350 X8 Y1 Z2 I1 ; configure microstepping with interpolation
M906 X1000 Y1200 Z1300 I5 T3; set axis driver currents
M917 X5 Y5 Z5; standstill current reduction
M92  X80 Y40 Z80 ; configure steps per mm
M208 X0:200 Y0:190 Z0:60 ; set minimum and maximum axis limits
M566 X900 Y900 Z900 ; set maximum instantaneous speed changes (mm/min)
M203 X1000 Y1000 Z2000 ; set maximum speeds (mm/min)
M201 X500 Y75 Z40 ; set accelerations (mm/s^2)

; Kinematics
M669 K0 ; configure Cartesian kinematics

; Probes
M558 K0 P5 C"io4.in" H15 F1500 T600 ; configure unfiltered digital probe via slot #0
G31 K0 P10 X0 Y0 Z0 ; set Z probe trigger value, offset and trigger height

; Endstops
M574 X1 P"!io0.in" S1 ; configure X axis endstop
M574 Y1 P"io1.in" S1 ; configure Y axis endstop
M574 Z2 P"io3.in+io2.in" S1 ; configure Z axis endstop

And here is the M122 report:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.4.0 (2022-03-15 18:59:15) running on Duet 3 Mini5plus Ethernet (standalone mode)
Board ID: 09WBW-1S8LU-F65J0-409NY-3013Z-HL3RU
Used output buffers: 3 of 40 (27 max)
=== RTOS ===
Static ram: 103684
Dynamic ram: 106056 of which 0 recycled
Never used RAM 29044, free system stack 154 words
Tasks: NETWORK(ready,25.5%,218) ETHERNET(notifyWait,0.2%,568) HEAT(notifyWait,0.0%,358) Move(notifyWait,0.0%,292) CanReceiv(notifyWait,0.0%,942) CanSender(notifyWait,0.0%,356) CanClock(delaying,0.0%,339) TMC(notifyWait,0.6%,105) MAIN(running,72.8%,511) IDLE(ready,0.0%,29) AIN(delaying,0.8%,264), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:25:05 ago, cause: software
Last software reset at 2025-02-12 14:07, reason: User, GCodes spinning, available RAM 28840, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00461000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU revision 3, ADC conversions started 1506042, completed 1506042, timed out 0, errs 0
Step timer max interval 1488
MCU temperature: min 46.8, current 47.2, max 49.9
Supply voltage: min 23.8, current 23.9, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/24/24, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 2, read errors 0, write errors 0, ifcnt 47, reads 62406, writes 1, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 0, ifcnt 41, reads 62407, writes 1, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 2, read errors 0, write errors 0, ifcnt 40, reads 62406, writes 1, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 12, read errors 0, write errors 0, ifcnt 40, reads 62406, writes 1, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 0, ifcnt 29, reads 62407, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2025-02-12 14:32:10
Cache data hit count 2623384019
Slowest loop: 8.45ms; fastest: 0.13ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 3.9ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 3, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 9, completed 9, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Segments left: 0
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
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== CAN ===
Messages queued 10672, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 18), ts 5929/0/0
Tx timeouts 0,0,5929,0,0,4743 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 11.63ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- Ethernet -
State: active
Error counts: 0 0 0 0 0
Socket states: 5 2 2 2 2 2 0 2

As you can see the temperature is very high, and this is even though I had the board idling for about 15 minutes now, not touching anything. I even sent M18 to shut off the motors.

I would be glad for your help, trying to find a solution. I have the same machine built already with the same components, and no issues there.

Cheers
Tobi

@T3P3Tony Thanks Tony, much appreciated!

Hello,

We are using the Duet 3 Mini 5+ Ethernet and need advice on the best connection mode to use with a Raspberry Pi 5. So far, we’ve identified three potential approaches:

Direct USB Mode

• Minimal components required.
• USB connection to the Duet.
• No SD card needed.
• G-code is sent to and executed on the Duet.

Standalone Mode

• Duet operates from an SD card.
• DuetWebControl available.
• Macros and configuration files are stored on the SD card.
• USB connection and G-code execution work similarly to Direct USB Mode.

SBC Mode

• Serial connection between the Pi and Duet.
• Some processing tasks are offloaded to the Raspberry Pi.
• Macros and configuration files are stored on the Pi.
• G-code execution is similar to other modes but requires selecting the serial port.

Questions and Considerations:
We have some restrictions, requirements, and open questions that need addressing:

• SD Card Reliability and Security
  Concern: SD cards could fail, potentially disabling the machine and requiring professional servicing (which we want to avoid).
  Security Concern: Someone might access the SD card, read stored information, or modify settings, which is unacceptable.
• Connection Reliability
  Which connection type (serial or USB) is more reliable for communication?
• SBC Mode and Raspberry Pi Performance
  We already run multiple tasks on the Raspberry Pi.
  How much computing power does SBC mode require? Could it overload the Pi?
• Error Handling and Machine Status Updates
  In SBC mode, the browser interface allows monitoring of machine status and receiving error notifications.
  Are these features (status updates, error notifications) still available in Direct USB Mode or Standalone Mode?
  Is there a way to receive error/machine status notifications proactively, or must we request updates through G-codes?
• Custom Machine Configuration in Direct USB Mode
  How are machine configuration settings saved?
  Is custom firmware compilation required in this mode?
• Ribbon Cable Pin Usage
  We need additional UART and SPI connections from the Raspberry Pi, but the standard ribbon cable blocks all GPIO pins.
  Which pins are used by the ribbon cable?
  Are other UART and SPI connections still available for use?
• Object Model Features
  Are any object model features missing when using Direct USB Mode?

Would you be able to answer our questions and make a suggestion, which mode of operation is most suitable?
Although it would be helpful to understand our whole setup, I can unfortunately not disclose much more information, as we are an industrial customer and information is confidential. We do have an NDA with Duet3d, but I could see on the website that technical support is only given in the forum. Would you be able to also provide individual technical support to us, perhaps in a TEAMS meeting?

Best Regards