Stall detection on Duet 3 Mini

Veti

that explains why i could not get stall detection to work when i tested with -64

mendenmh

Or, to make it more sensible, they have changed from a signed representation on [-64,63] with 63 being least sensitive to an unsigned representation on [0,127] with zero being least sensitive and 127 being most sensitive, with 7-bit math.

gloomyandy

Actually on TMC2209 they have changed the range as well... it runs 0..255 with 255 being most sensitive.

dc42

I've put a new unofficial 3.3beta build of Duet3MiniFirmware.uf2 at https://www.dropbox.com/sh/wme9k0z86sytg33/AAAT6wrHp2eeJHK-dYoW1Um4a?dl=0. This version accepts M915 S parameters between -128 (most sensitive) and +127 (least sensitive) for TMC2209 drivers.

fcwilt

@dc42 said in Stall detection on Duet 3 Mini:

I've put a new unofficial 3.3beta build of Duet3MiniFirmware.uf2 at https://www.dropbox.com/sh/wme9k0z86sytg33/AAAT6wrHp2eeJHK-dYoW1Um4a?dl=0. This version accepts M915 S parameters between -128 (most sensitive) and +127 (least sensitive) for TMC2209 drivers.

Hmm...

So what is wrong with 0 to 255?

Thanks.

Frederick

dc42

@fcwilt said in Stall detection on Duet 3 Mini:

So what is wrong with 0 to 255?

If we change M915 to always accept 0 .. 255, that will break existing Duet 2 and 3 user configurations. In particular, stall homing will fail, which may cause damage to user's machines. Not all users read the upgrade notes.
If we make M915 accept values of -64 .. +63 for Duet 2 and Duet 3 MB6HC, and 255 .. 0 for Duet 3 Mini and tool boards, that will be confusing to users, especially in those systems that have both TMC5160 and TMC2209 drivers.

I may introduce an additional parameter that accepts 0 .. 255 and when it is present is used instead of the S parameter. We would have to map it back to +63 .. -64 when used with TMC2660 or TMC5160 drivers. We could then deprecate the S parameter.

Veti

i kind of like 0 beeing the default in the middle.

because you can make it less - or more + sensitive.

fcwilt

@dc42 said in Stall detection on Duet 3 Mini:

@fcwilt said in Stall detection on Duet 3 Mini:

So what is wrong with 0 to 255?

If we change M915 to always accept 1 .. 255, that will break existing Duet 2 and 3 user configurations. In particular, stall homing will fail, which may cause damage to user's machines. Not all users read the upgrade notes.

If we make M915 accept values of -64 .. +63 for Duet 2 and Duet 3 MB6HC, and 255 .. 0 for Duet 3 Mini and tool boards, that will be confusing to users, especially in those esystems that have both TMC5160 and TMC2209 drivers.

I may introduce an additional parameter that accepts 0 .. 255 and when it is present is used instead of the S parameter. We would have to map it back to +63 .. -64 when used with TMC2660 or TMC5160 drivers. We could then deprecate the S parameter.

Thanks for the edification - that all makes perfect sense.

Frederick

Sotidii

This post is deleted!

carcamerarig

@dc42 What did you end up doing here? For clarity does the Gcode dictionary reflect the changes you made as the thread went cold and no definitive answer?
For my 0.9 LDO motors I have M915 X S-50 F0 H400 R0 on the mini, it homes but im having a hell of a game with motors banging, crashing, thumping however you want to call it. I had some help to try to keep spreadcycle active except for homing but still the bang / layer shift continues.
when I purchased the board @T3P3Tony said the 2209's ran nicely with 0.9's (bit off topic here) but I could seriously do with some help, im on the verge of scrapping it.