Posts made by tjhinton

One thing I have found that helps (prevent "short to vin" or "short to ground") is to raise the current of the offending axis slowly before sending any movements. So, for example, I have placed a 200 ms dwell/pause/wait after adjusting it to ~50%, then raising it to 80-100% with another pause after). Still not a explanation/solution, but it works better than anything else I've come up with.

@DocTrucker

Board is grounded along with the frame, but the culprit stepper hasn't ever been truly connected to ground or strapped to the case. I have tried to see a rise in voltage across the motor shaft and frame(ground), and I cannot. For what it's worth, the air in the room is usually >50% RH.

@droftarts

I suspected as much, but I've had this issue with very low inductance motors too (still high current, but less than 2A). Here is an example of one such motor:

WO-417-15-08. Inductance is <1mH, and it has an extremely low detent torque, meant for silent operation.

@oliof

This and the previous board were/are active cooled with a noctua fan that's blowing directly across the back and front of the driver side of the motherboard.

The stepper driver has never reported an overtemp, but I agree - it's a lot to be using. Either way, I had the same issue with lower current motors.

My current suspicion is that I'm damaging the 2209's stallguard circuitry or putting it in a state where it cannot be used for a while.

Update 2. I was fine for a while, but I just swapped in a large motor and set the Y axis driver to 1900 mAmps - and I think I fried the stepper driver, or part of it - stealthchop doesn't work while spreadcycle does. I had zero issues moving the motor around in stealthchop a few times, and found that I needed a very low sensitivity to avoid false stall reports w/ stallguard. I cannot figure out what I'm doing wrong, but I feel like I'm missing something obvious. This is a different duet 3 mini 5+ from the original board (w/ 2 fried drivers). Any input here is greatly appreciated.

XY motors are now both < 3mH inductance

When I tried a 0.7mH motor on the X, it reported a short notification immediately - motor was fine via my fluke multimeter. I can't explain this either. Ditched that motor for a 2.8mH SanMotion 0.9 stepper that has given me zero issues.

I'm running 3.5 rc2

Here's the homing gcode that I think killed the stepper driver:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Homing
G91                    ; relative motion
M400
M913 Y50               ; CURRENT       <<<
M201 Y600              ; acceleration
M566 Y5                ; jerk
M915 P0 S80 F0 H200 R2 ; SENSITIVITY   <<<
M400
;
G1 H1 Y180 F1600       ; home
M18 Y                  ; y off

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Stealthchop Tuning
M569 P0 D2             ; > spreadcycle 
G4 P400                ; wait
M569 P0 D3 V0          ; > stealthchop
M400                   ; (clear)	
M913 Y100              ; > full current
M201 Y3000
M566 Y5 
M17 Y                  ; y on
G4 P400                ; wait to allow driver to initialize parameters
; 
G1 H2 Y-0.1 F600       ; tiny move
G4 P200                ; wait >140ms
G1 H2 Y-18 F4000       ; medium velocity move to y-20 The move needs to be >400steps made at a "medium speed", I think RPM > 10

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Restore Settings
M400 
M913 Y100              ; > full current
M201 Y12000            ; accel
M566 Y600              ; jerk
M915 Y S80 F1 H400 R0  ; set sensitivity and enable reports
M400
G4 P200                ; wait
G92 Y145               ; set y coordinate

Quick update - I tried decreasing the speed of homing on the Y axis, and so far, no more short reports. A sharp stall paired with the Y being a high current 1.8 degree motor that is geared down 1:2 leads me to believe I was back-emf spiking the 2209, causing a short detection. This is mentioned as a concern on page 45/end of section 6.5 in the 2209 datasheet as a possible problem. The motor was set to home at F6000, which would make for I believe 17k usteps/s. To me, this seems like more than is expected for a stallguard 4.0 move. Switching it to half that (F3000) has prevented further short notifications. If another short occurs, I'll follow up.

Just replicated the "short to vin" with a new motor and board using the same y axis home code. I immediately reset the machine, and the driver seems to be ok. The best hypothesis I had was static from belts, but I couldn't measure more than a mV rise with my multimeter on any motor component.

First, my Duet 3 Mini 5+ has lost two of its 2209 drivers to shorts, and I cannot identify the cause. I'm reliably getting "Phase A/B short to VIN" and unresponsive behaviors from drivers 0 and 3. I have ordered a replacement board, but I'm afraid I will ruin another driver or that the drivers were faulty.

The culprit printer is a Cartesian machine using a meanwell 24V supply (23.5V). Pictures of the wiring and the printer are attached. The motors are as follows:

X axis: Moons MS17HA2P4100 (11.2mH inductance: set to 800mA, rated for 1A)
Y axis: StepperOnline 17HS19-2004S1 (3mH inductance: set to 1200mA, rated for 2A) <axis that is shorting
Z axis: Moons unlabeled (integrated leadscrew motor from ~2014) (~9mH inductance: set to 600mA, don't know rating)
E axis: Revo Hemera XS (pancake motor I'm assuming from LDO) (? inductance: set to 500mA, don't know rating)

I printed for a while with zero issues using spreadcycle (was noisy) and stealthchop (was quietish). In the process of setting up sensorless homing/tuning stealthchop and stallguard, I shorted the first driver (3; Y axis). I don't know how I did it, but here is the gcode (y axis homing) that ran immediately before that short:

G91                     ; relative motion

; Stealthchop Tuning
M18 Y                   ;y off
M569 P0.3 S1 D2         ;> spreadcycle 
G4 P200                 ;wait
M569 P0.3 S1 D3 V0	;> stealthchop
M400                    ;   (clear)
M913 Y100               ;> full current
M17 Y 			;y on
G4 P200			;wait to allow driver to initialize parameters
;
G1 H2 Y-0.1 F1000	;tiny move w report
G4 P200			;wait 200ms (>140ms)
G1 H2 Y-18 F4800	;medium velocity move to y-18 w report
G4 P200                 ;wait

; Homing
M400
M913 Y50                ;lower current to y 
M201 Y500               ;lower acceleration
M566 Y60                ;lower jerk
M915 Y S-10 F0 H200 R2  ;set high sensitivity   
;
G4 P200			;wait
G1 H1 Y180 F5000        ;move to Y axis endstop w report
G92 Y170		;set coordinate to Y max
M400
G90                     ;absolute motion
G1 H2 Y165 F1200        ;move away from max to allow X movements

; Restore Settings
M400
M913 Y100               ;% current
M201 Y9000              ;acceleration 
M566 Y900               ;jerk 
M915 Y S10 F1 H400 R0   ;set sensitivity & disable reports

Here is the relevant bit of my config file for motors and such:

; Drives
M569 P0.2 S0 D3 V0                                 ; physical drive 0.2 goes forwards
M569 P0.3 S1 D3 V0                                 ; physical drive 0.0 goes backwards
M569 P0.4 S0 F12 Y5:0 D3 V80                       ; physical drive 0.4 goes forwards
M569 P0.1 S0                                       ; physical drive 0.1 goes forwards
M584 X0.2 Y0.3 Z0.4 E0.1                           ; set drive mapping
M350 X16 Y16 Z16 E16 I1                            ; configure microstepping with interpolation
M92 X177.78 Y177.78 Z400.00 E397                 ; set steps per mm
M566 X900.00 Y900.00 Z1200.00 E120.00             ; set maximum instantaneous speed changes (mm/min)
M203 X19200.00 Y19200.00 Z2400.00 E2400.00         ; set maximum speeds (mm/min)
M201 X9000.00 Y9000.00 Z2400.00 E250.00              ; set accelerations (mm/s^2)
M906 X800 Y1200 Z600 E500 I10                       ; set motor currents (mA) and motor idle factor in per cent
M84 S1                                             ; Set idle timeout

; Axis Limits
M208 X0 Y0 Z-3.5 S1                                   ; set axis minima
M208 X301 Y171 Z180 S0                             ; set axis maxima

; Endstops
M574 X2 S3                                         ; configure sensorless endstop for high end on X
M574 Y2 S3                                         ; configure sensorless endstop for high end on Y
M574 Z1 S3                                         ; configure sensorless endstop for low end on Z
M915 X S3 F1 H400 R2                               ;set sensitivity   
M915 Y S10 F1 H400 R2                              ;set sensitivity 
M915 Z S3 F1 H400 R2                               ;set sensitivity   

After I started getting the "Phase B short to Vin" warning, I suspected the motor and immediately ordered a replacement motor. After getting the replacement, I set up the Y axis on driver 0.0, which was the unoccupied driver. This motor has an integrated harness, so the wires were new too, and I test each harness before connecting to the duet. Same thing happened - that homing code fried the Y axis driver after 3 or 4 runs (motor moved fine).

Second, I have figured out the hard way that the 2209's do NOT like my (relatively) high inductance moons motors on spreadcycle. They are noisy and no set of hysteresis, blanking time, or other variables has rendered them silent. For others who may read this: it is probably best to avoid high inductance motors if you want to print fast and quiet on the 2209's. I have also had a lot of trouble with stallguard with this particular printer; I'm guessing sensitivity settings vary depending on Vin. Maybe the spreadcycle-dependent stallguard on the 2660s (Duet 2) is more resilient to fluctuations induced by loads like a bed heater?

Here is the homing code for the X axis, which has the highest inductance motor: (please note the high sensitivity and low current that I have to use)

G91                     ; relative motion

; Stealthchop Tuning
M18 X			;x off 
M569 P0.2 S0 D2         ; > spreadcycle 
G4 P200                 ; wait
M569 P0.2 S0 D3 V0	; > stealthchop
M400			; (clear)	
M913 X100   		; > full current
M17 X 			; x on
G4 P200			; wait to allow driver to initialize parameters
; 
G1 H2 X-0.1 F1000	; tiny move
G4 P200			; wait >140ms
G1 H2 X-18 F4800	; medium velocity move to y-20 The move needs to be >400steps made at a "medium speed", I think RPM > 10
G4 P200

; Homing
M400
M913 X10              	;lower current to x
M201 X500             	;lower acceleration
M566 X50              	;lower jerk
;M350 X16 I0
M915 X S-50 F0 H200 R2  ;set high sensitivity
;
G4 P200			;wait
G1 H1 X330 F6000 	;home
G92 X300		;set x coordinate to max

; Restore Settings
M400 
M913 X100		;> full current
M201 X9000		;acceleration
M566 X900		;jerk
M915 X S3 F1 H400 R0    ;set sensitivity and disable reports

4 questions:

• Any ideas on what shorted the Y axis twice?

• How can I avoid unreliable stallguard behaviors on the 2209's? (re: current & sensitivity settings in the x homing code)

• How can I use spreadcycle quietly with a moons motor like the MS17HA2P4100? (spreadcycle is noisy)

• Can the spreadcycle performance of the 2209 (duet 3 mini 5) not match the performance of the 2660 (duet 2) in noise?

@Phaedrux

I love this idea! Thank you. Going to try the tandem.

@Phaedrux

I could do that. And I've thought that it would fix my issue. It's not simple to do. But it would mean the edge temp of the bed isn't correct, and it's not addressing the underlying problem - I can't use a bed that's lagging. That should be possible, right? All beds lag to some extent. I'm just outside the tolerance of M303 as is.

@NitroFreak

Image of the machine.

@Phaedrux

For reference, I'm at P1, or 100% PWM. and it's an SSR, so I wouldn't want to PWM it fast anyway for M303, right?

@Phaedrux

Even with an extreme D value, I get "auto tune cancelled because temperature is not falling"

This is because the bed heater turns off, but heat is still diffusing outward toward that peripheral thermistor. There's a delay before the temp starts to drop appreciably.

@Phaedrux

Is that supposed to say D value or P value?

I've set my D value to 600 and had no luck.

@NitroFreak

It is. I've removed the polyjet head from a broken objet and put ... lol ... a prusa i3 mk3s extruder I had lying around on it.

@jens55

The build plate is 330 x 340 x 35mm. Basically solid. Top plate is a milled/ground slab of aluminum with a pocket on its bottom for the heater. The bottom half is the "lifter" plate (also aluminum) and is fixed to 3 leadscrews.

@jens55

"You are W A Y W A Y W A Y under powered. Just as an example, I am using 1200 Watts and I might have maybe 2 kg worth of build plate. While slow and steady may win the race, it will cause you nothing but grief in this situation."

I appreciate your position on this. Unfortunately, it's not really something I can change - this printer is built like a tank, and it's much easier to just make this bed work for my needs. And this machine was designed with plenty of environmental control in mind - it doesn't drop temp when you put a fan on the bed. I don't need more than 60C, and I'm not actually doing much FFF, but I would like the ability to warm the bed to at least 60C with the Duet's firmware.

"There are a couple of things that will catch you right away - generally, the first layer is put down with extra bed temperature. In your case you have zero control over the bed temperature as shutting off the heater will not drop the temperature in a reasonable amount of time."

My understanding is that tuning catches this, assuming you do it right and set up the tune in an appropriately controlled situation - such as in an enclosed print volume.

"Also, you will find that the heater has insufficient power to overcome temperature losses from the environment. It will increase in temperature (slowly) until losses equalize the gains but you might find yourself in a situation where the heater never shuts off because it can never reach set temperature.
Yes you might be able to bypass the safeties but what you have is not workable!"

The build volume is enclosed. Even without the enclosed build volume, I've been printing PLA without issue, but I have to manually override the heating commands to get the bed up to temp - I would like to have the firmware take control for me, as it is designed to do. Thermal losses do not hamper this machine like you might be thinking - I don't entirely know if I'm missing something or not, but the bed is VERY stable with a cooling fan - much moreso than the other 5 machines I have.

I've got an Objet 3D printer that I'm repurposing for FFF. I can't autotune the bed heater because the thermal mass of the bed is too high to respond fast enough for M303. I get "auto tune cancelled because temperature is not increasing" or "auto tune cancelled because temperature is not falling". Realistically, I can expect the bed to heat around .1C/s when it's really going. It does not heat this quick until it's been on for about 5 minutes. It is even slower to cool. Is there a way for me to get around this? Is there a way to make M303 more tolerant on rise/fall rate?

I've tried a gain as low as 60, a C value as high as 10000, and a D of 99; for example:
M307 H0 A60 C10000 D99 B1

More on the printer:
For the build plate, the objet has a 120V 600W silicone heater pad sandwiched between a total of ~20lbs of Aluminum. I have my Duet 3 controlling a 120V SSR to power the bed. A single thermistor is located at the edge of the bed and is screwed into it. The design of this bed was to hit temp slowly and maintain it - it takes 40 min for the bed to passively cool down from 60C without a fan on it. It's also thick enough that it maintains a pretty even temperature across the surface. If you're not familiar with the machine - it's an XY extruder gantry with a bed traveling in the Z.

Curve approximation as straight segments would really be fine if there was hardware accurate/precise enough to create artifacts in FDM prints just from the "error" of microstepping, right? Polyjet machines are amazing because they show stl roughness. We still don't have proper pressure regulation within hotends. Nor do we have common methods for modeling kinematics (which may follow with the dissemination of higher order movement planning in desktop printing platforms). Perhaps a feature like s-curve movements will drive better hardware. It should lift the acceleration/payload and velocity ceilings a bit. I'd like to know if s-curves even match to "advance" behavior in a standard hotend like a titan aero.